What is MCP (Model Context Protocol)?
MCP, the Model Context Protocol, is an open standard that lets an AI agent reach external tools and data through one common interface.
MCP is the plumbing. It answers exactly one question: how does a model reach something that is not in its context window?
MCP and a WorkerKit kit are not alternatives
| MCP | WorkerKit kit | |
|---|---|---|
| What it is | A protocol for reaching a system | A configured worker for one job |
| Decides what may be called | No | Yes, per app at Off, Read or Write |
| Decides who may be contacted | No | Yes, via contact rules |
| Has a schedule | No | Yes |
| Leaves a receipt | No | Yes, every run |
| Uses the other | It is the wiring | A kit's apps are reached this way |
A kit uses MCP-style connections to do its job. Asking whether to pick MCP or a kit is like asking whether to pick HTTP or a website.
What an MCP server exposes
Three kinds of thing, and the distinction matters when designing one:
- Tools: actions the model can call, like
email_searchorcalendar_get_event. Each invocation is one tool call, which is also the unit WorkerKit meters capacity in. - Resources: data the client can read into context, addressed by URI.
- Prompts: reusable templates a user can invoke.
What MCP deliberately does not do
MCP connects. It does not decide, and it does not restrain.
The protocol has no opinion about which of a server's twelve tools a given agent should be allowed to call, which contacts it may email, or whether a draft may be sent rather than saved. Those are policy, and policy sits above the protocol.
That gap is the whole reason the safety layer exists. On WorkerKit it is three things, and all three ship on every plan including Free:
| Layer | Question it answers |
|---|---|
| App firewall | Which apps, and Off, Read or Write? |
| Contact rules | Which people may it see and reach? |
| Redaction | What must never leave, whoever it goes to? |
MCP also has no schedule. A server sits there until something calls it, which is what a worker schedule or a webhook trigger provides.
Both directions on WorkerKit
Worth keeping apart, because "MCP" gets used for both:
Workers use connected apps. Company Knowledge Concierge reaches Drive and SharePoint to answer questions with citations. Engineering Pulse reaches GitHub for its morning digest. You can also register a custom MCP gateway so a worker reaches a system WorkerKit ships no integration for.
A worker can be driven over MCP. An external client can connect to a worker, and the tools it sees reflect exactly that worker's permissions. Narrowing an app to Read narrows what the external client can do too, because the restraint lives with the worker rather than with the caller.
Connect what you already use on the Connected apps page.
When MCP is the wrong tool to reach for
The section above is about what MCP declines to do once you are using it. This is about whether to use it at all, which is a different question and the one people skip.
MCP solves an N by M problem: N clients needing M tools. Its value scales with that product, and at the bottom of the range it is overhead:
| Clients | Tools | Bespoke integrations | With MCP |
|---|---|---|---|
| 1 | 1 | 1 | 1 server, plus protocol |
| 1 | 5 | 5 | 5 servers, plus protocol |
| 5 | 20 | 100 | 25 pieces |
The top row is the case to be honest about. If you control both ends and need one tool for one client, a direct call is simpler, easier to debug, and has fewer moving parts than standing up a server that speaks a protocol so that one caller can use it.
Three other cases where something else fits better:
- The vendor already ships a good SDK and you are one consumer. Wrapping it in MCP adds a hop for a portability you are not using.
- It is data, not an action. Something a run could simply read once does not need a tool call per access.
- The thing you actually lack is a schedule. MCP will not start anything, so if the gap is that nothing runs, the answer is a worker with a schedule or a trigger.
The last one is the common confusion. Teams reach for MCP when the missing piece is autonomy rather than connectivity, and connect a system beautifully to something that still waits to be asked.
FAQ
Is MCP the same as a WorkerKit kit?
No. MCP is an open protocol for connecting an agent to tools and data. A kit is a ready-made worker with an instruction, per-app permissions, memories and a schedule, which runs unattended. A kit uses connections; it is not itself a connection.
Do I need to set up MCP servers to use WorkerKit?
No. The apps a kit needs are connected by signing in to them on the Connected apps page. Custom MCP gateways exist for the case where you want a worker to reach a system WorkerKit does not already integrate.
Does MCP control what an AI agent is allowed to do?
No, and this is the most common misunderstanding. MCP exposes tools; it has no permission model for deciding which agent may call which tool, or which contacts it may reach. WorkerKit adds that layer on top with per-app access levels, contact rules and redaction.
How does MCP relate to skills and plugins?
They stack. MCP is how an agent reaches a system, a skill is how it should use it, a plugin is how both get installed into a client, and a kit is a finished job done unattended.
Are MCP tool calls counted against my plan?
Yes. Every action a worker takes in a connected app is one tool call, and plans cap them daily: 500 a day on Free, 5,000 on Pro, 50,000 pooled on Team. At the cap a worker pauses until the counter resets, then picks its schedule back up.