How Reqi's AI helps you write, allocate and verify requirements today, and how the Model Context Protocol (MCP) lets Claude, Microsoft Copilot, ChatGPT and your other engineering tools read your project directly.
REX is Reqi's requirements engineering assistant. It works inside the project, on your data, at the points in the lifecycle where engineers lose the most time. Every run shows its estimated cost before it starts and is metered to your organisation.
REX critiques a requirement against the INCOSE 42-point guide: ambiguity, testability, unit and tolerance, escape clauses, compound statements. It proposes a rewrite and shows the before-and-after score. You can try this free, with no sign-up, on the REX page.
Upload a contract, specification or standard and REX extracts a structured requirements list, keeping the source wording and the clause it came from. Verbatim mode copies only what the document says; elicit mode drafts requirements the document implies.
Given your system breakdown structure, REX proposes which subsystem each requirement belongs to and why. Allocation proposals wait for a reviewer; nothing moves until someone with the role agrees.
REX derives child requirements down the hierarchy, drafts measurable acceptance criteria for each, and surfaces assumptions, constraints and dependencies into the ACD register so that risk is visible, not buried.
From a short brief REX drafts the stakeholder map, the needs analysis and a first-pass system architecture, giving a new project a structured starting point in minutes rather than weeks.
Index the project's documents and ask questions across them, with answers that cite the source page. Useful for tender clarification, change impact and finding where a number came from.
The Model Context Protocol is an open standard, published by Anthropic and adopted by Microsoft, OpenAI and a growing list of tool vendors, that lets an AI assistant or an application call a small set of well-defined tools on a system of record. The assistant asks a question in plain language; the client turns it into tool calls; the server answers from live data.
Reqi's MCP server makes a project a live data source, with the scope set by your organisation. Instead of exporting a register to a spreadsheet and pasting it into a chat window, your assistant reads the requirements, allocations, acceptance criteria and verification evidence as they stand right now, scoped to the projects you are a member of.
The standard tool set is deliberately small and every call names the project explicitly. The scope is set per organisation: a standard read scope covers the tools below, and custom scopes can be agreed where a team needs more.
| Tool | What it returns |
|---|---|
list_projects | The projects the signed-in person can see, with identifiers. |
search_requirements | Requirements matching a query within one project: identifier, text, status, allocated systems and acceptance state. |
verification_status | For a project or a subsystem, which requirements have evidence, which are in review and which have nothing yet. |
trace | Parents and children of a requirement, so an assistant can walk the hierarchy from a customer clause to the component level. |
Where an assistant should propose a change, Reqi already has a pattern for it: proposals that wait for a person with the right role to accept, the same way allocation requests work today. Custom scopes build on that pattern rather than writing straight to the register.
Three of the eleven safety requirements allocated to the Door Control Unit have no verification evidence:
The other eight are verified. REQ-231 is marked Review by the supplier, awaiting acceptance.
Four requirements allocated to the Braking Subsystem are in Review:
REQ-118 and REQ-121 have test reports attached and are waiting on your acceptance. The other two have no evidence yet.
Three of the four. REQ-118, REQ-121 and REQ-127 derive from CUST-042 (Braking performance). REQ-133 is an internal design requirement with no customer parent.
Other questions the tool surface supports: how many requirements derived from the customer specification are now accepted; what was added to a package since the last design review; which requirements allocated to a subsystem have acceptance criteria but no evidence; which supplier holds the most open items.
Extract the customer's requirements from the specification, check their quality, and ask the assistant what is ambiguous or untestable before the clarification deadline.
Allocate and derive with REX, then use MCP during design reviews to answer allocation and traceability questions from the live register rather than from slides.
Suppliers work in the same project. Ask which of their requirements are in review, which have evidence attached, and which are overdue, without opening each one.
Track V&V progress by subsystem and by supplier. The assistant reports what is verified, what is waiting on acceptance and what has no evidence at all.
More on Reqi's security posture is on the security page.
Any client that implements the Model Context Protocol. At launch that means Claude, Microsoft Copilot and ChatGPT, plus MCP-compatible desktop and engineering tools. The connector is the same for all of them.
Only within the scope your organisation has agreed. The standard scope answers questions. Where a custom scope allows changes, they arrive as proposals for a person with the right role to accept, following the allocation request pattern Reqi already uses.
The connector is part of the project plan. Questions answered through MCP read from your database and do not consume AI credit; only runs of REX's own AI features are metered.
MCP is enabled per organisation on request. Create an account, start a project, and ask for it from Settings → Connectors.
Three months, 500 requirements, unlimited users, no card. REX is included from day one; MCP is switched on for your organisation when you ask.