The architectural shift here is not โAI in governmentโ so much as a new integration boundary. MCP acts like a control plane between models and public systems, which means cities can stop treating every AI tool as a bespoke one-off integration. For architects, the real value is standardization: a governed way to expose datasets, service workflows, and future transactional APIs without letting each model scrape or improvise its own path.
That middle layer also changes the security model. Once agent traffic becomes a first-class workload, cities need to think about authentication, authorization, logging, rate controls, and abuse detection for machine callers, not just people in browsers. The articleโs open-data example is low risk, but the same pattern would become much more sensitive as it moves toward service requests, identity-linked interactions, or anything with eligibility, scarcity, or civil-liberties impact.
Operationally, the important trade-off is between reliability and flexibility. Pushing computation into the portal improves grounded answers and reduces dependence on model guessing, but it also means the underlying data platform must be queryable, well-described, and resilient under new usage patterns. In practice, success depends on metadata quality, API hygiene, and clear service boundaries more than on the model layer itself. Cities considering similar deployments should treat MCP as infrastructure work: it is closer to platform engineering and digital governance than to chatbot rollout.
The next wave of AI will be defined by agentic systems that can take actions: query databases, navigate portals, retrieve records, and increasingly interact with public digital infrastructure at scale.
That shift is already showing up as traffic hitting government sites and services is becoming machine traffic. Some of it is benign (search and discovery). Some of it is ambiguous (scraping and automated browsing). And some of it could become actively harmful if AI agents can reserve scarce services, submit fraudulent requests, or generate volume that overwhelms public systems.
The problem is that the governmentโs current interfaces were not designed for agent-to-government interactions, and the default state of the world has become improvisation: agents โfigure it outโ by scraping pages and guessing based on previous learning.
This is where Bostonโs work becomes instructive. Rather than treating agents as something to block wholesale, or something to embrace without guardrails, Boston is experimenting with a middle path: build a governed, secure, and reliable layer that mediates how AI agent systems interact with government resources.
Boston CIO, Santi Garces [Photo: City of Boston]
In a recent interview, Bostonโs chief information officer, Santi Garces, described why the city is investing in the Model Context Protocol (MCP) as that layer; why theyโre starting with open data as a low-risk proving ground; how theyโre improving reliability by pushing computation into the data portal itself; and what it would take for MCP-like infrastructure to become replicable digital public infrastructure that other cities can deploy.
Can you explain MCP, and why city governments should care?
MCP stands forย Model Context Protocol, and itโs relatively recent. Anthropic, the company behind Claude, launched MCP servers about a year ago. Why it matters is that it provides a way for large language models to interface with the kinds of resources we have in government. Concretely, itโs a way to connect LLMs to APIs and other programmatic systems, for example, allowing an AI assistant to retrieve transit updates or submit a service request through official city systems. We think it will be a new layer that serves as an intermediary between the governmentโs digital infrastructure and these models.
This is exciting for Boston because the world is moving fast, and weโre already seeing websites and services being activated or consumed by agents. MCP servers can serve as a layer through which the government can add governance and control.
Mechanically, an MCP server creates a set of tools. You describe, in plain language, when a tool should be used. Then you define what inputs need to be extracted from a natural-language request and how that translates into deterministic programmatic access to a resource. LLMs can be random; MCP is part of the pathway to make certain interactions more reliable and secure.
The dream is that cities invest in this infrastructure and point to different models to interact with a cityโs MCP layer, ensuring itโs reliable, secure, and provides a better experience for people using agentic systems to interact with the government. A lot has to be true for that future, but weโre very excited about it.
What normally breaks when people rely on โjust the chatbotโ and prompting, what problem is MCP solving?
Take our first MCP server: open data. If you ask Claude or ChatGPT or Gemini something like, โHow many restaurants are there in Boston,โ those models will answer using either (1) their training data, which is probably out of date, or (2) theyโll make something up. The risk of inaccuracy or hallucination is high.
It might do better if it can browse the web, but then youโre relying on it to find the right source, and we know a lot of information online is outdated or inaccurate. It might pull from an old report or an article from five years ago.
What weโve been able to do with Open Context, our first MCP instance tied to Bostonโs open data portal, is create a direct link between the portal and these AI tools. MCP servers are interoperable, so it doesnโt matter which AI tool youโre using.
If you ask an AI tool connected to this MCP server, โHow many restaurants are there in Boston given the open data portal,โ it automatically searches Bostonโs portal, finds the right dataset, and generates a SQL query against that dataset. It queries live data reliably and returns an answer grounded in the cityโs actual data infrastructure.
We spend a lot of money and time building data infrastructure that many people donโt use because itโs inconvenient. Most people donโt know SQL, and even knowing which dataset is right is hard. These tools bridge that gap, getting you to the right answer while avoiding many of the pitfalls in AI tools today.
How did you make this more trustworthy and what did the development process look like?
We started in the fall of 2025 with students from Northeasternโs AI for Impact program at the Burnes Center. Weโve been rolling out a tool to Boston city employees calledย AI Launchpad, which provides access to LLMs, but we wanted it to be more useful.
We looked at how employees use AI tools, drawing on our experience and survey data. Data analysis is a common use case. But to analyze, people have to download data, paste it into a context, and go through a lot of steps. So our starting motivation was: how do we make those workflows easier, more convenient, and more reliable?
Around that time, I was at an AI retreat in Boston and spoke with Romesh Raskar at MIT about what the agentic web will look like and the need to build an open version of it. That weekend turned into action quickly. Saturday at the retreat, then Sunday speaking at MIT, challenging people to build better agentic experiences for Boston. Then, on Monday, we said, letโs try to build an MCP server and connect it to AI Launchpad.
Because we had brilliant students, by October, we had a prototype that connected to the open data portal. Since November and December, weโve been iterating to make it more reliable. It did a good job finding datasets, but it wasnโt as strong at analyzing large datasetsโgood for small samples, less good at scale.
One innovation was to push more computation into the open data portal itself. Most data portals can run queries. So weโre using the portal to do more of the analytical work, which improves reliability and also makes the overall interaction more efficient and cost-effective.
Youโve also talked about this as a replicable layer of digital public infrastructure. What else do cities need to be able to implement this?
This is why weโre excited. With emerging technology, itโs possible weโll be using a different acronym in six months, but right now, MCP looks like a real path to solve this. We think MCP is a component of digital public infrastructure and should be tied to digital public infrastructure (DPI). The agentic web is only helpful if it creates reliable, secure intermediation that serves real human beings. AI could help if someone is busy, doesnโt speak English, or has a disability. There are many reasons this could matter for access. But without the right infrastructure, the experience becomes less reliable.
The MCP pattern is appealing because it lets you leverage existing DPI componentsโidentity, API exposures, payment APIsโby creating a middle layer between what an AI system โseesโ and the underlying infrastructure the government already has, in a way that can be made more reliable.
Weโre starting with open data because itโs low risk and already public. But it could evolve to intermediation around service requests and other interactions. We believe the government should have the capability to build and steward this. But we can also imagine vendors incorporating this type of interface into the products they sell to governments.
Letโs talk about security. What threats feel most realistic with agentic systems, and how does MCP help?
One concern is that our APIs are not always well secured. There are agentic browsers and tools that make it easy to automate interactions. And weโre seeing more and more traffic to boston.gov that isnโt from people, itโs from AI systems scraping and โdeep searching.โ
Itโs not hard to imagine AI tools also requesting services. A major risk is when an AI tool makes requests that arenโt tied to a real human need. You could have fraudulent requests or actors generating scarcity by consuming limited government resources and potentially reselling access, similar to ticket scalpers at concerts. Another risk is that without a controlled layer, itโs harder to secure and monitor the traffic between AI systems and government systems.
What excites us about MCP servers is that this middleware could make it easier to block unauthorized inbound agentic requests with cybersecurity tools, while still enabling legitimate uses. The idea is: people who need services use an authorized channel that the government controls, can associate with identity, and can monitor and secure end-to-end.
Without that middleware, government faces an uncomfortable choice: block agentic interaction entirely, or leave it open in the wild. MCP offers a middle ground: governance for agentic interactions.
Are there things youโre intentionally not exposing MCP to right now?
Weโre starting with open data. Our AI policies in Boston, rolled out a couple of months ago, state that weโre not using AI to process information that could affect peopleโs lives, property, or civil liberties because of reliability issues and intrinsic, complex biases. So, for now, those are categories we avoid. Itโs not just โa human in the loop.โ We know AI intermediation can create adverse effects that are hard to detect and remediate.
At the same time, we work closely with the disability community and with people who face language access issues. Government is hard to access for people who need it most. And those are often the same people least likely to have private access to LLMs, paid subscriptions, reliable internet, and personal devices.
If you had a magic wand, whatโs the biggest blocker youโd remove?
There are technical gaps because MCP is new. Early on, MCP servers didnโt support some authentication pieces natively; we had to add frameworks to secure them. The ecosystem is changing fast.
But the biggest thing is discoverability and ease of use. We need to get to a point where using MCP infrastructure is as easy as pointing an LLM to a URL. With websites, you type the name or use search. We need that for MCP: trivial discovery, trivial access, effectively zero barrier to entry. Weโve made it easier, but thereโs still too much technical legwork.
For another city that wants to move in this direction, what actions should they take now?
Good metadata management is essential. LLMs consume data, but they donโt understand what it is without good descriptions and context. So it starts with good data governance.
We intend to share this work. Weโre proud of it, and itโs thanks to collaboration with the GovLab and the Burnes Center that weโve been able to move quickly. We intend to make Open Context an open-source project so others can replicate it. The MCP server itself doesnโt cost a lot to run. Our goal is to make it as simple as deploying a package into whatever public cloud a city uses. The rest of the puzzle, how this ties into broader services, is something every city will have to solve, and weโre solving it in Boston, too.
But importantly, data becomes useful only when people use it. Data quality improved when we started publishing open data. We think governance and quality will improve further when more people use open data. And weโre hoping GenAI makes it easier for people to use open data, so we can solve problems collectively.
โ
A version of this interview was also published at Reboot Democracy.
https://www.fastcompany.com/91504876/boston-cio-santi-garces-on-ai-agents-mcp-open-data?partner=rss&utm_source=rss&utm_medium=feed&utm_campaign=rss+fastcompany&utm_content=rss
This is exciting for Boston because the world is moving fast, and weโre already seeing websites and services being activated or consumed by agents. MCP servers can serve as a layer through which the government can add governance and control.
Mechanically, an MCP server creates a set of tools. You describe, in plain language, when a tool should be used. Then you define what inputs need to be extracted from a natural-language request and how that translates into deterministic programmatic access to a resource. LLMs can be random; MCP is part of the pathway to make certain interactions more reliable and secure.
The dream is that cities invest in this infrastructure and point to different models to interact with a cityโs MCP layer, ensuring itโs reliable, secure, and provides a better experience for people using agentic systems to interact with the government. A lot has to be true for that future, but weโre very excited about it.
What normally breaks when people rely on โjust the chatbotโ and prompting, what problem is MCP solving?
Take our first MCP server: open data. If you ask Claude or ChatGPT or Gemini something like, โHow many restaurants are there in Boston,โ those models will answer using either (1) their training data, which is probably out of date, or (2) theyโll make something up. The risk of inaccuracy or hallucination is high.
It might do better if it can browse the web, but then youโre relying on it to find the right source, and we know a lot of information online is outdated or inaccurate. It might pull from an old report or an article from five years ago.
What weโve been able to do with Open Context, our first MCP instance tied to Bostonโs open data portal, is create a direct link between the portal and these AI tools. MCP servers are interoperable, so it doesnโt matter which AI tool youโre using.
If you ask an AI tool connected to this MCP server, โHow many restaurants are there in Boston given the open data portal,โ it automatically searches Bostonโs portal, finds the right dataset, and generates a SQL query against that dataset. It queries live data reliably and returns an answer grounded in the cityโs actual data infrastructure.
We spend a lot of money and time building data infrastructure that many people donโt use because itโs inconvenient. Most people donโt know SQL, and even knowing which dataset is right is hard. These tools bridge that gap, getting you to the right answer while avoiding many of the pitfalls in AI tools today.
How did you make this more trustworthy and what did the development process look like?
We started in the fall of 2025 with students from Northeasternโs AI for Impact program at the Burnes Center. Weโve been rolling out a tool to Boston city employees calledย AI Launchpad, which provides access to LLMs, but we wanted it to be more useful.
We looked at how employees use AI tools, drawing on our experience and survey data. Data analysis is a common use case. But to analyze, people have to download data, paste it into a context, and go through a lot of steps. So our starting motivation was: how do we make those workflows easier, more convenient, and more reliable?
Around that time, I was at an AI retreat in Boston and spoke with Romesh Raskar at MIT about what the agentic web will look like and the need to build an open version of it. That weekend turned into action quickly. Saturday at the retreat, then Sunday speaking at MIT, challenging people to build better agentic experiences for Boston. Then, on Monday, we said, letโs try to build an MCP server and connect it to AI Launchpad.
Because we had brilliant students, by October, we had a prototype that connected to the open data portal. Since November and December, weโve been iterating to make it more reliable. It did a good job finding datasets, but it wasnโt as strong at analyzing large datasetsโgood for small samples, less good at scale.
One innovation was to push more computation into the open data portal itself. Most data portals can run queries. So weโre using the portal to do more of the analytical work, which improves reliability and also makes the overall interaction more efficient and cost-effective.
Youโve also talked about this as a replicable layer of digital public infrastructure. What else do cities need to be able to implement this?
This is why weโre excited. With emerging technology, itโs possible weโll be using a different acronym in six months, but right now, MCP looks like a real path to solve this. We think MCP is a component of digital public infrastructure and should be tied to digital public infrastructure (DPI). The agentic web is only helpful if it creates reliable, secure intermediation that serves real human beings. AI could help if someone is busy, doesnโt speak English, or has a disability. There are many reasons this could matter for access. But without the right infrastructure, the experience becomes less reliable.
The MCP pattern is appealing because it lets you leverage existing DPI componentsโidentity, API exposures, payment APIsโby creating a middle layer between what an AI system โseesโ and the underlying infrastructure the government already has, in a way that can be made more reliable.
Weโre starting with open data because itโs low risk and already public. But it could evolve to intermediation around service requests and other interactions. We believe the government should have the capability to build and steward this. But we can also imagine vendors incorporating this type of interface into the products they sell to governments.
Letโs talk about security. What threats feel most realistic with agentic systems, and how does MCP help?
One concern is that our APIs are not always well secured. There are agentic browsers and tools that make it easy to automate interactions. And weโre seeing more and more traffic to boston.gov that isnโt from people, itโs from AI systems scraping and โdeep searching.โ
Itโs not hard to imagine AI tools also requesting services. A major risk is when an AI tool makes requests that arenโt tied to a real human need. You could have fraudulent requests or actors generating scarcity by consuming limited government resources and potentially reselling access, similar to ticket scalpers at concerts. Another risk is that without a controlled layer, itโs harder to secure and monitor the traffic between AI systems and government systems.
What excites us about MCP servers is that this middleware could make it easier to block unauthorized inbound agentic requests with cybersecurity tools, while still enabling legitimate uses. The idea is: people who need services use an authorized channel that the government controls, can associate with identity, and can monitor and secure end-to-end.
Without that middleware, government faces an uncomfortable choice: block agentic interaction entirely, or leave it open in the wild. MCP offers a middle ground: governance for agentic interactions.
Are there things youโre intentionally not exposing MCP to right now?
Weโre starting with open data. Our AI policies in Boston, rolled out a couple of months ago, state that weโre not using AI to process information that could affect peopleโs lives, property, or civil liberties because of reliability issues and intrinsic, complex biases. So, for now, those are categories we avoid. Itโs not just โa human in the loop.โ We know AI intermediation can create adverse effects that are hard to detect and remediate.
At the same time, we work closely with the disability community and with people who face language access issues. Government is hard to access for people who need it most. And those are often the same people least likely to have private access to LLMs, paid subscriptions, reliable internet, and personal devices.
If you had a magic wand, whatโs the biggest blocker youโd remove?
There are technical gaps because MCP is new. Early on, MCP servers didnโt support some authentication pieces natively; we had to add frameworks to secure them. The ecosystem is changing fast.
But the biggest thing is discoverability and ease of use. We need to get to a point where using MCP infrastructure is as easy as pointing an LLM to a URL. With websites, you type the name or use search. We need that for MCP: trivial discovery, trivial access, effectively zero barrier to entry. Weโve made it easier, but thereโs still too much technical legwork.
For another city that wants to move in this direction, what actions should they take now?
Good metadata management is essential. LLMs consume data, but they donโt understand what it is without good descriptions and context. So it starts with good data governance.
We intend to share this work. Weโre proud of it, and itโs thanks to collaboration with the GovLab and the Burnes Center that weโve been able to move quickly. We intend to make Open Context an open-source project so others can replicate it. The MCP server itself doesnโt cost a lot to run. Our goal is to make it as simple as deploying a package into whatever public cloud a city uses. The rest of the puzzle, how this ties into broader services, is something every city will have to solve, and weโre solving it in Boston, too.
But importantly, data becomes useful only when people use it. Data quality improved when we started publishing open data. We think governance and quality will improve further when more people use open data. And weโre hoping GenAI makes it easier for people to use open data, so we can solve problems collectively.
โ
A version of this interview was also published at Reboot Democracy.
Enjoyed this article? Sign up for our newsletter to receive regular insights and stay connected.