{"course":{"slug":"agents-and-automation","title":"Agents and Automation","url":"https://addaly.com/learn/agents-and-automation","level":"intermediate","track":"build"},"lesson":{"slug":"mcp-and-tool-standards","title":"MCP, and why a standard for tools matters","url":"https://addaly.com/learn/agents-and-automation/mcp-and-tool-standards","position":55,"of":72,"minutes":8,"answer":"A tool standard removes integration work; it does nothing about whether the model chooses tools well.","keyIdea":"A tool standard removes integration work; it does nothing about whether the model chooses tools well."},"body":{"format":"markdown","text":"## The N times M problem\n\nYou have six agents. Your company runs nine systems: Jira, Postgres, Google Drive, Slack, a CRM, a warehouse API, and so on. Without a standard, that is potentially fifty-four integrations, each written against a particular framework's tool format. Rewrite the agent in a different framework and you rewrite all nine connectors.\n\nThis is the same problem editors had with language tooling. Every editor needed a plugin for every language: N times M. The Language Server Protocol collapsed it into N plus M (write one server per language, one client per editor) and it stuck, because the underlying pain was real.\n\nMCP (Model Context Protocol) is the same move for tools. Anthropic released it in late 2024 and it has since been adopted well beyond Anthropic. It defines a JSON-RPC conversation between a **client** (your agent or app) and a **server** (something exposing capabilities). The server advertises its tools with names, descriptions and schemas. The client asks for that list, hands it to the model as ordinary tool definitions, and when the model requests one, the client calls the server.\n\nWhat you get for that: **the integration is written once and works in any MCP client.** A Postgres server someone published works in your custom loop, in an IDE, in a desktop app. That is the entire value proposition, and it is large.\n\n## What it explicitly does not do\n\nThis is where people get disappointed, so let us be direct.\n\n**It does not make the model use tools well.** A badly-described MCP tool is a badly-described tool. Everything from lesson two still applies, and now the description was written by a stranger who did not have your use case in mind.\n\n**It does not solve your context problem; it usually worsens it.** Connect four servers and you may inject seventy tool definitions into every single request. Teams regularly find their agent got *worse* after adding servers, and are puzzled, because adding capability is supposed to help. It is the same problem as before: past roughly twenty tools, selection accuracy falls, and the failure is quiet.\n\n**Auth is the messy part.** Getting credentials safely from a user, through a client, into a server that acts on their behalf has been the least settled area of the spec and the most common source of real security mistakes.\n\n**The model does not know MCP exists.** This is worth saying plainly, because it is a common confusion. The model sees ordinary tool schemas that the client rendered for it. MCP is plumbing between your code and a server. It never reaches the model.\n\n## Being honest about churn\n\nThe ecosystem is young and it moves. The transport has already changed once (server-sent events gave way to streamable HTTP). Servers you install today may need updating. Some published servers are excellent; many are a weekend project with no error handling, which matters enormously given that error strings are your agent's only feedback.\n\nNone of that means avoid it. It means: pin versions, read the server's source before granting it credentials, and expect maintenance. The direction (a shared interface between models and tools) is not going away, because N times M is not going away.\n\n## Practical rules\n\n1. **Connect the fewest servers that do the job.** Not the most impressive set.\n2. **Filter the tool list.** Most clients let you enable a subset. Expose eight tools from a server that offers thirty.\n3. **Read descriptions before trusting them.** If a server's tool descriptions are one-liners, your agent will misuse them, and you can often override.\n4. **Treat a third-party server as untrusted code with network access.** Because that is what it is."},"check":{"question":"A team replaces six hand-written tools with four MCP servers (GitHub, Postgres, Slack, filesystem), roughly seventy tools in total. The agent's task success rate drops noticeably. What is the most likely cause?","options":[{"text":"The model now selects from seventy definitions instead of six, and picking correctly got harder: the protocol standardised access, not selection.","correct":true},{"text":"MCP servers add a protocol hop and are slower than direct API calls, so more runs hit timeouts partway through.","correct":false,"tempting":"Assumes the bottleneck is latency; round trips do get slower, but that produces slow runs, not wrong answers."},{"text":"General-purpose servers lack the domain logic the hand-written tools encoded, so the servers need forking.","correct":false,"tempting":"Sometimes true, but assumes the drop is about what tools can do rather than how many there are, and forking four servers is a heavy fix for a selection problem."},{"text":"The model was not trained on MCP's schema format, so it misreads the tool definitions coming from servers.","correct":false,"tempting":"Imagines the model sees the protocol; it only ever sees ordinary tool schemas the client rendered, identical in form to hand-written ones."}]},"prev":{"slug":"composing-patterns","title":"Joining two automations without joining their failures","url":"https://addaly.com/learn/agents-and-automation/composing-patterns"},"next":{"slug":"writing-an-mcp-server","title":"Writing a small MCP server","url":"https://addaly.com/learn/agents-and-automation/writing-an-mcp-server"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'MCP, and why a standard for tools matters', in Agents and Automation. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/agents-and-automation/mcp-and-tool-standards (Accessed: 31 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"MCP, and why a standard for tools matters","courseTitle":"Agents and Automation","module":{"index":7,"slug":"shipping-and-operating","title":"Shipping it, and keeping it alive"},"answer":null,"keyIdea":"A tool standard removes integration work; it does nothing about whether the model chooses tools well.","hero":{"kind":"plate","image":null,"alt":null,"caption":null},"blocks":[{"t":"h2","id":"the-n-times-m-problem","runs":[{"text":"The N times M problem"}]},{"t":"p","runs":[{"text":"You have six agents. Your company runs nine systems: Jira, Postgres, Google Drive, Slack, a CRM, a warehouse API, and so on. Without a standard, that is potentially fifty-four integrations, each written against a particular framework’s tool format. Rewrite the agent in a different framework and you rewrite all nine connectors."}]},{"t":"p","runs":[{"text":"This is the same problem editors had with language tooling. Every editor needed a plugin for every language: N times M. The Language Server Protocol collapsed it into N plus M (write one server per language, one client per editor) and it stuck, because the underlying pain was real."}]},{"t":"p","runs":[{"text":"MCP (Model Context Protocol) is the same move for tools. Anthropic released it in late 2024 and it has since been adopted well beyond Anthropic. It defines a JSON-RPC conversation between a "},{"text":"client","b":true},{"text":" (your agent or app) and a "},{"text":"server","b":true},{"text":" (something exposing capabilities). The server advertises its tools with names, descriptions and schemas. The client asks for that list, hands it to the model as ordinary tool definitions, and when the model requests one, the client calls the server."}]},{"t":"p","runs":[{"text":"What you get for that: "},{"text":"the integration is written once and works in any MCP client.","b":true},{"text":" A Postgres server someone published works in your custom loop, in an IDE, in a desktop app. That is the entire value proposition, and it is large."}]},{"t":"h2","id":"what-it-explicitly-does-not-do","runs":[{"text":"What it explicitly does not do"}]},{"t":"p","runs":[{"text":"This is where people get disappointed, so let us be direct."}]},{"t":"p","runs":[{"text":"It does not make the model use tools well.","b":true},{"text":" A badly-described MCP tool is a badly-described tool. Everything from lesson two still applies, and now the description was written by a stranger who did not have your use case in mind."}]},{"t":"p","runs":[{"text":"It does not solve your context problem; it usually worsens it.","b":true},{"text":" Connect four servers and you may inject seventy tool definitions into every single request. Teams regularly find their agent got "},{"text":"worse","i":true},{"text":" after adding servers, and are puzzled, because adding capability is supposed to help. It is the same problem as before: past roughly twenty tools, selection accuracy falls, and the failure is quiet."}]},{"t":"p","runs":[{"text":"Auth is the messy part.","b":true},{"text":" Getting credentials safely from a user, through a client, into a server that acts on their behalf has been the least settled area of the spec and the most common source of real security mistakes."}]},{"t":"p","runs":[{"text":"The model does not know MCP exists.","b":true},{"text":" This is worth saying plainly, because it is a common confusion. The model sees ordinary tool schemas that the client rendered for it. MCP is plumbing between your code and a server. It never reaches the model."}]},{"t":"h2","id":"being-honest-about-churn","runs":[{"text":"Being honest about churn"}]},{"t":"p","runs":[{"text":"The ecosystem is young and it moves. The transport has already changed once (server-sent events gave way to streamable HTTP). Servers you install today may need updating. Some published servers are excellent; many are a weekend project with no error handling, which matters enormously given that error strings are your agent’s only feedback."}]},{"t":"p","runs":[{"text":"None of that means avoid it. It means: pin versions, read the server’s source before granting it credentials, and expect maintenance. The direction (a shared interface between models and tools) is not going away, because N times M is not going away."}]},{"t":"h2","id":"practical-rules","runs":[{"text":"Practical rules"}]},{"t":"ol","start":1,"items":[[{"text":"Connect the fewest servers that do the job.","b":true},{"text":" Not the most impressive set."}],[{"text":"Filter the tool list.","b":true},{"text":" Most clients let you enable a subset. Expose eight tools from a server that offers thirty."}],[{"text":"Read descriptions before trusting them.","b":true},{"text":" If a server’s tool descriptions are one-liners, your agent will misuse them, and you can often override."}],[{"text":"Treat a third-party server as untrusted code with network access.","b":true},{"text":" Because that is what it is."}]]}],"check":{"question":[{"text":"A team replaces six hand-written tools with four MCP servers (GitHub, Postgres, Slack, filesystem), roughly seventy tools in total. The agent’s task success rate drops noticeably. What is the most likely cause?"}],"options":[{"text":[{"text":"The model now selects from seventy definitions instead of six, and picking correctly got harder: the protocol standardised access, not selection."}],"correct":true,"tempting":null},{"text":[{"text":"MCP servers add a protocol hop and are slower than direct API calls, so more runs hit timeouts partway through."}],"correct":false,"tempting":[{"text":"Assumes the bottleneck is latency; round trips do get slower, but that produces slow runs, not wrong answers."}]},{"text":[{"text":"General-purpose servers lack the domain logic the hand-written tools encoded, so the servers need forking."}],"correct":false,"tempting":[{"text":"Sometimes true, but assumes the drop is about what tools can do rather than how many there are, and forking four servers is a heavy fix for a selection problem."}]},{"text":[{"text":"The model was not trained on MCP’s schema format, so it misreads the tool definitions coming from servers."}],"correct":false,"tempting":[{"text":"Imagines the model sees the protocol; it only ever sees ordinary tool schemas the client rendered, identical in form to hand-written ones."}]}],"order":[3,1,0,2],"why":null},"prev":{"slug":"composing-patterns","title":"Joining two automations without joining their failures","minutes":9},"next":{"slug":"writing-an-mcp-server","title":"Writing a small MCP server","minutes":10}}}