Model Context Protocol (MCP) FAQ
MCP is a standard way to expose tools and context to models — useful when you need a registry, dangerous if you treat every server as trusted.
The Model Context Protocol (MCP) is an open protocol for connecting AI models to tools, resources, and prompts through MCP servers, so clients are not hard-wired to one vendor’s function-calling shape. It is an integration standard, not a security boundary; you still need auth, allowlists, audit, and a sandbox.
What MCP is
Think USB for tools: a plug shape. It does not decide which devices are safe to plug in.
What is MCP, or the Model Context Protocol?
MCP is an open protocol that lets an AI host talk to MCP servers that expose tools (callable functions), resources (readable context), and prompts (reusable templates). Instead of a one-off integration per model vendor, the host speaks MCP and the server speaks your API. Anthropic introduced it; other hosts have been adopting the shape. It is plumbing. The agent still needs evals, permissions, and a fallback.
How is MCP different from function calling?
Function calling is the model emitting a structured tool request (name plus JSON arguments) that your runtime executes. MCP is a client–server protocol for listing those tools, calling them, and fetching resources across processes. In production you often use both: the model function-calls; the runtime maps that onto an MCP server or a native handler. MCP does not replace schemas, idempotency, or confirmations.
What is an MCP server?
A process that implements the protocol and exposes a set of tools, resources, and/or prompts — for example a GitHub server, a database server, or an internal CRM wrapper. It runs with some credential. That credential is the blast radius. Treat a new server like a new microservice with production access, because that is what it is, even if it was installed as a “plugin.”
Who created MCP, and is it an industry standard?
Anthropic published the protocol and a specification; other vendors and open-source hosts have implemented clients and servers. It is an emerging standard, not a law, and the spec still moves. Enterprise bets should pin versions, isolate servers, and keep a native-tool fallback. We will use MCP where it reduces connector sprawl; we will not freeze your architecture on a draft you cannot pin.
Why would we use MCP instead of native tools?
When several hosts (IDE, chat, agent runtime) must share the same tool set, when you want a vendor-neutral connector layer, or when a well-maintained server already wraps a system you need. Native tools win when one runtime owns all calls and you want fewer hops and a simpler audit story. The decision is operational, not aesthetic. We measure connector count and security review cost, not Hacker News.
Does MCP work with Claude, ChatGPT, and other models?
Hosts that implement an MCP client can attach servers regardless of which model they call — in principle. Support varies by product and version. Your agent runtime can speak MCP even when the model vendor does not. Model-agnostic at ReinforcedX means the planner can be swapped; the tool gateway is yours. Do not assume a consumer chat app’s MCP support is your production architecture.
What can MCP servers connect to?
Anything you can wrap: repos, tickets, docs, warehouses, browsers, internal HTTP APIs. The constraint is the credential and the blast radius, not the protocol. Start with read-only servers on one workflow. A server that can send email and query the warehouse is two risk classes; split them. Connecting “everything” on day one is how you skip threat modelling.
How MCP shows up in an implementation
The protocol is the easy part. Registry, identity, and evals on tool use are the work.
How do you secure MCP servers?
Run them in your VPC, issue least-privilege credentials, authenticate the host to the server, authorise per user (not a shared god token), audit every call, and sandbox filesystem and network. Sign and pin server versions. Untrusted servers do not join the registry. A local stdio server on an engineer’s laptop is not an enterprise control. Threat-model each server as an app with prod access.
Do we need an MCP gateway?
In production, yes if more than one server or more than one host is in play. The gateway is the registry, policy, rate limits, identity mapping, and audit log. Hosts talk to the gateway, not to a zoo of endpoints. That is the MCP tool-gateway architecture. Skipping it is how a demo laptop becomes the integration layer.
MCP vs OpenAPI tools — which should we expose?
If you already have a solid OpenAPI and a runtime that turns schemas into function calls, you may not need MCP on that path. MCP helps when multiple dissimilar hosts must share tools, or when resources and prompts are part of the contract. Generating MCP from OpenAPI is a reasonable bridge. Two parallel connector trees for the same API is how they drift.
Can we run MCP entirely inside our VPC?
Yes, and that is the default for anything that can see customer data. Servers, gateway, and traces stay in your perimeter. The model API may still live outside; tool results you send it are a data-flow decision with a written policy. We do not require a SaaS MCP cloud. If a host only works as a desktop app with unconstrained servers, it is the wrong host for that data.
How do you authenticate and authorise an MCP server?
The host authenticates to the gateway; the gateway maps the end-user identity from your IdP; the server receives a downstream credential scoped to that user or to a tightly named service role. Static API keys in a server config are a smell. OAuth where the source supports it. Missing-permission looks like no-result, not like a leaked existence bit. This matches how we do permissioned retrieval.
What is the difference between MCP resources, tools, and prompts?
Tools are actions (they can have side effects). Resources are readable context (files, tickets, schemas) the host can fetch. Prompts are reusable instruction templates the server offers. Mixing a write into a “resource” is how you skip confirmation. Production policy treats tools as the dangerous surface and resources as data, including injection risk from their contents.
What do you need from us to add MCP?
The list of systems, whether they have APIs, the hosts that must share tools (IDE vs agent vs chat), and a security owner. A weekly review. If the only requirement is “we heard MCP is the future,” we will still start from the workflow. Protocol choice is week two, not week zero.
MCP in production
Every server is code execution adjacent to your data. Trace it like an API, because it is one.
What are the security risks of MCP?
Untrusted servers executing with your credentials, prompt injection via resources, tool-name collisions, over-broad OAuth scopes, supply-chain risk on community servers, and hosts that let a model choose new servers at runtime. Indirect injection is live if a ticket body can instruct a tool. None of these are theoretical. Registry, sandbox, and evals for hostile content are the mitigations.
How do you audit MCP tool calls?
Every call through the gateway logs actor, server, tool, arguments (redacted), result status, model version, and trace id. That is the same reconstructable trail we require for any agent action. Server-local logs are not enough; the gateway is the record. Auditors should be able to replay who did what without SSHing into a laptop that ran stdio.
Should every integration be an MCP server?
No. High-churn internal APIs that only one runtime calls can stay native. MCP pays off on shared, relatively stable tool sets and on third-party systems with a maintained server. Wrapping everything doubles the surface you must patch. We add a server when a second host needs the same tool, or when isolation is easier that way — not as a tally on a scorecard.
How long to add MCP to an existing agent?
A first production-shaped path — one server, gateway, identity, evals on tool use — fits inside a four-week implementation if the agent already has traces. Replacing a working native registry “because MCP” is a migration with its own suite; we will not do it as a fashion pass. Shadow-mode tool calls compare MCP vs native before you cut over.
How do you evaluate MCP tool use?
The same way as native tools: golden goals, expected tool sequence, argument validity, and no extra dangerous calls. Add cases where a resource contains injection. Pin server versions in the suite so a community update cannot silently change behaviour. If you only eval the final sentence, a malicious or buggy server hides. Function-calling evals transfer; the transport should not need a new religion.
Who owns the MCP servers after handover?
You do. Images, configs, registry entries, and runbooks sit in your repo and cluster. Thirty days of on-call covers what we shipped. A community server you adopted is still your dependency: you pin it, scan it, and have a rollback. We are not an MCP marketplace and we do not run your servers as a SaaS.
When not to use MCP
A standard is a means. If it adds a hop without a second consumer, skip it.
When should we not use MCP?
When a single runtime already has a schema registry and no other host needs those tools, when you cannot sandbox or review a server, when the spec pin is unclear for your host, or when the data cannot leave a mainframe path MCP cannot reach. Also when the team would treat community servers as apps. Native function calling is still production-grade.
Is MCP for enterprise agents or for desktop IDEs?
Both, and the threat models differ. Desktop MCP often runs as local processes with the user’s credentials — fine for a developer, not a pattern to copy onto a production agent that serves customers. Enterprise MCP is gateway-mediated, identity-aware, and evaluated. Copying a personal Claude desktop config into a helpdesk agent is a category error.
What happens if an MCP server is compromised?
Assume it can call whatever its credential allows. Revoke that credential, pull the registry entry, rotate secrets, and read the gateway audit log for blast radius. This is why least privilege and split servers matter. A single server with warehouse plus email plus production writes is an incident waiting on a dependency. Incident response is your runbook; we include it in handover.
Should we use MCP or a computer-use / browser agent instead?
Prefer APIs and MCP/native tools when they exist. Computer-use (screenshot/DOM loops) is for systems with no API, and it is slower, more brittle, and harder to secure. MCP wrapping an API beats clicking the UI with a model. If the only access is a GUI, that is a different architecture — and a different FAQ and how-to — not a reason to skip a server you could have written.
What usually goes wrong with MCP in production?
Unpinned community servers, no gateway, shared god tokens, resources concatenated into the system prompt (injection), and treating MCP as a security feature. Hosts that let the model add servers at runtime are the other classic. Rescue starts by inventorying what can actually be called, then putting that list in a registry with evals. The protocol did not fail; the operating model did.
MCP standardises how a host (chat app, agent runtime) discovers and calls tools and resources on MCP servers. Native function calling remains what many APIs use internally; MCP is the USB-C of that idea across hosts. Enterprise use needs a gateway: registry, identity, audit, and sandbox — a random server from the internet is an unvetted tool with your credentials. ReinforcedX implements MCP inside your VPC when the standard reduces connector sprawl, and uses native tools when a single runtime already has a schema registry. Security review is not optional.
Keep reading
Ready to refine
your workflow?
Share your current process. We’ll help you identify what can be automated — and where efficiency can be reclaimed.