What MCP actually is (and isn't)
Model Context Protocol — MCP — is an open standard that defines how AI models communicate with external tools and data sources. If you've used a tool like Claude or an OpenAI-based assistant and found yourself wishing it could "see" your requirements database, query your issue tracker, or write directly into your specification document — MCP is the protocol that makes that possible in a structured, auditable way.
Before MCP, integrating an LLM with your toolchain meant building custom API wrappers, managing authentication yourself, and hoping the vendor's AI assistant supported your workflow. The result was a fragmented landscape: each AI product had its own integrations, its own context limits, its own prompt injection risks, and its own vendor lock-in. A requirement in one tool was invisible to your AI assistant unless someone copy-pasted it.
MCP changes this. It defines a standard protocol for a "host" (your AI model or agent) to connect to "servers" — structured interfaces that expose data and actions. An MCP server for a requirements tool can expose things like: read a requirement, list requirements in a project, create a draft revision, run a traceability query. The AI model talks to these servers through a defined protocol — not via scraping, not via copy-paste, not via a proprietary plugin marketplace.
The key insight for regulated teams: MCP separates who provides the AI from what data the AI can access. That separation matters more than it might seem.
Why "bring your own LLM" is the right model for regulated work
Every major requirements management vendor is adding AI. The pitch is seamless: the AI is already there, already connected, just click the button. For regulated industries, this pitch should trigger scrutiny, not relief.
When a vendor bundles an AI assistant, you're accepting their model choices, their training data, their retention policies, their output guarantees, and their update cadence. In a regulated software development process, the question "what AI was used to author or review this requirement, and what were its characteristics on the date it was used?" is not hypothetical. It's the kind of question that appears in audit findings.
Model choice isn't trivial. Different models reason differently about ambiguous requirement language. A model fine-tuned on medical device literature will catch anti-patterns that a general-purpose model will miss. A model with a large context window can review an entire specification for internal consistency; a smaller-context model can't. These aren't aesthetic preferences — they're engineering decisions about your verification workflow.
MCP-native tools let your team make those decisions explicitly. You connect the model you've evaluated. You configure the context it receives. You control whether it can read only, or also propose writes. And when the auditor asks what AI was involved in your requirements process, you can point to a specific model version, a specific configuration, and a specific review log — not "the assistant built into our tool, version unknown."
What you can actually do with MCP and a requirements tool
Here are concrete workflows that become possible when your LLM has structured MCP access to your requirements database:
Requirement quality review
A well-prompted LLM can review a requirement against standard writing guidelines — checking for ambiguous language ("the system shall perform adequately"), compound requirements ("the system shall X and Y"), requirements that are actually design decisions masquerading as requirements, and untestable acceptance criteria. This is tedious for humans to do consistently at scale. An LLM with access to your full requirement set can flag these issues across hundreds of requirements in seconds, returning structured findings that a human engineer reviews and acts on.
Gap analysis against standards
If you're developing under IEC 62304, you have a defined set of software requirements that must be addressed: hazard-related software functions, software safety classification, interfaces, performance constraints. An LLM with your requirements in context can compare your current requirement set against a standard checklist and identify gaps — requirements categories you haven't addressed, user needs that have no corresponding system requirements, design inputs that lack verification activities. This doesn't replace a regulatory consultant, but it catches obvious gaps before a formal review.
Trace link suggestions
Traceability is where most teams fall behind. Requirement A was written in January. Design input B was added in March. The link between them was never formally recorded. An LLM with access to both requirement sets can propose trace links based on semantic similarity and content analysis — surfacing potential connections for a human engineer to confirm or reject. A trace link suggested by AI and confirmed by a human engineer is a defensible record. A trace link silently created by an automated process is not.
Change impact analysis
When a user need changes, an LLM can query all downstream requirements, design inputs, and verification activities linked to it and produce a structured impact summary. Again, the value is not that the AI makes the decision — it's that the AI surfaces the scope of the decision for a human to make quickly and confidently.
The non-negotiable: human confirmation before any write
This deserves its own section because it's the place where AI in regulated workflows can go wrong quietly.
Any MCP-enabled AI action that writes to your requirements database must require explicit human confirmation before it executes. Not a checkbox buried in settings. Not an "undo within 30 seconds" escape hatch. A deliberate, visible approval step that creates an audit record.
This is not excessive caution. It is the minimum bar for a defensible regulated development process. When your design history is under audit and a reviewer asks who authored a specific requirement, "the AI suggested it and it was auto-committed" is not an answer that will satisfy an auditor. "The AI proposed this text, which was reviewed and approved by [name] on [date], recorded in revision history entry [ID]" is.
Rune's MCP implementation enforces this at the protocol level: every MCP write action surfaces as a proposed change that a human must confirm in the UI before it's committed to the requirement's revision history. The AI operates as a reviewer and proposer. The human engineer is always the author of record.
Model selection in practice
If your team is evaluating which LLM to connect for requirements work, here are practical considerations:
- Context window: Full specification review requires a model that can hold the entire document in context. For most early-stage medical device requirements sets (200–500 requirements), 128k tokens is sufficient. At scale, 200k+ becomes important.
- Reasoning quality: Requirements contain ambiguity by definition. Models that can reason carefully about what a requirement means, what it doesn't say, and what questions it raises are more useful than models that generate fluent but superficial feedback.
- Instruction following: Gap analysis against a standard checklist requires the model to follow structured instructions without drift. Test your candidate model against a fixed prompt before relying on it in a workflow.
- Data handling: Your requirements may contain confidential product information or patient-relevant design details. Review your LLM provider's data retention and training policies before connecting them to your requirements database. API access with zero data retention is the appropriate configuration for most regulated development.
MCP doesn't tell you which model to use. That's by design. The right model for gap analysis against IEC 62304 may not be the right model for writing first-draft requirement text from a design input. Keeping model selection as an engineering decision — not a vendor decision — is one of the more important structural choices you can make when building your AI-assisted regulatory workflow in 2026.