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: proof still requires a
non-VPS source_ip and matching your run_id to your own transcript via
packages/twzrd-agent-intel/scripts/count_attributed_runs.py --confirm.
See the returned not_external_run_proof.

Input Schema

TableJSON 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

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedJul 22, 2026

TDQS

A3.8/5.0

Behavior5/5

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

Annotations only declare readOnlyHint and idempotentHint, yet the description adds substantial behavioral context beyond them: the block path ABORTS without contacting a wallet/signer, no USDC is spent, and the call records an EXTERNAL_RUN candidate with the caller's run_id and real inbound IP in an attribution ledger. It also discloses a non-obvious side effect (ledger surfacing) and that proof is not implied.

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 purpose is front-loaded in the first sentence, but the description runs long and repeats the no-spend/no-wallet message ('Spends no USDC, contacts no wallet' restates 'a wallet/signer is never contacted'). The attribution-ledger paragraph earns its place, but there is avoidable redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value detail is not required and the description correctly focuses on behavior and the caveat that a candidate is NOT transitive proof. It covers side effects and constraints well; only explicit when-to-use routing to sibling tools 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 both parameters (run_id, integration) are already fully documented in the schema, including defaults and nullability. The description mentions run_id correlation but adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource (the TWZRD buyer-side x402 trust gate) and explicitly frames this as a recorded no-spend demo transcript rather than a live run, which separates it from live siblings like evaluate_x402_resource. It is clear, but the actual action (returning a deterministic fixture transcript) is embedded in prose rather than stated as a crisp verb+resource.

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?

It conveys the usage context ('discoverable at runtime with no install and no human') and the not-a-live-run framing, but never states when to choose this tool over live siblings such as evaluate_x402_resource or low_level_preflight. The agent must infer the demo/smoke-test use case.

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.