Skip to main content
Glama

review

Read-only

Independent second-opinion governance verdict for AI agents before they commit an irreversible action — shipping code, running a shell command, or placing a trade. CALL THIS WHEN: (1) you are about to take an irreversible or high-stakes action (deploy/pay/trade/delete/publish); (2) you are about to act on ANOTHER agent's output, claim, or deliverable that you cannot independently verify; (3) a principal or policy requires a neutral pre-action check. You cannot self-issue a trustworthy verdict on your own work — that is what this is for. Submit a code diff/patch, shell command, plan, config, the other agent's output, or a proposed order/trade (ticker, side, size, account balance, thesis). Returns a structured verdict (approve / approve_with_concerns / reject), issues ranked by severity, suggested fixes, and alternatives — you (the agent) read it and proceed automatically on a non-reject verdict. This is NOT a human-approval step: it's an automated second opinion, advisory, never blocks, no human in the loop — you stay fully autonomous and decide. Capital-scale-aware. Model-agnostic. Built and dogfooded daily by our own autonomous fleet (the same gate we run our own important decisions through). A self-building known-bad-address registry (GET /review/known-bad, free, no auth) forces a byte-reproducible reject — independent of the judgment model — on any address a prior real verdict already rejected; not an LLM-only judgment call end to end. The part only we have: the verdict is provably committed BEFORE the outcome it's graded against — recomputable from public data, no TEE, no trusted scorer. Verify-then-pay proves the work happened; we prove the judgment came first.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
signNoReturn a PORTABLE SIGNED proof of this verdict (binds verdict + artifact hash + our pubkey), including a content-addressed decision_ref = sha256(JCS({artifact_hash, artifact_type, policy_version, verdict, source_class})). Attach it to your output so a downstream agent can confirm via verify_proof — WITHOUT trusting you or us — that invinoveritas issued this verdict for this exact artifact. The agent-to-agent trust handshake. For artifact_type=trade|onchain_action|sanctions_screening, the proof also carries source_class ('agent_reported' today — no mediation-point integration exists yet) and, when applicable, a vantage_limitation field disclosing that the verdict is occurrence evidence, not an absence/completeness claim — check it before treating an irreversible-class verdict as sufficient on its own. The proof also carries an opaque engine_generation counter (informational, not bound into decision_ref) — compare it across two proofs to detect a backend/judgment-engine change between calls without us disclosing which model we run.
contextNoWhat you are trying to accomplish, why now, success criteria
artifactYesThe artifact to review: unified diff / patch, shell command, plan, config, analysis, agent output, or raw text
concernsNoSpecific things to check (e.g. 'production safety', 'edge cases in trading logic', 'regulatory risk')
artifact_typeNoType of artifact. 'code_diff' or 'patch' triggers deep code review. 'plan' for architecture/strategy. 'trade' triggers the capital-scale-aware risk-manager review of a proposed entry/exit. 'onchain_action' triggers the on-chain risk review of a proposed transfer/swap/approval/contract call (e.g. a Base MCP action) BEFORE you sign it — catches scam/honeypot tokens, unlimited-allowance drainers, address poisoning, slippage/MEV. 'sanctions_screening' for a compliance/AML result BEFORE acting on it — checks a categorical verdict (e.g. CLEAN) carries its own scope, not an unscoped claim. Tailors focus and suggestions. IMPORTANT for trade/onchain_action/sanctions_screening: a REJECT can happen purely from low confidence on an action you can't undo, even if content-wise the review leaned approve — see the response's reversibility_gate field. When present, epistemic_basis tells you WHY it's a reject: 'evidence_against' means a deterministic engine found a real positive finding (a known-bad address, an on-chain/sanctions hit); 'insufficient_evidence' means no finding either way, just confidence below the reversibility floor — different situations, do not treat them identically if your own logic branches on the reason.general
action_bindingNoOptional: the exact real-world action this verdict authorizes — tool identity, materialized (not templated) arguments, and the id of the agent that will execute it, e.g. {'tool': 'place_order', 'agent_id': 'your-stable-agent-id', 'args': {...}}. v14+: `tool` and `args` are bound as SEPARATE preimage fields (action_binding_tool_hash = sha256(tool), action_binding_args_hash = sha256(RFC-8785-JCS(args))) so a verifier can assert 'same tool, different arguments' as a checkable statement; `agent_id` is bound as a plain string (action_binding_agent_id, not hashed). All bound DIRECTLY into decision_ref — so the verdict commits to the exact action, not just the free-text `artifact` argument or the verdict conclusion. Recomputing decision_ref without byte-identical tool/args/agent_id values produces a different hash: an approval cannot be replayed against a different tool, different materialized arguments, or a different agent. Every sub-key is optional. Max ~8KB JSON-encoded. NOT independently verified by us — we hash exactly what you send. HONEST LIMIT: nothing stops a caller from submitting an under-specified action_binding (e.g. tool+side but not size) and getting an approval reusable across the omitted dimension — that's about who controls what goes into the fingerprint, not how it's hashed.
disclosed_summaryNoOnly used when confidentiality_tier='partial_disclosure'. A real, human-readable description of the reviewed artifact/decision you're choosing to make public — bound raw into decision_ref. Ignored for other tier values.
intended_audienceNoOptional: declare who/what this verdict is intended for (your own DID, endpoint URL, or gateway identifier). Bound into decision_ref so it can't be silently stripped or altered once issued. NOT independently verified — a reader compares this against their own identity and treats a mismatch as a signal the proof may be presented outside its intended context, a real context-binding replay-protection gap that earlier policy versions had no way to represent at all.
intended_verifierNoOptional: a CAIP-10 string naming the specific on-chain verifier/gate this verdict is meant to be checked against, e.g. 'eip155:8453:0x8004A169FB4a3325136EB29fA0ceB6D2e539a432'. Bound into decision_ref (itself inside the schnorr-signed content) so it achieves real crypto-level domain separation — the raw signed bytes otherwise bind only to our pubkey + content, nothing to a specific chain/contract, so a proof is technically replayable against any gate willing to accept it. NOT independently verified — a gate compares this against its own chain_id/address.
severity_thresholdNoMinimum severity to reportall
related_proof_eventNoOptional: if the artifact being reviewed IS another party's already-signed verdict proof (a verdict-of-verdict re-review), pass that proof's full signed event ({id, pubkey, created_at, kind, tags, content, sig}). We independently re-verify it ourselves before its source_class can affect this call's own — capped, never upgraded (an independent_mediator call reviewing an agent_reported inner verdict stays agent_reported). Fails closed to agent_reported if the inner event doesn't verify, regardless of your own registry status. One hop only. HONEST SCOPE: we verify the cited event's own authenticity, not that it's actually the thing your artifact claims to be re-reviewing.
request_capture_refNoOptional: a requester-controlled commitment (a hash/id you generated and can independently prove existed at request-time) that this artifact was submitted for review — the captured-admission-v0 review profile (trustless-ai/recompute-kit). Echoed back verbatim in the response's admission_receipt. NOT independently verified by us; closes the /ledger raw-tape-vs-published gap only for requesters who opt in.
confidentiality_tierNoWhich privacy/evidentiary tradeoff this verdict should use, only meaningful with sign=true. 'hash_only' (default): the proof carries only artifact_hash, raw content never disclosed — strongest privacy, weakest standalone evidentiary value (a third party can't confirm what the hash corresponds to without your later cooperation). 'partial_disclosure': pass disclosed_summary, bound raw into decision_ref, so a third party gets real checkable context without full exposure. 'full_disclosure': records intent to publish this verdict to the public /ledger (full_disclosure_requested=true in the proof) — strongest evidentiary tier, but actual publication is still a separate curated step on our side, not yet fully self-serve.hash_only
include_trading_stateNoSentinel mode: inject live Sovereign Earner state (equity, regime, open position, PnL) for trading-related reviews. Highly recommended for any trading or risk decision.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • changedInput schema / properties / artifact_type / description
      Previous value: -"Type of artifact. 'code_diff' or 'patch' triggers deep code review. 'plan' for architecture/strategy. 'trade' triggers the capital-scale-aware risk-manager review of a proposed entry/exit. 'onchain_action' triggers the on-chain risk review of a proposed transfer/swap/approval/contract call (e.g. a Base MCP action) BEFORE you sign it — catches scam/honeypot tokens, unlimited-allowance drainers, address poisoning, slippage/MEV. 'sanctions_screening' for a compliance/AML result BEFORE acting on it — checks a categorical verdict (e.g. CLEAN) carries its own scope, not an unscoped claim. Tailors focus and suggestions. IMPORTANT for trade/onchain_action/sanctions_screening: a REJECT can happen purely from low confidence on an action you can't undo, even if content-wise the review leaned approve — see the response's reversibility_gate field."New value: +"Type of artifact. 'code_diff' or 'patch' triggers deep code review. 'plan' for architecture/strategy. 'trade' triggers the capital-scale-aware risk-manager review of a proposed entry/exit. 'onchain_action' triggers the on-chain risk review of a proposed transfer/swap/approval/contract call (e.g. a Base MCP action) BEFORE you sign it — catches scam/honeypot tokens, unlimited-allowance drainers, address poisoning, slippage/MEV. 'sanctions_screening' for a compliance/AML result BEFORE acting on it — checks a categorical verdict (e.g. CLEAN) carries its own scope, not an unscoped claim. Tailors focus and suggestions. IMPORTANT for trade/onchain_action/sanctions_screening: a REJECT can happen purely from low confidence on an action you can't undo, even if content-wise the review leaned approve — see the response's reversibility_gate field. When present, epistemic_basis tells you WHY it's a reject: 'evidence_against' means a deterministic engine found a real positive finding (a known-bad address, an on-chain/sanctions hit); 'insufficient_evidence' means no finding either way, just confidence below the reversibility floor — different situations, do not treat them identically if your own logic branches on the reason."
  2. Changed1 schema field changed
    • addedInput schema / properties / action_binding
      Added value: +{
      +  "description": "Optional: the exact real-world action this verdict authorizes — tool identity, materialized (not templated) arguments, and the id of the agent that will execute it, e.g. {'tool': 'place_order', 'agent_id': 'your-stable-agent-id', 'args': {...}}. v14+: `tool` and `args` are bound as SEPARATE preimage fields (action_binding_tool_hash = sha256(tool), action_binding_args_hash = sha256(RFC-8785-JCS(args))) so a verifier can assert 'same tool, different arguments' as a checkable statement; `agent_id` is bound as a plain string (action_binding_agent_id, not hashed). All bound DIRECTLY into decision_ref — so the verdict commits to the exact action, not just the free-text `artifact` argument or the verdict conclusion. Recomputing decision_ref without byte-identical tool/args/agent_id values produces a different hash: an approval cannot be replayed against a different tool, different materialized arguments, or a different agent. Every sub-key is optional. Max ~8KB JSON-encoded. NOT independently verified by us — we hash exactly what you send. HONEST LIMIT: nothing stops a caller from submitting an under-specified action_binding (e.g. tool+side but not size) and getting an approval reusable across the omitted dimension — that's about who controls what goes into the fingerprint, not how it's hashed.",
      +  "type": "object"
      +}
  3. Changed1 schema field changed
    • addedInput schema / properties / request_capture_ref
      Added value: +{
      +  "description": "Optional: a requester-controlled commitment (a hash/id you generated and can independently prove existed at request-time) that this artifact was submitted for review — the captured-admission-v0 review profile (trustless-ai/recompute-kit). Echoed back verbatim in the response's admission_receipt. NOT independently verified by us; closes the /ledger raw-tape-vs-published gap only for requesters who opt in.",
      +  "type": "string"
      +}
  4. Changed1 schema field changed
    • addedInput schema / properties / intended_verifier
      Added value: +{
      +  "description": "Optional: a CAIP-10 string naming the specific on-chain verifier/gate this verdict is meant to be checked against, e.g. 'eip155:8453:0x8004A169FB4a3325136EB29fA0ceB6D2e539a432'. Bound into decision_ref (itself inside the schnorr-signed content) so it achieves real crypto-level domain separation — the raw signed bytes otherwise bind only to our pubkey + content, nothing to a specific chain/contract, so a proof is technically replayable against any gate willing to accept it. NOT independently verified — a gate compares this against its own chain_id/address.",
      +  "type": "string"
      +}
  5. Changed2 schema fields changed
    • addedInput schema / properties / confidentiality_tier
      Added value: +{
      +  "default": "hash_only",
      +  "description": "Which privacy/evidentiary tradeoff this verdict should use, only meaningful with sign=true. 'hash_only' (default): the proof carries only artifact_hash, raw content never disclosed — strongest privacy, weakest standalone evidentiary value (a third party can't confirm what the hash corresponds to without your later cooperation). 'partial_disclosure': pass disclosed_summary, bound raw into decision_ref, so a third party gets real checkable context without full exposure. 'full_disclosure': records intent to publish this verdict to the public /ledger (full_disclosure_requested=true in the proof) — strongest evidentiary tier, but actual publication is still a separate curated step on our side, not yet fully self-serve.",
      +  "enum": [
      +    "hash_only",
      +    "partial_disclosure",
      +    "full_disclosure"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / disclosed_summary
      Added value: +{
      +  "description": "Only used when confidentiality_tier='partial_disclosure'. A real, human-readable description of the reviewed artifact/decision you're choosing to make public — bound raw into decision_ref. Ignored for other tier values.",
      +  "type": "string"
      +}
  6. Changed1 schema field changed
    • addedInput schema / properties / intended_audience
      Added value: +{
      +  "description": "Optional: declare who/what this verdict is intended for (your own DID, endpoint URL, or gateway identifier). Bound into decision_ref so it can't be silently stripped or altered once issued. NOT independently verified — a reader compares this against their own identity and treats a mismatch as a signal the proof may be presented outside its intended context, a real context-binding replay-protection gap that earlier policy versions had no way to represent at all.",
      +  "type": "string"
      +}
  7. Changed1 schema field changed
    • addedInput schema / properties / related_proof_event
      Added value: +{
      +  "description": "Optional: if the artifact being reviewed IS another party's already-signed verdict proof (a verdict-of-verdict re-review), pass that proof's full signed event ({id, pubkey, created_at, kind, tags, content, sig}). We independently re-verify it ourselves before its source_class can affect this call's own — capped, never upgraded (an independent_mediator call reviewing an agent_reported inner verdict stays agent_reported). Fails closed to agent_reported if the inner event doesn't verify, regardless of your own registry status. One hop only. HONEST SCOPE: we verify the cited event's own authenticity, not that it's actually the thing your artifact claims to be re-reviewing.",
      +  "type": "object"
      +}
  8. Changed1 schema field changed
    • changedInput schema / properties / sign / description
      Previous value: -"Return a PORTABLE SIGNED proof of this verdict (binds verdict + artifact hash + our pubkey), including a content-addressed decision_ref = sha256(JCS({artifact_hash, artifact_type, policy_version, verdict, source_class})). Attach it to your output so a downstream agent can confirm via verify_proof — WITHOUT trusting you or us — that invinoveritas issued this verdict for this exact artifact. The agent-to-agent trust handshake. For artifact_type=trade|onchain_action|sanctions_screening, the proof also carries source_class ('agent_reported' today — no mediation-point integration exists yet) and, when applicable, a vantage_limitation field disclosing that the verdict is occurrence evidence, not an absence/completeness claim — check it before treating an irreversible-class verdict as sufficient on its own."New value: +"Return a PORTABLE SIGNED proof of this verdict (binds verdict + artifact hash + our pubkey), including a content-addressed decision_ref = sha256(JCS({artifact_hash, artifact_type, policy_version, verdict, source_class})). Attach it to your output so a downstream agent can confirm via verify_proof — WITHOUT trusting you or us — that invinoveritas issued this verdict for this exact artifact. The agent-to-agent trust handshake. For artifact_type=trade|onchain_action|sanctions_screening, the proof also carries source_class ('agent_reported' today — no mediation-point integration exists yet) and, when applicable, a vantage_limitation field disclosing that the verdict is occurrence evidence, not an absence/completeness claim — check it before treating an irreversible-class verdict as sufficient on its own. The proof also carries an opaque engine_generation counter (informational, not bound into decision_ref) — compare it across two proofs to detect a backend/judgment-engine change between calls without us disclosing which model we run."
  9. Changed1 schema field changed
    • changedInput schema / properties / sign / description
      Previous value: -"Return a PORTABLE SIGNED proof of this verdict (binds verdict + artifact hash + our pubkey), including a content-addressed decision_ref = sha256(JCS({artifact_hash, artifact_type, policy_version, verdict, source_class})). Attach it to your output so a downstream agent can confirm via verify_proof — WITHOUT trusting you or us — that invinoveritas issued this verdict for this exact artifact. The agent-to-agent trust handshake. For artifact_type=trade|onchain_action|sanctions_screening, the proof also carries source_class ('agent_reported' today — no mediation-point integration exists yet) and, when applicable, a vantage_limitation field disclosing that the verdict is occurrence evidence, not an absence/completeness claim — check it before treating an irreversible-class verdict as sufficient on its own. The proof also carries an opaque engine_generation counter (informational, not bound into decision_ref) — compare it across two proofs to detect a backend/judgment-engine change between calls without us disclosing which model we run."New value: +"Return a PORTABLE SIGNED proof of this verdict (binds verdict + artifact hash + our pubkey), including a content-addressed decision_ref = sha256(JCS({artifact_hash, artifact_type, policy_version, verdict, source_class})). Attach it to your output so a downstream agent can confirm via verify_proof — WITHOUT trusting you or us — that invinoveritas issued this verdict for this exact artifact. The agent-to-agent trust handshake. For artifact_type=trade|onchain_action|sanctions_screening, the proof also carries source_class ('agent_reported' today — no mediation-point integration exists yet) and, when applicable, a vantage_limitation field disclosing that the verdict is occurrence evidence, not an absence/completeness claim — check it before treating an irreversible-class verdict as sufficient on its own."
  10. Changed1 schema field changed
    • changedInput schema / properties / sign / description
      Previous value: -"Return a PORTABLE SIGNED proof of this verdict (binds verdict + artifact hash + our pubkey), including a content-addressed decision_ref = sha256(JCS({artifact_hash, artifact_type, policy_version, verdict, source_class})). Attach it to your output so a downstream agent can confirm via verify_proof — WITHOUT trusting you or us — that invinoveritas issued this verdict for this exact artifact. The agent-to-agent trust handshake. For artifact_type=trade|onchain_action|sanctions_screening, the proof also carries source_class ('agent_reported' today — no mediation-point integration exists yet) and, when applicable, a vantage_limitation field disclosing that the verdict is occurrence evidence, not an absence/completeness claim — check it before treating an irreversible-class verdict as sufficient on its own."New value: +"Return a PORTABLE SIGNED proof of this verdict (binds verdict + artifact hash + our pubkey), including a content-addressed decision_ref = sha256(JCS({artifact_hash, artifact_type, policy_version, verdict, source_class})). Attach it to your output so a downstream agent can confirm via verify_proof — WITHOUT trusting you or us — that invinoveritas issued this verdict for this exact artifact. The agent-to-agent trust handshake. For artifact_type=trade|onchain_action|sanctions_screening, the proof also carries source_class ('agent_reported' today — no mediation-point integration exists yet) and, when applicable, a vantage_limitation field disclosing that the verdict is occurrence evidence, not an absence/completeness claim — check it before treating an irreversible-class verdict as sufficient on its own. The proof also carries an opaque engine_generation counter (informational, not bound into decision_ref) — compare it across two proofs to detect a backend/judgment-engine change between calls without us disclosing which model we run."
  11. Changed1 schema field changed
    • changedInput schema / properties / sign / description
      Previous value: -"Return a PORTABLE SIGNED proof of this verdict (binds verdict + artifact hash + our pubkey), including a content-addressed decision_ref = sha256(JCS({artifact_hash, artifact_type, policy_version, verdict, source_class})). Attach it to your output so a downstream agent can confirm via verify_proof — WITHOUT trusting you or us — that invinoveritas issued this verdict for this exact artifact. The agent-to-agent trust handshake. For artifact_type=trade|onchain_action|sanctions_screening, the proof also carries source_class ('agent_reported' today — no mediation-point integration exists yet) and, when applicable, a vantage_limitation field disclosing that the verdict is occurrence evidence, not an absence/completeness claim — check it before treating an irreversible-class verdict as sufficient on its own. The proof also carries an opaque engine_generation counter (informational, not bound into decision_ref) — compare it across two proofs to detect a backend/judgment-engine change between calls without us disclosing which model we run."New value: +"Return a PORTABLE SIGNED proof of this verdict (binds verdict + artifact hash + our pubkey), including a content-addressed decision_ref = sha256(JCS({artifact_hash, artifact_type, policy_version, verdict, source_class})). Attach it to your output so a downstream agent can confirm via verify_proof — WITHOUT trusting you or us — that invinoveritas issued this verdict for this exact artifact. The agent-to-agent trust handshake. For artifact_type=trade|onchain_action|sanctions_screening, the proof also carries source_class ('agent_reported' today — no mediation-point integration exists yet) and, when applicable, a vantage_limitation field disclosing that the verdict is occurrence evidence, not an absence/completeness claim — check it before treating an irreversible-class verdict as sufficient on its own."
  12. Changed1 schema field changed
    • changedInput schema / properties / sign / description
      Previous value: -"Return a PORTABLE SIGNED proof of this verdict (binds verdict + artifact hash + our pubkey), including a content-addressed decision_ref = sha256(JCS({artifact_hash, artifact_type, policy_version, verdict, source_class})). Attach it to your output so a downstream agent can confirm via verify_proof — WITHOUT trusting you or us — that invinoveritas issued this verdict for this exact artifact. The agent-to-agent trust handshake. For artifact_type=trade|onchain_action|sanctions_screening, the proof also carries source_class ('agent_reported' today — no mediation-point integration exists yet) and, when applicable, a vantage_limitation field disclosing that the verdict is occurrence evidence, not an absence/completeness claim — check it before treating an irreversible-class verdict as sufficient on its own."New value: +"Return a PORTABLE SIGNED proof of this verdict (binds verdict + artifact hash + our pubkey), including a content-addressed decision_ref = sha256(JCS({artifact_hash, artifact_type, policy_version, verdict, source_class})). Attach it to your output so a downstream agent can confirm via verify_proof — WITHOUT trusting you or us — that invinoveritas issued this verdict for this exact artifact. The agent-to-agent trust handshake. For artifact_type=trade|onchain_action|sanctions_screening, the proof also carries source_class ('agent_reported' today — no mediation-point integration exists yet) and, when applicable, a vantage_limitation field disclosing that the verdict is occurrence evidence, not an absence/completeness claim — check it before treating an irreversible-class verdict as sufficient on its own. The proof also carries an opaque engine_generation counter (informational, not bound into decision_ref) — compare it across two proofs to detect a backend/judgment-engine change between calls without us disclosing which model we run."
  13. Changed3 schema fields changed
    • changedInput schema / properties / artifact_type / description
      Previous value: -"Type of artifact. 'code_diff' or 'patch' triggers deep code review. 'plan' for architecture/strategy. 'trade' triggers the capital-scale-aware risk-manager review of a proposed entry/exit. 'onchain_action' triggers the on-chain risk review of a proposed transfer/swap/approval/contract call (e.g. a Base MCP action) BEFORE you sign it — catches scam/honeypot tokens, unlimited-allowance drainers, address poisoning, slippage/MEV. Tailors focus and suggestions."New value: +"Type of artifact. 'code_diff' or 'patch' triggers deep code review. 'plan' for architecture/strategy. 'trade' triggers the capital-scale-aware risk-manager review of a proposed entry/exit. 'onchain_action' triggers the on-chain risk review of a proposed transfer/swap/approval/contract call (e.g. a Base MCP action) BEFORE you sign it — catches scam/honeypot tokens, unlimited-allowance drainers, address poisoning, slippage/MEV. 'sanctions_screening' for a compliance/AML result BEFORE acting on it — checks a categorical verdict (e.g. CLEAN) carries its own scope, not an unscoped claim. Tailors focus and suggestions. IMPORTANT for trade/onchain_action/sanctions_screening: a REJECT can happen purely from low confidence on an action you can't undo, even if content-wise the review leaned approve — see the response's reversibility_gate field."
    • changedInput schema / properties / artifact_type / enum
      Previous value: -[
      -  "code_diff",
      -  "patch",
      -  "shell_command",
      -  "plan",
      -  "config_change",
      -  "analysis",
      -  "agent_output",
      -  "trade",
      -  "onchain_action",
      -  "general"
      -]New value: +[
      +  "code_diff",
      +  "patch",
      +  "shell_command",
      +  "plan",
      +  "config_change",
      +  "analysis",
      +  "agent_output",
      +  "trade",
      +  "onchain_action",
      +  "sanctions_screening",
      +  "general"
      +]
    • changedInput schema / properties / sign / description
      Previous value: -"Return a PORTABLE SIGNED proof of this verdict (binds verdict + artifact hash + our pubkey). Attach it to your output so a downstream agent can confirm via verify_proof — WITHOUT trusting you or us — that invinoveritas issued this verdict for this exact artifact. The agent-to-agent trust handshake."New value: +"Return a PORTABLE SIGNED proof of this verdict (binds verdict + artifact hash + our pubkey), including a content-addressed decision_ref = sha256(JCS({artifact_hash, artifact_type, policy_version, verdict, source_class})). Attach it to your output so a downstream agent can confirm via verify_proof — WITHOUT trusting you or us — that invinoveritas issued this verdict for this exact artifact. The agent-to-agent trust handshake. For artifact_type=trade|onchain_action|sanctions_screening, the proof also carries source_class ('agent_reported' today — no mediation-point integration exists yet) and, when applicable, a vantage_limitation field disclosing that the verdict is occurrence evidence, not an absence/completeness claim — check it before treating an irreversible-class verdict as sufficient on its own."
  14. Changed2 schema fields changed
    • changedInput schema / properties / artifact_type / description
      Previous value: -"Type of artifact. 'code_diff' or 'patch' triggers deep code review. 'plan' for architecture/strategy. 'trade' triggers the capital-scale-aware risk-manager review of a proposed entry/exit. Tailors focus and suggestions."New value: +"Type of artifact. 'code_diff' or 'patch' triggers deep code review. 'plan' for architecture/strategy. 'trade' triggers the capital-scale-aware risk-manager review of a proposed entry/exit. 'onchain_action' triggers the on-chain risk review of a proposed transfer/swap/approval/contract call (e.g. a Base MCP action) BEFORE you sign it — catches scam/honeypot tokens, unlimited-allowance drainers, address poisoning, slippage/MEV. Tailors focus and suggestions."
    • changedInput schema / properties / artifact_type / enum
      Previous value: -[
      -  "code_diff",
      -  "patch",
      -  "shell_command",
      -  "plan",
      -  "config_change",
      -  "analysis",
      -  "agent_output",
      -  "trade",
      -  "general"
      -]New value: +[
      +  "code_diff",
      +  "patch",
      +  "shell_command",
      +  "plan",
      +  "config_change",
      +  "analysis",
      +  "agent_output",
      +  "trade",
      +  "onchain_action",
      +  "general"
      +]
  15. Changed1 schema field changed
    • addedInput schema / properties / sign
      Added value: +{
      +  "default": false,
      +  "description": "Return a PORTABLE SIGNED proof of this verdict (binds verdict + artifact hash + our pubkey). Attach it to your output so a downstream agent can confirm via verify_proof — WITHOUT trusting you or us — that invinoveritas issued this verdict for this exact artifact. The agent-to-agent trust handshake.",
      +  "type": "boolean"
      +}
  16. Changed2 schema fields changed
    • changedInput schema / properties / artifact_type / description
      Previous value: -"Type of artifact. 'code_diff' or 'patch' triggers deep code review. 'plan' for architecture/strategy. Tailors focus and suggestions."New value: +"Type of artifact. 'code_diff' or 'patch' triggers deep code review. 'plan' for architecture/strategy. 'trade' triggers the capital-scale-aware risk-manager review of a proposed entry/exit. Tailors focus and suggestions."
    • changedInput schema / properties / artifact_type / enum
      Previous value: -[
      -  "code_diff",
      -  "patch",
      -  "shell_command",
      -  "plan",
      -  "config_change",
      -  "analysis",
      -  "agent_output",
      -  "general"
      -]New value: +[
      +  "code_diff",
      +  "patch",
      +  "shell_command",
      +  "plan",
      +  "config_change",
      +  "analysis",
      +  "agent_output",
      +  "trade",
      +  "general"
      +]
  17. Changed1 schema field changed
    • removedInput schema / properties / return_suggestions
      Removed value: -{
      -  "default": true,
      -  "description": "Include concrete suggested fixes or alternative approaches (recommended for Grok Build / coding workflows)",
      -  "type": "boolean"
      -}
  18. Changed8 schema fields changed
    • changedInput schema / properties / artifact / description
      Previous value: -"The thing to review (diff, command, plan, config, analysis, output)"New value: +"The artifact to review: unified diff / patch, shell command, plan, config, analysis, agent output, or raw text"
    • changedInput schema / properties / artifact_type / description
      Previous value: -"What kind of artifact this is. Tailors review focus."New value: +"Type of artifact. 'code_diff' or 'patch' triggers deep code review. 'plan' for architecture/strategy. Tailors focus and suggestions."
    • changedInput schema / properties / artifact_type / enum
      Previous value: -[
      -  "code_diff",
      -  "shell_command",
      -  "plan",
      -  "config_change",
      -  "analysis",
      -  "agent_output",
      -  "general"
      -]New value: +[
      +  "code_diff",
      +  "patch",
      +  "shell_command",
      +  "plan",
      +  "config_change",
      +  "analysis",
      +  "agent_output",
      +  "general"
      +]
    • changedInput schema / properties / concerns / description
      Previous value: -"Optional: specific things you want checked (e.g., 'is this safe on production', 'any edge cases')"New value: +"Specific things to check (e.g. 'production safety', 'edge cases in trading logic', 'regulatory risk')"
    • changedInput schema / properties / context / description
      Previous value: -"Optional: what this is trying to accomplish, why now, what success looks like"New value: +"What you are trying to accomplish, why now, success criteria"
    • changedInput schema / properties / include_trading_state / description
      Previous value: -"Sentinel mode: auto-inject current Sovereign Earner state (equity, regime, open position, PnL, pause status) into review context. Use for trading-related diffs/configs/directives. Opt-in."New value: +"Sentinel mode: inject live Sovereign Earner state (equity, regime, open position, PnL) for trading-related reviews. Highly recommended for any trading or risk decision."
    • addedInput schema / properties / return_suggestions
      Added value: +{
      +  "default": true,
      +  "description": "Include concrete suggested fixes or alternative approaches (recommended for Grok Build / coding workflows)",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / severity_threshold / description
      Previous value: -"Lowest severity to surface in issues list"New value: +"Minimum severity to report"
  19. Changed1 schema field changed
    • addedInput schema / properties / include_trading_state
      Added value: +{
      +  "default": false,
      +  "description": "Sentinel mode: auto-inject current Sovereign Earner state (equity, regime, open position, PnL, pause status) into review context. Use for trading-related diffs/configs/directives. Opt-in.",
      +  "type": "boolean"
      +}
  20. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only provide readOnlyHint=true and openWorldHint=false; the description carries the full behavioral burden and exceeds it. It discloses the advisory/non-blocking posture, the deterministic known-bad-address registry that forces a byte-reproducible reject independent of the judgment model, the epistemic_basis distinction (evidence_against vs insufficient_evidence), honest limitations on action_binding under-specification, and that verdicts are occurrence evidence, not absence claims. No contradiction with the read-only annotation.

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?

Front-loaded correctly with purpose and labeled CALL THIS WHEN sections, but the latter half drifts into credibility/marketing content ('Built and dogfooded daily by our own autonomous fleet', 'The part only we have', 'Verify-then-pay proves the work happened; we prove the judgment came first'). These trust-signaling passages do not change how an agent invokes the tool and could be trimmed by roughly a third without losing operational value.

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?

With no output schema and 14 parameters including nested objects and enums, the description carries real burden — and it delivers the key interaction contract: the verdict shape (approve / approve_with_concerns / reject), ranked issues, fixes, alternatives, and the rule to 'proceed automatically on a non-reject verdict.' Some response semantics (admission_receipt, decision_ref composition, reversibility_gate) live in parameter descriptions rather than the tool description, so it is not fully self-contained, but the whole definition is operationally sufficient.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The tool description adds only marginal param context — e.g., elaborating what a trade artifact should contain (ticker, side, size, account balance, thesis) — while the schema's own per-parameter descriptions (artifact_type, sign, action_binding) are already exceptionally detailed. The description neither compensates for gaps nor substantially augments 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 opening sentence states a specific role — 'Independent second-opinion governance verdict for AI agents before they commit an irreversible action' — with concrete examples (shipping code, shell command, trade). The three numbered CALL THIS WHEN triggers and the explicit 'This is NOT a human-approval step' disambiguation separate it cleanly from siblings like execute, decision, reason, and validate.

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?

Provides an explicit, numbered when-to-call list covering irreversible actions, acting on another agent's unverifiable output, and policy-mandated checks. Also states exclusions: 'You cannot self-issue a trustworthy verdict on your own work' and clarifies the tool never blocks and keeps the agent autonomous. This is among the strongest usage guidance possible.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.6/5.0
Disambiguation4/5

Most tools have clearly distinct purposes, but there is potential confusion between 'decision' and 'reason', both offering advisory output. Also, 'review', 'witness', 'prove', and 'verify_proof' overlap in the proofs space, though descriptions differentiate them. Overall, an agent can disambiguate with careful reading.

Naming Consistency4/5

All tool names use lowercase and underscores (snake_case), which is consistent. However, the verbs vary: some are imperative (e.g., 'browse', 'execute'), while others are nouns (e.g., 'signals', 'ledger'), breaking a strict verb_noun pattern. Overall, the naming is readable and mostly predictable.

Tool Count2/5

With 30 tools, the surface is too large for a well-scoped server. Many functions could be separated (e.g., memory, workspace, feedback, marketplace). This excess makes it harder for an agent to navigate and select the right tool quickly.

Completeness3/5

The tool set covers core CRUD for memory and workspace, plus feedback, marketplace purchase, bounties, and verification. However, there is no tool to list or search marketplace listings, and workspace creation is only implicit via 'execute'. These gaps hinder fluid workflows.