What is the Model Context Protocol (MCP)?

Short answer: The Model Context Protocol is an open protocol that lets an AI application discover and call tools exposed by an external server over one standard interface. Your issue tracker, docs, or internal service can be reached by an assistant without a bespoke integration per product. It is a connection contract, not intelligence. For an engineering team the interesting questions are not about the protocol at all: which tools are enabled, who approves a call that changes something, where the credential lives, and what happens when the server is unreachable.

Where Crew Orbit uses connected tools

Enabled tools work in Agent chat and in task runs. Chat asks for approval before a call. A run calls an enabled tool without a second approval.

A run writes one MCP entry for the coding agent (Cursor, Claude Code, and the other supported agents). That entry points at Crew Orbit. Crew Orbit forwards the call to the connected server. The remote token stays in the credential store. Newly discovered tools stay off until someone enables them.

Connect the server, enable the tools you want a run to call, and submit the task. If a vendor says their agents already do this, ask them to show the tool call inside a run, not only in a chat window.

What MCP actually is

MCP standardizes the boundary between an AI application and the systems it needs to touch. There are two sides:

• A server wraps a system (a ticket tracker, a wiki, a database, an internal API) and describes what it offers: a set of named tools, each with a description and a typed input schema.
• A client lives inside the AI application. It connects to the server, asks what tools exist, presents them to the model, and executes calls the model asks for, returning results.

The value is combinatorial, not conceptual. Function calling already existed. What did not exist was one interface, so every AI product wrote a private integration for every system. Ten AI tools and ten internal systems meant a hundred bespoke connectors, each with its own auth handling and its own decay. With a shared protocol, the system is described once and any compliant client can use it. That is the whole idea, and it is enough of an idea to matter.

The protocol is genuinely open, documented at modelcontextprotocol.io, and implemented across a growing number of AI clients. It is not a proprietary hook.

What MCP is not

Most of the confusion in the market comes from people selling the protocol as if it were the product.

• It is not a model. MCP does not make an assistant smarter. It widens what the assistant can reach.
• It is not an agent framework. Planning, retries, and multi-step orchestration are your application's job.
• It is not an authorization system. The protocol carries credentials. It does not decide who in your company should be allowed to trigger which call. That policy has to exist somewhere, and if your vendor has not built it, the answer is "everyone who can open the chat".
• It is not a safety property. A tool description is text that a model reads and may act on. A server you do not control can describe a tool in ways designed to influence the model. That is the same class of problem as untrusted content in a prompt. Which servers you connect is a trust decision, not a convenience decision.

The four operational questions worth asking

If you are evaluating any product's tool connections, these four questions separate a shipped feature from a checkbox on a slide.

1. Which tools are enabled, and who decided? A server often exposes dozens of tools, several of which delete things. "Connected" and "everything is available" must not be the same state.

2. Who approves a call that changes something? Reading a ticket and closing a ticket are different risks. If both happen silently, you have handed write access to a probabilistic system.

3. Where does the token live, and can it reach places it should not? An endpoint field that accepts an internal address is a request-forgery surface pointed at your own network. Ask whether tokens are returned to the browser, and whether private addresses are rejected.

4. What happens when the server is down? Integrations fail constantly: expired tokens, moved endpoints, maintenance. The question is whether that becomes a visible state with a retry, or a confusing non-answer in a chat window, or a broken settings page.

How Crew Orbit answers them

In the product this surface is called Tool connections. "MCP" appears only as a technical subtitle for people who know the protocol. It lives under organization settings and under project settings, so a connection can be shared across the workspace or scoped to a single project.

• Tested before trusted. You paste the server's HTTP endpoint and the handshake is verified before the connection is saved. An unreachable server is not stored as a healthy row.
• Discovered tools start disabled. Connecting a server exposes nothing. You enable individual tools deliberately, which means the default state of a new connection is inert.
• Writes and external actions need an approval card. When an enabled tool would do something irreversible or reach outside the platform, the turn pauses and renders a card in the transcript showing what will happen, where, why, and the values a person can actually judge. Approve and Reject are buttons. Typing the word "approve" in the composer is never an approval mechanism, and a card that expires auto-rejects rather than defaulting to yes.
• Private network addresses are blocked, and auth tokens are stored encrypted and never returned to the client.
• Health is a state, not a mystery. A connection reads as healthy, unreachable (with a plain-language reason plus Retry, Edit, and Delete), off, damaged when the stored row cannot be read, or unavailable when a project inherits a workspace connection that has been disabled.
• One bad row never takes down the list. A single broken connection degrades to a clear state. The others keep working.

None of that is exotic engineering. It is just the part vendors skip, because a connect button demos beautifully and an approval card looks like friction on stage. The friction is the feature: it is the difference between an assistant that can reach your systems and an assistant that is allowed to.

A short evaluation checklist

Take this to your next vendor call:

• Do newly discovered tools default to off or on?
• Which categories of call require human approval, and is that enforced by the platform or by prompt wording?
• Can approvals expire, and what happens when they do?
• Are private and internal network addresses rejected at the endpoint field?
• Are tool tokens ever returned to the browser?
• Can connections be scoped per project, or only per company?
• Do connected tools work in autonomous execution, or only in chat? Get a straight answer to this one.
• What does the settings page look like when a server has been unreachable for a week?

Why the product states the boundary in the same words as the code

Enabled tools work in Agent chat and in task runs. Chat still asks for approval. A run does not ask a second time. Newly discovered tools stay off until someone enables them. Those sentences are on the connections screen because a claim that leads the shipped code gets found, usually by the engineer who tries it.

If the honest answer to a question about our product is no, the answer is no. That is also the reason you can trust the yeses on this page.

Related reading: AI code review for the branch you already pushed and how to govern AI changes before the security questionnaire arrives.