What is the Model Context Protocol (MCP)?

The Model Context Protocol is an open standard for connecting AI systems to external tools, data sources, and services. It solves the integration problem that has fragmented every agent framework until now.

The problem it solves

Before MCP, every agent framework invented its own tool integration. A connector written for framework A did not work with framework B. If you wanted your agent to use GitHub, Docker, or Stripe, you wrote glue code for your specific stack, and rewrote it when you switched.

MCP standardizes the contract. A tool integration written once, as an MCP server, works with any MCP client: Claude Code, Cursor, Devin, Antigravity, Kilo, Gemini CLI, Cline, VS Code, or your own agent. The protocol specifies how clients discover tools, invoke them, read resources, and render prompt templates. It says nothing about which agent framework sits on either end.

The three primitives

MCP defines three things a server can expose:

1. Tools: functions the model can invoke, with a name, a description, and a JSON schema for parameters. A tool might be "create a GitHub issue" or "query the database."
2. Resources: addressable content the server exposes, listed and read by URI. A resource might be a document, a file, or a database schema description.
3. Prompts: reusable message templates with arguments, so an external agent can trigger a structured interaction ("summarize this document") without knowing internal structure.

The two transports

• Stdio: the MCP server runs as a subprocess on your machine, communicating over standard input and output. This is how local tool integrations work: GitHub CLI, Docker, Playwright, file access.
• HTTP: the MCP server runs remotely and is reached over the network, with OAuth flows available for authenticated servers. This is how cloud services like Stripe and Notion integrate.

Client and server roles

The useful mental model is USB: any client can plug into any server. Your agent (client) connects to 30 tools (servers), and any tool you build (server) can be used by every client in the ecosystem. The roles compose in both directions, which is where the network effect comes from: more clients make server-building worthwhile, and more servers make every client more capable.

VIMS speaks it in both directions

VIMS is both an MCP client and an MCP server (Blog 05: MCP Connectors):

• As a client, it ships 30+ pre-configured connectors (GitHub, Stripe, Cloudflare, Playwright, Notion, Linear, Jira, Docker, AWS) with command allowlisting on stdio servers and URL validation against SSRF on HTTP servers.
• As a server, it exposes the entire VIMS toolset (files, agents, channels, chat, drive, database, knowledge base, schedule, meetings, micropayments) to any external MCP-compatible agent, so an agent running in Claude or Cursor can drive VIMS.
• Flow nodes can invoke MCP tools directly, so any connector becomes an automation step (Blog 11: Flow and Teams).

Security is enforced at the transport layer rather than trusted to the model: an allowlisted stdio connector cannot spawn anything off its list, and every outbound HTTP URL is checked against allowlist patterns. A prompt-injected agent cannot bypass either check (Blog 03: Security First).

To browse the connector catalog, see the MCP surface.