I still dont fully understand the point of MCP servers. What do they provide that a skill doesnt? Maybe I've just used too many poorly written ones.
Is there some sort of tool that can be expressed as an MCP and but not as an API or CLI command? Obviously we shouldnt map existing apis to MCP tools, but why would I used an MCP over just writing a new "agentic ready" api route?
- If your agent doesn't have a full Bash-style code execution environment it can't run skills. MCP is a solid option for wiring in tools there.
- MCP can help solve authentication, keeping credentials for things in a place where the agent can't steal those credentials if it gets compromised. MCPs can also better handle access control and audit logging in a single place.
Can you explain the auth part? I feel like auth for an agent is largely a matter of either verifying its context or issuing it a JWT that's scoped to its rights, which I assume is quite similar to how any tools would work. But I'm very unfamiliar with MCP.
I think they’re saying you could start up the mcp and pass it creds/auth for some downstream service, and then the LLM uses the tool and has auth but doesn’t know the creds.
Right. If you're running a CLI tool that is authenticated there's effectively no way to prevent the coding agent from accessing those credentials itself - they're visible to the process, which means they're visible to the agent.
With MCP you can at least set things up such that the agent can't access the raw credentials directly.
Skills are part of the repo, and CLIs are installed locally. In both cases it's up to you to keep them updated. MCP servers can be exposed and consumed over HTTPS, which means the MCP server owner can keep them updated for you.
Better sandboxing. Accessing an MCP server doesn't require you to give an agent permissions on your local machine.
MCP servers can expose tools, resources, and prompts. If you're using a skill, you can "install" it from a remote source by exposing it on the MCP server as a "prompt". That helps solve the "keep it updated" problem for skills - it gets updated by interrogating the MCP server again.
Or if your agentic workflow needs some data file to run, you can tell the agent to grab that from the MCP server as a resource. And since it's not a static file, the content can update dynamically -- you could read stocks or the latest state of a JIRA ticket or etc. It's like an AI-first, dynamic content filesystem.
If you expand your scope a bit from just developer tooling, you’ll notice a lot of scenarios where an agent running somewhere as a service may need to invoke commands elsewhere, in other apps, or maybe provided by a customer in a bring-your-own-MCP setup. In these cases, the harness is not running locally, you don’t have a filesystem to write skills on demand to (or a fixed set of skills is baked into the container), so to get extensibility or updates to tooling, you want something that avoids redeployments. MCP fills that spot.
I built an MCP server various people in our company can use to query our various databases. I can have a service account scoped only to the non-sensitive data, and users only need to have an MCP aware agent on their computer instead of dealing with setting up drivers, DB tools, etc.
You could get pretty far with a set of agent-focused routes mounted under e.g. an /agents path in your API.
There'd be a little extra friction compared to MCP – the agent would presumably have to find and download and read the OpenAPI/Swagger spec, and the auth story might be a little clunkier – but you could definitely do it, and I'm sure many people do.
Beyond that, there are a few concrete things MCP provides that I'm a fan of:
- first-class integration with LLM vendors/portals (Claude, ChatGPT, etc), where actual customers are frequently spending their time and attention
- UX support via the MCP Apps protocol extension (this hasn't really entered the zeitgeist yet, but I'm quite bullish on it)
- code mode (if using FastMCP)
- lots of flexibility on tool listings – it's trivial to completely show/hide tools based on access controls, versus having an AI repeatedly stumble into an API endpoint that its credentials aren't valid for
I could keep going, but the point is that while it's possible to use another tool for the job and get _something_ up and running, MCP (and FastMCP, as a great implementation) is purpose built for it, with a lot of little considerations to help out.
A skill can also act as an abstraction layer over many tools (implemented as an mcp server) to save context tokens.
Skills offer a short description of their use and thus occupy only a few hundled tokens in the context compared to thousends of tokens if all tools would be in the context.
When the LLM decides that the skill is usefull we can dynamically load the skills tools into the context (using a `load_skill` meta-tool).
Yeah, calling itself "the standard framework" doesn't feel right to me, https://github.com/modelcontextprotocol is the home of the actual standard and has a bunch of libraries for this, of which FastMCP is not one.
If I recall correctly, the ‘official’ Python one is a fork of FastMCP v1 (which then removed the attribution, arguably in violation of the original software’s license)
Have FastMCP become the standard sdk? The docs is great, honestly way better than the official website modelcontextprotocol which most if its pages is ”under construction”.
Well it sure took "FastMCP" long enough. And the announcement lands at a time when its looking increasingly like CLI is the preferred method vs MCP. I'm sure in a few months time, even that will be out of date
For MCP servers, there's no need to install a potentially untrusted software on your computer. Remote MCP can do very little harm, a CLI though? You're vulnerable to bad actors or supply chain attacks.
It has a json schema, that’s the main point. It also enforces good documentation by design. No need to get a man page or run the help command, it’s in the context. It can work remotely with authentication.
Most CLI tools have JSON support. Your arguments fall flat pretty short.
I think MCP is fine in an env where you have no access to tools, but you cannot ripgrep your way through an MCP (unless you make an MCP that calls ripgrep on e.g. a repo, which in that case what are you doing).
Whatever you do do not simply put 1 to 1 rest apis to mcp tools. Really think about common workflows users want and make good abstractions for good chunks of work.
Is there some sort of tool that can be expressed as an MCP and but not as an API or CLI command? Obviously we shouldnt map existing apis to MCP tools, but why would I used an MCP over just writing a new "agentic ready" api route?
- If your agent doesn't have a full Bash-style code execution environment it can't run skills. MCP is a solid option for wiring in tools there.
- MCP can help solve authentication, keeping credentials for things in a place where the agent can't steal those credentials if it gets compromised. MCPs can also better handle access control and audit logging in a single place.
With MCP you can at least set things up such that the agent can't access the raw credentials directly.
(Moved from wrong sub)
Also, I run programs on my machine with a different privilege level than myself all the time. Why can’t an agent do that?
Better sandboxing. Accessing an MCP server doesn't require you to give an agent permissions on your local machine.
MCP servers can expose tools, resources, and prompts. If you're using a skill, you can "install" it from a remote source by exposing it on the MCP server as a "prompt". That helps solve the "keep it updated" problem for skills - it gets updated by interrogating the MCP server again.
Or if your agentic workflow needs some data file to run, you can tell the agent to grab that from the MCP server as a resource. And since it's not a static file, the content can update dynamically -- you could read stocks or the latest state of a JIRA ticket or etc. It's like an AI-first, dynamic content filesystem.
There'd be a little extra friction compared to MCP – the agent would presumably have to find and download and read the OpenAPI/Swagger spec, and the auth story might be a little clunkier – but you could definitely do it, and I'm sure many people do.
Beyond that, there are a few concrete things MCP provides that I'm a fan of:
- first-class integration with LLM vendors/portals (Claude, ChatGPT, etc), where actual customers are frequently spending their time and attention
- UX support via the MCP Apps protocol extension (this hasn't really entered the zeitgeist yet, but I'm quite bullish on it)
- code mode (if using FastMCP)
- lots of flexibility on tool listings – it's trivial to completely show/hide tools based on access controls, versus having an AI repeatedly stumble into an API endpoint that its credentials aren't valid for
I could keep going, but the point is that while it's possible to use another tool for the job and get _something_ up and running, MCP (and FastMCP, as a great implementation) is purpose built for it, with a lot of little considerations to help out.
A skill is, at the end of the day, just a prompt.
A skill can also act as an abstraction layer over many tools (implemented as an mcp server) to save context tokens.
Skills offer a short description of their use and thus occupy only a few hundled tokens in the context compared to thousends of tokens if all tools would be in the context.
When the LLM decides that the skill is usefull we can dynamically load the skills tools into the context (using a `load_skill` meta-tool).
In an era where technology exists that can lend the appearance of legitimacy to just about anyone, that kind of statement needs to be qualified.
UPDATE: I was wrong about this, see comment reply. The python-sdk in https://github.com/modelcontextprotocol is a fork of FastMCP.
https://modelcontextprotocol.io/docs/develop/build-server
For client side MCP it's a different story.
I think MCP is fine in an env where you have no access to tools, but you cannot ripgrep your way through an MCP (unless you make an MCP that calls ripgrep on e.g. a repo, which in that case what are you doing).