If you work in operations, you are probably hearing about MCP in vendor emails, product updates and team chats. Your AI assistant "now supports MCP." Your ticketing tool "has an MCP server." A colleague wants to "connect everything through MCP." It sounds technical, and it is easy to nod along without knowing what it means for the processes you are responsible for.
This guide explains the Model Context Protocol in plain language, shows where it fits next to the tools you already use, covers the risks that matter to operations teams, and gives you a staged plan and a review sheet to adopt it safely. You do not need to be an engineer to follow it.
A note on scope: MCP is a young and fast-moving standard, and products that support it change often. Treat product details here as a snapshot, and confirm on the sources linked at the end before you act.
What MCP is, in plain language
The official documentation describes MCP as an open-source standard for connecting AI applications to external systems. With MCP, AI applications such as Claude or ChatGPT can connect to data sources like local files and databases, tools like search engines and calculators, and workflows like specialized prompts. The documentation's own analogy is a USB-C port: a single standard way to connect devices, applied to AI applications and the systems they use.
Why that matters: before a shared standard, every connection between an AI assistant and a business tool was a custom job. With a shared standard, a tool vendor can publish one connector, and any assistant that supports the standard can use it.
The three parts, without jargon
The MCP specification describes a client-host-server design.
| Part | What it is | Ops-friendly analogy |
|---|---|---|
| Host | The AI application you use, which coordinates everything and enforces security policies and consent | The office manager who decides who gets a key |
| Client | A connector the host creates for each server, with a one-to-one link to that server | A dedicated phone line to one supplier |
| Server | A program that exposes data, tools and prompts from a system, either on your machine or as a remote service | The supplier's front desk |
Servers expose three kinds of things: resources (data the assistant can read), tools (actions it can take) and prompts (reusable instructions). The specification also states a design principle that is useful to remember: servers should not be able to read the whole conversation or see into other servers, and the host enforces those boundaries.
An example flow
Imagine a finance operations assistant connected to your ticketing system and your accounting system.
- A teammate asks, "What is the status of the Acme invoice dispute?"
- The host sends the request to the ticketing server, which looks up the case and returns the notes.
- The host sends a second request to the accounting server for the invoice record.
- The assistant combines both results into a short summary for the teammate.
Nothing in that flow changed a record. That is the safest category of use, and the one to start with.
MCP, APIs, webhooks and automation platforms
MCP does not replace the tools you already use. It sits alongside them.
| Option | Best for | Who decides what happens | Typical control |
|---|---|---|---|
| API | One system talking to another in a defined way | The developer who wrote the integration | Code and keys |
| Webhook | Pushing an event the moment something happens | The sender, with rules on the receiver | Endpoint security and retries |
| Automation platform (Zapier, Make, n8n) | Fixed, repeatable workflows with clear triggers | You, when you design the workflow | Workflow steps and logs |
| MCP | Letting an AI assistant look things up and use tools as a person asks | The assistant, within the permissions you grant | Server review, scopes, approvals and logs |
The big difference is who chooses the next step. In a workflow, you decide it in advance. With MCP, an assistant may decide at run time which tool to call. That is useful for open-ended questions and risky for anything that moves money or changes records. Our guide on AI agents vs workflows covers that choice in depth, and webhooks, APIs and iPaaS explains the plumbing underneath.
If your process is the same every time, a regular workflow is usually the better choice. The comparison of Zapier, Make and n8n can help you decide.
Where MCP fits in operations
Think about use cases in three risk levels.
Low risk: read and summarize.
- Look up the status of a ticket, order, invoice or purchase request.
- Search a shared knowledge base or SOP library and answer questions.
- Pull figures from a report and explain a change.
Medium risk: draft and propose.
- Draft a reply to a customer or supplier for a person to approve.
- Prepare a journal entry or a purchase order for review.
- Suggest a category or owner for a new request.
High risk: change records or move money.
- Approve or pay an invoice.
- Change a supplier's bank details.
- Delete or overwrite data.
- Grant system access.
Start at the low-risk end. Move up only when you have the controls described below, and keep a person in the loop for the high-risk end. The guide to human-in-the-loop approvals shows how to design review steps that people can actually do well.
The risks that matter
1. Instructions hidden in the data
An assistant that reads emails, tickets or documents can be steered by whoever wrote them. This is called prompt injection. The UK's National Cyber Security Centre has written that prompt injection is not SQL injection and may be worse, which is a useful warning against assuming a simple fix exists. With MCP the risk grows with the number of tools connected: the more the assistant can do, the more a hidden instruction could make it do. Our guide on securing AI workflows against prompt injection covers practical defenses, and the OWASP Top 10 for LLM Applications lists related risks.
2. Servers you have not reviewed
An MCP server is software that runs with access to your data or your tools. A local server may run on a laptop with the user's permissions. A remote server is a service run by someone else. Review each one the way you would review a new vendor, using the questions in AI tool vendor review.
3. Too much access
If a server connects with a powerful token, the assistant can do whatever that token allows, even if you only meant it to read. The MCP authorization specification points toward least privilege: servers should indicate the scopes required, and clients should request only the scopes needed for their operations.
4. Tools that change after you approve them
A server can add or change tools over time. If you approved a harmless "look up record" tool, a later change could add an action you did not review. Keep an inventory of approved tools and check for changes.
5. No record of what happened
If the assistant takes an action and nobody can see what it did, you cannot investigate a mistake. Logging is not optional once an assistant can act.
What the specification says about authorization
The MCP specification includes an authorization section. Several points matter to operations teams, even if you never read the technical details:
- Authorization is optional for MCP implementations. That means a server can exist with no login at all, and you need your own policy to require one.
- Implementations using an HTTP-based transport should follow the specification's authorization flow, which is built on OAuth. Implementations using a local STDIO transport should not follow it and should instead retrieve credentials from the environment.
- Servers must validate that access tokens were issued specifically for them, and must not accept or pass along other tokens.
- Access tokens must not be placed in the URL query string.
- The specification points clients toward the principle of least privilege when requesting scopes.
Translated into policy: require authentication, use narrow scopes, never paste a powerful key into a tool "just to get it working," and know where each server stores credentials.
What government guidance adds
In May 2026, third-party summaries reported that the US National Security Agency published guidance titled "Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation." We could not open the NSA document itself while writing this guide, so treat the following as a secondary summary and read the original before you rely on it. As summarized by MCPBlog.dev, its recommendations include filtering outbound connections, scanning tool outputs for injected instructions, logging tool output, pinning the inventory of approved tools, structured audit logging, sandboxing each server and scanning for local MCP listeners.
You do not need to implement every item to benefit from the direction of travel: control what connects, watch what comes back, record what happens and contain each server. The NIST AI Risk Management Framework offers a broader structure for managing AI risk if your organization needs one.
A staged adoption plan
Stage 0: Decide whether you need it (week 1). Write one sentence describing the job: "We want an assistant to look up X so that Y takes less time." If you cannot, wait. Check whether a regular workflow would do the job more simply.
Stage 1: Read-only pilot (weeks 2 to 3).
- Pick one server for one system with data you can afford to expose.
- Give it read-only access and the narrowest scope available.
- Use a test account or a small, low-sensitivity data set first.
- Have two or three people use it and record where answers are wrong.
Stage 2: Review and logging (weeks 3 to 4).
- Complete the server review sheet below.
- Turn on logging for tool calls, and decide who reviews the logs and how often. A weekly review works well at first, similar to the cadence in automation alert review.
- Write a one-page policy: which servers are approved, who can add one, and how to switch one off.
Stage 3: Draft-and-approve (weeks 5 to 8).
- Allow the assistant to draft actions, but require a person to approve before anything is sent or saved.
- Measure how often approvers change the draft. If they change most of them, the assistant is not ready.
Stage 4: Limited actions (after a review).
- Allow narrow, reversible actions with small limits, such as adding a note to a ticket.
- Keep money, access and deletion behind human approval. The agent guardrails template gives you wording for boundaries.
Stage 5: Review quarterly.
- Re-check the approved list, scopes and logs. Remove what is not used.
MCP server review sheet
Copy this into a document and complete it before you connect any server.
| Question | Why it matters | Answer |
|---|---|---|
| Who publishes and maintains the server? | Unknown authors are a risk | |
| Is it local or remote? | Local runs with the user's permissions; remote means data leaves your environment | |
| What data can it read? | Defines what could leak | |
| What actions can it take? | Defines what could go wrong | |
| How does it authenticate, and what scopes does it request? | Least privilege | |
| Where are credentials stored? | Tokens must not sit in plain text | |
| What does it log, and can you export the logs? | Needed to investigate | |
| How are tool changes announced? | Prevents silent changes | |
| What happens to data sent to it? | Retention and training use | |
| How do you disconnect it and revoke access? | Your exit path | |
| Who is the internal owner? | Someone must be accountable |
A worked example (illustrative)
A small finance operations team wants an assistant that helps with supplier questions. They write down the approved tools:
| Tool | Access | Approval needed |
|---|---|---|
| Look up invoice status | Read-only | No |
| Search supplier contract summaries | Read-only | No |
| Draft a supplier email | Draft only | Yes, a person sends it |
| Add a note to a ticket | Write, reversible | No, but logged |
| Change supplier bank details | Not allowed | Not available to the assistant |
| Approve or pay an invoice | Not allowed | Not available to the assistant |
The last two rows matter most. Changes to bank details are a known fraud route, as the FBI's Internet Crime Complaint Center describes in its business email compromise warning, so they stay with people who verify the request through a separate channel. This example is invented to show the method. Your own tools, risk and limits will differ.
Common mistakes
- Connecting everything at once. Each connection adds risk. Add one, learn, then add another.
- Giving write access on day one. Start read-only.
- Using personal accounts or admin tokens. Use a dedicated account with narrow permissions.
- Trusting a server because it is popular. Review it like any vendor.
- Skipping logs. If you cannot see what happened, you cannot fix it.
- No owner. Every approved server needs a named person.
- Assuming the assistant will refuse bad instructions. Hidden instructions in data can work. Controls must exist outside the model.
- No exit plan. Know how to disconnect a server and revoke its access.
Key takeaways
- MCP is an open standard for connecting AI applications to external systems. The official documentation compares it to a USB-C port for AI.
- It sits alongside APIs, webhooks and automation platforms. The key difference is that an assistant may choose the next step at run time.
- Start with read-only use cases, then move to draft-and-approve, and keep money, access and deletion behind human approval.
- Authorization is optional in the specification, so your own policy has to require it, with narrow scopes and no tokens in URLs.
- Review every server like a vendor, keep an inventory of approved tools, and log what the assistant does.
- Prompt injection is a real and unsolved risk. Put controls outside the model.
Sources and further reading
The pages below are where we checked the facts in this guide. MCP and its products change quickly, so read the current version before you rely on them. Written by Sam at OpsGrit with AI assistance and an automated editorial review. If you spot something wrong, tell us.
- Model Context Protocol: What is the Model Context Protocol (MCP)?. The official introduction.
- Model Context Protocol: Architecture. Host, client and server roles and design principles.
- Model Context Protocol: Authorization (draft specification). Authorization requirements for HTTP and STDIO transports. This is a draft revision and may change.
- NCSC: Prompt injection is not SQL injection (it may be worse).
- OWASP Top 10 for LLM Applications (2025).
- NIST AI Risk Management Framework.
- MCPBlog.dev: summary of the NSA's MCP security guidance. A third-party summary, not the NSA document.
- FBI Internet Crime Complaint Center: Business Email Compromise PSA.
The staged plan, review sheet and example are OpsGrit's own and are starting points. Adapt them with your security and finance owners.