The agent had everything it needed. Read access to the backlog item, the linked test cases, the parent epic and the acceptance criteria, all of it arriving through a clean MCP pipe in a few hundred milliseconds. It generated the module in about four minutes, and the module was good: typed, covered by tests, documented, matching every line of the ticket it had been pointed at. The ticket was wrong. Three people in that building could have said so in a sentence, and nobody had asked them.
That is the shape of the problem nobody is pricing yet, now that an MCP server can hand an agent your requirements on demand. Not access. Not latency. Not whether the model is strong enough to read a requirements repository, because it obviously is, and the plumbing that lets it do so cleanly is a genuine engineering advance that deserves the attention it is getting. The question underneath is duller and much more expensive: was the thing it read worth executing?
What is an MCP server for requirements?
A standard socket. The Model Context Protocol gives an agent a structured, permissioned way to read and act on a system's data without somebody hand-rolling a bespoke integration for every tool, and requirements platforms have started shipping servers of their own. Jama Software announced one on 4 May 2026, describing Jama Connect as the first engineering management software to deliver an MCP server. That is a real milestone and worth saying plainly.
Read their announcement closely, though, because the scope of the claim is unusually honest. The server, in their words, "enforces existing permissions, lifecycle workflows, and audit requirements; thereby ensuring that AI governance and regulatory compliance is maintained." Permissions. Workflows. Audit. Every one of those is a statement about who may reach what, and what gets recorded when they do, and not one of them is a statement about whether the requirement on the other end of the pipe describes something the business actually wants built.
I want to be careful here, because this is where the argument usually goes wrong and turns into a cheap swipe at a vendor. Jama built it right. A governed pipe is strictly better than the ungoverned one most teams improvise with a personal access token and a weekend script, and the fact that a serious requirements vendor scoped its claim to access rather than overclaiming correctness is a sign of a mature product team, not a gap in it.
64%
of software technical leaders named security concerns and requirements as the obstacle blocking or slowing MCP adoption, the top answer of any option offered. The two safeguards they most often apply are role-based permissions (67%) and audit logging (60%).
Source: Stacklok, State of Model Context Protocol in Software 2026. Vendor-sponsored research with disclosed methodology: 100 senior technical leaders in the software industry (of 300 across software, financial services and retail), surveyed December 2025, titles largely CTO, Principal Engineer or Director of AI Platform.
Look at what that second sentence is describing. Role-based permissions and audit logging are both answers to the question "who touched this, and were they allowed to." They are good answers. They are also, taken together, the entire safety posture of a large share of the field, which means the industry has quietly agreed that the risk of connecting an agent to enterprise data is a risk about reach.
Does agent access make requirements better?
No. It makes them faster to act on, which is a different property that feels like the same one when the demo goes well.
Think about what actually changes the moment the socket is live. Before, a developer read a poorly specified ticket, felt a flicker of doubt somewhere around the third acceptance criterion, and walked over to ask somebody, and that walk was an unbudgeted quality gate that the organization had been relying on for years without ever writing it down. After, the agent reads the same ticket, has no flicker, and ships. Speed went up. Doubt went to zero. Only one of those is good.
The economics of this are not subtle. A wrong requirement used to cost you one developer's afternoon before somebody caught it, because throughput was bounded by how fast humans could type and how often they interrupted each other to sanity-check things. Now it costs you a fully built, fully tested, fully documented implementation of the wrong thing, delivered before anybody has had a chance to read it. Same defect. Different blast radius.
97% vs 23%
of executives say their company deployed AI agents in the past year, while only 23% report significant return on investment from those agents. Separately, 36% say they have no formal plan for supervising AI agents, and 35% admit they could not immediately pull the plug on a rogue one.
Source: WRITER with independent research firm Workplace Intelligence, Enterprise AI adoption in 2026, published 7 April 2026. Vendor survey (WRITER sells enterprise AI tooling), disclosed sample: 1,200 C-suite executives and 1,200 non-technical employees actively using AI at work.
Deployment at 97% and value at 23% is a gap you can drive a budget cycle through. And the supervision numbers underneath it are the ones I would put in front of a board: better than a third of executives have no formal plan for supervising the agents they have already deployed, which is not a technology problem at all but a governance one that happens to have arrived faster than the org chart could absorb it.
Where does MCP help, and where does it not?
It helps enormously with a specific and real class of pain. Stale context, copy-paste drift between a ticket and a prompt, agents hallucinating a requirement because nobody gave them the actual one, traceability that falls apart the moment work leaves the tool of record. Those are genuine failures and a governed protocol fixes them properly, which is why adoption is moving as fast as it is: 26% of software organizations report MCP in limited production and another 19% in broad production, in the same Stacklok survey. The plumbing works.
Here is the boundary. MCP is a transport and permission layer. It answers "can this agent read this artifact, under whose authority, and is that recorded." It does not answer, and was never designed to answer, "is this artifact a correct and complete description of what the business needs." Those are different questions with different owners, and conflating them is how a team ends up believing it has governed something it has only wired up.
Let me revise something I said earlier, because "no" was too clean. Access does improve requirements at the margin, in one narrow way: when an agent can see the full traceability graph, it can sometimes surface a contradiction that a human skimming a single ticket would miss, flagging that a child story contradicts its parent epic. That is real. It is a validation benefit that comes free with good plumbing. It is also structural consistency, not correctness. A perfectly self-consistent set of requirements can still describe a product nobody asked for.
From the field
The most instructive example in this whole story is the Jama Connect launch itself, and it is instructive because of what the company did not claim. In a market where "AI governance" gets stamped on almost anything, a requirements vendor shipped an MCP server on 4 May 2026 and scoped its governance claim precisely: permissions, lifecycle workflows, audit trails, and a product graph of explicit semantic relationships exposed through the protocol. Access, governed properly. No assertion anywhere that the requirements travelling through it are right.
Look again. Every control in the list above is about the pipe. Not one of them reads a requirement and asks whether three stakeholders would agree with it. The industry has built a careful, well-engineered answer to one question, and it is the wrong question to be answering on its own while the other one goes quietly unasked.
Sources: Jama Software press release, 4 May 2026; Stacklok, State of MCP in Software 2026.
What does governing agentic access to requirements actually require?
Three layers, and most organizations have built exactly one of them.
The first is the access layer, and it is the one everybody is working on. Who reads what. Under whose identity. With what recorded. Role-based permissions, audit logs, scoped tokens, the ability to revoke. This is well understood, the vendors are shipping it competently, and if you stop here you will pass a surprising number of internal reviews while remaining completely exposed to the actual failure mode.
The second is the validation layer, and it is the one almost nobody has. Before a requirement becomes reachable by something that executes at machine speed, has anyone established that it is complete, unambiguous, consistent with the other requirements it touches, and endorsed by the people who will live with the outcome? That question predates artificial intelligence by about forty years. Not new. Agents simply removed the slack that used to hide it.
The third is the accountability layer, which is where the 36% number becomes uncomfortable. Nobody owns it. When an agent builds the wrong thing correctly, who owns that, and how quickly can it be stopped? A third of executives said they could not immediately pull the plug on a rogue agent, and a rogue agent in the sense that matters most is rarely a dramatic one. It is usually an obedient agent, executing a bad instruction, very well, at scale.
How do you validate before you connect?
Start smaller than you want to. The instinct is to open the whole repository to the agent because that is what makes the demo impressive, and it is precisely backwards.
Four things, in order:
- Scope the pipe to what has been validated. Not the whole backlog. The subset that has passed a real review, marked in a way the MCP server can filter on. If that subset is embarrassingly small on day one, you have learned the single most valuable thing this exercise can teach you.
- Make ambiguity machine-visible. Requirements fail in patterns: undefined terms, passive voice hiding the actor, acceptance criteria that cannot be tested, a "should" doing the work of a "must". These are detectable before an agent ever reads them, and detecting them is a different activity from serving them.
- Interrogate from more than one angle. A single reviewer, human or model, reproduces their own blind spots at speed. This is the argument for multiple specialist perspectives challenging a requirement before it is executable, including one whose job is to argue against it.
- Keep the decision record, not just the access log. Your audit trail should show why a requirement was accepted and by whom, not only which agent read it at which timestamp. The audit trail that matters is the one that captures judgment.
None of this argues against connecting agents to requirements data. Connect them. The pipe is good, the protocol is good, and teams that refuse to wire anything up will lose to teams that do, which is the part of this that the cautious commentary keeps getting wrong. Just put a gate in front of it, and know that the gate is a different piece of engineering than the pipe.
Key takeaway
An MCP server answers "can this agent reach the requirement, and is that recorded." It does not answer "is this requirement worth executing." The market solved that. The second is the one that decides whether machine-speed delivery compounds value or compounds rework, and it needs a validation layer sitting in front of the pipe, not inside it.
What are the most common questions about MCP and requirements?
Does an MCP server improve requirements quality?
No. It improves requirements accessibility and traceability. Quality is a property of the requirement itself: whether it is complete, unambiguous, testable and endorsed by the people affected. An MCP server transports the requirement faithfully, which means a well-built server will deliver a badly written requirement with perfect fidelity and full audit logging.
Is connecting AI agents to requirements data a bad idea?
Not at all, and the teams that refuse will fall behind. The plumbing solves real problems: stale context, copy-paste drift, agents inventing requirements because nobody supplied the real ones. The argument is about sequence, not permission. Validate first, then connect, and scope the connection to what has actually been validated.
What is the difference between AI governance and requirements validation?
AI governance, as the market currently ships it, mostly governs access and behaviour: who may act, on what, with what recorded, and how it can be stopped. Requirements validation governs input correctness: whether the instruction being acted on describes what the organization actually needs. You can pass every governance control and still build the wrong product, on schedule, with a complete audit trail.
How do we know whether our requirements are ready for agentic access?
One test. Take ten backlog items at random, and for each ask whether a competent stranger could build it without a single clarifying question, and whether the people who will use it would recognise their need in the text. If most fail, your requirements are not ready to be executed at machine speed, whatever the protocol layer says.
Does traceability count as validation?
It counts as evidence, not as validation. Traceability proves a requirement is connected to a parent, a test and a decision, and that structural consistency is genuinely useful: it can surface a child story that contradicts its epic. But a fully traceable set of requirements can still be a fully traceable description of the wrong product. Consistency and correctness are not the same property.
Who should own validation once agents are in the loop?
Whoever owned it before, with more support and far less time. The role does not disappear because an agent can read the backlog. It gets harder, because the window between a bad requirement being written and a bad requirement being built has collapsed from weeks to minutes, and the informal human checks that used to fill that window are exactly what the automation removed.
