What is Model Context Protocol (MCP)?
By Identra · Updated
Model Context Protocol (MCP) is an open standard that lets AI applications discover and use external tools, data sources and reusable prompts through MCP servers. It standardizes the connection only, so access control and limits on actions still depend on the application and the services behind it.
How does Model Context Protocol work?
There are three roles. The host is the AI application, such as Claude Desktop, Cursor or Claude Code. Inside it, a client holds a connection to an MCP server. The server exposes things the host can discover and call, like a Jira search, a Postgres query or the local filesystem. The official MCP architecture documentation describes these roles.
Ask Cursor to summarize open tickets and it finds the server's search tool, reads the input schema, sends a request and gets ticket text back. The model writes the summary from that. Whether the host asks you before a tool call, and when, is the host's decision. Check it in the app your people actually run.
What are MCP tools, resources and prompts?
A server can offer any of the three. A Postgres server might expose a query tool, the schema as a resource and a prompt template for explaining query plans. The official server overview defines each type.
Judge each one by what it makes possible. A read-only search tool can still leak HR records. A prompt template can change how the assistant behaves. The tool's name and description are what the author claims. The code and its credentials are what it does.
Tool
- What it does
- Runs an operation the model requests
- Example
- Search Jira or open a new ticket
Resource
- What it does
- Supplies content as context
- Example
- A design doc or a database schema
Prompt
- What it does
- A reusable instruction template
- Example
- Steps for reviewing an incident
Does MCP replace APIs or need a remote server?
No to both. An MCP server usually wraps an API that already exists. The GitHub API still does the work, and MCP gives Claude, Cursor and other hosts one common way to find and call it. Whether a given pair works together still depends on the protocol version and features each side supports.
Servers run locally or remotely. Local servers usually talk over stdio. Streamable HTTP handles network connections and works locally too. The MCP transports specification defines both.
Location changes what you review. A local server listed in ~/.cursor/mcp.json or a project's .mcp.json is a program running as that user, with every file and token the user can reach. A remote server is someone else's network service handling your data. Neither gets trust for free.
What can go wrong when an assistant uses MCP?
If the server runs on a broad service account, a narrow request from the user doesn't narrow what the server can do. MCP authentication controls who may open the connection. Each operation still needs its own authorization check at the service that runs it.
Text coming over the connection is untrusted. MCP tool poisoning hides instructions in a tool's description or metadata. An honest search tool can also return a document carrying indirect prompt injection. Either way, a simple lookup can end in a leak or an action nobody asked for.
The rest is old integration risk. Stolen tokens. A lookalike package posing as a popular server. Too much access. An update nobody reviewed. MCP security covers all of it. Speaking the protocol certifies nothing about the publisher.
What does MCP look like in a real workflow?
Say a support engineer asks Claude Desktop to summarize an escalation. One MCP server searches Zendesk. Another pulls runbooks from Confluence. A good answer has the relevant facts and none of the other customers' tickets.
Now one ticket says to upload the conversation to an outside URL for verification. That's text in a ticket. The engineer never asked for it. The setup should block unrelated outbound transfers and limit search to what the engineer can already see. A shared admin token breaks that boundary.
If the engineer then asks it to reply to the customer, the host should show the recipient and the exact message first. Reading tickets and sending email are separate permissions. AI agent delegation is about whose authority the assistant is using at each step.
How do you roll out MCP safely?
Start from the job and work back to the fewest tools it needs. Apply least privilege to the server's credentials. Hiding a tool in the UI does nothing if the backend still accepts the call.
- Record the publisher, internal owner, where it runs, the approved version and what it's for.
- Split search access from write and admin access.
- Run local servers with limited filesystem access. Scope remote ones to the intended users and data.
- Enforce authorization in the service that executes the action, and treat tool descriptions and returned text as untrusted.
- Require approval for sensitive actions, with the target and the change on screen.
- Log identity, tool, target, approval and outcome. Leave secrets out of the logs.
- Re-review when the version, tool list, credentials or reachable data change. Practice switching the server off and revoking its token.
How Identra thinks about it
Identra finds the MCP servers, AI clients, coding agents, skills and plugins on macOS and Windows endpoints, so security teams know which MCP connections exist. AI agent tool calls are checked against policy, and every agent run is recorded with the user, device, AI client and whether it was allowed or blocked.
Go deeper: AI security, built on identity
Frequently asked questions
Is MCP an AI model or an AI agent?
Neither. It's a protocol. A server can expose search or file operations without containing a model or making any decisions.
Does every MCP server support every AI application?
No. Protocol versions, transports, capabilities and app settings all vary. Test the exact host and server pair before approving it.
Does MCP give a server the entire conversation?
Not by default. The server gets what the host sends in requests and tool arguments. Check the real data flow for the host you use.
Is a read-only MCP server safe?
Read-only stops changes. It can still expose sensitive data, and what it returns can carry instructions aimed at the assistant.
Can MCP enforce a user's existing business permissions?
Only if the integration passes the user's identity through and the downstream service checks it. A server running on a shared service account won't.