You can mint, verify, and gate tamper-evident receipts for consequential agent actions, with optional read-only Trust Gate API evidence views.
Mint signed receipts for CRM record changes, with old/new values stored as SHA-256 hashes.
Audit a caller-provided MCP tool inventory by worst-regret ranking; read-only, no receipt.
Mint signed receipts for arbitrary agent actions, with optional caller-claimed attestation fields.
Verify receipts offline, check integrity, and optionally pin the signer via expected_kid with PQ-required verification.
Run a two-phase decision gate: PREVIEW returns ALLOW/DENY/ESCALATE; COMMIT re-evaluates and mints a signed verdict receipt, issuing GRANTED only on ALLOW.
Classify a data sample for egress sensitivity and get a receipt; the tool flags blocked but cannot block itself.
Run an exit drill checking local signing key and Ollama model configuration, returning a receipt.
When configured with Trust Gate API credentials, use nine read-only views for oversight cases, role questions, intervention evidence, qualification changes, acceptance packs, receipt/decision evidence, decision replay, and requalification proposals.
Allows verification of local model access via Ollama as part of vendor exit readiness drills.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Trust Gate MCP mint receipt for approving high-value purchase"
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.
Tamper-evident receipts for consequential agent actions, as an MCP server, with a decision gate that returns ALLOW, DENY or ESCALATE.
Sixteen tools: seven local ones on one shared signing primitive, the open-source OpenAgentOntology mint_receipt, plus nine optional read-only views over a Trust Gate API (see "Read-only API views" below).
What actually gets signed depends on what you install -- OAO detects its backend at import time, so this is worth stating plainly rather than advertising the best case:
Install | Legs | Notes |
| Ed25519 + ML-DSA-65 | Default. The ML-DSA leg comes from |
| Ed25519 + ML-DSA-65 (native backend) | Installs |
PQ-required verify (the default) demands at least one verified post-quantum leg. That shows a post-quantum signature is present and valid over the same bytes. It does not say whose key made it (see "What a valid receipt proves"), and it does not make the default backend production-grade.
Tool | What it does |
| Mints a receipt for a CRM record change. Works with any CRM (open-core Relaticle, hosted CRMs via their own MCP, custom). Old/new values are SHA-256 hashes (unsalted, so a low-entropy value can be guessed from its hash). |
| Ranks a CALLER-PROVIDED list of MCP tools by worst-regret if they act (a name-based heuristic that weights a name's first word most: |
| Receipt for any consequential agent action. Attestation values ( |
| Verify a receipt from the certificate alone -- offline, no DB. Refuses unsigned receipts, checks the |
| Two-phase decision gate with a real verdict. PREVIEW returns ALLOW, DENY or ESCALATE with the risk tier and reasons, without acting. COMMIT re-evaluates and mints a signed receipt for the verdict. Only ALLOW returns a |
| Flags sensitive markers in a data sample (a finite list of keywords, SSN and card-number shapes, and common credential formats, including |
| Vendor exit readiness drill. Checks the local signing key (names the post-quantum backend and whether the hash-based leg is available) and that a local model endpoint is configured (Ollama; it is not contacted, and a remote host is not counted). Returns step-by-step results + receipt. Informational; it signs one receipt, which creates the signing key on a host that has none yet. |
Nine tools show what a Trust Gate API computes from records YOU supply. They do nothing until you set
TRUST_GATE_API_URL (https; http only for localhost), TRUST_GATE_API_KEY (a bearer credential issued for one tenant) and
TRUST_GATE_TENANT_ID. The seven local tools above need none of these and never call out.
Tool | Shows |
| Readiness report for one oversight case |
| Questions routed to a role for a case. It proposes; it asks no one |
| Evidence on whether an intervention could be shown to have taken effect |
| Status of each proposed retest after a change: current, not current or unbound |
| Acceptance-pack export, optionally mapped to one control id and version you name |
| Evidence view of one receipt, with what the service could and could not check |
| Evidence view, verdict and open questions for a decision and its facts |
| Replay of a decision's evidence path over supplied records. It executes nothing |
| Impact and a requalification proposal. It never runs a retest |
Each takes one object, request, forwarded as the call body. Rules every one follows:
Read-only. Nothing is written, signed, executed or authorized. The answer is built from the records you pass in; their claims are yours, not verified facts.
The tenant is configuration. request may not name a tenant at its top level, and a tenant key at any depth (tenant, tenant_id, tenant-id, TenantId, in any case) must equal TRUST_GATE_TENANT_ID, otherwise the request is refused before any call. Only TRUST_GATE_TENANT_ID is ever sent as the tenant.
Fail closed. A missing setting, a 404 (the surface is off or not deployed), a rate limit, a server error, a transport error or an answer of the wrong shape returns status: "UNAVAILABLE" with a reason. A refusal from the API returns REFUSED with its short code. Data is never filled in or defaulted.
The credential is never logged or returned, and no exception text is passed on.
A mapping or readout is not a compliance finding. Every result says so.
Version match. The receipt, decision, replay, propose and requalification views (get_receipt_evidence, get_decision_evidence, replay_decision, propose_requalification, compare_qualification_change) and the case, question, evidence and pack views need a Trust Gate API version that serves them. Against an older server, or one with the surface switched off, they return UNAVAILABLE (surface_not_available) until it does.
Requests are capped at 64 KiB; answers are read up to 1 MiB (error bodies up to 4 KiB) and never further. 10 second timeout, no redirects, and proxy environment variables are ignored.
Related MCP server: DCL Evaluator
Scope. It applies only to actions your code routes through gate_decision. It does not observe, intercept or block anything an agent does, and it does not check afterward whether an action happened. Your code (a hook, a wrapper) must ask first and must obey the answer.
ALLOW is a closed list. An action gets ALLOW only when its name is a known read verb (read, get, list, search, query, find, show, view, inspect, describe) followed only by words from a small built-in vocabulary of nouns (for example read_file, list_files, search_files, list_dir, get_user, describe_table), the name is a plain identifier, and the resource is built only from words of that vocabulary, a few ordinary document words (readme, guide, changelog, ...) and source or prose file types (md, txt, py, ...), with digits allowed between words (docs/2024/notes.md). A name that contains any other word escalates to a human, because the gate has not seen it. This is deliberately narrow: most real file names escalate. Widening it means adding words to the vocabulary in the source, which is a visible change.
Structural rules escalate as well. A hidden path (.env, .ssh, .git, ..), an absolute path, a URL, a host name as the first part of a path (example.com/x, localhost), a network address in any of its usual spellings (four dotted numbers of any width, hexadecimal, octal such as 0177.1, one long integer, 0; short dotted numbers such as 1.2.3 stay versions unless the last number is too large for a version or the first is 0 or 127), a resource that starts with -, a phrase of three or more words, anything containing characters other than letters, digits, spaces and _ . - / (after Unicode compatibility folding), and a file whose real type is configuration, data, key, state or archive (a rotation counter such as .1 is ignored when judging the type; a listed data or archive type earlier in a dotted name, such as users.csv.txt, counts too). A resource that carries a command escalates: a listed mutating word (alter, merge, flush, load, ...), a critical verb glued to a word (deleteall), or any multi-word resource after a query verb.
DENY is for a critical lead verb (payments, deletion, deployment, code execution, privilege changes). A risky word elsewhere in the name, or in the resource, escalates so that a human decides; so do the high-risk lead verbs (format, remove, reset, release, escalate) and a file name that contains a risky word (test_delete_user.py).
Risky and sensitive words are listed, and the lists are finite. Listed secret and regulated-data words (password, token, key, pass, config, ssn, diagnosis, ... in their glued, plural and digit-swapped forms) give the HIGH tier a specific reason. The lists are not what keeps a name from being allowed (a sensitive name on no list still escalates, because ALLOW is closed). history is not a read noun. Matching runs across word boundaries, so some harmless names show the sensitive reason (api/index.md contains "pii"). A lookup such as list_users is a read like any other: the gate does not judge how much personal data it returns. Common read tools whose names contain a word that is also a risky verb (get_email, list_messages) escalate.
It is a name-based heuristic, not a proof. ALLOW does not mean the action is safe: an agent that calls a dangerous tool read_file is not caught, because the gate sees names, not behaviour. context is recorded in the receipt as a hash and is not used to decide. There is no operator override in this package.
Read the verdict from the receipt, and check who issued it. receipt.decision (and receipt.evidence.ontology.verdict) are signed. The top-level verdict and permit fields of the response are not; verify_receipt lists the unsigned keys of any receipt it checks. A receipt is a gate verdict from your server only if verify_receipt with expected_kid set to your server's kid returns signer_pinned: true AND verified.issuer_tool is gate_decision AND verified.operation is decision_gate_commit; every other tool signs its own issuer_tool, and without the pin those fields are only claims made by whoever signed.
No permit without a receipt this server would accept. COMMIT issues GRANTED only if the receipt was minted and signed, and verifies under this server's own policy (in PQ-required mode that includes a valid post-quantum signature).
Action and resource are recorded in clear text in the signed receipt. Do not put secrets or personal data in them.
A receipt is evidence of a verdict, not a log entry. atom_id is derived from the content (40 bits of the evidence hash), so identical decisions share one and different decisions can too; key on evidence_hash and signed_at. The server keeps no log of the receipts it signs: store the ones you need. There is no replay or freshness check: compare evidence.ontology.action and resource with what you are about to do.
0.2.1 returned GRANTED for every action. Upgrade to 0.3.0 or later. See the changelog.
verify_receipt returning ok: true means the evidence is unchanged since it was signed, the receipt carries a signature, any kid it carries matches the key it carries, and (in the default PQ-required mode) at least one post-quantum signature verified over the same bytes.
It does not mean the receipt came from a server you trust: anyone can generate keys and sign a receipt. To check who signed, pass expected_kid (the kid of the Ed25519 key you trust, learned out of band; 32 hexadecimal characters, case and surrounding spaces ignored, a blank or malformed pin is refused). A pin counts only when that key's own Ed25519 signature verifies, and signer_pinned: true says it did (a signature verifying shows that the key signed those bytes, not that anyone holds its private key: Ed25519 accepts a few special public keys that verify for any message, which cannot affect a pin on a key you trust); ok: true with signer_pinned: false is an integrity result only, and kid is reported only when the Ed25519 signature verified. A receipt that names an Ed25519 signer (key or kid) without a valid signature from it is refused: those two values are public and can be copied into a receipt signed with other keys.
On stdio the signing key is stored unencrypted under the user's home directory, so an agent running as that user can read it: a pin does not protect against the agent you are gating. The kid fingerprints the Ed25519 key only. The ML-DSA and hash-based keys inside a receipt are not covered by it, so a pinned check is only as strong against a quantum attacker as Ed25519. Results can also depend on which post-quantum backends the verifying host has installed (a leg it cannot check is reported unverifiable).
H1 key persistence + bootstrap with FAIL-CLOSED kid-drift check (container deploy; the bootstrap checks the Ed25519 key only)
H2 per-IP token-bucket rate limit (FIFO eviction). It parses the request body exactly as the MCP transport does, from the raw bytes (a byte-order mark, UTF-16 and UTF-32 are read too), and charges the tool it names; the signing tools share the signing budget. A body it cannot parse, or one over 64 KiB, is charged to the signing budget; a request is refused with 413 as soon as its body exceeds 1 MiB (at most 1 MiB is buffered). Signing (about 70 ms per call with the default backend) and verification (about 20 ms) run on the event loop and the budgets are per client, so there is no overall cap on that work. Clients are identified by the connection address as uvicorn resolves it: set TRUST_GATE_FORWARDED_ALLOW_IPS to your proxy's address, or any client can choose its own identity with an X-Forwarded-For header.
H3 PQ-required verify: refuses a receipt with no verified post-quantum signature (and any unsigned receipt)
H4 128-bit kid on every minted receipt, recomputed from the canonical key bytes and checked on verify
Optional bearer auth and a narrowed CORS allowlist via TRUST_GATE_BEARER_TOKEN + TRUST_GATE_ALLOWED_ORIGINS
The test suite pins every listed verb, noun and sensitive word individually (from an independent copy of the lists) and tests their inflected, plural, glued, digit-swapped and compatibility-character forms, plus adversarial cases for receipt forgery and PQ stripping; real MCP requests are posted through the whole HTTP stack
The HTTP entrypoint (server_http.py) is written for the container image, where its modules sit side by side; with a pip install, use the stdio server. Bearer auth is off by default and CORS is * in that mode. Anyone who can reach an open deployment can obtain receipts signed with its key, including "ALLOW" receipts for read-only names, and a receipt from an open deployment says nothing about who asked. If you host it, set TRUST_GATE_BEARER_TOKEN and TRUST_GATE_ALLOWED_ORIGINS.
The HTTP entrypoint counts ?via=<label> visits as one log line (label, kind, user-agent family). Only three built-in labels plus those named in TRUST_GATE_CHANNELS (comma separated) are recorded; the host's own access log also records request lines, including client addresses.
DNS-rebinding protection is off and there is no switch for it: on a local HTTP server without bearer auth, any web page you visit can call it. Put it behind a proxy that checks the Host header, or set TRUST_GATE_BEARER_TOKEN.
pip install trust-gate-mcp
trust-gate-mcpAdd [slh] for the native ML-DSA backend (see the table above). From a checkout, pip install -e ".[dev]" then
python -m trust_gate_mcp.
docker build -t trust-gate-mcp .
docker run -p 8081:8081 -v trust-gate-data:/data/oao trust-gate-mcpThe volume mount on /data/oao is required for production: without it the signing key changes on every container restart, receipts signed before a restart still verify from their own certificate, but a pinned kid stops matching new ones. The persistent key_metadata.json holds the signer's kid; the bootstrap step refuses to start if it drifts. The image installs dilithium-py by default; see the table above.
Apache-2.0 (full text in LICENSE). Copyright 2026 Cyber Warrior Network. Built on the open-source OpenAgentOntology primitive.
Rank a CALLER-PROVIDED list of MCP tools by worst-regret if they act (a name-based heuristic that weights a name's first word most). Read-only: it mints no receipt. Cannot auto-discover the inventory -- MCP does not allow that; the caller must pass it in.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | ||
| inventory | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations the description carries the full burden, and it does disclose the key traits: read-only with no receipt minted, the name-first-word heuristic nature, and the hard inability to auto-discover inventory. It omits behavior on malformed or empty input (errors, ranking ties), which keeps it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core action and free of filler. Slightly dense parentheses aside, but every clause adds a distinct fact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation, and the heuristic plus read-only constraint are covered. The unexplained 'notes' parameter and the undocumented structure of inventory entries, against 0% schema coverage, leave it only partially complete for a nontrivial ranking tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description must compensate, but it only characterizes the inventory argument loosely ('list of MCP tools'). The shape of inventory items and the entire 'notes' parameter are left unexplained in both schema and description, leaving a real gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Rank a CALLER-PROVIDED list of MCP tools by worst-regret') and immediately qualifies the scope with the heuristic used. It clearly distinguishes itself from the mint_*/verify_* siblings by stating it mints no receipt, so an agent can route correctly without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a real usage constraint ('Cannot auto-discover the inventory -- MCP does not allow that; the caller must pass it in') and implies its read-only role versus receipt-minting siblings. However, it never states when to reach for this tool versus check_egress or gate_decision, so selection guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Egress classification check. Scans a data sample for a finite list of sensitivity markers and classifies as NO_MARKERS_FOUND / INTERNAL / CONFIDENTIAL / RESTRICTED. RESTRICTED sets blocked=true; this tool cannot block anything itself, and NO_MARKERS_FOUND is not clearance to send. Returns classification, retention info, and a tamper-evident receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | Yes | ||
| data_sample | Yes | ||
| destination | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose key traits: RESTRICTED drives blocked=true, the tool is non-enforcing, and the result includes retention info and a tamper-evident receipt. It omits whether the sample itself is retained/logged (implied by 'retention info') and any auth or rate-limit requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the core action, followed by the exclusivity caveat and return summary. No filler or repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, yet the description still summarizes the returns, which is mildly redundant but helpful. Combined with the classification semantics and enforcement boundary, an agent has enough to decide whether to call it; the main gap is undocumented parameter formats.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for all three required parameters, so the description must compensate and largely does not. It implies data_sample is what gets scanned but says nothing about the format or meaning of 'provider' and 'destination' (e.g., is provider an email/cloud vendor, is destination a URL?).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('scans a data sample for sensitivity markers and classifies') and names the exact output taxonomy (NO_MARKERS_FOUND / INTERNAL / CONFIDENTIAL / RESTRICTED). This is distinct from siblings like gate_decision or verify_receipt, which handle enforcement and receipts respectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly bounds the tool's role with two strong exclusions: 'this tool cannot block anything itself' and 'NO_MARKERS_FOUND is not clearance to send.' However, it never names the alternative tool (e.g., gate_decision) that does perform blocking, so the agent must infer the routing itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Status of each proposed retest after a change (current, not current or unbound), from the proposal inputs and results you supply. Read-only view of the records you supply; it writes, signs and executes nothing. Needs TRUST_GATE_API_URL, TRUST_GATE_API_KEY and TRUST_GATE_TENANT_ID to be set, and the tenant comes from that setting, never from an argument. Returns status OK, REFUSED or UNAVAILABLE (a missing setting, a surface that is off, or an error is UNAVAILABLE, never made-up data). The Trust Gate API must be a version that serves this view; it returns UNAVAILABLE until then. A mapping or readout is not a compliance finding.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full load and does so well: it discloses read-only semantics ('writes, signs and executes nothing'), auth/config requirements (TRUST_GATE_API_URL/KEY/TENANT_ID, tenant never from an argument), and the explicit OK/REFUSED/UNAVAILABLE response contract including the no-fabrication guarantee and version gating.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The key constraint (read-only, no writes) is front-loaded and every clause is substantive, but the tail end is slightly padded with restatements ('never made-up data', 'A mapping or readout is not a compliance finding') that dilute focus.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value detail is partly redundant, and config/version caveats are well covered. However, for a tool whose only parameter is a free-form nested object, the absence of any guidance on request contents is a meaningful gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the single required parameter is an open-ended nested object ('request', additionalProperties true). The description only gestures at 'the proposal inputs and results you supply' without naming or documenting any of the request's expected fields, leaving the agent unable to construct a valid call from the definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: it returns the status of each proposed retest after a change, enumerating the possible statuses (current, not current, unbound). It is distinguishable from siblings such as propose_requalification, though it does not explicitly contrast itself with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the tool is a read-only comparison view that takes proposal inputs and results, which implies usage, but it never says when to call it instead of propose_requalification or replay_decision. The only explicit conditions are prerequisites (env vars, API version), not selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Acceptance-pack export for one or more cases, optionally mapped to one control id and version you name. Read-only view of the records you supply; it writes, signs and executes nothing. Needs TRUST_GATE_API_URL, TRUST_GATE_API_KEY and TRUST_GATE_TENANT_ID to be set, and the tenant comes from that setting, never from an argument. Returns status OK, REFUSED or UNAVAILABLE (a missing setting, a surface that is off, or an error is UNAVAILABLE, never made-up data). The Trust Gate API must be a version that serves this view; it returns UNAVAILABLE until then. A mapping or readout is not a compliance finding.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses read-only semantics, that nothing is written/signed/executed, the three required environment settings, that the tenant comes from config and never from an argument, and the OK/REFUSED/UNAVAILABLE status model including that errors surface as UNAVAILABLE rather than fabricated data. It also states the API version prerequisite and the 'not a compliance finding' caveat; only per-status remediation is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and scope come first, followed by behavior, prerequisites and return statuses in a logical order. The environment-variable and status enumeration is dense but each clause carries operational meaning; only the phrasing is slightly compressed rather than padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a nested opaque request object, no annotations and an existing output schema, the description covers the operational essentials: read-only nature, required configuration, tenant resolution, and the tri-state return model. Remaining gaps are minor — what a REFUSED implies for the caller's next step, and any limits on case volume.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the single `request` parameter is an untyped free-form object, so the description does real work by revealing that it carries one or more cases plus an optional control id and version. That is partial compensation only — the shape, field names and required contents of `request` remain undocumented in both places.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource pair ('Acceptance-pack export for one or more cases') and adds the optional control-id/version mapping, so an agent knows exactly what is produced. It does not name any sibling tool, so differentiation from the many other evidence/receipt tools is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly frames this as a read-only view of records the caller supplies ('it writes, signs and executes nothing'), which implicitly tells an agent this is the non-mutating path. However, there is no explicit when-to-use versus alternatives guidance and no sibling is referenced, so the agent must infer its place among export/evidence tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Two-phase decision gate with a real verdict. PREVIEW returns ALLOW, DENY or ESCALATE with the risk tier and reasons, plus a preview_id, without acting. COMMIT re-evaluates the same inputs and mints a signed receipt for the verdict. Only ALLOW returns a GRANTED permit; DENY returns DENIED; ESCALATE returns WITHHELD_PENDING_HUMAN and a human must decide outside this tool. Applies only to actions the caller routes through it: it does not observe or block what an agent does. Verb-tier heuristic on the action name and resource, not a proof. Stateless. Optional attestation: triggered_by_type, triggered_by_source, decision_model.
| Name | Required | Description | Default |
|---|---|---|---|
| phase | No | PREVIEW | |
| action | Yes | ||
| context | Yes | ||
| resource | Yes | ||
| preview_id | No | ||
| decision_model | No | ||
| triggered_by_type | No | ||
| triggered_by_source | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses statelessness, that the verdict comes from a verb-tier heuristic on the action name and resource rather than a proof, exactly what each verdict returns, and that ESCALATE requires a human outside this tool. It also warns that the gate does not observe or block un-routed agent actions – a critical scope limit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core concept ('Two-phase decision gate with a real verdict') followed by tightly packed sentences that each carry distinct, load-bearing information. No filler or restatement of the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a stateless, high-complexity tool with an output schema, the description covers the phase model, verdict outcomes, scope limits, and attestation fields adequately; the output schema relieves it of describing return shape. The main gap is `context` semantics and the precise preview_id→COMMIT linkage, but overall it is close to complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% across 8 parameters, so the description must compensate. It explains phase (PREVIEW/COMMIT), preview_id's role in the two-phase flow, and that triggered_by_type/source/model are optional attestation, but it never explains the `context` object or what triggered_by_* actually attest, leaving several parameters undocumented in both places.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('two-phase decision gate') and enumerates the exact verdicts (ALLOW/DENY/ESCALATE) and phase semantics (PREVIEW/COMMIT). It is distinguishable from siblings like mint_action_receipt and verify_receipt because it frames this tool as the decision gate that other tools' receipts record/verify.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context: PREVIEW acts without acting, COMMIT re-evaluates and mints a receipt, and it only applies to actions the caller explicitly routes through it. It does not, however, explicitly say when to choose this over mint_action_receipt or verify_receipt, so the alternative-routing guidance is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evidence view, verdict and open questions for one decision and the facts you supply. Read-only view of the records you supply; it writes, signs and executes nothing. Needs TRUST_GATE_API_URL, TRUST_GATE_API_KEY and TRUST_GATE_TENANT_ID to be set, and the tenant comes from that setting, never from an argument. Returns status OK, REFUSED or UNAVAILABLE (a missing setting, a surface that is off, or an error is UNAVAILABLE, never made-up data). The Trust Gate API must be a version that serves this view; it returns UNAVAILABLE until then. A mapping or readout is not a compliance finding.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it states the operation writes, signs and executes nothing; enumerates the required environment settings TRUST_GATE_API_URL, TRUST_GATE_API_KEY and TRUST_GATE_TENANT_ID; specifies that tenant comes from configuration and never from an argument; and discloses the OK/REFUSED/UNAVAILABLE outcome model with the guarantee that missing config or errors yield UNAVAILABLE rather than fabricated data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded and every sentence adds a real constraint (read-only, env vars, status semantics, API version dependency). The prose is slightly dense and the opening clause is grammatically tangled, but there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value detail is not strictly required, and the description still adds useful status semantics. The decisive gap is the opaque nested `request` parameter and the absence of any routing hint against sibling evidence tools, which leaves an agent unable to construct a correct call from the definition alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter is an untyped object with additionalProperties allowed and 0% schema description coverage, so the description must compensate and does not. Phrases like 'the facts you supply' and 'the records you supply' gesture at its contents without naming a single field, shape, or required key inside `request`.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence names the resource (evidence view, verdict, open questions for one decision) and the scope (the facts you supply), which is specific enough to distinguish it from a plain decision read. However, it never names or contrasts the near-identical siblings get_intervention_evidence and get_receipt_evidence, so an agent must guess which evidence tool to pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes that this is read-only and touches nothing, but gives no explicit when-to-use guidance and no alternatives among 15 siblings. It also does not say when NOT to call it (e.g. versus replay_decision for re-execution or verify_receipt for signature checking).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evidence for whether an intervention could be shown to have taken effect, from the records you supply. Read-only view of the records you supply; it writes, signs and executes nothing. Needs TRUST_GATE_API_URL, TRUST_GATE_API_KEY and TRUST_GATE_TENANT_ID to be set, and the tenant comes from that setting, never from an argument. Returns status OK, REFUSED or UNAVAILABLE (a missing setting, a surface that is off, or an error is UNAVAILABLE, never made-up data). The Trust Gate API must be a version that serves this view; it returns UNAVAILABLE until then. A mapping or readout is not a compliance finding.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so well: it states the tool is strictly read-only, writes/signs/executes nothing, requires three environment settings, takes tenant only from configuration, and returns OK, REFUSED, or UNAVAILABLE rather than made-up data. It also discloses an API-version dependency and failure semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and then layers in read-only behavior, environment requirements, return statuses, version dependency, and scope disclaimer. It is slightly long and repeats 'records you supply,' but most sentences add concrete value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value explanation is not strictly needed, yet the description still usefully names the possible statuses. However, for a tool with a nested, undocumented request parameter, the definition stops short of explaining the input shape an agent needs in order to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the single required parameter is a nested object with additionalProperties. The description only says evidence comes 'from the records you supply' and that tenant is never an argument; it does not describe the request object's fields or structure, leaving the parameter materially undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb+resource: it retrieves evidence for whether an intervention took effect, from supplied records. It does not explicitly distinguish itself from close siblings such as get_receipt_evidence or get_decision_evidence, so the agent must infer which evidence-retrieval tool to use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied through 'records you supply' and the disclaimer that 'a mapping or readout is not a compliance finding,' but there is no explicit when-to-use guidance versus alternatives. The agent is left to infer selection among get_decision_evidence, get_receipt_evidence, and similar siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evidence view of one receipt you supply, with what the service could and could not check. Read-only view of the records you supply; it writes, signs and executes nothing. Needs TRUST_GATE_API_URL, TRUST_GATE_API_KEY and TRUST_GATE_TENANT_ID to be set, and the tenant comes from that setting, never from an argument. Returns status OK, REFUSED or UNAVAILABLE (a missing setting, a surface that is off, or an error is UNAVAILABLE, never made-up data). The Trust Gate API must be a version that serves this view; it returns UNAVAILABLE until then. A mapping or readout is not a compliance finding.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden and does so well: read-only, writes/signs/executes nothing, tenant sourced from config not arguments, explicit return statuses OK/REFUSED/UNAVAILABLE, and failure-to-UNAVAILABLE semantics rather than fabricated data plus an API-version gating note.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but largely front-loaded and each clause carries information (env requirements, statuses, version gating, the compliance caveat). Some run-on bundling of failure modes could be tightened, but waste is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values are partly covered, and the description handles env/behavior/statuses thoroughly. The significant remaining gap is that an agent learns nothing about what the required `request` payload must contain for this nested-object tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for a single opaque `request` object with additionalProperties true. The description only clarifies one negative constraint (tenant is never passed as an argument) and that the receipt is the one supplied; it says nothing about the shape or required contents of `request`.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: an evidence view of one supplied receipt, including what could and could not be checked. This is distinguishable from a bare verify/read tool, though it never explicitly contrasts itself with siblings like verify_receipt or get_decision_evidence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives prerequisites (TRUST_GATE_API_URL/KEY/TENANT_ID) and behavioral constraints, and warns that a mapping or readout is not a compliance finding. However, it never states when to choose this over verify_receipt or get_decision_evidence, leaving usage selection implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Readiness report for one oversight case, computed from the records you supply. Read-only view of the records you supply; it writes, signs and executes nothing. Needs TRUST_GATE_API_URL, TRUST_GATE_API_KEY and TRUST_GATE_TENANT_ID to be set, and the tenant comes from that setting, never from an argument. Returns status OK, REFUSED or UNAVAILABLE (a missing setting, a surface that is off, or an error is UNAVAILABLE, never made-up data). The Trust Gate API must be a version that serves this view; it returns UNAVAILABLE until then. A mapping or readout is not a compliance finding.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so thoroughly: it states the tool writes, signs, and executes nothing; explains required environment variables and that tenant comes from configuration rather than an argument; and defines OK, REFUSED, and UNAVAILABLE, including that errors are never replaced with made-up data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and safety context, then proceeds through prerequisites and return semantics. It is mostly efficient, though 'the records you supply' is repeated and some sentences are dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers operational context such as read-only behavior, environment configuration, error statuses, and API version dependency, and an output schema exists for return values. However, for a tool with a required nested request object and zero schema description coverage, it does not provide enough detail for an agent to construct a valid request.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single nested request object with no property descriptions and 0% coverage, so the description must compensate. It only vaguely says the report is computed from 'the records you supply' and clarifies that tenant is not an argument, but it does not describe the request object's structure or expected fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation as a readiness report for one oversight case, computed from supplied records, and clarifies that it is a read-only view. It does not name alternative sibling tools, but the explicit contrast with writing, signing, and executing helps distinguish it from mutation-oriented siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by saying it is a read-only readiness report and not a compliance finding, and it notes prerequisites like required environment settings and a compatible API version. However, it does not explicitly say when to use this tool versus alternatives such as get_intervention_evidence, gate_decision, or audit_my_agent_inventory.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mint a signed receipt (Ed25519, plus ML-DSA-65 when the post-quantum backend is available) for an arbitrary consequential agent action. Optional attestation: triggered_by_type (human/agent/script), triggered_by_source (api/cli/cron), decision_model (the LLM model used). Attestation values are caller claims: allowlisted to safe characters, signed, not verified. Decisions that contain a gate verdict word are reserved for gate_decision.
| Name | Required | Description | Default |
|---|---|---|---|
| inputs | No | ||
| policy | No | agent action evidence | |
| target | Yes | ||
| agent_id | Yes | ||
| decision | No | ACTION_GOVERNED | |
| operation | Yes | ||
| decision_model | No | ||
| triggered_by_type | No | ||
| triggered_by_source | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden, and it does disclose meaningful traits: Ed25519 signing with ML-DSA-65 fallback, attestation values being caller claims (allowlisted, signed, not verified), and the reservation rule. It omits permissions/auth requirements and durability of the emitted receipt.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and mechanism, then the optional attestation, then the exclusion rule. Dense but each sentence carries information; only the parenthetical backend caveat is slightly incidental.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation, and the description covers mechanism, optional fields, and sibling routing. It would be complete if it addressed the overlap with mint_receipt_for_record_change and any auth prerequisites for minting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% across 9 params, so the description must compensate. It documents three parameters with example values (triggered_by_type human/agent/script, triggered_by_source api/cli/cron, decision_model) and implicitly constrains 'decision' via the gate-verdict rule, but agent_id, operation, target, inputs, policy, and the ACTION_GOVERNED default are left undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('mint a signed receipt ... for an arbitrary consequential agent action') with the crypto mechanism named, and explicitly carves out the sibling gate_decision for gate-verdict decisions. An agent can distinguish it from verify_receipt and gate_decision without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes gate-verdict-word decisions to gate_decision, which is genuine when-not guidance. However it never mentions mint_receipt_for_record_change, the nearest-scoped sibling, so the agent must infer the boundary between 'arbitrary action' and 'record change'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mint a signed receipt (Ed25519, plus ML-DSA-65 when the post-quantum backend is available) for one CRM record change. Old/new values are carried as SHA-256 hashes. Works with any CRM (Relaticle, hosted CRMs, custom).
| Name | Required | Description | Default |
|---|---|---|---|
| field | Yes | ||
| policy | No | per-decision CRM change evidence | |
| tenant | No | ||
| new_value | Yes | ||
| old_value | Yes | ||
| record_id | Yes | ||
| object_type | Yes | ||
| changed_by_agent | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does add real behavioral context: signature algorithms (Ed25519, conditional ML-DSA-65), SHA-256 hashing of values, and CRM-agnostic support. It omits important traits for a mutation-style tool, such as whether receipts are persisted, idempotency, required permissions, or failure behavior when the post-quantum backend is unavailable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the core purpose. Some budget is spent on crypto-backend detail that matters less than the undocumented parameters, but there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need no explanation, but for an 8-parameter, annotation-free tool the description leaves too much unsaid. No parameter guidance, no usage routing, and no operational constraints make it insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 8 parameters (6 required), so the description must compensate and does not. It never explains record_id, object_type, field, tenant, policy, or changed_by_agent, and its claim that old/new values are 'carried as SHA-256 hashes' ambiguously implies hashing behavior without clarifying whether callers pass raw or pre-hashed values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (mint) and resource (signed receipt for one CRM record change) plus scope, so an agent knows what it produces. However, it does not distinguish itself from the sibling mint_action_receipt, leaving the agent to guess which receipt tool applies to which scenario.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no prerequisites, and no routing to or from alternatives like mint_action_receipt or verify_receipt, despite those siblings existing. The agent is left to infer the place of this tool in the broader workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Impact and a requalification PROPOSAL for a change, over the graph you supply. It never runs a retest. Read-only view of the records you supply; it writes, signs and executes nothing. Needs TRUST_GATE_API_URL, TRUST_GATE_API_KEY and TRUST_GATE_TENANT_ID to be set, and the tenant comes from that setting, never from an argument. Returns status OK, REFUSED or UNAVAILABLE (a missing setting, a surface that is off, or an error is UNAVAILABLE, never made-up data). The Trust Gate API must be a version that serves this view; it returns UNAVAILABLE until then. A mapping or readout is not a compliance finding.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses read-only semantics, the required TRUST_GATE_* environment settings, that tenant comes from config not arguments, and detailed failure behavior (missing setting/off surface/error all yield UNAVAILABLE, never fabricated data). It also warns about API version prerequisites and that a mapping is not a compliance finding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then constraints and failure modes. Slight redundancy between 'never runs a retest' and 'writes, signs and executes nothing', but every sentence largely earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists covering the status values, and the description reinforces it. Behavioral coverage is strong for a complex tool; the notable gap is the shape of the nested request payload, which the description does not compensate for.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single opaque 'request' object with additionalProperties=true and 0% schema coverage. The description only hints that it carries 'the graph you supply' and 'records you supply' without describing the object's structure, so the nested payload remains largely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the resource (a requalification proposal for a change) and scope (impact analysis over the supplied graph, no retest executed). It reads partly as a restatement of the name, but the negative scoping ('never runs a retest', 'writes, signs and executes nothing') genuinely clarifies what the tool is.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through the read-only framing and the 'returns UNAVAILABLE until the API serves this view' caveat, but there is no explicit routing versus siblings like compare_qualification_change or gate_decision. An agent must infer when to pick this over the comparison tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Questions routed to a role for one oversight case, from the records and source lookups you supply. It proposes; it never asks anyone. Read-only view of the records you supply; it writes, signs and executes nothing. Needs TRUST_GATE_API_URL, TRUST_GATE_API_KEY and TRUST_GATE_TENANT_ID to be set, and the tenant comes from that setting, never from an argument. Returns status OK, REFUSED or UNAVAILABLE (a missing setting, a surface that is off, or an error is UNAVAILABLE, never made-up data). The Trust Gate API must be a version that serves this view; it returns UNAVAILABLE until then. A mapping or readout is not a compliance finding.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full load and does it well: it declares a read-only view, states it writes/signs/executes nothing, names the three required settings, specifies that tenant comes from config and never from an argument, and defines the OK/REFUSED/UNAVAILABLE semantics including that errors degrade to UNAVAILABLE rather than fabricated data. It also flags the API-version prerequisite and the caveat that a mapping is not a compliance finding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The read-only claim is restated three times ("it never asks anyone", "writes, signs and executes nothing", "read-only view"), and the most actionable content (env vars, status codes) is buried mid-paragraph. The purpose should lead; instead the emphatic negations do.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with an output schema and no annotations, the description covers setup, failure modes, safety posture and interpretation caveats thoroughly. The one real hole is the input contract for the sole `request` object, which is undocumented in both schema and description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the single `request` parameter is an open object with no property documentation, so the description must compensate. It partially does by indicating the payload holds records and source lookups and that tenant must NOT be passed as an argument, but it never describes the shape, required keys, or a role identifier for the request.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence is a noun phrase ("Questions routed to a role for one oversight case") rather than a clear verb+resource statement, so the agent must infer from the name that this proposes questions. "It proposes; it never asks anyone" helps disambiguate that nothing is dispatched, but the description never names a sibling (e.g. inspect_oversight_case) to separate this from the surrounding oversight tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives prerequisites (env vars) and failure semantics but no when-to-use guidance and no exclusions against the 16 siblings that also operate on oversight cases and decisions. An agent has to guess whether this or inspect_oversight_case is the right entry point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replay of a decision's evidence path over the records you supply. It replays records; it executes nothing. Read-only view of the records you supply; it writes, signs and executes nothing. Needs TRUST_GATE_API_URL, TRUST_GATE_API_KEY and TRUST_GATE_TENANT_ID to be set, and the tenant comes from that setting, never from an argument. Returns status OK, REFUSED or UNAVAILABLE (a missing setting, a surface that is off, or an error is UNAVAILABLE, never made-up data). The Trust Gate API must be a version that serves this view; it returns UNAVAILABLE until then. A mapping or readout is not a compliance finding.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations the description carries the full burden and does solid work: it declares read-only/non-executing semantics, names the three required environment settings, specifies that the tenant comes from configuration and never from an argument, and enumerates OK/REFUSED/UNAVAILABLE including that errors and missing settings never yield fabricated data. It omits latency, cost, and any notion of what a successful replay actually produces beyond status.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded in the first sentence, which is good. But the non-execution claim is restated three times ('it replays records; it executes nothing', 'it writes, signs and executes nothing', 'never made-up data'), padding a short description with defensive repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so explaining return values is not strictly required, yet the description does cover the status semantics and prerequisites well. The critical hole is the nested request object: for a tool whose only argument is an opaque object, saying nothing about its contents leaves an agent unable to construct a valid call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'request' parameter is a free-form object with additionalProperties true and 0% schema description coverage, so the schema tells the agent nothing. The description only hints that it carries 'the records you supply' and warns the tenant must not appear in it; the required shape and fields of the request object remain entirely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: replay a decision's evidence path over records supplied. It implicitly separates itself from mutating siblings by insisting it 'executes nothing' and 'writes, signs and executes nothing'. It never names an alternative such as get_decision_evidence or verify_receipt, so the agent must infer the boundary itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: this is the read-only replay path as opposed to gate_decision or mint_action_receipt, and the closing line warns the output is not a compliance finding. There is no explicit 'use this when X, use sibling Y when Z', and no guidance on when replay is warranted versus simply reading evidence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Vendor exit readiness drill. Checks local signing key, local model access (Ollama). Returns step-by-step results and a tamper-evident receipt. Informational; it signs one receipt, which creates the signing key on a host that has none yet.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does disclose a genuinely non-obvious side effect: despite being 'Informational', it signs one receipt, which creates a signing key on a host that has none yet. That is exactly the kind of mutation disclosure an agent needs before invoking. It stops short of describing auth requirements, rate limits, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with what the drill is, then what it checks, then the return shape and the caveat. Every sentence carries information and none is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the description need not explain the step-by-step results or receipt structure, and it correctly does not. It covers purpose, checks performed, and the key side effect; only invocation prerequisites (permissions, environment assumptions) are left implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and the schema is empty at 100% coverage, so there is nothing for the description to disambiguate. The baseline for a parameterless tool is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb+resource ('Vendor exit readiness drill') and enumerates exactly what it inspects: the local signing key and local model access via Ollama. It is clearly not a receipt-minting or egress-checking tool, so an agent can separate it from most siblings, though it never explicitly contrasts itself with check_egress or audit_my_agent_inventory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'Informational' implies this is a diagnostic to run when validating vendor-exit readiness, and the check list hints at the preconditions it evaluates. However, there is no explicit when-to-use, when-not-to-use, or named alternative among the six sibling tools, so usage must be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a Trust Gate receipt from the certificate alone (offline). ok=true means unchanged since signing, signed, kid consistent with the embedded key, and (require_pq default on) at least one post-quantum leg verified; unsigned receipts fail. It does not prove who signed: pass expected_kid to pin the signer's Ed25519 key; a pin counts only when that key's own signature verifies (see signer_pinned). The post-quantum keys in a receipt are not covered by the kid.
| Name | Required | Description | Default |
|---|---|---|---|
| receipt | Yes | ||
| require_pq | No | ||
| expected_kid | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral burden. It explains what ok=true means, that unsigned receipts fail, that it does not prove signer identity, how expected_kid pinning works, and that post-quantum keys are not covered by the kid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core verification contract, then adds the important signer-pinning caveat and PQ-key caveat. Every sentence adds necessary semantic information without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the cryptographic complexity, missing annotations, and 0% schema description coverage, the description covers the critical behavioral guarantees and limitations. Return values are additionally covered by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains require_pq's effective default and expected_kid's pinning semantics in detail, though the receipt parameter itself is left largely opaque as a Trust Gate receipt object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: verify a Trust Gate receipt. It also names the exact verification mode, offline from the certificate alone, which clearly distinguishes it from the minting siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for use and conditionally describes when to supply expected_kid to pin the signer. It does not explicitly compare against sibling tools or state when not to use this tool, so it falls short of the top level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.4.0compare_qualification_changeexport_acceptance_packget_decision_evidenceget_intervention_evidenceget_receipt_evidenceinspect_oversight_casepropose_requalificationpropose_role_questionreplay_decisionv0.3.0verify_receipt1 field changedInput schema / properties / expected_kidAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Expected Kid"
+}v0.2.1audit_my_agent_inventorycheck_egressgate_decisionmint_action_receiptmint_receipt_for_record_changerun_exit_drillverify_receiptScored across 16 tools
Most tools have distinct artifact-oriented names, but many of the evidence/proposal views share almost identical boilerplate descriptions, making boundaries between tools like get_decision_evidence vs replay_decision or propose_role_question vs propose_requalification less immediately clear. The first sentence of each description helps, but selection still requires careful reading.
All tools use snake_case and begin with a verb, generally following a verb_noun pattern. Variations such as mint_receipt_for_record_change and audit_my_agent_inventory are still readable and consistent with the overall convention.
Sixteen tools is slightly above the typical 3–15 range, but the server covers a broad governance/evidence surface where each tool maps to a distinct artifact or action. The count is reasonable, though a few evidence views could potentially be consolidated.
The surface covers key workflows: egress checking, gated decisions, receipt minting, receipt verification, evidence views, replay, export, and exit/inventory audits. Some discovery or lifecycle management operations such as listing cases/receipts or resolving escalations are absent, but core trust-gate workflows are represented.
Signed, append-only receipts of an AI agent's decisions and outcomes, with public proof links.
Independent effect verification and signed receipts for consequential AI agent actions.
Did it really happen? Independent signed receipts for AI agents: page, domain, email, heartbeat.
Issue signed receipts for AI agent actions; verify any receipt offline - free, no account.
