What can you do with this server?

It is an MCP trust-boundary server that hashes and audits third-party MCP tool calls, emits signed hash-chained evidence envelopes, and lets you verify chain integrity. * verify_tool_descriptor: hash a full tool descriptor (including protocolVersion) and compare against a baseline to detect post-approval drift/poisoning. * record_tool_call: append a signed RGE v0.2 envelope with input/output hashes, descriptor hash, permission scope, approval state, and anomaly flags to a trace audit chain. * verify_chain_integrity: walk the persisted envelope chain for a trace, detect tampering/reordering, and refuse mixed-schema chains. * query_audit_history: replay persisted audit envelopes (most-recent first) for review and incident analysis. * CLI: inspect chain head (head), verify chains (verify-chain), and show individual envelopes (show) with exit codes and assurance reporting. * Stubs: record_user_approval and flag_anomaly return structured not-implemented markers; audit_record_decision logs non-MCP policy decisions alongside MCP calls. * Persistence: envelopes are stored under ~/.phionyx/mcp_audit/ / (configurable), with an append-only JSONL index and canonical JSON envelope files.

How do I use phionyx-mcp-server?

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-mcp-server verify the tool descriptor against the approved 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.

phionyx-mcp-server

by halvrenofviryel

Overview Schema Source Related Servers Discussions Admin

Python

Local

phionyx-mcp-server

The MCP trust boundary in the Phionyx runtime — descriptor signing, signed evidence envelopes, and a hash-chained audit chain over third-party MCP tool calls.

phionyx-mcp-server sits between an MCP-capable host (Claude Desktop, Cursor, Zed, VS Code, JetBrains) and any third-party MCP server it talks to, producing hash-chained evidence at every trust-boundary crossing (un-rechained edits are detectable; producer authenticity requires a configured signer). It closes a security gap the MCP specification (2025-11-25) explicitly defers to implementors:

"MCP itself cannot enforce these security principles at the protocol level; implementors SHOULD..."

The threat surface is aligned with arXiv:2512.06556 (Jamshidi et al., Securing the Model Context Protocol) — tool poisoning, shadowing, rug pulls.

Where it fits

Phionyx ships three distinct things, each on its own version line — don't cross-attribute them:

Engine — phionyx-core: the deterministic governance runtime (46-block canonical pipeline, kill switch, HITL queue, ethics/safety gates, signed audit chain). pip install phionyx-core.
Gate — phionyx-pipeline-mcp: an agent self-claim gate that verifies "I fixed / I tested / this changed" against the repository's actual diff.
Format — AI Runtime Evidence Protocol (AIREP): an experimental, vendor-neutral open format for an AI decision receipt — one signed, hash-chained, offline-checkable record per runtime decision, readable by anyone and tied to no vendor. AIREP is a proposed format, not a ratified standard. AIREP v0.2.0-beta.1 was published on 9 September 2026 as an experimental prerelease: it ships a first-party Python producer for Decision, Control, Execution and Effect artifacts, runnable lifecycle examples and structured reconciliation; the v0.1 line remains frozen and supported. External implementation results are version- and role-specific — an independently authored producer measured against frozen v0.1.2, and an independently implemented consumer/verifier measured against an earlier v0.2 handoff — and they do not establish same-beta producer-to-consumer interoperability. 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).

This package is the outward MCP trust boundary — it produces hash-chained evidence (optionally Ed25519-signed) over third-party MCP tool calls. The envelopes it emits are RGE records. It interoperates with the gate through a shared session trace, so both governance surfaces share one view.

Related MCP server: Chirindo

Status

v0.2.2. Five of eight capabilities are fully implemented; three are explicit stubs that return structured not_implemented markers (callers can detect server maturity). The two load-bearing capabilities — descriptor verification and tool-call audit — are live. Envelopes follow RGE v0.2 (Reasoned Governance Envelope).

#	Capability	Status
1	Tool descriptor hash	✅ implemented
2	Descriptor change detection	✅ implemented
3	Tool permission scope	🟡 envelope field populated; policy logic stub
4	Tool call I/O hash	✅ implemented
5	User approval state	🟡 envelope field populated; UX surface stub
6	Runtime anomaly record	🟡 records to the audit side-log; drift scoring stub
7	Signed evidence envelope	✅ implemented (RGE v0.2)
8	Chain verification command	✅ implemented (`phionyx-mcp verify-chain`)

Install

pip install phionyx-mcp-server
phionyx-mcp --help

Use — as an MCP server

Add to your MCP-capable host (Claude Desktop example):

{
  "mcpServers": {
    "phionyx-governance": { "command": "phionyx-mcp-server" }
  }
}

The host then sees four production MCP tools:

verify_tool_descriptor(descriptor, baseline_hash) — hash and compare against an approved baseline (full descriptor, including protocolVersion).
record_tool_call(turn_index, user_text, producer, …, trace_id=None) — emit a signed RGE v0.2 envelope. trace_id is optional; resolved from PHIONYX_TRACE_ID or ~/.phionyx/active_trace.
verify_chain_integrity(trace_id=None) — walk the chain, refuse mixed schemas.
query_audit_history(trace_id=None, limit=50) — replay envelopes for review.

Plus three stub tools returning structured not_implemented markers.

Shared trace with the gate

When installed alongside phionyx-pipeline-mcp, the two servers share a single trace_id per session, so one session's evidence spans both governance surfaces:

PHIONYX_TRACE_ID env var → highest precedence.
PHIONYX_ACTIVE_TRACE_FILE (default ~/.phionyx/active_trace) → file fallback.
The first caller generates a UUID-derived trace and persists it.

Use — as a CLI

phionyx-mcp head --trace trace-abc123          # current chain head
phionyx-mcp verify-chain --trace trace-abc123  # walk + verify the chain
phionyx-mcp show --trace trace-abc123 --turn 7 # show one envelope

verify-chain selects its verifier from the environment: PHIONYX_MCP_VERIFY_KEY (Ed25519 public key, hex or path) → verify signatures; PHIONYX_MCP_DEMO=1 → the demo HMAC verifier; neither → signatures are not checked (hash continuity only).

Exit code — the same contract the printed assurance block reports:

exit	meaning
`0`	signatures verified (`valid: true` — assurance E2, or E0 in demo mode)
`1`	tamper/break (`valid: false`), or signatures not verified (`valid: null`, `NOT_MEASURED` — no verify key, so tamper-evidence is unmeasured, never a silent pass)
`2`	invocation error (bad path / corrupt chain)

The result carries an assurance block separating the dimensions — schema, hash_continuity, signature_performed, signature_valid, algorithm, key_id, key_trust, revocation, overall_assurance (E0/E1/E2/INVALID). key_trust and revocation are NOT_MEASURED here — they are concerns AIREP defines but an RGE v0.2 envelope does not carry, reported rather than faked.

Persistence

Envelopes are written under $PHIONYX_MCP_AUDIT_ROOT (default ~/.phionyx/mcp_audit/):

<root>/<trace_id>/chain.jsonl      (append-only index)
<root>/<trace_id>/<turn:06d>.json  (full canonical-JSON envelope)

Swap the persistence layer by passing an alternative EnvelopeStore-protocol implementation (S3, DynamoDB, …).

Schema — RGE v0.2

Envelopes conform to RGE v0.2 (Reasoned Governance Envelope). RGE is being developed toward AIREP interoperability; no AIREP-conformance claim is made. The signature covers all envelope content except the self-referential mcp_tool_audit.signed_envelope_ref. The schema, RFC, and worked examples ship in this repository.

Signing — the signer is chosen by the environment

environment	signer	`integrity.signature`
`PHIONYX_MCP_SIGNING_KEY` set (hex or path; `PHIONYX_MCP_KEY_ID` optional)	Ed25519 (production)	`ed25519:<hex>`
`PHIONYX_MCP_DEMO=1`	demo HMAC (evidence level E0 — the secret ships in-package)	`demo-hmac:<hex>`
neither	UNSIGNED	`unsigned`

A run with no key provisioned emits explicitly unsigned envelopes — the demo HMAC is never a silent stand-in for a missing production key. A real Ed25519 key always wins over the demo flag.

Tests

pip install -e .
pytest -q

The suite pins descriptor-hash semantics (full descriptor including protocolVersion), RGE v0.2 schema conformance (jsonschema Draft 2020-12), and hash-chain integrity (tamper, reorder, and mixed-schema detection).

License

AGPL-3.0-or-later.

Available Tools

7 tools

audit_record_decisionA

Catch-all decision logger — append a runtime decision (release/block/defer/redact) to the audit chain without populating mcp_tool_audit. Useful for non-MCP policy events the host wants to record alongside MCP calls.

ParametersJSON Schema

Name	Required	Description	Default
`turn_index`	Yes
`decision`	Yes
`decision_reason`	Yes
`trace_id`	No
`runtime_policy_basis`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/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 decisions are appended to the audit chain without populating mcp_tool_audit, a key behavioral trait. Does not mention side effects or permissions but is adequate for a simple append operation.

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?

Two sentences, each carrying significant information. First sentence combines purpose and key behavioral detail; second provides usage context. No redundant words.

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?

With 5 parameters and 0% schema coverage, description should provide more parameter context. It gives a good high-level purpose and usage but lacks explanation of individual parameters beyond listing example decision values. Provides adequate context for use but not full completeness.

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

Parameters2/5

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

Schema description coverage is 0%, but description does not explain any parameters. It mentions example values for 'decision' in the text but does not link them to the schema or explain required/optional fields like trace_id and runtime_policy_basis.

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?

Description clearly states it appends runtime decisions (release/block/defer/redact) to an audit chain, distinguishing it from record_tool_call which populates mcp_tool_audit. The verb 'append' and resource 'audit chain' are specific.

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 says it's for non-MCP policy events the host wants to record alongside MCP calls, implying it should not be used for MCP tool calls (use record_tool_call instead). Could be improved by stating direct alternatives.

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

flag_anomalyC

Capability 6 (stub in v0.1.0-dev): forward an anomaly observation from the host into the audit envelope's runtime_anomaly_flag field. Will pull live scores from phionyx_core.pipeline.blocks.behavioral_drift_detection in v0.5.

ParametersJSON Schema

Name	Required	Description	Default
`trace_id`	Yes
`source`	Yes
`severity`	Yes
`detail`	No
`session_id`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.4/5.0

Behavior2/5

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

With no annotations, the description carries full burden. It mentions being a stub and plans for future integration, but does not disclose side effects, error conditions, or whether the operation is destructive/reversible. The forwarding action is stated but lacks necessary behavioral context.

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

Conciseness3/5

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

The description is concise (two sentences) but front-loads a capability number and version note, which may confuse agents. It lacks a clear structure like purpose, usage, and parameter hints.

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

Completeness2/5

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

Given the tool has 5 parameters (0% schema coverage), no annotations, and is a stub, the description is insufficient. It does not explain return values (despite an output schema existing) or clarify the current limitations of the stub implementation.

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

Parameters1/5

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

Schema description coverage is 0%, and the description provides no information about the parameters (trace_id, source, severity, detail, session_id). Without any parameter semantics in either schema or description, the agent has no guidance on what values to provide.

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: forwarding anomaly observations into the audit envelope's runtime_anomaly_flag field. It distinguishes from sibling tools like audit_record_decision by focusing on anomaly flagging. However, the mention of 'stub' and future version adds ambiguity about current functionality.

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

Usage Guidelines2/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. While the purpose implies it should be used when an anomaly is detected, there is no exclusion criteria or comparison with siblings like record_tool_call or verify_chain_integrity.

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

query_audit_historyA

Read the audit chain for trace_id as a list of envelopes (most-recent first by default). Companion to verify_chain_integrity for replay and post-incident review.

ParametersJSON Schema

Name	Required	Description	Default
`trace_id`	No
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.5/5.0

Behavior3/5

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

The description adds behavioral context beyond schema: ordering (most-recent first) and companion relationship. However, no annotations exist, and the description omits critical details like whether trace_id is optional, default limits, or auth requirements. It partially compensates but leaves gaps.

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?

Two sentences, 18 words, no fluff. The key action and ordering are front-loaded. Every sentence adds value.

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

Completeness2/5

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

Despite having an output schema, the description does not cover essential parameter details (trace_id and limit) or behavioral traits like idempotency or side effects. For a tool with two parameters and no annotations, this is inadequate.

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

Parameters1/5

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

With 0% schema description coverage, the description fails to clarify parameters. It mentions trace_id in backticks but offers no explanation of its semantics, default, or the limit parameter. This is a major deficiency.

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 reads the audit chain for a trace_id as a list of envelopes, most-recent first. It explicitly mentions being a companion to verify_chain_integrity, distinguishing its purpose from related siblings.

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 provides usage context: 'for replay and post-incident review' and implies it is read-only compared to verify_chain_integrity. However, it does not explicitly state when not to use it or cover other siblings like audit_record_decision.

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

record_tool_callA

Capability 4 + 7: record a tool call (input + output hashes) as a signed RGE v0.2 envelope with the mcp_tool_audit block populated. Appends to the trace's audit chain and returns the new envelope's integrity hash. The envelope is persisted under ~/.phionyx/mcp_audit//.json by default (configurable via PHIONYX_MCP_AUDIT_ROOT).

ParametersJSON Schema

Name	Required	Default
`turn_index`	Yes
`user_text`	Yes
`producer`	Yes
`trace_id`	No
`tool_descriptor_hash`	No
`descriptor_change_detected`	No
`tool_permission_scope`	No
`input_hash`	No
`output_hash`	No
`approval_state`	No
`anomaly_flag`	No
`decision`	No	release
`decision_reason`	No	no policy violation
`runtime_policy_basis`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.5/5.0

Behavior4/5

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

With no annotations, the description carries full burden and reveals key behaviors: writing signed envelopes, appending to chain, returning hash, configurable persistence path. It omits potential failure modes, permission requirements, or side effects, but covers core behavior well.

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?

Three sentences (50 words) front-load capability IDs and action, then detail functionality. No redundant phrases; every sentence adds value.

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

Completeness2/5

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

Despite mentioning return of integrity hash, the description lacks explanation for 14 parameters, omits output schema details, and provides no examples. For a complex audit-writing tool, this is insufficient for an agent to use correctly.

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

Parameters1/5

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

Schema description coverage is 0% for 14 parameters. The description only mentions 'input + output hashes' but fails to explain critical parameters like turn_index, user_text, producer, trace_id, etc. This leaves agents without meaningful guidance on parameter usage.

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 records a tool call with input/output hashes as a signed envelope, appends to audit chain, returns integrity hash, and persists to file. It distinguishes from sibling audit tools (decision, anomaly, query, verification) by focusing solely on recording the call itself.

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 implies use for recording tool calls in an audit trail but does not explicitly state when to use this tool versus alternatives like audit_record_decision or query_audit_history. No when-not-to-use guidance is given.

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

record_user_approvalB

Capability 5 (stub in v0.1.0-dev): capture user approval state for a tool. Full implementation lands when the host-side UX surface is defined; current returns a structured 'not_implemented' marker that callers can detect.

ParametersJSON Schema

Name	Required	Description	Default
`tool_name`	Yes
`descriptor_hash`	Yes
`approved`	Yes
`approval_ref`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.4/5.0

Behavior4/5

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

Without annotations, the description effectively discloses that it is a stub and returns a structured 'not_implemented' marker, which is key behavioral info. Could be improved by noting if input data is stored or ignored.

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?

Description is three sentences, with the purpose in the first sentence and essential usage caveats in the next two. No filler or redundancy.

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

Completeness2/5

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

Given 4 parameters and an output schema, the description is incomplete. It omits parameter semantics and does not explain the return marker structure, which the output schema might cover but is not described.

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

Parameters2/5

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

Schema description coverage is 0% and the description does not explain any of the 4 parameters (tool_name, descriptor_hash, approved, approval_ref). Agent must infer meaning from names, which is insufficient for accurate invocation.

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?

Description states the tool captures user approval state for a tool, which is a clear verb+resource. However, it does not explicitly differentiate from sibling tools like 'audit_record_decision' which may have overlapping function.

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 indicates it's a stub and not yet fully implemented, guiding agents not to rely on it for persistent storage. But it lacks explicit when-to-use or alternatives among sibling tools.

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

verify_chain_integrityB

Capability 8: walk the persisted envelope chain for trace_id and verify every link. Refuses mixed-schema chains. Returns {valid, checked, broken_at, reason}.

ParametersJSON Schema

Name	Required	Description	Default
`trace_id`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses that the tool walks and verifies chains, refuses mixed-schema chains, and returns a specific structure ({valid, checked, broken_at, reason}). This provides good insight into behavior, though it doesn't mention side effects or permissions.

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

Conciseness3/5

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

The description is short (two sentences) but includes the unclear 'Capability 8' prefix. It conveys the main action and return format, but could be better structured and avoid jargon.

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 tool has one optional parameter and an output schema, the description mentions return fields but does not explain them in detail. It covers basic functionality but lacks completeness on error conditions or parameter behavior.

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

Parameters2/5

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

The schema has only one parameter (trace_id, nullable with default null). The description mentions 'trace_id' in context but does not explain the implications of null or the format. With 0% schema coverage, the description adds limited 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 the tool's purpose: to walk and verify every link in a persisted envelope chain for a given trace_id. It also mentions that it refuses mixed-schema chains, distinguishing it from sibling tools like verify_tool_descriptor.

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

Usage Guidelines2/5

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

The description does not provide any guidance on when to use this tool versus alternatives. It mentions 'Capability 8' which is not helpful, and there are no when-to-use or when-not-to-use instructions.

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

verify_tool_descriptorA

Capability 1 + 2: hash an MCP tool descriptor (Q3 semantics — full descriptor INCLUDING protocolVersion) and compare against the user-approved baseline. Returns the current hash and a change_detected flag. Hosts SHOULD call this before forwarding a tool call to detect post-approval descriptor drift (tool poisoning / rug pull defense per arXiv:2512.06556).

ParametersJSON Schema

Name	Required	Description	Default
`descriptor`	Yes
`baseline_hash`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses the hashing method (Q3 semantics), the comparison action, and the outputs (current hash and change_detected flag). It also references a security paper for context. No behavioral contradictions.

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?

The description is two sentences, front-loading the purpose and key details. Every sentence adds value, including the critical usage directive. No verbose or redundant phrases.

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 the tool's complexity (hashing, comparison, security context) and the presence of an output schema, the description covers purpose, usage, and behavioral details. It does not elaborate on parameter formats, but the output schema likely covers return values. It could be more complete if it explained parameter specifics.

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

Parameters2/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. It implicitly explains the 'descriptor' parameter as the object to hash and 'baseline_hash' as the comparison value, but it does not explicitly describe their structure, format, or constraints. This leaves ambiguity for an AI agent.

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 function: hashing an MCP tool descriptor with Q3 semantics including protocolVersion, then comparing it against a baseline hash to detect changes. It distinguishes itself from sibling tools like verify_chain_integrity by focusing on tool descriptor drift detection.

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 provides explicit usage guidance: 'Hosts SHOULD call this before forwarding a tool call to detect post-approval descriptor drift'. This tells when to use it, though it does not explicitly list alternatives or when not to use it.

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.

7 tool updatesv0.2.0Jun 10, 2026
- First observedaudit_record_decision
- First observedflag_anomaly
- First observedquery_audit_history
- First observedrecord_tool_call
- First observedrecord_user_approval
- First observedverify_chain_integrity
- First observedverify_tool_descriptor

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

A3.6/5.0

Scored 2026-06-10 10:10 across 7 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: recording decisions, flagging anomalies, querying history, recording tool calls, recording approvals, verifying chain integrity, and verifying descriptors. No two tools overlap in function.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., audit_record_decision, verify_chain_integrity). The naming is uniform and predictable.

Tool Count5/5

With 7 tools covering the core audit and integrity verification operations, the count is well-scoped for the server's purpose. No unnecessary tools are present, and the set is not too small.

Completeness4/5

The tool set covers recording, reading, and verifying the audit chain, as well as descriptor verification. A minor gap is the lack of a tool to list or manage traces, but this appears intentional for immutability.

Maintenance

ActivityMaintained

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

agent-audit-logger-mcp
io.github.CSOAI-ORG
Hash-chained HMAC-signed audit log MCP for A2A (agent-to-agent) calls. Every tool-call, agent-ha...
Security Observability
2
a2adependencyinspector-mcp
com.clauxel.a2adependencyinspector
Remote MCP for A2A dependency inspector MCP, structured receipts, audit logs, and reviewer-ready evi
Developer Tools Code Analysis
2
c2paintake-mcp
com.clauxel.c2paintake
Remote MCP for C2PA intake verifier MCP, structured receipts, audit logs, and reviewer-ready evidenc
Security Legal & Compliance
2
MCP Queen A
com.mcpqueen
The evidence layer for MCP: live operational grades plus Trust Receipts for every registry server.
Search Agent Orchestration
72

Related MCP Servers

Agent Audit Logger MCP
Security Observability
CSOAI-ORG
A
license
B
quality
C
maintenance
Hash-chained HMAC-signed audit log MCP for A2A (agent-to-agent) calls. Every tool-call, agent-handoff, decision gets a tamper-evident signed record.
Updated 3 months ago (2026-06-26 05:24 UTC)
5
167 PyPI
MIT
Chirindo
Security Agent Orchestration
LembaGang
A
license
Not graded
quality
B
maintenance
A fail-closed cryptographic gate for the MCP tool-call boundary that intercepts tools/call requests, evaluates a policy, and either forwards or denies the call with signed receipts, providing tamper-evident evidence for AI agent actions.
Updated 24 days ago (2026-08-27 14:02 UTC)
23 npm
Apache 2.0
Sentinel Gateway
Security Monitoring
jaisimha18
A
license
B
quality
C
maintenance
MCP zero-trust gateway that sits in front of every internal MCP server, detects tool-poisoning/metadata drift in real time, and maintains a cryptographic provenance ledger of every agent tool call.
Updated 2 months ago (2026-07-26 07:19 UTC)
20
3 npm
ISC
agent-receipts
Observability Security Monitoring
yulinlina
A
license
Not graded
quality
C
maintenance
An MCP server that provides append-only, tamper-evident local receipts for AI agent actions, capturing command executions, outputs, and handoff evidence.
Updated a month ago (2026-08-06 10:52 UTC)
MIT

phionyx-mcp-server

Where it fits

Status

Install

Use — as an MCP server

Shared trace with the gate

Use — as a CLI

Persistence

Schema — RGE v0.2

Signing — the signer is chosen by the environment

Tests

See also

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers