A common manual pattern looks like this: copy data from a CRM, paste it into ChatGPT or Claude, ask a question, then copy the answer back into the system where the work happens.
This works. It's also slow, error-prone, and doesn't scale. The AI's answer is only as good as what you remembered to paste.
Model Context Protocol (MCP) is an open standard created by Anthropic in 2024 and now governed through the Agentic AI Foundation under the Linux Foundation. It gives AI applications a consistent way to connect to approved tools and data sources instead of relying on manual copy-pasting.
Related reading (MCP in the physical world, on-device context, and control planes)
Recent posts in this cluster show how different MCP surfaces solve different jobs: Google Home MCP for authorized smart-home state and actions; LUCI local MCP for on-device screen recall without desktop control; MCP gateway inline enforcement for proxy policy before `tools/call` runs; and Cua Driver for background window-targeted computer use over MCP.
The simple version
Without MCP: "Here's our CRM data [paste 2000 words of text]. Now tell me which leads are most likely to close this quarter."
With MCP: "Which leads are most likely to close this quarter?" The AI application can invoke an approved CRM tool, retrieve current data, and use it as context for an answer.
The difference matters more when you're doing this dozens of times a day, or when the answer requires cross-referencing data from multiple systems.
How it actually works
MCP uses three roles. The host is the AI application (for example Claude Desktop or an IDE). The host creates a client for each MCP server it uses. The server is the program that exposes approved tools, resources, and reusable prompts to that client.
A CRM server might define tools such as "get lead by ID," "list open opportunities," or "update appointment status." When you ask a question, the host can select an available tool, request your approval where appropriate, call it through the MCP server, and pass the result back to the model as context. Servers can run locally or remotely. Where data travels depends on the host application, model provider, deployment, and configuration, not MCP alone. The official MCP architecture guide explains these roles in more detail.
A compatible host can connect to multiple MCP servers at once (for example, one for a CRM and another for accounting) and make their approved capabilities available together. Which systems and actions are available still depends on the host, permissions, and server configuration.
What the current protocol revision changes for builders
The current protocol revision is protocolVersion `2026-07-28`. The practical changes for builders are versioning, discovery, transports, and which client primitives still apply.
MCP is largely stateless now. Each request carries the protocol version and the capabilities relevant to that request in its `_meta` field, so the server can handle the request without relying on a long-lived session handshake as the whole story. Servers must implement `server/discover`. Clients may call it first to learn supported versions, capabilities, and identity, or they can invoke a request directly and handle a version error if the sides disagree. See the architecture section on statelessness and discovery.
Transports stay the same two standard options: stdio for a local subprocess, and Streamable HTTP (HTTP POST, optional SSE) for remote or shared deployments. For the trade-offs between local and remote setups, read local vs. remote MCP servers.
Sampling is deprecated as of `2026-07-28`. New implementations should call LLM provider APIs directly instead of asking the host to complete model samples over MCP. Elicitation remains: servers can still request additional user input when a step needs confirmation or missing details. Production work still needs deliberate authentication, authorization, and human approval for sensitive actions. Protocol features do not replace those controls. For hardening patterns, see securing a production MCP server.
What this looks like in practice
Real estate team example: an agent asks their AI assistant "show me all leads from Zillow this week that haven't been contacted." An approved MCP tool queries Follow Up Boss, filters by source and last-contact date, and returns a list. The agent then asks for follow-up drafts. If the deployment includes a permitted write tool, the agent can review and approve the messages before they are sent. Logging must be designed into the host, server, or downstream system; MCP does not add it automatically.
Healthcare example: a clinic manager asks "which appointments scheduled for tomorrow haven't confirmed?" A server can query the EHR within the user's authorized scope and return the relevant schedule. An approved reminder workflow can then prepare or send messages according to the practice's permissions, policies, and review rules.
No tab switching. No copy-pasting. No asking the AI to "pretend" it has data it doesn't have.
What production use requires
MCP is evolving quickly. A production server still needs deliberate authentication and authorization, least-privilege access, data minimization, input and output validation, failure handling, and audit controls appropriate to the systems it touches.
I've built and maintain multiple MCP servers, including an open-source Vertex AI server with more than 80 GitHub stars. That work informs how I scope schemas, permissions, error handling, and deployment for business integrations. See my custom MCP server development service for details on how this works in practice. Related reading: lessons from building seven MCP servers.
Is it worth it?
For teams where people frequently switch between AI tools and other software to get answers, it can be. Current, relevant tool data can reduce manual context gathering and help ground an answer. The result still depends on data quality, tool implementation, model behavior, prompts, and validation.
For businesses where AI usage is occasional or the data is simple enough to copy-paste quickly, it might not be worth the build cost yet. I'll tell you that on our first call if that's the case.
