MCP for city IT: what the Model Context Protocol means for your systems
The Model Context Protocol lets AI assistants use tools in other systems. What it is in plain terms, where it helps city IT, and the access controls to insist on before connecting anything.
AI assistants are only as useful as what they can reach. On its own, an assistant can answer general questions. Connected to your systems, it can tell you which integration failed last night, or why. The Model Context Protocol (MCP) is an open standard for making those connections.
This post explains MCP in plain terms, where it can help a city IT team, and the guardrails to put in place first.
What MCP is
MCP defines a standard way for an AI assistant to discover and call tools offered by another system. A system that offers tools is an MCP server. An assistant that uses them is an MCP client.
A tool is a specific action with a description and inputs, such as "list failed runs from the last day" or "look up a parcel by address". The assistant reads the descriptions, decides which tool fits the question, and calls it.
Before MCP, each assistant needed its own custom integration for each system. With MCP, a system describes its tools once and any compatible assistant can use them.
Two directions
For an integration platform, MCP works both ways.
Your assistant reads your integrations
The platform offers tools to your assistant. A staff member can ask:
- "Which flows failed in the last 24 hours, and why?"
- "Trace permit B-2041. Did it reach the GIS layer?"
- "Explain the payment posting flow for the new analyst."
- "Draft a flow that copies closed 311 requests into the reporting database."
The assistant answers by calling the platform's tools, within that person's access.
Your flows use other systems' tools
The platform can also act as an MCP client: a step in a flow calls a tool on another system's MCP server, such as a parcel lookup for each record, or opening a ticket.
Where it helps city IT
- Faster troubleshooting. Ask what failed instead of clicking through run history.
- Handover. New staff can ask an assistant to explain flows in plain language.
- Drafting. Describe a new integration and review the draft, rather than starting from a blank canvas.
- Reaching systems with MCP servers. As more vendors offer MCP servers, flows can use their tools without a custom connector.
The guardrails to insist on
Connecting an AI assistant to systems that move resident data needs the same care as any other access.
Personal tokens, capped by role
The assistant should connect with a token belonging to a specific person, and be able to do no more than that person can. A viewer's token shouldn't be able to run flows.
Expiry and revocation
Tokens should be able to expire, and be revoked at once. Tokens shouldn't be able to create more tokens.
Network limits
If sign-in is limited to your networks, assistant access should be too.
Drafts only
An assistant should be able to draft flows, not turn them on or change flows that are running. A person reviews and turns on every flow.
Safe preview
When a flow calls another system's MCP tools, preview should only call tools that the server marks as read-only, so trying a flow never changes anything.
Everything logged
Every call an assistant makes should appear in the activity log: who, when and which tool.
What it doesn't change
MCP is a way to connect; it doesn't decide what an assistant should see. The usual questions still apply. Does the assistant receive record contents, or only settings and metadata? Which AI provider processes the conversation, and under what terms? Involve your security and privacy staff before connecting assistants to anything sensitive.
Getting started
- Pick one low-risk use, such as asking about run health, and try it with IT staff only.
- Use read-only roles at first.
- Review the activity log after the first week.
- Expand to drafting once people are comfortable with how it behaves.
In SentraBridge
SentraBridge is an MCP server: assistants such as Claude can list flows, explain them, check run health, trace a record and draft new flows, using a personal token capped by the person's role. Drafts arrive turned off, running flows can't be changed, and every call is logged.
In the other direction, the Call an MCP tool step uses any MCP server's tools in a flow, and preview only calls read-only tools. See MCP for developers.