MCP, the Model Context Protocol: how AI assistants connect to your company's tools and data

What MCP is, in one paragraph

The official MCP documentation compares it to a USB-C port for AI applications: just as USB-C gives a standard way to connect devices, MCP gives a standard way to connect AI applications to external systems. Its examples include an assistant reaching your calendar and notes, a coding agent building an app from a design file, and company chatbots connected to several internal databases. The documentation lists support in AI assistants such as Claude and ChatGPT and in development tools such as Visual Studio Code and Cursor, so one server can serve many AI applications.

The three participants

A server can run locally, on the same machine as the AI application, using the stdio transport; or remotely, over the Streamable HTTP transport, typically serving many clients. For remote servers, the documentation says MCP supports standard HTTP authentication and recommends OAuth to obtain tokens.

What a server can offer: tools, resources, prompts

Servers can also ask the user for more information or for confirmation of an action, through what the specification calls elicitation. The protocol itself uses JSON-RPC 2.0 messages. It evolves: the current documentation describes protocol version 2026-07-28, a stateless design in which each request carries its own version and capabilities, and marks some older features as deprecated. Check the version your tools support.

• Tools: functions the AI application can invoke to perform actions, such as an API call or a database query. For a business: “find this client”, “create a task”, “draft a quote”.
• Resources: data sources that give the AI context, such as file contents or database records. For a business: a product catalogue, a policy document.
• Prompts: reusable templates that structure interactions with the model. For a business: “weekly client summary”, “answer in our support tone”.

Connecting Claude to an MCP server

In Claude Code, Anthropic's documentation shows servers being added with the claude mcp add command, using a remote HTTP server (recommended), a local stdio server, or older transports. Servers can be configured for one project only, shared with the team through a .mcp.json file committed to the project, or for all of a user's projects. Many cloud MCP servers use OAuth 2.0: you add the server, then sign in through the browser.

Anthropic's documentation also carries a clear warning: verify you trust each server before connecting it, because servers that fetch external content can expose you to prompt injection risk.

Security rules that matter

The MCP project publishes security best practices. Several translate directly into business rules:

• Least privilege: grant minimal scopes first and ask for more only when a privileged action is needed; avoid wildcard or “full access” scopes.
• No token passthrough: an MCP server must not accept tokens that were not issued for it, nor forward a client's token unchanged to another service.
• Consent for local servers: before a one-click local server runs, the client must show the exact command and get explicit approval, since local servers run with the user's privileges.
• Never treat a handle as identity: servers that keep state must verify every request and must not treat possession of a state identifier as authentication.
• Trust and review: connect only servers you trust, and review what they can do.

Is it useful for a small business?

What we built at Takat

We built an MCP server that lets our whole team plug their own Claude into our company operating system: each person connects their assistant, and every call is logged. It is the same pattern we offer to clients: a small set of well-named tools on top of your existing systems, access per person, confirmation for anything that changes data, and a full log. See Claude & MCP integrations and API integrations.