I know of two benefits to MCP over Skills:

- 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.

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.

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.

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 can tightly constrain MCPs and shape the context that is shared back to the Agent.

A skill is, at the end of the day, just a prompt.