MCP explained for project leaders — or why "we have an API" is the new "we have a fax"

For twenty years the integration question in a software evaluation has been "do you have an API?" The answer was always yes. What followed was a developer, a forty-page mapping document, a connector that one person understood, and that person leaving.

That question is being replaced, and project leaders should understand the replacement before their AI tools do, because the AI tools have already started.

What MCP actually is, without the acronyms

Imagine a new colleague who is very capable, very fast, and has never seen your systems. On day one they need to know what each system can do and how to ask it. Traditionally you would write them a manual. With the Model Context Protocol, the system writes its own manual, in a form the colleague can read instantly, and the colleague can then use the system on your behalf, with your access badge.

The colleague is an AI client — Mistral, Claude, Gemini, ChatGPT, the coding tool on a developer's laptop, or an agent your organisation built. The manual is a set of tools the platform publishes with their inputs and their permissions. The badge is you.

The difference from an API is who does the integrating. With an API, a developer decides in advance which calls to make and wires them together. With MCP, the agent decides at the moment of the request, from the tools on offer, which ones answer the question. "What slipped on the customer portal programme this week?" becomes a plan read and a governance log read that the agent composes on the spot, without anyone having written that report, ever.

Why a CIO should care this quarter, not next year

Your portfolio already lives partly inside AI tools. Architects use Cursor. Programme managers draft in Mistral, Claude, Gemini or ChatGPT. Steering group members ask their assistant to summarise the pre-read on the train. If the governance record is not reachable from those tools, people paste into them anyway. Which means the most sensitive description of the business is being copied into whichever chat window is open, by whoever is in a hurry, with no permissions, no trail, and a cheerful "sure, here's the whole risk log".

An MCP surface on the governance platform is the alternative: the agent reads the record as the person, in the person's roles, through the front door. The record stays where it is. What leaves is what the agent asked for, for that person, in that session.

Five things to check before you connect anything

The protocol is neutral. What matters is how a vendor implemented it. Five checks, with TransformRadar's answers alongside so you can compare.

• Does the agent act as a named user? It should have that person's

roles on each project and not one more. TransformRadar runs every MCP call through the same permission table as a click in the interface.

• What is off by default? External access should be a decision, not a

side effect of the licence. In TransformRadar an Org Admin enables it, chooses which clients are allowed, and switches on write tiers separately; until then, nothing.

• Can a write happen without a person? It should not, ever. Every

TransformRadar write tool returns a preview and nothing is applied until the person confirms, through the same protocol as the in-app assistant. Membership, invitations and role changes are never tools at all.

• Is every call audited? Each mutation should record that it came via

MCP, by whom, and when. TransformRadar's audit log does, with soft rate limits per organisation and per user so an enthusiastic agent cannot turn into a denial-of-service attack with good intentions.

• Where does the conversation go? The agent belongs to its own

provider, so that provider processes what the agent asks for. That is a real change in who handles the data and a vendor should say so plainly. In TransformRadar the Org Admin acknowledges it before enabling access, and the platform's own AI stays on the European chain.

What a connected agent can do today

With access enabled, an agent connected to TransformRadar can read projects, the plan, the delivery backlog with its sprints and workflow states, the governance log, status reports, steering plans, value realisation and Programme Health. With the task tier on, it can prepare tasks, delivery items, governance entries and value readings. With the governance-draft tier on, it can draft the weekly status report and the steering plan. Every one of those writes lands as a preview.

In practice: a programme manager asks Claude what is overdue and unowned across three projects and gets an answer with item keys. An architect in Cursor turns a design note into delivery items under the right epic. A PMO analyst pastes a meeting transcript into ChatGPT and confirms the two risks it proposes, and declines the third because it was a joke someone made about the coffee machine. None of that needed a developer or a mapping document.

What comes next

Today the surface runs one way: agents into TransformRadar. The direction is both ways — TransformRadar's own agents asking questions of other systems' agents, a budget variance verified against the finance system's agent without anyone exporting a ledger at 11 p.m. That is the interoperability half of the agentic shift, and the roadmap post sets it out.

The MCP access page has the connection steps, the client ids and the full list of what is and is not exposed. No fax required.

• MCP
• AI
• agentic AI
• governance
• integrations