Every agent project spent 2023 and 2024 writing wrappers. A Python class around the Notion API. A shim around the GitHub client. A slightly different shim around the WordPress REST API. It was tedious, it never quite worked, and everyone rewrote the same code because none of the wrappers were reusable across agents.
Then Anthropic shipped Model Context Protocol in late 2024, and the industry quietly stopped writing wrappers. Not everyone, not everywhere, and the migration isn't done. But the direction is clear enough that a new agent built in 2026 that isn't MCP-first is making a specific choice, not a default one.
Hermes is aggressively MCP-first. So is Claude Desktop, so is Cline, and so is a growing list of everything else. The interesting question isn't whether to adopt MCP — it's what an MCP-first automation actually looks like in practice.
What MCP-first automation actually is
MCP is a standardized way for an LLM-driven agent to talk to external services. Instead of writing a Python client that knows how to call Notion's API and then teaching an agent how to call that Python client, you run an MCP server for Notion. Any agent that speaks MCP can now use Notion. The wrapper is written once, by the server author, and everyone benefits.
MCP-first automation is the pattern of building agents where every external integration is an MCP server. Not most integrations. Every one. Even the ones that would be five lines of Python. The bet is that consistency of interface outweighs the occasional overhead of running one more small server.
Three things separate this from the "hook up a few APIs" pattern that came before. First, discovery is standardized: any MCP client can enumerate a server's tools, prompts, and resources without reading the source. Second, transport is standardized: stdio or HTTP+SSE, not "whatever the SDK author felt like." Third, capability negotiation is a first-class concept — a server declares what it can do, a client declares what it accepts, and neither has to guess.
What the pattern actually does
- Discovers tools on connection. The agent asks the server what it can do, and the server answers with a machine-readable schema. No documentation-scraping. No hardcoded lists.
- Routes tool calls through a uniform interface. The agent never learns Notion-flavored Python; it calls
tool(name, args)and MCP handles the rest. - Isolates secrets at the server boundary. The Gmail MCP server owns the OAuth token. The agent never sees the raw credential — it sees a "send email" tool.
- Sandboxes execution per server. A misbehaving MCP server is contained; it can't reach across into another server's state.
- Registries aggregate available servers. Hermes's Skills Hub added mandatory security scans in v0.17.0, which is one shape a registry can take. Anthropic's own MCP directory is another.
- Approval gates wrap write operations. The agent can propose "delete these three rows," and a human confirms before the server executes. Servers that skip approval on destructive operations are the source of every "agent went off and did something" story that ends up on Twitter.
Why it beats bespoke SDK glue
The old pattern was: pick an API, wrap it, teach one agent how to use the wrapper, discover a bug six months later, fix the wrapper, forget to update the other three agents that depend on it. Repeat for every service.
MCP-first collapses that into: run the server, done. The server is maintained (or not) by its author, and the maintenance concentrates in one place instead of being smeared across every agent that touches the service. When Notion changes an API, one server updates; every downstream agent is fixed automatically. When you switch from GPT to Claude to a local model, none of your integrations break, because the integration surface is the protocol, not the model.
There's also a security dividend that's easy to underweight. In the wrapper era, credentials tended to leak into agent config files, into logs, into the model's context window when the agent quoted its own configuration. MCP servers own their credentials. The agent knows there's a tool called "send email"; it doesn't know the SMTP password, and it can't accidentally quote it.
The cost is real: you're now running N small servers instead of N functions in one process. For a personal automation on a $5 VPS, that's fine. For an enterprise deployment where you want to sandbox and audit each integration separately, it's actually the point.
Where this is being built
Anthropic's MCP announcement named the pattern and provided the reference implementations. Claude Desktop was the first product to speak MCP natively. Claude Code followed shortly after. From there, adoption fanned out fast: Cline (IDE-embedded agent), Aider (terminal coding agent), Continue (editor plugin), Zed (editor with native MCP support), and Hermes on the personal-automation side all speak MCP now.
The registry side is younger. Anthropic's own directory is one option. Hermes's Skills Hub with mandatory security scans is another, aimed specifically at making it safe to install a stranger's MCP server without reading the source first. There will be more, and the interesting competition over the next year is whether one of these registries becomes the default the way npm did for JavaScript, or whether the space stays fragmented.
On the server side, the ecosystem is broad already. There are official or well-maintained MCP servers for GitHub, GitLab, Slack, Notion, Google Drive, Google Calendar, Gmail, Postgres, SQLite, Puppeteer, filesystem access, and dozens of vertical-specific ones. Not all of them are good. Some are official, some are community, some are one weekend of work by someone who wanted a quick win.
How to evaluate a solution
Six checks before you install an MCP server into a workflow that matters.
Which version of the MCP spec does the server support? The protocol is moving. A server pinned to an old spec version may miss features (structured output, resource updates) that your agent expects.
How does it handle secrets and OAuth? Read the source. Look for whether tokens are stored on disk, in memory, in an environment variable, or in a keychain. "Environment variable" is fine for personal use. "Plaintext on disk in the home directory" is a red flag.
Is the server sandboxed? A filesystem MCP server that can read anything the user can read is convenient and dangerous. Look for scoping — can you constrain it to a directory, a project, a namespace?
What are the rate-limit and cost implications per tool? An MCP server calling a paid API doesn't automatically show up in your usage dashboards. Ask how you'll know when a runaway agent has spent $200.
Are write operations gated? For any server that touches production data — a database, a live site, a customer's calendar — the write operations should require confirmation, not just be exposed as tools.
What's the security scan or audit process? Registry-scanned servers are safer than unscanned ones. Vendor-published servers are safer than community ones. If neither applies, read the source. Every install of an unaudited MCP server is a trust decision.
MCP is not magic. It's a protocol that saved the ecosystem from writing the same SDK wrapper a thousand times. That's enough.