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.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.

TDQS

A4.5/5.0
Behavior5/5

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

The description goes well beyond the readOnlyHint annotation by disclosing the structured verdict shape (approve / approve_with_concerns / reject), ranked issues, suggested fixes, alternatives, advisory non-blocking behavior, capital-scale awareness, and the known-bad-address registry that can force a byte-reproducible reject. It also explains the provable-before-outcome property without contradicting 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?

The description is front-loaded with a clear 'CALL THIS WHEN' section and structured exclusions, making it scannable. However, several sentences are promotional or trust-building rather than operational, such as 'Built and dogfooded daily by our own autonomous fleet' and the verify-then-pay comparison, so not every sentence earns its place.

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?

For a 14-parameter tool with no output schema, the description is highly complete: it covers trigger conditions, accepted artifact types, expected verdict format, advisory behavior, irreversibility awareness, and proof/trust mechanics. The rich schema property descriptions fill the remaining parameter-level gaps, so an agent has enough context to invoke the tool correctly.

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% and each of the 14 parameters already has a rich description, so the baseline is 3. The tool description adds only light parameter-level value by enumerating example artifact types and trade details, but it does not materially extend the schema's parameter semantics.

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 a specific purpose: an independent second-opinion governance verdict before irreversible or high-stakes actions, with concrete examples such as shipping code, running a shell command, or placing a trade. The 'CALL THIS WHEN' conditions and the explicit 'NOT a human-approval step' clarification make it easy for an agent to distinguish this from execution, approval, or decision-style sibling tools.

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?

It gives explicit when-to-use guidance: before irreversible/high-stakes actions, when acting on another agent's unverifiable output, or when policy requires a neutral pre-action check. It also provides clear when-not-to-use context: it is not a human-approval gate, never blocks, and the agent remains fully autonomous and makes the final call.

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.