Model Context Protocol (MCP) for AI Agents: A 2026 Integration Guide

Most AI agent failures in production come down to one problem: the agent cannot reliably reach the tools and data it needs. The Model Context Protocol (MCP) is an open standard that addresses part of this. Introduced by Anthropic and now supported by many AI applications, it gives a model a uniform way to discover tools, fetch context and call actions, without a bespoke integration for every pair of model and data source.

This guide explains what MCP is, why it matters for AI agents, when a native connector is still the better choice, and exactly where Orkeste stands today.

What is the Model Context Protocol?

MCP is an open protocol that standardises how AI applications reach tools, data and prompts. Think of it as a common plug for AI integrations: a tool vendor publishes one MCP server, and any MCP-aware client can use it.

Before MCP, every AI application had to write its own adapter for Gmail, Slack, Notion, Postgres and so on. MCP turns that N×M problem into N+M: vendors publish a server once, and clients such as Claude Desktop or Cursor connect to it.

The protocol defines three primitives:

  • Tools: functions the model can call (send an email, query a database, create a ticket).
  • Resources: read-only context the client can attach (documents, rows, files).
  • Prompts: reusable, parameterised instructions the server suggests to the client.

Why MCP matters for agents

Single-agent demos rarely need a protocol. Systems that touch many tools do. Three reasons:

  • Tool sprawl. A real workflow touches many systems, and custom adapters for each become hard to maintain.
  • Authorisation boundaries. An MCP server holds the credentials; the model only sees the capabilities it exposes.
  • A typed interface. Every tool call has a declared name and schema, which makes logging and review easier.

MCP does not decide whether an action should run. Approvals, budgets and audit remain the job of the platform that runs the agent.

Native connectors or MCP?

Native connectors trade reach for precision: each action is designed, tested and documented. MCP trades precision for reach: any server, with whatever quality its author gave it.

Where Orkeste stands

Orkeste agents use both: 26 native connectors and the remote MCP servers you add. The 26 connectors (Gmail, Outlook, HubSpot, Salesforce, Zendesk, Jira, Slack and others) are built directly on each tool's API, and each connector page lists exactly what an agent can read and change. Since October 2026, a workspace can also register remote MCP servers, and an agent in agentic mode uses their tools alongside its connectors.

How it works in practice:

  • Add the server. In Connectors, an owner or admin enters the server's HTTPS URL and, if it needs one, a header and its value (an API key or a token). Orkeste connects, lists the tools and only then saves the server. The credential is encrypted and cannot be read back through the API, even by a member.
  • Attach it to an agent. In Agent Studio, you pick which servers an agent may use. Its tools appear next to the connector tools, named after the server.
  • Keep approvals. A tool the server does not mark as read-only is treated as a write: the call waits in Validations with its arguments, like a Gmail draft or a HubSpot update. You can turn approval off per server once you trust it.

A worked example: a logistics company exposes its order database through an internal MCP server with two tools, lookup_order (read-only) and reschedule_delivery. A support agent reads a Zendesk ticket, calls lookup_order on its own, then proposes reschedule_delivery with the new date. That call waits for a person, who approves it from the same queue as the Zendesk reply.

The guard rails are the same as for connectors. Results from an MCP server are passed to the model as untrusted data, never as instructions, which limits prompt injection through a tool result. Requests go only to public HTTPS addresses, without redirects, with a timeout and a size limit.

The limits are real. MCP servers are on the Pro plan (5 servers) and Business (unlimited), not on Free or Starter. Only servers without authentication or with a static key in a header are supported: servers that require an OAuth sign-in are not yet. Agents use MCP tools in agentic mode, which is still in beta, and the quality of a tool is the quality its author gave it.

Orkeste also publishes a read-only MCP server, in an early version, for your own workspace. After you sign in from an MCP client such as Claude, you can ask it about your agents and their configuration, recent runs and failures, connector status, pending validations and your credit balance. It cannot run agents, approve actions or change anything.

If your system should start an agent rather than serve it tools, use an event trigger: a signed webhook starts the agent at once. The Agent-as-an-API does the same from your own code (Pro plan and above).

FAQ

Is MCP an Anthropic-only standard?

No. Anthropic introduced it as an open specification, and many AI applications and frameworks now implement it.

Do I need to run my own MCP server?

Only to expose an internal system. For public tools, the vendor or the community often publishes one; check its quality before you rely on it.

How does MCP compare to function calling?

Function calling is a model capability: the model emits a structured call. MCP is the layer that tells the application which tools exist, how to authenticate and how to exchange results. They work together.

Can Orkeste agents use my MCP servers?

Yes, on the Pro and Business plans. Add the server in Connectors, attach it to an agent in agentic mode, and its tools join the agent's connector tools. Write tools wait for approval unless you turn approval off for that server.

Which MCP servers work with Orkeste?

Remote servers over Streamable HTTP, reachable on a public HTTPS address, without authentication or with a static key in a header. Servers that require an OAuth sign-in are not supported yet.

What can the Orkeste MCP server do?

Read only: list your agents and their configuration, recent runs and errors, connectors, pending validations and credit balance. It is useful to ask an assistant why a run failed or what is waiting for approval.