What can you do with this server?

This server provides MCP tools that act as a self-governance gate for AI coding agents, verifying completion claims against repository truth via git diff and deterministic thresholds. Key capabilities include: * phionyx_verify_claim: Verify a completion claim before declaring 'fixed' or 'done', returning a pass/regenerate/reject directive with reasons. * phionyx_verify_paths: Cross-check claimed code paths against actual git diff, providing a trust score and warnings for discrepancies or underreporting. * phionyx_causal_trace: Validate a causal debugging chain from symptom to root cause, issuing a 'deepen' directive if the chain is too short or weak. * phionyx_response_gate: Apply action-type-specific thresholds before committing or deploying, with directives like pass/hedge/regenerate/block, and enforce knowledge boundaries. * phionyx_checkpoint: Record lightweight session state snapshots for dense telemetry. * phionyx_session_report: Generate an end-of-session summary with claims, directives, drift metrics, and optional audit chain. Additionally, it offers a reviewer-runnable CLI, a pre-commit hook to enforce verification discipline, sharing of trace IDs with the companion phionyx-mcp-server for end-to-end visibility, and an evidence taxonomy to weigh different evidence types when gating claims.

Which integrations are available for this server?

Verifies claimed code paths against actual git diff to ensure agent's declarations match repository truth. Provides a command-line gate helper that can be used in pre-commit hooks to reject or require regeneration of claims before commits.

How do I use phionyx-pipeline-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@phionyx-pipeline-mcp Verify my claim: I fixed the auth timeout bug and tested login and logout paths." 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.

phionyx-pipeline-mcp

by halvrenofviryel

Overview Schema Source Related Servers Discussions Admin

Python

Local

phionyx-pipeline-mcp

A self-governance MCP server for Claude Code — gates the agent's own "I fixed this / I tested that / this code path changed" declarations against git diff truth and a deterministic gate.

phionyx-pipeline-mcp solves a less-discussed agent-trust problem: when an AI coding agent reports back on its own work, that report is itself a trust object. Without verification, you accept it on faith.

This package gives any MCP-capable host (Claude Desktop, Cursor, Zed, VS Code, JetBrains) a six-tool surface that turns those self-reports into reviewable evidence — coverage of paths claimed vs. paths actually touched, severity-weighted evidence taxonomy, drift tracking across a session, and an explicit pass | regenerate | reject directive before the agent claims "done."

Where this sits in the Phionyx stack

Phionyx ships three distinct things, each with its own version line. This package is the gate:

Engine — phionyx-core (current release on PyPI): the deterministic runtime (46-block canonical pipeline, state vector, kill switch, HITL, ethics/safety gates, audit-record contracts — the signed chain is demonstrated at the MCP boundary today).
Gate — phionyx-pipeline-mcp (this package): the inward-facing self-claim gate described here. It verifies what the agent says about its own work against git diff truth and a deterministic gate. v0.3.1 adds opt-in, default-off evidence binding (the require_tool directive + continuity binding) on top of the claim-grounding gate. It is the claim-governance layer of the Phionyx governance stack; phionyx-mcp-server (current release on PyPI) is the outward MCP trust boundary.
Format — the AI Runtime Evidence Protocol (AIREP): an experimental, vendor-neutral open format for an AI decision receipt — one signed, hash-chained, offline-checkable record per AI runtime decision, readable by anyone and tied to no vendor. Phionyx's Reasoned Governance Envelope (RGE) is developed alongside AIREP; a conformant projection between the two is not implemented (measured 2026-08-06: AIREP's own reference verifier rejects an RGE envelope handed to it directly). RGE producer (developed alongside AIREP; a conformant projection between the two is not implemented (measured 2026-08-06: AIREP's own reference verifier rejects an RGE envelope handed to it directly)). AIREP is a proposed format, not a ratified standard. See ai-runtime-evidence-protocol.

These three version lines — engine v0.9.1, gate v0.3.1, and AIREP v0.1 (experimental) — are never cross-attributed.

Related MCP server: CodePeel MCP Server

How it works — three-stage verification

Stage 1: LLM declaration   →   Stage 2: Repo truth          →   Stage 3: Deterministic gate
  "I fixed X, tested Y,         git diff parsed; functions       evidence + recency + revision
   affected paths a,b,c"        extracted; cross-checked         thresholds → directive

The gate is deterministic. Stage 1 (the agent's input) is stochastic. Stage 2 — verifying the agent's path declarations against the actual git diff — is what narrows the gap.

(These three stages are internal to the gate's verification flow. They are unrelated to the broader Phionyx governance-stack layers.)

Where this fits on phionyx.ai

This package surfaces under phionyx.ai/bounded-authority — the safety-first AI providers entry. It is the inward-facing self-claim gate that verifies the agent's own "I fixed / I tested / this code path changed" narration against the repository's actual diff and a deterministic gate, producing a pass | regenerate | reject directive paired with reviewer-runnable evidence.

Companion package: phionyx-mcp-server

This package is the inward-facing layer: it gates what the agent says about its own work.

A companion package, phionyx-mcp-server (current release on PyPI), is the outward-facing layer: it sees the host calling a third-party MCP server and signs evidence of that call (descriptor hash, drift detection, audit chain).

When both packages are installed and registered with the same Claude Code host, they agree on a single trace_id per session via PHIONYX_TRACE_ID (with ~/.phionyx/active_trace file fallback). One conversation = one trace = a joined view of the third-party tool calls and agent self-claim gate decisions recorded in that session.

phionyx_session_report (this package) surfaces the server-MCP envelope chain head + validity inline, so a reviewer can see both layers in one JSON.

Install

# This package only:
pip install phionyx-pipeline-mcp

# With the outward-facing companion (recommended for full session evidence):
pip install "phionyx-pipeline-mcp[mcp-server-integration]"

Register with Claude Code

Add to .claude/mcp.json in your project:

{
  "mcpServers": {
    "phionyx-pipeline": {
      "command": "phionyx-pipeline-mcp"
    },
    "phionyx-mcp-server": {
      "command": "phionyx-mcp-server"
    }
  }
}

Both servers will share ~/.phionyx/active_trace by default.

Tool surface

Tool	When to call
`phionyx_verify_claim`	Before claiming "fixed" or "done." Takes the claim, the evidence, the evidence type, paths tested, paths affected. Returns a directive (`pass / regenerate / reject`) plus the reasons.
`phionyx_causal_trace`	While debugging. Validates a causal chain from symptom to root cause. Chains shorter than 3 links or weaker than 40% code-specificity get a `deepen` directive.
`phionyx_response_gate`	Before committing or deploying. Action-type-specific thresholds: `claim_fixed` is strictest, `deploy` is very strict, `default` is standard.
`phionyx_verify_paths`	Cross-check claimed-affected and claimed-tested paths against `git diff`. Flags underreporting.
`phionyx_checkpoint`	Lightweight snapshot — call frequently to keep the session telemetry dense.
`phionyx_session_report`	End-of-session summary: claims, directives, drift metrics, evidence taxonomy, and (if the server MCP is installed) the audit chain head + validity.

Reviewer-runnable CLI (`phionyx`)

pip install phionyx-pipeline-mcp also installs a phionyx command that exposes the same three-stage verification as the MCP server, but reachable from a plain terminal — no Claude Code / MCP host required.

Four subcommands:

# 1. Verify a self-claim against the gate
phionyx verify-claim \
    --claim "scenario continuation bug is fixed" \
    --evidence "12 scenes played, quest_complete=True" \
    --type integration_test \
    --tested "src/foo/regression.py::regression_handler" \
    --affected "src/foo/regression.py"

# 2. Aggregate the audit chain over the last N days
phionyx audit --days 30
phionyx audit --days 7 --json   # machine-readable

# 3. Replay a specific session's timeline by trace_id (or unique prefix)
phionyx replay --trace <trace_id_or_session_id_prefix>

# 4. The killer demo — reviewer reproduces the failure mode in 5 seconds
phionyx demo broken-test-disabled

The demo is the entry point a reviewer should try first. It runs a scripted scenario in which Claude claims a fix passes and the gate detects that no tested-path coverage exists and the evidence weight is the bottom of the taxonomy — and rejects the claim. The exit code is 2 because the gate did its job.

Exit codes:

Code	Meaning
`0`	`pass` / `proceed` — gate accepts the claim
`1`	`regenerate` / `rewrite` / `hedge` — claim must be revised
`2`	`reject` — gate rejects outright
`3`	error (invalid args, missing telemetry, internal failure)

CLI and MCP-host invocations write to the same telemetry directory (PHIONYX_PROJECT_ROOT/data/mcp_telemetry/), so phionyx audit and phionyx replay see prior sessions started inside Claude Code or any other MCP-capable host.

Evidence taxonomy

Not all evidence is equal. The gate weights confidence by the type of test that backs a claim:

Evidence type	Weight
`browser_test`	0.9
`manual_repro`	0.8
`integration_test`	0.7
`endpoint_test`	0.6
`log_inspection`	0.5
`unit_test`	0.4
`code_review`	0.3
`none`	0.0

A claim_fixed action with evidence_type=none will be rejected outright; even high confidence values cannot compensate for missing test evidence.

Pre-commit gate helper

A standalone phionyx-pipeline-check-gate CLI reads the recent telemetry and exits non-zero if the most recent gate directive was reject or regenerate. Drop it into your pre-commit hook to enforce the discipline:

phionyx-pipeline-check-gate --mode pre-commit

Exit codes: 0 pass · 1 failed (recent reject/regenerate) · 2 no telemetry (warn-only).

Shared-trace contract

When phionyx-mcp-server is also installed, this package extends phionyx_session_report's output with:

{
  "trace_id": "<active trace>",
  "mcp_envelope_chain": {
    "trace_id": "<same trace>",
    "count": 7,
    "head_hash": "sha256:...",
    "valid": true,
    "broken_at": null
  }
}

The integration is read-only — this package imports FilesystemEnvelopeStore + verify_chain from phionyx-mcp-server and reads its chain. No cross-package write coupling. When the server package isn't installed, the field reports "phionyx-mcp-server not installed" and the rest of the report continues to work.

Tests

pip install -e ".[test]"
pytest tests/ -q

License

AGPL-3.0-or-later. See LICENSE.

Available Tools

6 tools

phionyx_causal_traceB

Validate a causal debugging chain. Call when investigating a bug.

Args: symptom: What the user observes (e.g. "scenarios end at scene 2") causal_chain: Arrow-separated chain from symptom to root cause (e.g. "0 choices shown → play page reads res.choices → play_card returns empty → make_choice uses wrong key")

ParametersJSON Schema

Name	Required	Description	Default
`symptom`	Yes
`causal_chain`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry full burden. It only says 'Validate a causal debugging chain' without detailing side effects, required permissions, return format (despite having an output schema), or what 'validation' entails.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, with the purpose and usage stated upfront, followed by parameter details. However, the structure could be improved by separating guidance from parameter examples.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool (2 parameters, has output schema), the description is partially complete: it explains what and when, but omits what validation produces and any behavioral details, requiring the agent to infer from context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With schema description coverage at 0%, the description adds value by providing concrete examples for both parameters, including the arrow-separated format for causal_chain, which clarifies usage beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Validate a causal debugging chain' and when to call it ('when investigating a bug'). It distinguishes itself from sibling tools like phionyx_verify_claim by focusing on causal chains.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides a basic usage guideline ('Call when investigating a bug'), but lacks explicit when-not-to-use or alternatives among siblings, leaving room for ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

phionyx_checkpointA

Lightweight physics state snapshot. Call frequently — after completing any subtask, before switching context, or when reporting progress.

This is cheap (no git diff, no verification). Use it to keep the telemetry timeline dense so the founder can track session physics in real time.

Args: context: Brief note of what you're doing (e.g. "finished implementing selector")

ParametersJSON Schema

Name	Required	Description	Default
`context`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses that it's cheap, no git diff, no verification, and for telemetry density. Could mention side effects or return behavior, but adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise: two sentences for purpose and usage, then parameter description. Front-loaded key info with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool is simple with one optional param. Description covers when, what, and behavioral traits. No explanation of return value, but output schema likely covers it. Sufficient for its simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only parameter 'context' has 0% schema description coverage, but description explains its purpose: 'Brief note of what you're doing' with example. Adds value beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Lightweight physics state snapshot', a specific verb+resource. It distinguishes from siblings like 'phionyx_verify_claim' by emphasizing frequency and cheapness.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to call: 'after completing any subtask, before switching context, or when reporting progress'. Does not mention when not to use or alternatives, but context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

phionyx_response_gateA

Response revision gate with action-type-specific thresholds. Call before committing.

Directives: pass | hedge | regenerate | block | require_tool (P1). Different action types trigger different threshold profiles:

claim_fixed: strictest (entropy_reject=0.90, phi_min=0.08)
deploy: very strict (entropy_reject=0.85, phi_min=0.10)
default: standard pipeline thresholds
require_tool (P1): for factual action_types (claim_fixed/claim_working/deploy) with no externally-bound evidence, the result carries require_tool{triggered}; with PHIONYX_GATE_REQUIRE_TOOL_ENFORCE=1 an otherwise-passing directive becomes 'require_tool' — bind real evidence (run a tool) before the claim can pass.
continuity_binding (P2): the result carries continuity_binding{bound,stale,dds} from the session constraint ledger. compute_dds(confidence, continuity_score) flags "confident while binding unbound/stale"; with PHIONYX_GATE_CONTINUITY_ENFORCE=1 an otherwise-passing directive is downgraded to 'hedge' (re-bind constraints).
ask_question / make_claim (Block 15 short-circuit): each identifier in artifact_references is scored against the read-knowledge boundary by phionyx_core's KnowledgeBoundaryDetector; any source not present in artifact_paths_read is assessed outside the boundary → directive='regenerate' with the ungrounded set + the core's reasoning surfaced. Use 'ask_question' BEFORE asking about a named artifact; use 'make_claim' BEFORE asserting what a named source (file, paper, theory, config) says/contains.

Args: action_type: claim_fixed | claim_working | deploy | refactor | investigate | ask_question | make_claim confidence: Your confidence 0.0-1.0 evidence_count: Number of independent test/verification points evidence_type: Type of evidence (see phionyx_verify_claim for options) affects_user_facing: Whether this change is visible to end users artifact_references: Comma-separated artifact identifiers mentioned in the question/claim (file paths, URLs, issue numbers, named sources). Only meaningful when action_type in {'ask_question', 'make_claim'}. artifact_paths_read: Comma-separated artifact identifiers actually opened this turn (Read tool results, gh issue view output, WebFetch URLs). Only meaningful when action_type in {'ask_question', 'make_claim'}.

ParametersJSON Schema

Name	Required	Default
`confidence`	Yes
`action_type`	Yes
`evidence_type`	No	code_review
`evidence_count`	Yes
`affects_user_facing`	No
`artifact_paths_read`	No
`artifact_references`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It thoroughly discloses thresholds, directive outcomes, and special behaviors like require_tool and continuity_binding, including environment variable effects. This meets the high standard for transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with sections and front-loaded purpose, but it is verbose. Every sentence adds value, but could be slightly more concise without losing critical details. It earns its place given complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema (not shown), the description covers all behavioral aspects and parameter semantics. Given the tool's complexity with multiple action types and special cases, the description is complete and leaves no critical gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

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 entirely. It explains all 7 parameters: action_type values, confidence range, evidence_count, evidence_type linking to verify_claim, affects_user_facing boolean, and conditional usage of artifact_references and artifact_paths_read. This adds significant meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it is a 'response revision gate with action-type-specific thresholds' and instructs to 'Call before committing.' The verb 'call' and resource 'response' are specific, and the description distinguishes from sibling tools by detailing unique thresholds and directives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use guidance for each action type, including special cases like 'ask_question' and 'make_claim'. It also instructs to call before committing and explains the conditions for each directive, aiding proper selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

phionyx_session_reportA

Session summary: claims, directives, drift metrics, evidence taxonomy, physics state.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden for behavioral traits. It does not disclose whether the tool is read-only, has side effects, or requires specific permissions. For a summary report, read-only is likely but not stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence. It is front-loaded with 'Session summary' and lists key elements without fluff. Could be slightly more structured, but it is appropriately concise for a no-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and an output schema that likely defines the return structure, the description adequately outlines the report contents. However, it does not specify when to invoke this tool (e.g., after certain operations), leaving some contextual gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist in the input schema, and schema coverage is 100% (vacuously). The description adds meaning by enumerating the content of the report (claims, directives, etc.), compensating for the lack of param details. Baseline is 3, but the description goes beyond the name.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Session summary' and lists specific components (claims, directives, drift metrics, evidence taxonomy, physics state), clearly indicating a summary report tool. It distinguishes from siblings like phionyx_causal_trace or phionyx_verify_claim, which focus on specific aspects.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives such as phionyx_causal_trace or phionyx_verify_claim. The description implies it is for an overview, but lacks context or exclusionary criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

phionyx_verify_claimA

Verify a completion claim using three-layer verification. Call BEFORE saying 'fixed' or 'done'.

Layer 1: Parse your declarations (claim, evidence, paths) Layer 2: Cross-check paths against git diff (input verification) Layer 3: Physics gate (phi + entropy + revision thresholds)

P1 require_tool: if the claim asserts a factual / external-state fact (live / deployed / version / merged / tests-pass / endpoint-up) and the evidence is not externally bound (only code_review/none, not a run/inspection), the result carries require_tool{triggered,...}; with PHIONYX_GATE_REQUIRE_TOOL_ENFORCE=1 an otherwise- passing directive becomes 'require_tool' — go bind the evidence (run the tool) first.

Args: claim: What you're claiming (e.g. "scenario continuation bug is fixed") evidence: What test output proves it (e.g. "12 scenes played, quest_complete=True") evidence_type: Type of evidence — determines confidence weight. One of: browser_test, manual_repro, integration_test, endpoint_test, log_inspection, unit_test, code_review, none code_paths_tested: Comma-separated functions/endpoints you actually tested code_paths_affected: Comma-separated functions/endpoints affected by the change referenced_sources: (P2b) Comma-separated sources the claim cites/depends on (roadmap, spec, a module/file). Optional. read_paths: (P2b) Comma-separated sources actually Read/bound THIS turn. Optional — when BOTH this and referenced_sources are given, the gate checks read_but_not_bound (a cited source not bound this turn → continuity violation; with PHIONYX_GATE_CONTINUITY_ENFORCE=1 → 'regenerate'). Omit (leave null) when no read-set is available → check is skipped (non-regressive).

ParametersJSON Schema

Name	Required	Description	Default
`claim`	Yes
`evidence`	Yes
`read_paths`	No
`evidence_type`	Yes
`code_paths_tested`	Yes
`referenced_sources`	No
`code_paths_affected`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It details three verification layers, require_tool logic based on evidence type, continuity checks with read_paths, and environment variable effects. Highly transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is lengthy but well-structured with sections and bullet points. Some redundancy exists (e.g., repeated mention of three layers, but it is necessary for clarity. Front-loaded with primary purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 7 parameters, 5 required, and complex gate logic, the description covers all key aspects: layers, require_tool conditions, continuity checks, and environment variables. Very complete for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description explains each parameter's role in verification layers, including optionality of read_paths and the impact of evidence_type on require_tool. Fully compensates for missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool verifies a completion claim using three-layer verification. It does not explicitly distinguish from sibling tools, but the purpose is specific and actionable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description instructs to call BEFORE saying 'fixed' or 'done', and provides detailed conditions for require_tool and continuity checks. It lacks explicit alternatives among sibling tools but gives clear usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

phionyx_verify_pathsA

Cross-check your claimed code paths against git diff reality. Call to verify your own declarations.

Compares what you say you affected/tested against what git diff actually shows. Returns discrepancies, trust score, and warnings about underreporting.

Args: claimed_affected: Comma-separated paths you claim are affected claimed_tested: Comma-separated paths you claim to have tested

ParametersJSON Schema

Name	Required	Description	Default
`claimed_tested`	Yes
`claimed_affected`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must bear full burden. It states that the tool returns discrepancies, trust score, and warnings, which adds useful behavioral context. However, it does not disclose potential side effects, authentication needs, or rate limits, leaving some transparency gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded with the core purpose. The Args section is helpful, though the first sentence could be slightly tightened. Overall, every sentence contributes value without significant redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that an output schema exists (context confirms), the description adequately covers the tool's function and return types (discrepancies, trust score, warnings). For a tool with two parameters and no nested objects, this is sufficient for an agent to understand usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no parameter descriptions (0% coverage), but the description adds explicit semantics: claimed_affected and claimed_tested are comma-separated paths. This significantly enhances understanding beyond the raw schema, though more detail (e.g., path format requirements) could be added.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: cross-check claimed code paths against git diff reality. It uses a specific verb ('verify') and resource ('paths'), and distinguishes itself from siblings by focusing on path verification against git diff, while siblings like verify_claim may handle other claim types.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description tells when to call the tool ('to verify your own declarations'), but does not provide explicit guidance on when not to use it or alternatives. Given the sibling list, some implicit differentiation exists, but explicit exclusions are missing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesv0.3.0Jul 6, 2026
- First observedphionyx_causal_trace
- First observedphionyx_checkpoint
- First observedphionyx_response_gate
- First observedphionyx_session_report
- First observedphionyx_verify_claim
- First observedphionyx_verify_paths

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored 2026-07-06 10:05 across 6 tools

Disambiguation4/5

Tools have distinct purposes, though response_gate and verify_claim share some verification concepts. Detailed descriptions help differentiate them.

Naming Consistency5/5

All tools start with 'phionyx_' and use snake_case. Despite some being nouns and others verb-noun, the pattern is consistent.

Tool Count5/5

Six tools is an appropriate number for a pipeline validation server, covering key operations without being excessive.

Completeness4/5

The set covers causal debugging, state snapshots, gates, verification, and reporting. Minor gaps like explicit rollback may exist, but core workflows are supported.

Maintenance

ActivityMaintained

ResponsivenessUnresponsive

Resources

Need Help?

Related Servers

Related MCP Connectors

gnt
io.github.gnt-ai
Git-native policy layer for AI agents: check_action verdicts against rules approved via PR.
Security Version Control Autonomous Agents
130
governance-platform A
ai.geodesiclabs
Pre-execution governance for AI agents. Deterministic PASS/FAIL/REVIEW verdicts, replayable proof.
AI & Machine Learning Testing & QA Tools Monitoring
373
twothumbs B
io.github.asselwan
Verifies AI agent work end to end: real artifacts and outcomes checked, not self-reported success.
Testing & QA Tools Autonomous Agents
31
Norma by Quality CloudsOAuth
ai.qualityclouds
Deterministic AI code review, with an audit record. Governance inside the agent loop.
Code Analysis Developer Tools
11

Related MCP Servers

AI Workbench MCP
Autonomous Agents CI/CD & DevOps Coding Agents
hrishikesh-thakre
A
license
C
quality
C
maintenance
Enables acceptance gates for AI coding-agent runs by recording evidence, running deterministic validation, applying a quality gate, and rendering auditable outcomes.
Updated 3 months ago (2026-06-27 17:03 UTC)
7
Apache 2.0
CodePeel MCP Serverofficial
Code Analysis Testing & QA Tools
codepeel
F
license
A
quality
D
maintenance
Enables AI agents to review code diffs for bugs, security issues, and bad patterns, and generate fixes.
Updated 3 months ago (2026-06-04 09:58 UTC)
4
-
DiffGate
CI/CD & DevOps Code Analysis Testing & QA Tools
srbsa
A
license
A
quality
A
maintenance
Diffgate MCP server acts as a code review engine, enabling AI coding agents to analyze and validate code diffs before application. It enhances AI workflows by providing self-checking capabilities to optimise and secure code changes.
Updated 2 months ago (2026-07-27 15:21 UTC)
7
41 npm
5
Apache 2.0
sqlproctor
Code Analysis Testing & QA Tools
debabsah
A
license
Not graded
quality
A
maintenance
Enables deterministic semantic verification of agent-generated SQL queries against a git-versioned contract, blocking incorrect queries and returning structured feedback for self-correction.
Updated 2 months ago (2026-07-10 03:54 UTC)
MIT

phionyx-pipeline-mcp

Where this sits in the Phionyx stack

How it works — three-stage verification

Where this fits on phionyx.ai

Companion package: phionyx-mcp-server

Install

Register with Claude Code

Tool surface

Reviewer-runnable CLI (phionyx)

Evidence taxonomy

Pre-commit gate helper

Shared-trace contract

Tests

License

See also

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

CodePeel MCP Serverofficial

Reviewer-runnable CLI (`phionyx`)