Model Context Protocol (MCP)

The Model Context Protocol is an open standard for connecting AI applications to external systems, such as data sources, tools and workflows, over one defined wire protocol instead of a custom integration for each pair. The project's own introduction compares it to a USB-C port for AI applications: one standard way to plug things in.

How does MCP work?

The specification, current revision 2026-07-28, names three roles and one message format. Hosts are the LLM applications that start connections. Clients are the connectors inside a host. Servers are the services that provide context and capabilities. They exchange JSON-RPC 2.0 messages. The current revision makes the base protocol stateless, self-contained requests with capabilities negotiated per request, a change from earlier revisions that held a stateful session.

The lineage is stated in the spec: MCP takes some inspiration from the Language Server Protocol, which standardised how a programming language is supported across many editors. The bet is the same: N assistants times M systems is unworkable; N plus M is not.

What can an MCP server offer?

A server may expose three features:

• Resources: context and data for the user or the model.
• Prompts: templated messages and workflows for users.
• Tools: functions the model can execute.

The direction people forget is the other one. A client can offer elicitation to a server: the server asks the person for information it needs, mid-call. Beside that sit utilities for configuration, progress, cancellation and errors, and opt-in extensions such as Tasks for long-running work and MCP Apps for interactive UI inside a conversation. That two-way arrangement is why an MCP server is not just a REST API in a different envelope.

What does a real MCP call look like?

The numbers on several pages of this glossary were read through an MCP server, ours, so here is one of those calls, on a question about MCP itself. An assistant connected to the Attensira MCP server asked how answer engines respond when a buyer asks for an "MCP server for AI search visibility", one of the questions tracked for attensira.com. The request named one tool and its arguments:

{
  "tool": "get_prompt",
  "arguments": {
    "prompt": "MCP server for AI search visibility",
    "days": 30
  }
}

Part of what came back on 4 October 2026, trimmed but not altered:

{
  "text": "MCP server for AI search visibility",
  "answers_read": 24,
  "visibility": { "value": 0, "n": 24 },
  "leader": {
    "name": "SE Ranking",
    "kind": "brand",
    "rate": { "value": 0.625, "n": 24 }
  },
  "platforms": {
    "chatgpt": { "tracked": true, "rate": { "value": 0, "n": 12 } },
    "perplexity": { "tracked": true, "rate": { "value": 0, "n": 12 } }
  },
  "delta": { "value": null, "real": false },
  "window": {
    "coverage": { "days_sampled": 3, "days_in_window": 31 }
  }
}

It is not a flattering result, which is why it is a useful one. On a question about the very protocol we serve on, neither engine named us in 24 answers, while SE Ranking was named in 15; the chart at the top of this page shows the pages ChatGPT's answers leaned on instead, led by code on github.com, with attensira.com absent. Three details show what a well-built server does that a screenshot cannot. Every rate carries its n, so the assistant knows 0 of 24 is a small sample, not a verdict. delta.real: false says there is no change that passed a significance test, so there are no grounds to report a trend. And days_sampled: 3 says the question has only been read on three days of the window, because it was added recently. The model gets the caveats as data, in the same response as the number.

What are MCP's security rules?

MCP opens paths to data access and code execution, and the specification spends a section on what follows:

• User consent and control. Users must consent to and understand all data access and operations, and keep control over what is shared and done.
• Data privacy. Hosts must get explicit consent before exposing user data to servers.
• Tool safety. Tools are arbitrary code execution. Tool descriptions should be treated as untrusted unless they come from a trusted server, and hosts must get explicit consent before invoking a tool.

The crucial admission is that the protocol cannot enforce any of this; these are obligations on whoever builds the host and the server. An untrusted server's tool description is text that reaches a model, which makes it an indirect prompt injection surface by construction.

Why does MCP matter outside engineering?

It changes where the surface is. A model with no connectors works from training data and whatever a search tool retrieves. A model with connectors reads systems directly, on demand, in whatever structure they expose. That makes a machine-readable interface a distribution question, the same reasoning llms.txt applies to documentation, applied to live data. The protocol's introduction lists Claude, ChatGPT, Visual Studio Code and Cursor among the clients that support it.

What goes wrong with MCP integrations?

• Granting write access as if it were read. A credential that can delete or spend is a workspace credential.
• Trusting tool descriptions from unknown servers. They reach the model as text and can carry instructions.
• Assuming the protocol enforces consent. It does not; the host has to.
• Building on an old revision. Revisions change behaviour; name the one you target.

How do you use Attensira through MCP?

Connect the Attensira MCP server at https://mcp.attensira.com/mcp from Claude, ChatGPT, Cursor or any client that speaks Streamable HTTP, with OAuth sign-in or a workspace API key. Your assistant can then read every number the dashboard shows, with sample sizes and significance attached, add prompts, run automations, and approve or decline the crew's work in your Inbox without leaving the conversation. Reading is free; the documentation names the tools that spend credits, and an OAuth connection always carries write access, so treat it like a workspace key. There is also a REST API for your own code.