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.

The limit, up front: in Crew Orbit, connected tools work in Ask, not in runs

Before any of the explanation below is useful to you as a buyer, here is the constraint you would otherwise find out in week two. In Crew Orbit, connected tool servers are available to Ask Crew Orbit, the conversational surface. Runs cannot call them yet.

The specific reason: the backend invoke proxy is in place, but the piece that makes enabled tools reachable from inside a run is a CLI stdio bridge, and that bridge is not shipped. Until it lands, tool connections are Ask-only. That is also what the product itself says on the connections screen, because a limitation a customer discovers after purchase costs more than one printed on the box.

So: connect your tracker and ask questions against it in chat, with approvals. Do not plan a workflow where an autonomous run calls your internal service through MCP. If a vendor tells you their agents already do that end to end, ask them to show it in a run rather than a chat window. The distinction is easy to blur in a demo and expensive to discover later.

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 we state the limit instead of implying capability

We publish the Ask-only constraint on the landing page, in the product, and here, because the alternative is worse for everyone. A prospect who buys on an implied capability becomes a support ticket, then a churn risk, then a story someone tells about your company. And a claim that leads the shipped code always gets found, usually by the one engineer on the buying committee 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.