The Model Context Protocol (MCP) gives an LLM a typed list of tools to call. Tools are described with JSON Schema; the LLM picks which tool to invoke based on the user’s request. It is a small, well-scoped specification — and that smallness is the point.
Wire MCP to an inbox and you can ask Claude to "read the morning emails, draft replies to the easy ones, and tell me what to do with the rest". The LLM calls the read-inbox tool, then the draft-reply tool. That is the easy part.
What MCP gives you
- A typed transport. Tools are JSON-Schema-described; an LLM client can introspect the surface and call the right tool with the right arguments.
- A standard handshake. Any MCP-aware client (Claude Desktop, Cursor, ChatGPT, n8n) can drive the server without bespoke glue.
- A clean separation. The LLM does reasoning; the server does work. The protocol does not specify how either is implemented.
What MCP deliberately leaves out
- Identity. MCP does not say who the server is acting as. That is your problem.
- Permissions. The protocol does not enforce scopes; tools can claim to do anything.
- Audit. There is no built-in concept of "who approved this action".
- Approval flow. Human-in-the-loop is not in the spec.
- Email plumbing. Connecting Gmail, Outlook, IMAP, or a fresh dedicated address is your code, not the protocol’s.
These omissions are correct. MCP is a protocol, not a product. But they mean a vanilla MCP-server-on-an-inbox skips the parts that take months: identity, audit, approvals, mailbox provisioning.
Where Helix sits
Helix is the opinionated bundle. The MCP endpoint is one of three driving surfaces (alongside REST and webhooks). Behind the endpoint sits an identity object, an approval queue, an audit log, and the mailbox abstraction over Gmail / Outlook / fresh agent inbox. The same identity persists across LLM clients and sessions.
The trade-off is shape. A vanilla MCP server lets you do anything; Helix lets you do "agent identity with approval" with no setup. If you only need a couple of bespoke tools, ship a vanilla MCP server. If you need an agent that sends email on someone’s behalf with audit and approval, Helix saves you months.
A practical pattern
Many teams run both. A bespoke MCP server exposes domain-specific tools (CRM, support tickets, billing). It calls Helix over the REST API to send mail and book meetings. The agent has one identity in Helix; the bespoke MCP server is just another driver of that identity. Approval flow, audit log, and mailbox plumbing live in Helix; domain logic lives in your code.
That layering is what makes MCP useful in practice. The protocol is a transport; the identity is the product.