For most of the generative AI boom, companies focused on the model itself.
They compared model quality, context windows, response speed, hallucination rates, coding ability, and cost. Startup teams spent months deciding whether to build on OpenAI, Anthropic, Google, or an open-source model, while engineering discussions often centered on prompts, retrieval systems, and fine-tuning.
Those questions still matter, but a different problem is becoming just as important.
AI systems increasingly need to interact with the software, databases, tools, and business systems where real work happens.
A model may understand a request perfectly, but that does not help much if it cannot retrieve the latest customer record, check a network environment, inspect a software error, read a company’s internal knowledge, create a marketing campaign, or update an operational system.
This is the problem that the Model Context Protocol, or MCP, is trying to solve.
Anthropic introduced MCP in November 2024 as an open standard for connecting AI applications to outside tools and data sources. Instead of developers building a different custom integration every time an AI system needs access to another platform, MCP provides a common structure for exposing selected capabilities to compatible AI applications.
That idea is becoming increasingly important because AI is moving beyond simple conversation.
The first generation of generative AI mostly answered questions. The next generation is being designed to complete tasks, call software tools, make decisions, update records, and move through workflows with much less human input.
Once AI begins doing that, connectivity becomes infrastructure.
Boston is becoming one of the more interesting places to watch this shift because companies across the region are already using MCP in very different industries.
HubSpot has built MCP access around CRM workflows. Klaviyo has created MCP capabilities for marketing data and campaign operations. Dynatrace uses MCP to connect AI systems with observability data. DataRobot exposes AI functionality through MCP. SmartBear is bringing MCP into software development workflows. IP Fabric connects agents to network intelligence, while LogRocket gives agents access to product experience information.
Cybersecurity research company IANS has also launched MCP access, and BCC Research has created MCP-based access to market intelligence. Even the City of Boston has experimented with an open-source framework that connects AI systems to public civic data.
Taken together, these examples suggest that Boston’s MCP opportunity is much broader than simply building developer tools.
The larger opportunity is to make valuable software, data, and business capabilities usable by AI systems in a secure and structured way.
The Short Version: MCP Could Become the Connection Layer Between AI Agents and Boston Software
The easiest way to understand MCP is to look at the problem it is trying to remove.
Imagine that a Boston startup is building an AI sales agent.
The agent needs to retrieve customer records from a CRM, review previous sales activity, check product information, inspect support history, schedule a meeting, prepare a quote, and then update the customer record after the work is complete.
Without a shared standard, every one of those connections can become its own engineering project.
The CRM may have one authentication system and one API structure. The support platform may use something completely different. The calendar may have another set of permissions, while the product database may require a custom internal integration.
Now imagine that the same company wants several AI agents to access those same systems.
The number of integrations grows quickly, and engineering teams end up rebuilding similar connection logic again and again.
MCP tries to simplify that situation by creating a common interface that AI applications can understand.
Instead of teaching each AI system separately how every outside platform works, a company can expose selected tools, resources, and workflows through an MCP server.
Compatible AI applications can then discover those capabilities in a more standardized way.
This does not remove the need for APIs, security, authentication, or business logic. It simply creates a more consistent layer between the AI system and the underlying software.
A simplified MCP architecture looks like this:
| Layer | Main role |
| AI model | Understands the task and reasons about what to do |
| Agent or AI application | Manages the broader workflow |
| MCP client | Connects the AI application to MCP services |
| MCP server | Exposes approved tools, resources, and capabilities |
| Existing systems | CRM, databases, APIs, infrastructure, files, SaaS platforms |
| Business outcome | The actual task the user wanted completed |
This architecture changes one important assumption about software.
For decades, most software products were primarily designed around human users.
People logged into an application, navigated menus, opened dashboards, clicked buttons, entered data, and moved information between systems.
The agentic AI model creates a second type of user.
Software itself can begin using other software.
That leads to a new product question for Boston SaaS companies.
Instead of asking only, “How should a human interact with our product?” companies may increasingly need to ask, “How should an AI agent safely interact with our product?”
MCP is becoming one possible answer.
What Exactly Is the Model Context Protocol?
MCP stands for Model Context Protocol.
At its core, it is a standard for connecting AI applications with external systems.
Those systems can include databases, SaaS platforms, internal tools, APIs, files, developer environments, research systems, and other sources of information or functionality.
The word “context” sometimes causes confusion because it can make MCP sound like a system that simply gives an AI model more documents to read.
That is only one part of what MCP can do.
An MCP server can expose information, but it can also expose tools that allow an AI system to perform actions.
That distinction is important because it marks the difference between an AI assistant that only knows things and an AI agent that can participate in work.
MCP Can Give AI Access to Current Information
Imagine a life-sciences company in Cambridge that maintains an internal database of research procedures.
An internal AI assistant may need access to those procedures when helping researchers answer questions.
Instead of relying on information stored in the model’s training data, the AI can retrieve current internal information through an approved MCP connection.
That means the model can work with the latest version of the company’s knowledge rather than relying on old or incomplete information.
MCP Can Give AI Access to Software Tools
Now imagine the same company has another internal system that tracks laboratory inventory.
An MCP server could expose a tool such as:
check_inventory
The AI does not need to understand every database table or backend service behind that tool.
It only needs to understand what the tool does, what information it requires, and what kind of result it returns.
This creates a cleaner boundary between the AI and the underlying software.
MCP Can Let AI Perform Approved Actions
The model becomes more powerful when the MCP layer includes write actions.
A CRM MCP server could allow an agent to retrieve a customer record, add a note, update a sales opportunity, or change another approved field.
A marketing MCP server could allow an agent to inspect campaign performance and then create a draft campaign.
A developer tool might allow an agent to inspect code quality, run a test, or retrieve an error.
The important point is that MCP can give AI systems controlled authority, not just information.
Once that happens, identity, permissions, security, logging, and human approval become central product concerns.
Why MCP Is Attracting So Much Attention
Technology standards appear constantly, and many disappear just as quickly.
That means founders should be careful about treating any emerging protocol as inevitable.
MCP is still evolving, and it would be premature to claim that it will become the universal standard for AI integrations.
However, it is receiving serious attention for a very practical reason.
Software teams are tired of rebuilding similar integration logic.
When many AI applications need to reach many business systems, point-to-point integrations become expensive to maintain.
Standardization can reduce some of that repeated work.
The comparison with the early web is useful, although it should not be taken too literally.
HTTP did not eliminate websites, servers, or application logic. Instead, it created a common communication layer that allowed many systems to interact in predictable ways.
MCP is attempting something similar for AI applications and external tools.
If enough software providers adopt a shared way of exposing agent-friendly capabilities, AI builders can spend less time creating one-off connection layers and more time designing useful workflows.
That shift could change the economics of agent software.
The Integration Problem MCP Is Trying to Reduce
Consider a company with five AI applications that need to reach eight outside systems.
If every application requires a custom connection to every system, the company could face as many as 40 different integration relationships.
As the environment grows, the complexity grows much faster.
Illustrative Integration Burden
| Architecture | Potential point-to-point relationships |
| 5 AI applications × 8 systems | 40 |
| 10 AI applications × 20 systems | 200 |
| 20 AI applications × 50 systems | 1,000 |
This table is intentionally simple because real enterprise architecture is more complex.
MCP does not magically turn hundreds of integrations into one connection. Companies still need identity management, permissions, schemas, testing, monitoring, and business logic.
What MCP can do is standardize the way AI applications discover and call those capabilities.
That changes where engineering effort is spent.
Instead of every AI system learning a custom interface, the MCP server can expose tools through a common structure.
That is where the leverage comes from.
What Happens When an AI Agent Uses MCP?
A basic MCP workflow can be understood as a sequence of connected steps.
Imagine that a Boston sales manager asks an internal AI agent:
“Find our largest stalled deals and identify the accounts that have not received a follow-up in the past two weeks.”
The user’s request sounds simple, but the agent may need several systems to complete it.
Step 1: The User Defines the Outcome
The user starts with a business objective rather than an API instruction.
They care about finding stalled deals and improving follow-up.
They do not care which endpoint needs to be called.
Step 2: The Agent Determines What Information Is Needed
The AI may decide it needs to retrieve deal values, pipeline stages, activity history, account owners, and recent communications.
If the workflow also includes updating the CRM, the agent may need additional permission to write back to the system.
Step 3: The MCP Client Discovers Available Capabilities
The compatible AI application can inspect the tools made available through the MCP server.
Those tools include structured descriptions of what they do and what inputs they expect.
The agent can then decide which tool is relevant to the task.
Step 4: The Tool Is Called
The AI sends a structured request through the MCP connection.
The server then communicates with the underlying application, database, API, or service.
Step 5: The Result Returns to the Agent
The agent receives the output, reasons about it, and decides what should happen next.
It may call another tool, request approval, update a record, or present the final answer to the user.
This is very different from a simple chatbot session.
The AI is no longer only generating text.
It is participating in a workflow.
Why MCP Matters More in the Agentic AI Era
MCP arrived at an important moment in the development of AI software.
The first wave of generative AI products largely revolved around conversation.
A user asked a question, and the system generated an answer.
That model created useful products, but the AI usually stopped once the answer was delivered.
Agentic AI is designed to go further.
An agent can receive an objective, gather information, choose tools, perform actions, evaluate the results, and continue working until the task is complete or until human approval is required.
That model creates a new technical requirement.
Agents need reliable access to outside systems.
Without tools, an agent is limited.
With dozens of brittle custom integrations, the system becomes difficult to maintain.
MCP sits directly between those two problems.
Original BostonBizScene Research: Tracking Boston’s Public MCP Adoption
To understand whether MCP is actually gaining traction in Boston, rather than simply generating online attention, BostonBizScene reviewed publicly available evidence from Boston-area technology and information companies.
The goal was not to create a complete list of every organization experimenting with MCP.
That would not be possible because many implementations are private.
Instead, we created a deliberately conservative public sample.
Methodology
An organization was included in the core commercial sample only when two conditions were met.
First, it had a meaningful Boston-area headquarters, corporate presence, or well-documented operation.
Second, there was public evidence of an MCP server, MCP product capability, or substantial MCP implementation.
For every included company, we recorded the earliest clear public launch or announcement date that could be verified.
The resulting sample contains nine organizations.
| Organization | Boston-area connection | Public MCP evidence | Earliest verified public MCP date |
| HubSpot | Cambridge headquarters | Remote MCP server | May 6, 2025 |
| Klaviyo | Boston headquarters | Klaviyo MCP Server | Aug. 20, 2025 |
| SmartBear | Somerville headquarters | Swagger/SmartBear MCP capabilities | Aug. 28, 2025 |
| BCC Research | Boston headquarters | Public and subscriber MCP services | Nov. 21, 2025 |
| Dynatrace | Boston headquarters | Dynatrace MCP Server | Jan. 28, 2026 |
| IP Fabric | Boston headquarters | MCP Server | Apr. 22, 2026 |
| DataRobot | Boston headquarters | Global MCP server | Apr. 27, 2026 |
| LogRocket | Boston headquarters | LogRocket MCP | June 9, 2026 |
| IANS | Boston presence | Cybersecurity MCP server | July 15, 2026 |
The sample is intentionally narrow.
We did not include companies simply because they mentioned MCP in a blog post, job listing, or conference presentation. We required evidence of a real product capability or deployment.
That decision almost certainly understates the true level of activity, but it makes the resulting analysis more defensible.
Original Finding #1: Boston’s Visible MCP Adoption Expanded Quickly
The earliest implementation in our core sample was HubSpot’s public MCP beta on May 6, 2025.
The most recent was IANS’ MCP launch on July 15, 2026.
That means the entire public rollout represented in our sample occurred over approximately 435 days.
Cumulative MCP Adoption in the BostonBizScene Sample
May 2025 █ 1
Aug 2025 ███ 3
Nov 2025 ████ 4
Jan 2026 █████ 5
Apr 2026 ███████ 7
Jun 2026 ████████ 8
Jul 2026 █████████ 9
The number nine is not important by itself.
What matters is the range of industries represented.
Within a little over fourteen months, publicly visible MCP products appeared in CRM, marketing, developer tooling, market intelligence, observability, network operations, AI infrastructure, product analytics, and cybersecurity.
That diversity suggests MCP is moving beyond a narrow developer trend.
Original Finding #2: Adoption Continued Into MCP’s Second Year
Four organizations in the core sample launched publicly documented MCP capabilities during 2025.
Five additional organizations appeared in 2026.
MCP Launches by Year
| Year | Companies | Share of sample |
| 2025 | 4 | 44.4% |
| 2026 through July 15 | 5 | 55.6% |
The median launch date in the sample is January 28, 2026, which corresponds with the Dynatrace MCP Server announcement.
That is significant because it suggests Boston MCP activity did not peak immediately after Anthropic introduced the protocol.
Instead, adoption continued as the ecosystem matured.
That is a healthier signal than a short-lived burst of experimentation.
Original Finding #3: MCP Adoption Is Spread Across Several Boston Technology Strengths
We grouped the companies according to the main business function their MCP capabilities support.
The distribution is surprisingly balanced.
Primary Business Function in the Sample
Customer and marketing ██ 22.2%
Software development ██ 22.2%
AI and observability ██ 22.2%
Cyber and network ██ 22.2%
Research intelligence █ 11.1%
No single category dominates.
That matters because it shows MCP is not limited to coding agents or developer tools.
It is appearing wherever software contains valuable data or meaningful business actions.
Boston MCP Activity by Business Area
| Area | Examples | What AI can potentially access |
| CRM and marketing | HubSpot, Klaviyo | Customers, deals, campaigns, performance |
| Development and product | SmartBear, LogRocket | APIs, tests, errors, user behavior |
| AI and operations | DataRobot, Dynatrace | Models, production systems, telemetry |
| Cybersecurity and networking | IANS, IP Fabric | Security intelligence, network state |
| Research | BCC Research | Market intelligence and proprietary analysis |
For founders, this is one of the most important findings in the entire dataset.
MCP is not tied to one vertical.
The opportunity appears wherever there is useful context or a valuable business action that an AI system needs to reach.
Original Finding #4: Boston Companies Are Connecting Agents to Operational Systems
The next important pattern is the type of information being exposed.
These are not mainly document libraries.
HubSpot connects agents to CRM records and write actions.
Klaviyo connects agents to campaign data and marketing workflows.
Dynatrace gives AI systems access to production observability information.
IP Fabric connects agents with network state.
LogRocket exposes product experience signals.
DataRobot exposes AI platform capabilities.
This points to a major shift in enterprise AI.
Early enterprise deployments focused heavily on retrieval.
The most common use cases looked like this:
“Find this policy.”
“Summarize this document.”
“Answer a question using this knowledge base.”
The newer MCP pattern is much more operational.
“Inspect this customer.”
“Check this network.”
“Analyze this incident.”
“Create this campaign.”
“Update this record.”
“Investigate this software problem.”
That difference is crucial.
The value is shifting from AI that simply knows more toward AI that can participate in real work.
The City of Boston Is Experimenting With the Same Idea
The local MCP story extends beyond private companies.
The City of Boston has published an open-source project called OpenContext that is designed to make civic data easier for AI systems to access through an MCP-style interface.
The project provides a useful example because civic data can be difficult to navigate manually.
Imagine asking:
“How many pothole complaints were reported in a specific Boston neighborhood over the past six months?”
A general AI model may try to answer using old information, a search result, or an article.
An AI system connected directly to Boston’s underlying data could instead query the source.
That changes the nature of the answer.
The AI is no longer guessing from what it may have learned.
It is interacting with the system that holds the information.
That same pattern can apply to enterprise software.
Why Boston Is a Natural Market for MCP
MCP is a global protocol, so there is nothing inherently Boston-specific about the technology.
However, Boston has several characteristics that make the region a particularly strong fit.
Boston Has a Deep Enterprise Software Base
MCP becomes more valuable when a company already controls useful workflows, structured data, APIs, or systems of record.
Boston has spent decades building companies in exactly those areas.
The local ecosystem includes enterprise software, cybersecurity, developer tooling, cloud infrastructure, analytics, healthcare technology, biotechnology, robotics, and financial services.
Those companies already possess the raw ingredients agents need.
The new challenge is exposing those capabilities safely.
Boston Is Strong in High-Stakes Industries
MCP matters more when mistakes are expensive.
A consumer chatbot may be able to tolerate an occasional bad answer.
A hospital, financial institution, research lab, cybersecurity team, or industrial operator cannot tolerate an autonomous system taking the wrong action.
That means the real challenge is not simply connecting AI to tools.
The harder challenge is deciding what the AI is allowed to do.
Which systems can it access?
Which records can it read?
What can it change?
What requires approval?
What must be logged?
How should malicious content be handled?
Boston’s concentration in regulated and technically demanding industries makes those questions especially relevant.
Boston Already Has Strong Infrastructure Expertise
Many local companies have spent years solving problems around APIs, observability, software quality, cloud infrastructure, and cybersecurity.
That expertise transfers directly into MCP.
A badly designed API creates developer problems.
A badly designed AI tool can create autonomous workflow problems.
A poorly secured MCP endpoint can expose systems that should never be accessible to an agent.
Boston’s existing infrastructure strength could therefore become an important advantage.
MCP Does Not Replace APIs
One misconception needs to be cleared up immediately.
MCP is not replacing APIs.
In many products, the MCP layer will simply sit on top of existing APIs.
The API still connects software systems at the technical level.
MCP provides a more agent-friendly structure for discovering and calling selected capabilities.
Traditional APIs Versus MCP
| Question | Traditional API | MCP |
| Main consumer | Developers and applications | AI applications and agents |
| Discovery | Documentation | Structured capability discovery |
| Integration style | Application-specific | Standardized agent-facing interface |
| Natural-language workflow | Requires additional layer | Common use case |
| Underlying backend replaced? | No | No |
This distinction matters because startups do not necessarily need to rebuild their core systems.
They may simply need a safer and clearer agent-facing layer over what already exists.
The Biggest Opportunity May Be Turning Existing Software Into Agent-Ready Infrastructure
A common mistake in the AI market is assuming every company needs to build a new general-purpose agent.
Many of the strongest opportunities may instead come from existing software companies that already own important workflows.
Imagine a Boston procurement startup.
Today, its customers log into a dashboard, search suppliers, compare quotes, review contracts, and approve purchase orders.
In a more agentic environment, the customer’s internal purchasing agent may want to perform some of those tasks directly.
That changes the product roadmap.
The right question is no longer:
“How do we add an AI chatbot?”
The better question is:
“What should an authorized agent be allowed to do through our system?”
That is a much more strategic design problem.
Tool Design Is Becoming Product Design
Traditional SaaS teams spend enormous effort on user interfaces.
They think about menus, dashboards, buttons, navigation, labels, onboarding, and error states.
Agent-facing software introduces another interface.
The tool itself becomes part of the product experience.
Suppose an MCP server exposes a capability named:
get_customer
That tool needs a clear purpose.
Its description must explain when it should be used.
Its inputs must be predictable.
Its output must be structured.
Its permissions must be narrow.
Now compare that with a tool named:
manage_customer
The second name is far more ambiguous.
What does “manage” mean?
Can it read?
Can it edit?
Can it delete?
Can it send messages?
These details matter because the AI is making decisions based partly on the tool descriptions it receives.
That means tool design is not merely documentation.
It is part of product design and part of the security model.
Boston Startups Should Think in Terms of Capabilities, Not Pages
A useful exercise is to ignore the user interface for a moment and list the actual jobs customers perform.
A cybersecurity product may allow users to investigate alerts, inspect assets, retrieve vulnerability information, recommend remediation, and create tickets.
A healthcare operations product may allow users to check scheduling availability, verify administrative requirements, retrieve workflow guidance, and create follow-up tasks.
A financial platform may allow users to retrieve positions, compare risk, prepare reports, and submit actions for approval.
These jobs are more useful than pages when thinking about MCP.
Each one can potentially become a carefully controlled agent capability.
What Boston Companies Can Learn From Klaviyo
Klaviyo provides one of the clearest local examples of how MCP can change distribution.
Its MCP capabilities allow compatible AI applications to interact with marketing data and workflows.
That means users do not always need to begin inside the Klaviyo interface.
An AI assistant can potentially retrieve campaign information, analyze performance, or help create work through an external environment.
The strategic lesson is larger than marketing.
Klaviyo does not have to own every interface where its product creates value.
Its capabilities can travel into other AI experiences.
That is a major change from traditional SaaS.
In the old model, the user travelled to the software.
In the agent model, parts of the software can travel to the user’s agent.
What Boston Companies Can Learn From HubSpot
HubSpot illustrates the same shift in CRM.
Its MCP capabilities allow compatible AI systems to access CRM information and perform approved write actions while respecting existing user permissions.
That detail matters.
The CRM does not disappear.
HubSpot’s database remains the source of truth.
Its permission system still matters.
The existing product still matters.
MCP simply adds another controlled access layer.
That could become a common enterprise design pattern.
What Boston Companies Can Learn From Dynatrace
Dynatrace offers a useful example from observability.
Its MCP tools allow AI applications to work with live production information, investigate problems, analyze events, examine vulnerabilities, and interact with operational data.
This is important because operations teams already work across too many systems.
Logs may live in one place.
Code may live in another.
Tickets may live somewhere else.
Infrastructure information may sit in another dashboard.
An AI agent that can securely connect those pieces could reduce the manual work required to investigate incidents.
That is a much more valuable use case than simply adding chat to a dashboard.
What Boston Companies Can Learn From LogRocket
LogRocket points toward an even more interesting future.
Its MCP approach gives AI systems access to information about how users are actually experiencing a software product.
That means a coding agent could potentially inspect a real user problem, connect that information with software code, and use the evidence when investigating a bug.
This creates a powerful loop.
User behavior becomes context for software development agents.
The observability layer and the coding layer begin to connect.
That combination could become an important market in its own right.
What Boston Companies Can Learn From IP Fabric
IP Fabric shows why permissions matter.
Its MCP capabilities can expose network information that may include inventory, topology, paths, routing behavior, and operational state.
That information is extremely valuable, but it is also sensitive.
A network agent should not automatically receive unlimited authority simply because it can retrieve data.
This is where role-based access, scoped permissions, and audit logs become essential.
The more powerful the underlying system, the more important the control layer becomes.
What Boston Companies Can Learn From BCC Research and IANS
MCP is also changing the way proprietary information can be distributed.
BCC Research has used MCP to expose market intelligence.
IANS has used MCP to provide cybersecurity knowledge.
This creates a major opportunity for Boston because the region has a large research economy.
Universities, research organizations, legal databases, life-sciences companies, financial information providers, technical publishers, and specialist consultancies all own knowledge that general AI models may not have.
Historically, those organizations distributed information through reports, PDFs, websites, portals, and APIs.
MCP creates another distribution channel.
Their knowledge can become directly usable inside AI workflows.
Original Finding #5: MCP Is Creating a New Software Distribution Model
The Boston commercial sample can be divided into two broad strategies.
Strategy One: Make Existing Software Accessible to Agents
This includes companies such as HubSpot, Klaviyo, Dynatrace, SmartBear, DataRobot, IP Fabric, and LogRocket.
Their core product remains the same.
MCP simply allows approved agents to access selected capabilities.
Strategy Two: Make Proprietary Information Accessible to Agents
BCC Research and IANS fit this pattern.
Their value comes partly from specialized knowledge.
MCP creates a new way to distribute that knowledge into AI systems.
Both strategies lead to the same conclusion.
Customers may increasingly receive value from a software product without spending the entire workflow inside that product’s interface.
That has major implications for SaaS distribution.
From SaaS Distribution to Agent Distribution
Traditional SaaS often follows a familiar funnel.
Search
↓
Website
↓
Signup
↓
Dashboard
↓
Human completes workflow
↓
Value
Agent-based distribution can look very different.
User asks AI
↓
Agent identifies required capability
↓
Agent connects through MCP
↓
Software performs the work
↓
Structured result returns
↓
Agent continues the workflow
The vendor still owns the software.
However, the agent may increasingly own the interaction layer.
That creates both opportunity and risk.
The Opportunity: Your Product Can Appear in More Workflows
A well-designed MCP service can make a company’s capabilities available inside multiple AI applications.
That can lower distribution friction.
It can also allow customers to combine different software tools in ways the vendor never had to build directly.
This can expand the number of workflows in which the product creates value.
The Risk: The User Interface May Become Less Central
If customers increasingly work through AI agents, they may visit individual SaaS dashboards less often.
That does not necessarily reduce the value of the software.
The underlying system may become even more important.
However, the product may lose some control over the user relationship.
That is why MCP should not be treated as a simple engineering feature.
It can affect product strategy, pricing, distribution, and customer ownership.
“We Support MCP” Will Not Be a Lasting Advantage
As standards spread, support becomes expected.
The same thing happened with APIs, SSO, webhooks, and many other software features.
The real advantage will come from the value behind the connection.
Two vendors may both support MCP, but one may offer generic information that can easily be found elsewhere while the other owns unique proprietary data, deeply embedded workflows, trusted permissions, and actions that customers rely on daily.
Those products are not equally valuable.
MCP can expose a capability.
It does not create the underlying moat.
The Best MCP Businesses Will Own Unique Data or Important Actions
Founders should evaluate their products through two questions.
What Information Do We Have That an Agent Cannot Easily Get Elsewhere?
The answer might include proprietary scientific data, security research, operational history, customer behavior, private financial records, infrastructure telemetry, or specialized internal knowledge.
What Valuable Action Can Our Product Perform?
The answer might include running a simulation, updating a CRM, testing software, creating a campaign, checking a network path, executing a workflow, or producing a regulated report.
The strongest agent-facing products may combine both.
They own useful information and the ability to do valuable work with it.
MCP Could Improve AI Startup Architecture
Early AI products often place everything inside one application.
The agent, prompts, tools, integrations, and workflow logic are tightly connected.
That architecture can work when the system has only a few capabilities.
It becomes harder to manage as the number of tools grows.
MCP offers a cleaner separation between the reasoning layer and the tool layer.
A startup can update or replace the agent while keeping the tools stable.
It can also update the tools without rewriting the entire reasoning system.
That modularity can become increasingly valuable as AI models change quickly.
Enterprise MCP Is Becoming More Important Than Local MCP Demos
Early MCP usage often happened locally on developer machines.
That was useful for experimentation, but large organizations need much more.
Production systems require authentication, identity, gateways, load balancing, monitoring, caching, versioning, and reliable permission controls.
The protocol has been evolving in that direction.
That matters because MCP will only become strategic if it can operate safely inside enterprise infrastructure.
Boston companies already know how difficult that work is.
The opportunity may therefore shift from building simple MCP connectors toward building enterprise-grade agent infrastructure.
Security Is the Central MCP Problem
The moment an AI can perform actions, security becomes inseparable from product design.
A chatbot that makes a mistake may provide a bad answer.
An agent with write access can do much more damage.
It could change a customer record, send the wrong communication, expose confidential information, trigger an expensive process, or alter production data.
The more authority the agent receives, the more important the control layer becomes.
An Agent Should Not Automatically Receive a User’s Full Permissions
A common mistake is giving the AI the same access as the person using it.
That can create unnecessary risk.
A chief executive may have broad access to company systems, but that does not mean every AI workflow launched by that executive should inherit the same authority.
Permissions should match the task.
A reporting agent may only need read access.
A sales agent might be allowed to prepare CRM changes but require approval before writing them.
An infrastructure agent might be allowed to inspect production systems but not deploy code.
The correct question is not “What can the user do?”
The better question is “What does this agent need to do for this specific workflow?”
Read-Only Access Is an Important Starting Point
Companies do not need to jump directly from no AI access to full autonomy.
A staged approach is much safer.
Practical Agent Authority Ladder
| Level | Agent authority |
| 0 | No external system access |
| 1 | Read public information |
| 2 | Read approved private information |
| 3 | Prepare a recommended action |
| 4 | Execute low-risk reversible actions |
| 5 | Execute sensitive actions with approval |
| 6 | Execute defined workflows autonomously |
Most organizations should not begin at Level 6.
They should move upward only when reliability, security, and governance have been demonstrated.
Prompt Injection Becomes More Serious When Agents Have Tools
Prompt injection is already a concern for AI assistants.
The risk becomes larger when the assistant can take actions.
Imagine an AI agent reading a support ticket that contains malicious instructions designed to influence its behavior.
If the system does not clearly separate trusted instructions from untrusted content, the agent may make a poor decision.
That means companies need clear boundaries between system policy, user instructions, external content, tool output, and untrusted data.
Any organization connecting AI to operational systems should assume that hostile instructions will eventually reach the model.
Tool Descriptions Are Part of the Security Model
A tool description does more than explain a feature.
It influences whether the AI chooses to use that capability.
That makes clarity essential.
Compare:
manage_customer
with:
get_customer_contact_details_read_only
The second description is more specific.
The AI has a better understanding of its purpose and limitations.
Narrow tools reduce ambiguity.
They also make permissions easier to control.
High-Impact Actions Need Full Audit Trails
When agents perform important actions, companies need to reconstruct exactly what happened.
A useful audit trail should answer several questions.
Who initiated the task?
Which agent made the tool call?
Which tool was selected?
What inputs were provided?
Which permission was used?
What information was returned?
Was approval required?
What changed as a result?
What happened next?
Without this visibility, it becomes difficult to trust autonomous workflows.
Boston Startups Should Build an MCP Risk Matrix
Before exposing tools, companies should evaluate their risk.
A simple framework can look at two dimensions:
the impact of an incorrect action and the difficulty of reversing it.
MCP Tool Risk Matrix
| Example capability | Impact if wrong | Reversibility | Recommended starting control |
| Search documentation | Low | Easy | Automatic |
| Read analytics | Low | Easy | Automatic |
| Draft CRM update | Low | Easy | Automatic draft |
| Change CRM field | Medium | Usually reversible | Scoped write |
| Send customer message | Medium to high | Difficult | Human approval |
| Delete production data | Very high | Difficult | Do not expose initially |
| Move money | Very high | Difficult | Strong policy and approvals |
This framework can be expanded later with data sensitivity, regulatory risk, financial impact, and operational blast radius.
The important point is to evaluate risk before giving the agent authority.
The MCP KPI Dashboard Boston Companies Should Build
Launching an MCP server is not a business outcome.
The goal is to complete useful work more efficiently and reliably.
That means companies should measure performance at the workflow level.
Recommended MCP KPIs
| KPI | Why it matters |
| Successful tool-call rate | Measures technical reliability |
| Task completion rate | Shows whether the workflow succeeds |
| Wrong-tool selection rate | Reveals routing and description problems |
| Human approval rate | Indicates trust in proposed actions |
| Human override rate | Shows how often AI decisions are rejected |
| Median task time | Measures workflow speed |
| Cost per completed task | Tests economic viability |
| Permission-denied rate | Reveals poor access design |
| Repeated-call rate | Identifies inefficient agent behavior |
| Human minutes saved | Measures operational impact |
| Reversal rate | Shows how often actions must be corrected |
These numbers are much more important than the number of MCP connections a company has created.
A demo can look impressive while the underlying workflow performs badly.
Production systems cannot survive that way.
Start With One Workflow Instead of Dozens of Tools
One of the biggest mistakes companies can make is exposing too many tools too quickly.
A large tool set creates more choice for the agent, but it also increases ambiguity.
The AI may choose the wrong capability.
Permissions become more complicated.
Testing takes longer.
Debugging becomes harder.
A better approach is to begin with one measurable workflow.
For example:
“Investigate an enterprise support escalation.”
That workflow may only require five tools:
retrieve the customer,
retrieve recent tickets,
retrieve product telemetry,
search internal documentation,
and prepare an escalation summary.
That is enough to test whether MCP creates real value.
A 90-Day MCP Plan for Boston Startups
Companies should treat MCP as product infrastructure rather than a hackathon experiment.
A disciplined rollout can happen in three stages.
Days 1–30: Map the Workflow
Choose one business process that is frequent, expensive, or slow.
Interview the people who perform it.
Document every system they use.
Measure how long the task takes today.
Identify where human judgment is required.
Then decide which parts an agent could safely handle.
Do not start by asking which tools can be exposed.
Start with the job that needs to become easier.
Days 31–60: Build the Smallest Useful MCP Surface
Expose only the capabilities required for that workflow.
Keep tool names clear.
Give each tool one job.
Use narrow permissions.
Return structured outputs.
Log every call.
Design obvious failure states.
Keep sensitive write actions behind approval wherever possible.
Then test the workflow against realistic edge cases.
Days 61–90: Measure Business Performance
Move the system into a controlled production environment.
Measure completion rate, time saved, tool-selection errors, human corrections, workflow cost, reliability, and user trust.
Review failures manually.
Then decide whether the agent should receive more authority.
The system should earn autonomy through evidence.
Where New Boston MCP Startups Could Be Built
The most obvious opportunity is helping software companies create MCP servers.
That is useful, but the larger markets may sit around the protocol.
Opportunity 1: MCP Security
Every enterprise will need to control which agents can reach which tools.
That creates demand for products focused on policy enforcement, authentication, permission management, prompt-injection protection, runtime monitoring, audit logs, and tool approval.
As the number of agents increases, these controls become more valuable.
Boston’s cybersecurity ecosystem gives local founders a natural advantage.
Opportunity 2: MCP Observability
Agent systems can fail even when every individual API request technically succeeds.
The model may choose the wrong tool.
It may use the correct tool with the wrong arguments.
It may repeat calls unnecessarily.
It may take an expensive path when a cheaper one was available.
It may complete a task incorrectly even though every connection worked.
That creates a need for observability focused on agent behavior rather than ordinary software uptime.
Boston already has deep expertise in this category.
Opportunity 3: MCP Gateways
Large enterprises will not want hundreds of AI agents connecting directly to sensitive systems.
They are likely to want a controlled gateway.
That gateway could manage identity, authorization, tool discovery, routing, logging, rate limits, versioning, and cost policy.
API gateways became important as software environments grew more complex.
Agent infrastructure may create a similar market.
Opportunity 4: Vertical MCP Platforms
Some of the strongest MCP startups may not look like infrastructure companies at all.
They may focus on a specific industry.
A life-sciences MCP platform could connect research agents to laboratory systems, validated literature, experimental data, and scientific workflows.
A financial-services platform could connect agents to portfolio information, compliance systems, research, and risk tools.
A healthcare MCP platform could connect administrative agents to scheduling, billing, and operational workflows.
Boston has enough domain knowledge to build specialized platforms in each of these areas.
Opportunity 5: MCP Testing
Companies will also need to test whether their tools behave correctly across different models and agents.
A testing platform could evaluate tool selection, parameter generation, permission boundaries, malicious inputs, latency, structured outputs, and model compatibility.
This could become a large market because tool reliability is central to autonomous software.
Opportunity 6: Proprietary Data for AI Agents
Organizations that own valuable information can create agent-facing data businesses.
BCC Research and IANS provide early examples.
Boston has many companies and institutions with specialized information.
The next generation of research products may not be limited to reports or searchable databases.
They may sell trusted context directly into AI workflows.
MCP Could Change SaaS Pricing
Traditional SaaS pricing is often based on seats.
That model becomes less obvious when AI agents do more of the work.
One employee may launch hundreds of automated workflows without spending much time inside the vendor’s application.
A company may receive large amounts of value while using relatively few human seats.
That could push some software businesses toward pricing based on usage, transactions, tool calls, workflow volume, data access, or outcomes.
Not every company will make that change.
However, founders should start measuring how their capabilities are consumed.
Agent Distribution Could Become as Important as App Marketplaces
Software companies spent years optimizing for ecosystems such as Salesforce, Shopify, Slack, HubSpot, and cloud marketplaces.
Agent platforms may create a new kind of distribution channel.
If an AI agent needs a capability, how does it discover a trusted provider?
How does it understand what that provider does?
How does it know which permissions are required?
How does it evaluate reliability or cost?
These questions suggest that agent discovery could become a major product discipline.
MCP Optimization May Become a New Form of Product Discovery
Companies already optimize websites for search engines.
They may eventually need to optimize software capabilities for agents.
An agent needs structured information about what a tool does, when it should be used, what inputs it expects, and what risks it carries.
That is not traditional SEO.
However, the strategic goal is similar.
The company wants to make its offering easy to discover, understand, and trust.
Tool descriptions could eventually function like product pages for machines.
Standardized Tools Could Reduce Dependence on One AI Model
Another benefit of separating the reasoning layer from the tool layer is flexibility.
If a company’s tools are tightly integrated with one proprietary model, switching to another model can become expensive.
A more standardized tool layer can reduce some of that coupling.
Changing models will never be completely painless because different models behave differently.
However, a cleaner architecture gives startups more options.
That matters in an industry where model performance can shift quickly.
MCP and Agent-to-Agent Protocols Solve Different Problems
Founders will hear many protocol names over the next few years.
It helps to separate them by function.
MCP primarily focuses on connecting AI applications to tools and data.
Agent-to-agent protocols focus more on communication between agents.
A future enterprise may use both.
One agent may communicate with another agent, while both use MCP to interact with software systems.
A simplified architecture could look like this:
Customer Agent
│
│ agent communication
▼
Operations Agent
│
│ MCP
├──── CRM
├──── Database
├──── Billing
└──── Support Platform
The important point is not choosing one acronym over another.
The important point is understanding what each layer is responsible for.
MCP Does Not Mean Companies Should Connect Everything
Standardization makes connectivity easier.
That does not mean unlimited connectivity is wise.
Every additional tool expands the number of actions available to an agent.
That increases the number of possible mistakes.
The safest architecture may therefore be much narrower than the most technically impressive architecture.
Agents should receive the smallest tool set required to complete the task.
This principle becomes increasingly important as companies move from one agent to hundreds.
The Most Important Question Is What the Agent Should Not Be Allowed to Do
Product teams naturally focus on adding capabilities.
What can the agent automate?
Which systems can it connect?
Which tasks can it perform?
A more mature design process begins with constraints.
What data must never leave this environment?
Which action must always require human approval?
Which tools should never share credentials?
Which operations could create irreversible damage?
What happens if a malicious instruction reaches the model?
These limits define the safe operating area.
The agent should work inside that boundary.
What Boston Investors Should Look For
Investors will increasingly see startups describing themselves as “MCP-native” or “the MCP platform for X.”
Those labels do not reveal much by themselves.
The deeper questions matter more.
Does the Company Own Valuable Context?
If the underlying information is public and easy to copy, the protocol creates limited defensibility.
Does It Own Important Actions?
A product that performs a difficult or valuable workflow is stronger than a thin integration layer.
Is It Embedded in a System of Record?
Deep integration can make the product harder to replace.
Does It Control Identity and Trust?
Enterprise customers will care about permissions, auditability, and governance.
Does Usage Grow as Agent Activity Grows?
A product that becomes more valuable as more work is delegated to agents may have strong structural upside.
Is the Product Valuable Even If the Protocol Changes?
Protocols evolve.
The startup should own something more durable than an MCP wrapper.
What Boston Founders Should Build First
Founders do not need a massive MCP roadmap.
They need one useful workflow.
A simple five-question framework can help.
1. Which Repetitive Job Creates Real Customer Value?
Choose something frequent and measurable.
2. Which Systems Are Needed to Finish It?
Map the actual data and software dependencies.
3. Which Capabilities Can Safely Become Tools?
Expose as little as necessary.
4. Where Should Humans Remain in Control?
Design approval into the workflow from the start.
5. Which Metric Proves the New Workflow Is Better?
Time saved is useful.
Reliable task completion is better.
Business impact is best.
A Simple MCP Readiness Scorecard
Boston companies can use the following framework before investing heavily.
| Question | Weak readiness | Strong readiness |
| Are our APIs stable? | Limited or inconsistent | Mature and documented |
| Do we own useful data? | Mostly public | Proprietary or real-time |
| Do customers repeat structured workflows? | Rarely | Frequently |
| Are permissions granular? | Broad | Specific |
| Can actions be audited? | Limited | Complete |
| Can outcomes be measured? | Difficult | Clear KPIs |
| Do customers use external AI tools? | Rarely | Frequently |
| Can we expose narrow capabilities? | Monolithic | Modular |
A company with weak permissions and unstable APIs should probably improve those foundations before exposing important MCP actions.
Original Finding #6: Boston’s Best MCP Advantage May Be Trust
Silicon Valley will almost certainly produce a huge number of MCP services.
Boston does not need to compete by producing the largest number.
The region may have a stronger advantage in trusted infrastructure.
Boston’s economy includes healthcare, biotechnology, cybersecurity, financial services, enterprise software, research, and scientific computing.
These are areas where accuracy, reliability, compliance, security, and auditability matter.
That creates an opportunity to build the trusted layer of agent infrastructure.
The winning products may not be the ones that expose the most tools.
They may be the ones that expose the right tools with the strongest controls.
The Bigger Story: Software Is Becoming Usable by Software
The most important MCP shift is easy to miss because the technology sounds technical.
For decades, business software was designed primarily around people.
People opened dashboards.
People searched for information.
People clicked buttons.
People copied data between applications.
APIs allowed software systems to communicate, but developers still had to wire those systems together.
AI agents create a different interaction model.
A software system can understand an objective, inspect available capabilities, choose a tool, use it, evaluate the result, and continue working.
MCP is an attempt to standardize the bridge between that reasoning process and the software underneath it.
That changes how products are designed.
The interface is no longer only the screen.
The product is also the set of capabilities that another intelligent system can safely use.
What This Means for Boston’s Startup Ecosystem
Boston already has the pieces required to benefit from this shift.
The city has enterprise software companies.
It has cybersecurity expertise.
It has developer tools.
It has healthcare technology.
It has biotechnology.
It has financial services.
It has research institutions.
It has companies already exposing MCP capabilities.
The opportunity is therefore not to copy every AI trend appearing elsewhere.
The better opportunity is to combine Boston’s existing strengths with the emerging agent architecture.
Boston may not need another generic chatbot.
It may need infrastructure that lets agents operate safely inside hospitals.
It may need scientific tools that expose research workflows.
It may need security systems that control agent permissions.
It may need observability platforms that explain what agents actually did.
It may need financial infrastructure designed for controlled autonomous work.
It may need testing systems that evaluate thousands of agent-tool combinations.
Those are deeper and more defensible problems.
Five Developments Boston Business Leaders Should Watch
MCP Support Could Become an Enterprise Procurement Question
Software buyers may increasingly ask vendors whether their products expose agent-compatible capabilities.
Over time, this could become as normal as asking about APIs, SSO, webhooks, or integrations.
Agent Security Could Become Its Own Budget Category
As agents receive more authority, companies will need dedicated tools for monitoring what they can access and what they are doing.
Permission management, runtime policy, and auditability are likely to become major enterprise requirements.
SaaS Products Will Be Designed for Humans and Agents at the Same Time
The user interface will remain important.
However, more products will also need a machine-facing layer.
Proprietary Data Companies Will Find New Distribution Channels
Research businesses that once sold reports or database access may begin selling trusted context directly into AI workflows.
The Most Valuable Agents May Barely Look Like Chatbots
Many successful systems will operate quietly inside business processes.
Users may care less about the conversation and more about whether the job was completed correctly.
Final Takeaway: MCP Is Moving AI From Conversation Into Real Work
The Model Context Protocol sounds like a technical standard.
Its impact could be much broader.
The first generation of generative AI changed how people interacted with software.
Users could talk to applications instead of clicking through menus.
The next generation changes what AI itself can interact with.
Agents can reach software systems, retrieve live information, call tools, and perform approved actions.
That is why MCP matters.
Our BostonBizScene analysis identified nine Boston-connected commercial organizations with clear public MCP implementations across several very different categories. The observed rollout occurred over roughly 435 days and included companies in CRM, marketing, observability, software development, networking, cybersecurity, product analytics, AI infrastructure, and market research.
Boston’s city government has also experimented with MCP-style civic data access.
No individual example proves that MCP will become the permanent standard for AI integrations.
However, the combined pattern shows that the protocol has already moved beyond a small developer experiment.
The strategic question for founders is therefore not simply:
Should we build an MCP server?
The more useful question is:
If AI agents become important users of software, which parts of our product should they be able to understand, access, and safely operate?
That question affects far more than engineering.
It affects product design.
It affects distribution.
It affects pricing.
It affects security.
It affects software architecture.
It affects the role of the traditional user interface.
Most importantly, it could determine which Boston startups become essential infrastructure for a world in which software increasingly performs work on behalf of people.
