
For a long time, enterprise software only had to work well for one user, the person sitting in front of the screen, but that is changing fast.
More teams are now using AI for real work, not just first drafts and meeting summaries. They are asking agents to pull information from their tools, surface the right context, and take action inside increasingly complex workflows. That shift matters across the stack, including product management software.
It’s no longer enough for a product tool to have a clean UI and decent search. Increasingly, it also needs a way for AI systems to understand what information it contains, what actions it can support, and how to interact with it reliably.
That is where MCP comes in.
If you have started hearing the term and wondering whether it’s just another bit of AI jargon, the short answer is no. MCP points to a real shift in how software tools may need to operate in an AI-first world.
Book a demo
MCP stands for Model Context Protocol. In simple terms, it’s a standard way for AI applications to connect with external tools, systems, and data sources. It helps AI clients understand what a system can expose, what context they can retrieve, and what actions they may be able to take.
If that sounds a bit like an API, that’s because there is some overlap. But an MCP server isn’t just an API by another name.
An API allows one piece of software to talk to another. MCP is more specifically designed to help AI assistants and agents work with software tools in a structured, reusable way. It gives AI systems a more consistent way to discover capabilities, pull in relevant context, and interact with external products.
Spencer Cowley, Product Manager at airfocus, explains the difference between how AI systems actually work with software. APIs are powerful, but they are usually designed for software-to-software communication, not for an AI assistant trying to understand what tool to use, what information to retrieve, and what format an action needs.
“We don’t build APIs to be simple for a human to use,” says Spencer. “We build them to be performant and to create a good application experience. If we just gave a large language model hundreds of APIs and said, ‘Go use these,’ it would get confused. MCP creates a layer between the APIs and the LLM that makes it much easier for the model to understand and use.”
Because the way people use software is changing. In the past, a product manager might jump between a roadmap, a feedback board, a doc, and a project tracker before turning all of that into an update or a prioritization decision.
Now imagine that same person asking an AI assistant:
What customer pain points are driving this initiative?
What changed in priority since last quarter?
Pull together the context I need for tomorrow’s leadership review.
Those kinds of workflows become far more useful when the AI can access the right systems in the right way.
That is why MCP is gaining so much attention. It’s a critical part of the infrastructure that makes software more usable in AI-driven workflows.
And as AI assistants become more capable, the tools that are easiest for them to work with may become more visible in day-to-day decisions, and more valuable because of it.
That is a fair shorthand, but it’s not the full picture. If you want the simple version, yes: MCP helps connect AI systems to software tools, much like APIs connect software systems to each other. But the bigger idea is standardization and usability by AI.
Without a shared approach, every AI client and every software vendor would need to build separate custom integrations for every use case. But that quickly gets messy. It’s also slow. And it doesn’t scale well.
MCP aims to create a more consistent way for AI applications to interact with external tools, which is important in an AI landscape that is moving rapidly. Product teams don’t want a future where every assistant or agent needs its own one-off connection into the product stack.
So while “API for AI” is a useful starting point, MCP is really about making software tools more legible and more usable to AI systems in a standardized way.
For product tools, MCP has strategic implications for how teams access product context and where product work happens.
Product management software sits on top of some of the most important context in the business: priorities, roadmaps, feedback, research, decisions, trade-offs, and progress. That context is valuable, but only if teams can get to it when they need it.
In a platform like airfocus, that could mean giving external AI tools secure, structured access to roadmap items, priorities, customer feedback, objectives, and the logic behind key product decisions.
MCP creates new ways for that information to be surfaced and used.
“AI agents are only as useful as the context they can access,” says Spencer.
Out of the box, an AI assistant may understand product management in general, but it does not automatically know the specific context of a team’s work: the roadmap items, customer feedback, comments, activity history, Slack threads, Jira tickets, or strategic decisions that shape what the product team is actually doing.
Spencer says this is why context becomes so important in a product environment. Without it, AI can produce plausible but generic answers. With it, an agent can retrieve relevant product knowledge, summarize what matters, and surface the customer and business signals behind a decision.
For product teams, that means less time digging, faster answers, and better-informed decisions.
The AI ecosystem is quickly evolving. New assistants, copilots, and agent frameworks continue to appear.
If every tool has to build a separate integration for every AI environment, the result is fragmentation. MCP offers a more standard foundation.
Now, this doesn’t mean that integration work completely disappears. But it does mean product tools have a better chance of supporting multiple AI workflows without rebuilding the same connection every time.
Many product teams are already using AI tools that have been approved inside their organization, whether that is ChatGPT, Claude, internal copilots, or coding agents.
The challenge is that those tools are only as useful as the context they can access. If they cannot see the roadmap, understand current priorities, or pull in relevant customer feedback, their output will only go so far.
MCP helps bridge that gap. It allows teams to bring trusted product context from airfocus into the AI workflows they are already using, so assistants and agents can work with better information and support more useful outcomes.
That means teams do not have to choose between the AI tools they want to use and the product context they need to use them well.
Product work is full of context-heavy questions. What changed since last quarter? Why did this initiative move up the roadmap? What is slowing delivery?
These are not questions an AI can answer well without access to the right systems.
By making that access more structured, MCP creates the foundation for more useful AI support inside product workflows. That could mean summarizing customer feedback, pulling the logic behind prioritization decisions, or gathering context for a stakeholder update.
Fast is easy. Building the right thing isn’t. Meet the new airfocus: Built for alignment in an AI-first world.
The exact answer will vary by tool and implementation, but the broader direction is already clear.
Here are a few examples of the kinds of workflows MCP could help support in a product environment:
Summarizing the customer feedback behind a roadmap item
Pulling the latest priorities for a team or initiative
Gathering context before a stakeholder meeting
Checking whether recent feedback trends match what is currently prioritized
Retrieving product information inside another AI-powered workflow
One practical example might be a product manager and UX designer connecting a coding agent to an opportunity brief inside airfocus. Instead of manually copying requirements and linking customer feedback into another tool, the agent can use that context to quickly scaffold a working prototype. The team gets something clickable in front of internal users or customers far earlier in the process, long before a sprint has even started.
Spencer says one of the most interesting things about MCP is that a single AI client can connect to multiple MCP servers. In practice, that means a team could work from one AI interface while drawing context from many different systems, such as a product management platform, Slack, Jira, or other tools in the stack.
Because product work rarely lives in one place, MCP creates a more structured way for AI to move across that context and support the workflow.
Product leaders are already under pressure to move faster, communicate more clearly, and keep strategy connected to execution across increasingly complex organizations. AI will only become more central to how teams try to meet those demands.
As more teams build AI into their day-to-day workflows, they also want their core product tools to connect cleanly with external assistants, copilots, and coding agents. That is part of what makes MCP relevant now.
That raises a new set of questions:
Can our core tools work well with AI systems?
Can teams retrieve trustworthy product context without manual digging?
Are we building product operations around standards that will scale with the AI ecosystem?
Will our tools become more useful as AI adoption grows, or easier to bypass?
These questions shape how visible your product data is, how quickly teams can get answers, and how much manual work still sits between insight and action.
It is also worth being clear about what MCP is not.
MCP is not a shortcut to good product decisions. It does not fix messy data. It does not create alignment where none exists. It does not replace governance, permissions, or thoughtful AI guardrails. Nor does it automatically turn an AI assistant into a reliable product strategist.
Spencer makes a similar point when talking about product data. A product tool cannot simply become a dumping ground for disconnected information and expect AI to make perfect sense of it. The value comes when the data is structured enough for an agent to understand how one piece of context relates to another – how feedback connects to an opportunity, how an opportunity connects to development work, or how an initiative connects to strategy.
What it does do is improve the connection layer, which makes better workflows possible. But the value still depends on the quality of the underlying product data, the structure of the workflows, and the care with which the tool is implemented.
In other words, MCP is an enabler, not a magic wand.
The broader direction of travel is hard to ignore. Software is beginning to shift from being something people only use directly to something they may increasingly access through AI assistants and agents. In that world, the tools that can expose their context and capabilities clearly will be in a much stronger position.
For product tools, that could be especially important. If AI becomes a more common interface for getting work done, product tools will need to be designed for more than human users alone. They will also need to work well with the assistants and agents helping teams retrieve context, make sense of complexity, and move faster.
MCP is one of the standards shaping that future.
For now, the most important thing is not to memorize the protocol. It is to understand that it represents a move toward software that is easier for AI to understand and easier to use as part of real work.
For product tools, that could be a very big deal.
Emma-Lily Pendleton
Book a demo







