MCP: when to use it (and when you shouldn't)

MCP has become the standard to connect agents with external tools, but it's not always the right tool. Learn what MCP is, how it works, and a simple rule for when to use it and when a CLI, function, or skill does the job better.

Ramses Mata

Associate Developer Advocate at AWS

Published Aug 5, 2026

Last modified Aug 5, 2026

If you've been adding tools to your AI agent lately, somebody probably told you to just wrap everything in MCP. And look, MCP is great. It's becoming the standard way agents talk to the outside world. But here's something not everyone really tells you. Sometimes MCP is actually the wrong tool for the job, and a lighter option does better.
So in this post I want to show you what MCP actually is, how it works behind the scenes, and more importantly, when you should reach for it and when you shouldn't. By the end you'll have a simple rule for deciding, instead of defaulting to "put it in MCP" every time.
The problem MCP is actually solvingBefore we talk about when to use it, let's talk about the problem it solves, because that's where a lot of the confusion comes from.
Think about how many AI agents exist today. Claude, Kiro, Cursor, and also any custom agent you can build with a framework or SDK like  Strands Agents . Now think about all the tools you might want to plug them into. GitHub, Slack, your database, your docs.
Without a standard, every single agent needs its own custom integration for every single tool. If you had five agents and ten tools, that's fifty integrations somebody has to build and keep alive. And if a new agent comes out tomorrow, you start all over again. This is usually called the N by M problem, and it's the same headache we had with phone chargers before USB-C. Every brand had its own cable, and losing one meant hunting down that exact model again.
This diagram makes the difference obvious. On the left, every agent wires up to every tool on its own. On the right, MCP sits in the middle and everything connects through it.
﻿
Notice that the problem here is fragmentation, not that the model is outdated. That distinction matters, because it tells you what MCP is really for.
What is MCPThis is exactly the problem MCP solves. MCP stands for Model Context Protocol, and the easiest way to think about it is like USB-C, but for AI agents.
Then USB-C showed up and one cable just worked with everything. MCP is that same idea for agents. It's an  open protocol , so if you build a tool that speaks MCP, any agent that also speaks MCP can use it. You build it once, and it works everywhere. That's why the whole industry picked it up so fast, it killed a real, expensive problem.
How it worksSo how does this actually work? There are three pieces to keep in mind.
On one side you've got your agent, the AI app you're working in, like Kiro or Claude. On the other side there's the server, the tool out there in the world. And in between there's the client, which is the part that actually speaks the MCP protocol. Your agent uses the client to reach the server.
Here's the flow, step by step:
When the agent starts up, its client connects to the server and basically asks, "hey, what can you do?"
The server answers back with its list of capabilities.
Those capabilities get handed to the model as part of its context, so now your agent knows what's available.
When you ask something, the model decides whether one of those capabilities can help.
If it picks one, the client runs the actual call to the server.
The server does the work and sends the result back.
That result goes to the model so it can put together your answer.
Here's that whole exchange in one picture:
﻿
The key thing to sit with is step 4. You don't program when each tool runs, the model decides. You just make the capabilities available, and the model reaches for them when it thinks they help. How well it does that depends on how capable your model is. Smaller models struggle more, and even with capable ones, asking explicitly ("use the docs server for this") tends to give you more consistent results.
Seeing it in actionLet's make this concrete. I'll connect the AWS MCP Server, part of the  Agent Toolkit for AWS , to Kiro CLI. It's a managed server AWS maintains that, among other things, lets the agent search the official docs in real time.
One thing worth knowing, even if we won't lean on it here. This same server can also interact directly with AWS, calling APIs across 300+ services to actually create, read, or change resources. That part uses your AWS credentials to sign each request, so you'd need them configured locally. The documentation search we're using in this demo doesn't need any of that, so you can try it without logging in. We're staying on the docs side to keep the example simple, but it's worth knowing the API access is there, because it's a big part of what makes this server useful.
First, without MCP. I asked an older model how to log in to the AWS CLI, and it answered from memory with a few options. They work, but they're a bit outdated and have some friction, especially for someone just starting in the cloud.
﻿
Now with the AWS MCP Server connected. Same question. Watch what it does. It asks for permission to use a tool, goes out and searches the documentation, reads the pages it needs, and comes back with an answer. This time the top recommendation is  aws login , the current, simpler and safer way to do it, pulled straight from the live docs instead of whatever it remembered from training.
﻿
I didn't write any integration, and I didn't teach it where the docs live. I just pointed it at a server, and then my agent could reach live, up-to-date information straight from the source. Connecting it is just a config file. In Kiro CLI it lives at  .kiro/settings/mcp.json  for a single project, or  ~/.kiro/settings/mcp.json  if you want it available everywhere.
JSON
{
  "mcpServers": {
    "aws": {
      "command": "uvx",
      "args": [
        "mcp-proxy-for-aws@1.6.4",
        "https://aws-mcp.us-east-1.api.aws/mcp",
        "--metadata", "AWS_REGION=us-west-2"
      ]
    }
  }
}
You'll need  uv  installed, and AWS credentials configured locally for anything that hits AWS APIs (documentation search works without them). This setup can change over time, so always check the  Agent Toolkit for AWS docs  when you set it up. Once it's saved, run  kiro-cli , type  /mcp  to confirm the server loaded, and  /tools  to see what it exposes.
But not always: the hidden costOkay, so MCP looks like a superpower. Why wouldn't you use it for everything? Here's the part not everyone mentions.
Remember how the server hands all of its capabilities to the model as context? Those descriptions sit inside the model's context window, which is the limited space the model has to think. And they sit there whether the model uses them or not.
Every single turn of the conversation, that whole context window gets sent to the model again, from scratch. The model doesn't remember the last turn on its own, so everything gets resent each time. So if you've loaded up a bunch of big servers with tons of tools, you're paying to resend all those tool descriptions on every message, even the ones you never touch. That's more tokens, more cost, and a slower response.
For one big reusable capability, that overhead is absolutely worth it. For a single, simple task, it often isn't.
When to use whatSo here's the decision tree I'd give you.
Reach for MCP when:
The capability is something you want to reuse across different agents. You build the integration once instead of rewriting it for each one.
It's a remote service that needs real authentication. MCP gives you a clean, standard way to handle that connection.
Reach for a lighter option when it's a single, simple job:
A plain CLI command the agent can run.
A small function you write directly.
A quick API call.
A skill, which bundles instructions for the agent and only loads when it's actually needed, so it doesn't sit in your context the whole time.
The rule of thumb is simple. MCP for capabilities you reuse across agents or reach remotely, lighter options for one-off jobs. MCP is a great tool. It's just not the only tool, and knowing when to use which is what makes you better at building agents.
Frequently asked questionsDoes adding an MCP server slow down my agent?It can, if you add a lot of them. Every connected server loads its tool descriptions into the context window, and that gets resent every turn. A couple of focused servers are fine. A dozen heavy ones will cost you tokens and latency.
MCP or a skill, what's the difference?An MCP server exposes capabilities (tools, data, prompts) over a protocol, and its descriptions live in context the whole session. A skill bundles instructions and only loads when it's relevant, so it doesn't take up context when you're not using it. For something you reach for occasionally, a skill is often the lighter choice.
Do I have to build my own MCP server?Almost never. There are already tons of ready-made servers, for GitHub, PostgreSQL, Slack, your filesystem, and many AWS services. Search for the tool you want and check whether it already speaks MCP before building anything.
RecapMCP kills fragmentation. You build the integration once and any compatible agent can use it.
It works with a client and a server, and the model decides when to use a capability, you don't program it.
MCP has a real cost. Tool descriptions live in the context window and get resent every turn.
Reusable, shared, or remote points to MCP. Simple and one-off points to a lighter option like a CLI, a function, or a skill.
Next time someone tells you to just put everything in MCP, you'll know when that's the right call and when it isn't. Have you hit a case where a simpler alternative beat an MCP server? I'd love to hear it in the comments.