TWZRD Agent Intelligence

twzrd_demo_gate

Read-onlyIdempotent

No-spend transcript of the TWZRD buyer-side x402 trust gate, a recorded example,
not a live run - discoverable at runtime with no install and no human.

Returns a deterministic transcript showing the gate's behaviour on a fixture
counterparty: the block path ABORTS and a wallet/signer is never contacted, the
allow path would proceed, and ok=true. Spends no USDC, contacts no wallet.

This call surfaces an EXTERNAL_RUN *candidate* in TWZRD's honest attribution
ledger (it carries a non-internal integration id + your run_id, tagged with your
real inbound IP). A candidate is NOT an EXTERNAL_RUN: TWZRD's operator still has
to match your run_id to a non-internal caller and confirm it.
See the returned not_external_run_proof.

Input Schema

Name	Required	Description	Default
`run_id`	No	Optional caller-supplied run id to correlate with your transcript. Omit to have one generated for this call.
`integration`	No	Stable label for your integration (e.g. your agent/app name). Echo it plus the returned run_id in your own transcript so a run can later be confirmed. Defaults to a generic MCP-discovery label.	mcp-agent-discovery

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedJul 22, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Far exceeds the annotations (readOnlyHint/idempotentHint): it discloses that the block path ABORTS and no wallet/signer is contacted, the allow path proceeds, ok=true, no USDC is spent, and that the call writes an EXTERNAL_RUN *candidate* into an attribution ledger tagged with the caller's IP. It even clarifies that a candidate is not a confirmed EXTERNAL_RUN and points to not_external_run_proof — exactly the side-effect transparency a mutation-adjacent call needs.

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 the core purpose and the critical 'not a live run / spends no USDC' caveats, and the ledger caveat is clearly segmented. Slightly verbose in the attribution-ledger paragraph, but every sentence carries real 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 an output schema present, the description needn't explain return values, and it covers everything else an agent needs: what runs, what is and isn't touched, the deterministic transcript contents, and the ledger side effect plus its caveat. Nothing material is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already fully documents run_id and integration. The description references 'your run_id' and the integration id only in the context of the ledger entry, adding narrative context but no new syntax, format, or constraint detail beyond the schema. Baseline 3 is appropriate.

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?

States a precise verb+resource: a no-spend, recorded transcript of the TWZRD buyer-side x402 trust gate. It explicitly marks itself as 'a recorded example, not a live run', which cleanly separates it from live siblings like evaluate_x402_resource or low_level_preflight without needing to name them.

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

Usage Guidelines3/5

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

Implies usage ('discoverable at runtime with no install and no human', a no-spend demo), but never states when an agent should pick this over evaluate_x402_resource or a real gate run, nor any exclusions. Context is inferable but not spelled out.

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

All TWZRD Agent Intelligence 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.