标签：#mcpllm

The Setup I've been building AI agents that use tools — reading files, running commands, calling APIs. There are two main ways to give agents these tools: MCP (Model Context Protocol) — the new standard everyone's adopting Direct CLI calls — good old command-line execution Everyone says MCP is the future. But nobody talks about the token cost . So I measured it. The Test I built a simple file-reading tool and measured the exact token consumption for each approach: Method Tokens per Call Latency (avg) MCP (structured) ~3,400 tokens 280ms CLI + raw output ~200 tokens 45ms Ratio 17x 6x Why MCP Uses So Many Tokens The overhead comes from three places: 1. Tool Schema in Every Request MCP sends the full JSON Schema of every available tool with each request to the LLM. My simple file-reader schema alone is ~800 tokens. With 10+ tools, that's 8,000+ tokens of schema on every single call. { "name" : "read_file" , "description" : "Read contents of a file at given path" , "parameters" : { "type" : "object" , "properties" : { "path" : { "type" : "string" , "description" : "File path to read" } }, "required" : [ "path" ] } } 2. Structured Response Wrapping MCP wraps every response in a structured envelope with metadata, status codes, and typed content blocks. A simple "file not found" error becomes a 200-token JSON object. 3. Round-Trip Protocol Overhead Each MCP call involves: request → server parse → execute → format response → return → client parse → extract. Each step adds tokens for protocol framing. The CLI Alternative With direct CLI execution: $ cat /path/to/file.txt [ raw file content] That's it. Raw input, raw output. No schemas, no envelopes, no metadata. When MCP Is Worth It Despite the token cost, MCP shines when: You need standardized discovery — agents dynamically finding available tools You're building reusable tool servers — one MCP server serves many agents Security sandboxing matters — MCP's permission model is more granular Team collaboration — shared tool de