How to Write MCP Rigor (.mcpr) Suites Humans Can Review
Author: Ashwin Kondapalli, Founder & CTO, LoopIQ Updated: October 9, 2026
A generated .mcpr package lands in the review queue. Assertions are vague ("it works"), the contract link is missing, and a token was pasted into a requirement field "for convenience." Nobody can approve confidently—so someone runs it anyway. That is how weak evidence enters go/no-go.
Reviewable MCP Rigor suites make human approval possible: clear intent, assertions bound to approved contracts, secrets kept in protected parameters, and honest discovery vs acceptance labeling. Generate review-only → approve → execute (MCP Rigor help). Same discipline as intent-based testing.
What does "reviewable" mean for .mcpr?
A reviewer should answer yes to:
What requirement/intent is this for?
Is this discovery smoke or acceptance?
Which approved contract justifies the assertions?
Are expected behaviors specific enough to fail meaningfully?
Are secrets absent from suite/requirement text?
What evidence will the run produce for the dossier?
If any answer is "unclear," reject or revise—do not rubber-stamp.
How should you structure naming, assertions, contracts, secrets, and approval?
Naming and structure
Name suites by intent (mcp-refund-partial-acceptance), not only by timestamp.
Separate discovery smoke suites from acceptance suites.
Keep one primary requirement link per acceptance suite when practical.
Assertions
Prefer expected behaviors from the approved contract over "Expect it succeeds" alone for acceptance.
Discovery may legitimately assert list-tools success—label it as smoke (discovery vs acceptance).
Contracts before generate
Incomplete contracts produce discovery-only fallbacks. Confirm tool contracts against discovery vs acceptance coverage and the MCP Rigor help before generating acceptance suites.
Secrets hygiene
Use protected parameters MCP_URL and MCP_TOKEN.
Short-lived OAuth or bot tokens; scope to needed resources.
Never paste tokens into requirements, source, or reports.
Approval gate
Human approve before execution.
Existing YAML suites remain supported; do not mix approval stories.
How does this work in LoopIQ?
Prerequisites: MCP Rigor enabled; org/team correct; contract attached for acceptance; reviewers assigned (help).
Sequence: Open Test Automation → MCP Rigor → select requirement + contract → generate review-only → review .mcpr → approve → configure protected params → execute → review sanitized JSON evidence → link to release evidence workflow.
Hosted limits (factual): Hosted execution does not support arbitrary stdio servers, token shell commands, interactive OAuth, custom extensions, snapshots, remote datasets, or LoopIQ Tunnel; private networks and cloud metadata endpoints remain blocked—hosted restrictions, not a blanket MCP capability denial.
Approvals and outputs: Approve before run. Success does not authorize a release. Tests do not authorize a release. Pricing: $4.99/user/month.
What does an illustrative human-review checklist look like?
Label: Illustrative demo data. Not a customer result.
Suite name states intent — Yes
Labeled discovery vs acceptance — Yes — acceptance
Approved contract linked — Yes
Assertions cite expected behaviors — Yes
No tokens in suite/requirement text — Yes
Requirement + candidate link plan — Yes
Reviewer named — QA reviewer
FAQ: quick answers
What is an .mcpr suite? MCP Rigor natural-language suite package; approve before execute. YAML remains supported.
What should reviewers check? Intent, contract binding, assertion quality, discovery/acceptance label, secrets hygiene, evidence links.
Should tokens appear in suite text? No—protected parameters only.
Do generated suites skip review? No—review-only until approved.
See a requirement become reviewed tests and execution evidence
CTA: See a requirement become reviewed tests and execution evidence. Book: https://meet.brevo.com/ashwin-kondapalli.
Further reading: MCP Rigor help · Discovery vs acceptance · Passing MCP still blocks release · Intent-based testing · Test results to release evidence · Pricing.
General information for engineering, quality, release, and compliance leaders. Not legal, audit, or regulatory advice.