What does MCP stand for?

MCP stands for Model Context Protocol, an open protocol for connecting AI applications to tools and data. It uses JSON-RPC 2.0 messages between hosts, clients and servers. Servers can offer tools the model executes, resources that supply context, and prompt templates. The latest specification revision is dated 28 July 2026.

Can an API be an MCP server?

Not by itself, but you can wrap one. An MCP server exposes chosen API operations as tools, each with a name, a description and an input schema, and calls the API when a tool runs. Expose only the operations an agent actually needs, and give read and write operations separate scopes so a stolen token can't do both.

What is MCP tool poisoning?

It's an indirect prompt injection attack. A malicious server returns tool output with hidden instructions, and the model treats them as trusted context. OWASP notes that descriptions are reviewed once at connect time, while responses reach the model unchecked. The agent may then call restricted tools or leak data. OWASP's mitigations are an allowlist of approved servers, structured tool output and access control enforced on the server side.

Should MCP servers run locally or remotely?

Local servers run on stdio as a subprocess of the client, with the user's privileges and credentials from the environment. That suits developer tools but is hard to audit across a team. Remote servers use Streamable HTTP and can use the spec's OAuth-based authorization, which makes central allowlisting, token scoping and logging easier. One sound split is to sandbox local servers and move shared tools to managed remote servers.

Is MCP secure enough for enterprise use?

It can be, but the protocol won't do it for you. The specification says MCP cannot enforce its security principles at the protocol level, so safety comes from the implementation: vetted servers, per-server OAuth tokens, narrow scopes, human confirmation on sensitive tools and a complete audit log.

Who created the Model Context Protocol?

Anthropic open-sourced MCP on 25 November 2024. It was created there by David Soria Parra and Justin Spahr-Summers. On 9 December 2025, Anthropic donated the protocol to the Agentic AI Foundation, a directed fund under the Linux Foundation, and said the project's governance model would stay the same.

MCP vs API for Security and Governance (2026)

Quick Answer: The MCP vs API difference is who chooses the call: your code invokes an API, while an AI agent picks MCP tools at runtime. MCP servers usually wrap existing APIs, so security shifts from protecting an endpoint to governing which tools an agent sees and which OAuth 2.1 scopes it holds. Fixed integrations stay on direct APIs.

The current MCP revision (2026-07-28) is blunt about the trade. It tells hosts to treat tool descriptions as untrusted unless they come from a trusted server, and to get explicit user consent before any tool runs. It also says the protocol can't enforce those principles itself.

For platform and security teams, the question is no longer only "is this endpoint protected?" It's "which agent may see which tool, under whose identity, and where is that logged?"

How is MCP different from a regular API?

An API is a fixed contract that a developer reads and codes against. MCP is a protocol that lets an AI application discover tools at runtime and lets the model decide which one to call.

The Model Context Protocol specification defines hosts (the AI application), clients (connectors inside the host) and servers (services that expose tools, resources and prompts), all talking JSON-RPC 2.0. A client asks a server for its tools with tools/list. Each tool arrives with a name, a plain-language description and an input schema. The model reads those descriptions and picks one with tools/call.

	Direct API	MCP
Who decides the call	Your code, at build time	The model, at runtime
How capabilities are found	Docs or an OpenAPI file a developer reads	A `tools/list` request the server answers
Message format	Whatever the API defines, often REST and JSON	JSON-RPC 2.0
What the caller relies on	A contract you reviewed	Tool descriptions a server supplies
Best fit	Fixed, predictable integrations	Agents choosing among many tools

That's the core of MCP vs API: an API exposes a capability to code, while MCP exposes capabilities to an agent that finds and invokes them on its own.

Does MCP replace APIs?

No. An MCP server usually sits in front of existing APIs and turns a tool call into one or more API calls, so the API still does the work.

The spec describes tools as the way models reach external systems, such as querying databases or calling APIs.

Keep calling an API directly when the flow is deterministic, when it's high-volume service-to-service traffic, or when the action moves money and you want no model in the decision. Put MCP in front of an API when a coding assistant or internal chat tool should pick from several tools, or when several AI hosts should reuse one integration. For the wider choice between direct APIs, MCP servers and middleware, see how AI agent integration patterns compare.

How does MCP change the security model compared with a direct API?

The authorization question gets longer. For an API it's "can service A call POST /payments?" For MCP it's "can this user, through this agent, call refund_payment with these arguments?"

The model chooses the action, so the tool catalog becomes part of your security control plane. Tool descriptions and tool output also flow into the model's context, so they're input you treat as untrusted. The same shift toward agents is changing how software gets built, as how AI-native and AI-assisted teams differ explains.

Control point	Direct API	MCP
Identity	Service account or user token for your app	User, then AI host, then (for remote servers) an OAuth 2.1 token issued for that specific MCP server
Authorization	Scopes checked per endpoint	Scopes per server; the tool list can shrink to what granted scopes allow
Untrusted input	Request payloads	Payloads plus tool descriptions and tool output
Who picks the action	Code a reviewer approved	The model, so sensitive tools need confirmation
Blast radius	Endpoints the credential covers	Every tool the agent can see, chained in one session
Audit trail	Gateway and service logs	User, agent, server, tool, arguments and downstream call, linked

Per the spec's tools page, servers may return only the tools the caller's scopes permit, a human SHOULD be able to deny a tool call, and clients SHOULD log tool usage.

Are MCP servers a security risk?

Yes, when they're unvetted or over-permissioned. Each server is code an agent can drive, and the spec's security best practices name how that goes wrong:

Tool poisoning: a malicious server hides instructions in its tool responses. OWASP documents MCP tool poisoning as indirect prompt injection that can make an agent call restricted tools or leak data.
Changed tools: servers can change their tool list after you approved it.
Confused deputy: an MCP proxy server that uses a static client ID with a third-party authorization server can let an attacker obtain authorization codes without proper user consent.
Token passthrough: a server forwards a token that wasn't issued for it to a downstream API. The spec forbids this.
Local server compromise: a local server runs with the client's privileges, so a malicious startup command can read SSH keys.
SSRF: a malicious server plants URLs in OAuth metadata that make a client fetch internal addresses or cloud metadata endpoints.

OWASP's 2025 Top 10 for LLM applications files the underlying risk under excessive agency: an agent with more tools, permissions or autonomy than its task needs. That's the lens for MCP server security reviews.

How do you secure MCP authentication and permissions?

Authentication changes less than authorization. For remote servers, follow the spec's OAuth 2.1-based flow and grant the narrowest scopes each tool needs.

The MCP authorization rules for HTTP transports:

The server acts as an OAuth 2.1 resource server and publishes Protected Resource Metadata (RFC 9728).
Clients send a resource parameter (RFC 8707) naming the exact server the token is for.
Servers MUST check each token was issued for them and MUST NOT pass other tokens through.
Tokens travel in the Authorization header, never in a query string.

Local stdio servers skip this flow and read credentials from the environment, so treat those secrets like production secrets, scoped per server. Start every server with a minimal scope and step up only when a privileged tool is first used; the spec supports this with WWW-Authenticate scope challenges. On the host, keep a per-agent tool allowlist and require confirmation before write tools run.

How do you govern MCP traffic centrally?

Put one policy point between your agents and your MCP servers. It holds the approved server list, applies rate limits, keeps secrets out of prompts and writes one audit trail.

The chain runs user, AI host, policy point, approved server, tool, downstream API. Log every hop with a shared correlation ID, as the best-practices page recommends for scope elevation.

If you're choosing an enterprise LLM gateway to route and manage internal AI coding tools, ask whether it only proxies model APIs or can also front tool servers. An MCP gateway applies the same policy idea to tool traffic. If data must stay on your hardware, compare self-hosted LLM gateways on logging, access control and air-gapped support.

What mistakes should you avoid when rolling out MCP servers?

The common thread is trust granted once and never checked again:

Installing community servers unvetted. One-click setup runs code with the user's privileges. Review the command and pin versions.
Passing user tokens through. Each server needs its own token for its own audience.
One server with every permission. Split read and write tools; don't request admin:* up front.
Restricting tools only in the system prompt. Injected instructions can override it. Enforce access where the tool executes.
Auto-approving write tools. Keep a human step for anything that changes data.
No audit log of tool calls. Without user, agent, tool and arguments on record, you can't reconstruct an incident.

How Origins AI governs model traffic from coding tools

Origins AI (originshq.com) builds the Origins AI Coding Tool, a self-hosted AI coding assistant and LLM gateway deployed inside the customer's own infrastructure. According to its product page, all model traffic from IDE plugins, CI pipelines and internal tools routes through that gateway, which logs every request, token count and response.

The page says the gateway redacts secrets, API keys and PII before content reaches the model layer, and lists per-team and per-engineer access policies and token quotas.

It runs on-premise, in your own AWS, Azure or GCP account, air-gapped with local models, or hybrid. In on-premise and air-gapped modes, prompts and code context stay inside your network. In hybrid mode, only the code context submitted to the hosted model leaves your network. Our guide to on-premise, private cloud and air-gapped AI covers that choice.

The gateway doesn't replace the MCP controls above: server approval, OAuth scopes and confirmation for write tools still sit with the host and the servers.

Talk to an engineer

If you're working out which agents may call which tools, and where the logs should live, book a call with the engineering team.

Written by Apoorva Kumar, Co-Founder & CEO, Origins AI.