Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@iso9000-agentops-mcp approve Human Gate 1 for the current frozen baseline"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
iso9000-agentops)
A zero-dependency, production-grade ISO 9001:2015 / Agile V Quality Management System (QMS) and AgentOps Governance Engine for autonomous coding agents (Google Antigravity, Claude Code, and MCP-compatible IDEs).
flowchart TD
Req["User Engineering Request"] --> E1["Echelon 1: Normative Planning & Frozen Baseline<br/>Risk Matrix (L0-L4) + AOP Solvability + HMAC-SHA256 Gate Seal"]
E1 --> E2["Echelon 2: SOP-Agent Finite State Machine<br/>PLANNING -> TEST_DESIGN -> SYNTHESIS -> VERIFICATION -> CAPA"]
E2 --> E3["Echelon 3: Two-Phase Serialization & Role Isolation<br/>Test-Designer (tests/**) vs Build-Agent (src/**)"]
E3 --> E4["Echelon 4: Swiss Cheese Guardrails & Planarian Rollback<br/>PreToolUse Shell/File Guard + Safe Backup before Restore"]
E4 --> E5["Echelon 5: Independent Verification & W3C PROV-DM Audit Chain<br/>SHA-256 EvidenceUnits + Immutable Audit Ledger"]
E5 --> E6["Echelon 6: CAPA / PDCA Continuous Improvement<br/>ExpeL Rule Weighting + OptoPrime Textual Gradients + Trace2Skill"]Related MCP server: MCP
Cryptographic Human Gate 1 Seals (HMAC-SHA256):
Tasks classified as L2-L4 require explicit Human Gate 1 approval (approve-gate1) signed with a workspace-local HMAC key (.supergraph/.gate_secret or ISO9000_GATE_SECRET). Manual text tampering of human_gate_1_approved: true in frozen_baseline.yaml without a valid gate_seal_hmac is automatically rejected.
Self-Grading Bias Prevention (File & Shell Sabotage Guard):
Enforces strict role separation between TEST_DESIGN (test-designer, restricted to tests/**) and SYNTHESIS (implementer, restricted to src/**, app/**).
Intercepts both direct file tools (write_file, edit_file, Write, Edit) and shell redirection/mutation commands (run_command, Bash) targeting tests/ or .supergraph/frozen_baseline.yaml.
Safe Planarian Asymmetric Rollback:
Captures clean workspace statepoints (.supergraph/statepoints/<node_id>/) prior to synthesis.
Upon 3 consecutive oracle failures, automatically backs up in-progress files to .supergraph/rollback_backups/<timestamp>/ before restoring the clean statepoint.
Multi-Provider LLM Adapter & Own-Target Framing:
Supports offline (deterministic regex/clause decomposition), argon (Gemini 4 Argon daemon), openai, and anthropic providers with automatic fallback and domain-neutral prompt framing.
1-Click Hook Installer & Built-in JSON-RPC 2.0 MCP Server:
Generates ready-to-use PreToolUse, PostToolUse, and Stop hooks for Antigravity Golden Stack (supergraph, antigravity-monitor, agents-learning) and Claude Code (.claude/settings.json).
Exposes all 6 Echelons over stdio JSON-RPC 2.0 (iso9000-agentops-mcp).
pip install -e ".[dev]"# 1. Initialize an L3 Frozen Baseline
iso9000-agentops --workspace . init-baseline "(REQ-001) Add HMAC auth; (REQ-002) Add audit log" --risk L3 --offline
# 2. Approve Human Gate 1 (writes 64-char HMAC-SHA256 seal)
iso9000-agentops --workspace . approve-gate1
# 3. Transition to TEST_DESIGN (Test-Designer role)
iso9000-agentops --workspace . set-phase TEST_DESIGN --role test-designer --emit-brief
# 4. Transition to SYNTHESIS (Build-Agent role) & Save Statepoint
iso9000-agentops --workspace . set-phase SYNTHESIS --role implementer --emit-brief
iso9000-agentops --workspace . checkpoint --label pre_synthesis
# 5. Run Independent Verification Oracle & Build W3C PROV-DM Audit Chain
iso9000-agentops --workspace . verify --cmd "pytest -q"
# 6. Run CAPA / ExpeL Consolidation & Trace2Skill Extraction
iso9000-agentops --workspace . capa --trace2skill --skill-name verified-auth-sop --offline# Install Antigravity Golden Stack plugins
iso9000-agentops install-hooks --target antigravity --dest ~/.gemini/config/plugins
# Install Claude Code lifecycle hooks
iso9000-agentops install-hooks --target claude-code --dest ./.claudeAdd iso9000-agentops-mcp to your MCP client configuration:
{
"mcpServers": {
"iso9000-agentops": {
"command": "iso9000-agentops-mcp",
"args": []
}
}
}Run iso9000-agentops benchmark or pytest tests/test_iso9000_agentops.py -v:
Sandbox | Target Defect Class | Mechanism Verified | Result |
| Unsealed Gate 1 bypass + direct/shell mutation of |
| PASSED (100% Blocked) |
| Hallucination spiral (3 consecutive test failures) + work loss risk | Backup to | PASSED (100% Restored) |
| Provenance drift + recurring defects + OSS release leakage | W3C PROV-DM | PASSED (100% Verified) |
Released under the MIT License. Copyright (c) 2026 orakulzero.
Approve Human Gate 1 and write a cryptographic HMAC-SHA256 seal.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose that a cryptographic seal is written, which signals mutation and a durable side effect, but it omits permissions required, irreversibility, whether approval can be repeated or revoked, and what the seal attests to.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no wasted words. It is efficient, though its brevity contributes to the broader under-specification of a high-stakes approval operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a gate-approval operation that writes a cryptographic seal, the description is thin: no prerequisites, no consequences of approval, no error or idempotency behavior, and no annotations or output schema to fill the gap. An agent has only the bare action and side effect to work from.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there are no parameter semantics to explain and the baseline is 4. The description adds no parameter information, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Approve') and a specific resource ('Human Gate 1'), plus the notable side effect of writing an HMAC-SHA256 seal. It is distinguishable from siblings like init_baseline or verify_oracle, though it does not explicitly contrast itself with any of them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool, what prerequisites must be satisfied before approving Gate 1, or how it relates to alternatives such as verify_oracle or get_audit_chain. The name implies a workflow step, but the description leaves all sequencing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the current W3C PROV-DM SHA-256 audit chain and state summary.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. 'Retrieve' implies a read operation, but the description does not state that it is read-only, whether it requires authentication, how large the audit chain response may be, or any other operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. Every phrase contributes directly to identifying the resource and its technical format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read tool, the description gives the core content (audit chain and state summary) and format indicators (W3C PROV-DM, SHA-256). However, with no output schema and no annotations, it could do more to describe the shape or size of the returned chain and summary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so there is no parameter semantics to explain. The baseline for a parameterless tool is 4, and the description does not introduce confusion about inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (Retrieve) and resource (W3C PROV-DM SHA-256 audit chain and state summary), making the operation clear. It does not explicitly differentiate from the other iso9000 siblings, but the 'get' verb and audit-chain subject naturally distinguish it from init/approve/set/verify/run tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to call this tool versus alternatives, or what preconditions apply. The intended use (inspecting the audit chain or state summary) is implied only by the description's wording, not stated explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Initialize an ISO 9001:2015 / Agile V frozen baseline and risk matrix.
| Name | Required | Description | Default |
|---|---|---|---|
| offline | No | ||
| request | Yes | ||
| risk_level | No | L2 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden, yet it says nothing about side effects: whether it writes files, is idempotent, what 'frozen' implies about mutability afterward, or what happens if a baseline already exists. 'Initialize' implies a write, but consequences and reversibility are undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler, which is structurally clean. However, its brevity is under-specification rather than economy, since a state-mutating initialization tool with three undocumented parameters needs more than one clause.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and 0% parameter documentation, the description is the only source of truth and it omits preconditions, effects, and parameter meaning. An agent could not reliably invoke this without guessing at the semantics of all three inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across three parameters, so the description must compensate and does not. It never explains what 'request' contains (free text? structured payload?), what risk_level values like 'L2' mean, or what offline=true changes behaviorally; 'risk matrix' only vaguely gestures at risk_level.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Initialize') and specific artifacts ('ISO 9001:2015 / Agile V frozen baseline and risk matrix'), which clearly separates it from siblings like approve_gate1, set_phase, or run_capa. It is jargon-heavy but not tautological. It does not explicitly name when another sibling should be used instead, keeping it at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to call this, what precondition must hold (e.g., no existing baseline), or how it relates to the other iso9000_* tools in the workflow. The agent must infer that 'init' means first step in a sequence. No exclusions or alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute Echelon 6 CAPA / ExpeL rule consolidation and Trace2Skill extraction.
| Name | Required | Description | Default |
|---|---|---|---|
| skill_name | No | iso9000-learned-skill | |
| trace2skill | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Execute' implies an action, but the description does not state whether this mutates state, what side effects occur, what permissions are needed, or whether the operation is idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler or repetition. Its brevity is not the issue; the missing information belongs in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-annotation, no-output-schema tool with two undocumented parameters and domain-specific jargon, the description is far too thin. It states a high-level purpose but omits usage context, parameter effects, behavioral traits, and outcome expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for both parameters, and the description does not explain what 'skill_name' controls or what enabling 'trace2skill' actually changes. The phrase 'Trace2Skill extraction' offers only a weak hint tied to one parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action and domain process ('Execute Echelon 6 CAPA / ExpeL rule consolidation and Trace2Skill extraction'), which distinguishes it from siblings like init_baseline or approve_gate1. However, the core terms are unexplained internal jargon, so the purpose is clear only to an already-informed agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no indication of when this tool should be used versus alternatives, nor any prerequisites or exclusions. It implies a workflow step but leaves routing entirely to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transition Agile V state machine phase and emit role-isolated subagent brief.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | implementer | |
| phase | Yes | ||
| emit_brief | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It hints at a side effect (emitting a brief) and some isolation property ('role-isolated'), but says nothing about whether the transition is reversible, whether it validates the current phase, what permissions are required, or what a brief contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler or repetition. It is efficient, though the terseness contributes to the under-specification rather than reflecting deliberate economy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a state-mutating tool with three parameters, zero annotation coverage, and no output schema, the description is thin. An agent cannot determine valid phase values, error behavior on invalid transitions, or the brief's format from this definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate and it largely does not. It implicitly maps the three parameters (phase, role, emit_brief) to concepts, but never enumerates allowed phase values, explains the role default of 'implementer', or clarifies when emit_brief=false is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
It names a specific verb ('Transition') and resource ('Agile V state machine phase') plus a side effect ('emit role-isolated subagent brief'), so the action is identifiably distinct from siblings like approve_gate1 or get_audit_chain. However, 'Agile V state machine' is unexplained jargon and the description never says what a phase actually is or which transitions are valid.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to call this versus the sibling tools (init_baseline, approve_gate1, verify_oracle, run_capa), no prerequisites, and no exclusions. The agent must infer the workflow position of a phase transition entirely on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run independent verification oracle, record W3C PROV-DM EvidenceUnit, or trigger Planarian rollback.
| Name | Required | Description | Default |
|---|---|---|---|
| cmd | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It mentions a rollback, which implies a potentially destructive operation, but gives no detail on permissions, reversibility, side effects, or what running the verification oracle entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence, so it is concise, but it is under-specified rather than efficiently informative. The three alternatives are front-loaded without enough structure to clarify the command interface.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a command-dispatch tool with no annotations, no output schema, and undocumented cmd semantics, the description is missing critical details about parameter values, expected outcomes, and rollback consequences. It names operations but does not provide enough context for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single required parameter 'cmd' has 0% schema description coverage and no explanation in the description. The three listed actions may map to cmd values, but the description never states accepted values, format, or how cmd selects behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names three possible actions—running a verification oracle, recording an EvidenceUnit, and triggering a rollback—but does not make clear whether this is one multi-action dispatch tool or which primary purpose it serves. It gives specific verbs and resources, but the alternatives blur the tool's core identity and do not distinguish it from siblings like iso9000_get_audit_chain or iso9000_run_capa.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists possible operations but gives no guidance on when to use this tool versus the sibling tools. It does not state prerequisites, contexts, or exclusions, so an agent must infer usage entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0iso9000_approve_gate1iso9000_get_audit_chainiso9000_init_baselineiso9000_run_capaiso9000_set_phaseiso9000_verify_oracleScored across 6 tools
Each tool targets a distinct lifecycle action (init, gate approval, phase transition, verification, audit retrieval, CAPA), so an agent can generally tell them apart. Minor overlap exists between approve_gate1 and set_phase (both advance workflow state) and between verify_oracle's rollback behavior and phase transitions, but descriptions clarify.
All tools share the iso9000_ prefix followed by a consistent lowercase snake_case verb_noun pattern (init_baseline, approve_gate1, set_phase, verify_oracle, get_audit_chain, run_capa). No mixed conventions or ambiguous verb styles.
Six tools is a reasonable, well-scoped set for a complex ISO 9001 lifecycle, covering the core stages without bloat. It is slightly thin given the domain's breadth, but each tool earns its place.
Core lifecycle coverage exists (init baseline, gate approval, phase transition, verification, audit read, CAPA), but there are notable gaps: no explicit tool to read the baseline/risk matrix, no gate rejection/failure path, only Gate 1 approval appears supported, and rollback is embedded rather than directly invocable.
Guarded MCP server for agent-readable business truth, provenance, readiness, and discovery.
Governed MCP: agent audit, provenance, deterministic checks, and receipt-backed FragGate execution.
MCP server for mandates, delegation, policy-gated execution, credential grants, and audit.
MCP Spec Compliance MCP — audits any MCP server.json against the official Model Context Protocol
