Odile Gate

Export a signed audit proof

gate_audit_proof

Read-only

Returns chained audit rows, decided-action feature snapshots and signed anchors; use it for a portable tamper-evident export instead of gate_audit's recent-call view, then check it with gate_audit_verify. No sealed paths/bodies, notes, keys or IPs in the action labels. Legacy actions lack snapshots and are excluded. store_audit=false has no chain. Follow next_from for audit rows and next_actions_after as actions_after for labels (10,000 each). Use API/SDK to verify exports above the MCP request size limit. The signature is HMAC-SHA256.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project_id": "<project_id>",
      "admin_key": "<admin_key>"
    },
    "name": "gate_audit_proof"
  }
}

Input Schema

Name	Required	Description
`to`	No
`from`	No
`admin_key`	Yes	The project admin key (ga_...). Read it from the .env; never print it.
`project_id`	Yes	The project id from gate_create_project, e.g. p1a2b3...
`actions_after`	No	Action cursor from next_actions_after

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 24, 2026

addedInput schema / properties / actions_after

Added value: +{
+  "description": "Action cursor from next_actions_after",
+  "type": "string"
+}

AddedOct 21, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only say readOnly/openWorld, but the description adds substantial context beyond them: what is deliberately omitted from labels (sealed paths/bodies, notes, keys, IPs), the HMAC-SHA256 signing scheme, the two independent pagination cursors with 10,000 batch limits, and the size ceiling that forces API/SDK verification. No annotation contradiction — a read-only export matches readOnlyHint=true.

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

Conciseness4/5

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

Front-loaded with purpose and routing, and no sentence is filler. The semicolon-chained caveats mid-paragraph make it denser than ideal to parse, but every clause carries operational information.

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?

With no output schema, the description carries the return-value burden itself and does so: rows, snapshots, anchors, two cursors, and signature algorithm. Combined with exclusion and size-limit caveats, an agent has everything needed to call and consume this correctly.

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

Parameters4/5

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

With 60% schema coverage, the description compensates by explaining that next_from drives audit rows while next_actions_after must be passed as actions_after for labels — a non-obvious mapping the schema alone does not state. The from/to integers are left unexplained, which is the only gap.

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?

Opens with a specific verb and resource list — 'Returns chained audit rows, decided-action feature snapshots and signed anchors' — and immediately scopes it as 'a portable tamper-evident export instead of gate_audit's recent-call view', which cleanly separates it from the closest sibling. An agent can pick this over gate_audit without opening either schema.

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?

Names both the alternative (gate_audit's recent-call view) and the follow-up tool (gate_audit_verify), plus explicit exclusion conditions: legacy actions lack snapshots, store_audit=false has no chain, and exports above the request size limit require API/SDK. That is when-to-use, when-not-to-use, and alternatives all present.

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

All Odile Gate tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?