What is Model Context Protocol (MCP)?
Definition: An open standard, introduced by Anthropic in late 2024, that lets AI agents and LLMs connect to external tools, data sources, and APIs through one common interface instead of a custom integration per tool. For a GTM Engineer, it's how a coding agent reaches Clay, your CRM, and your enrichment APIs without you writing glue code for each.
The Model Context Protocol (MCP) is a standard for connecting AI applications to outside systems. Anthropic introduced it in November 2024, then opened it up, and it's now supported across a range of clients. The docs describe it as a USB-C port for AI: one connector that plugs an agent into any tool that speaks the protocol. A tool author writes an MCP server once, and every MCP-aware agent can use it. See the spec at Model Context Protocol.
The architecture has three parts. A host is the app the human runs (Claude Code, a chat app, an IDE). A client lives inside the host and opens a connection. A server exposes the actual capabilities: tools to call, data to read, prompts to reuse. The server can be a 50-line script you wrote in an afternoon or an official product from a vendor.
Why a GTM Engineer cares: without MCP, every time you want an AI coding agent to touch Clay, HubSpot, your Postgres database, or an enrichment API, you write a bespoke integration. One agent, one tool, one custom script, repeated for every pair. MCP collapses that into a single interface. Point your agent at a Clay server and a HubSpot server, and it reads and writes both through the same protocol. Both Claude Code and OpenAI Codex support MCP servers (Codex can also run as a server so other agents call it as a tool), so the integrations you set up aren't locked to one vendor's agent.
Transports cover the two cases you'll hit. Stdio runs the server as a local subprocess and pipes JSON over standard input and output. Use it for anything on your own machine: a local database, a file system, a Python script that hits an API with your keys. HTTP (with streaming, which replaced the older HTTP+SSE setup) runs the server as a remote service, which is how hosted vendor servers work.
Vendors ship official servers now. HubSpot exposes contacts, companies, deals, and notes as objects the agent can query and update. Stripe exposes customer lookups, subscriptions, refunds, and invoice history. Notion maintains its own server. So an agent can log a note on a deal or pull invoice history through the same interface it uses for everything else.
A concrete GTM example: your agent reads enriched rows from a Clay table over an MCP server, scores each account against your ICP with an LLM call, then writes the scored accounts and a fit grade back into HubSpot over a second MCP server. Both ends of that workflow run through the same protocol, so you describe the job in plain language instead of wiring two API clients together by hand.
One caution worth taking seriously. An MCP server you don't control can feed text straight into the model's context, including tool descriptions the agent reads before it does anything. A malicious or compromised server can hide instructions there, a prompt-injection vector researchers have documented (one variant is called "line jumping"). The protocol does not authenticate that content for you. Treat servers like dependencies: vet who built them, prefer official or open-source ones you can inspect, and don't connect a random server to an agent that holds your production CRM credentials.