TWZRD Agent Intelligence

twzrd_demo_gate

Read-onlyIdempotent

Runnable, no-spend proof of the TWZRD buyer-side x402 trust gate - 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

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnlyHint and idempotentHint, but the description adds rich behavioral detail: no wallet/signer contact, no USDC spend, ledger candidate surface with real inbound IP, and the requirement for non-VPS source_ip and run_id matching to promote a candidate to an EXTERNAL_RUN. This goes far beyond the structured annotations without contradicting them.

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?

The description is front-loaded with the core purpose and safety characteristics, then moves to caveats and proof requirements. It is somewhat dense and technical, but every sentence contributes needed context and there is no filler.

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 still covers behavior, side-effect-like attribution implications, safety, and proof verification steps. It fully explains the candidate-vs-run distinction and references the returned not_external_run_proof, making it complete for a tool of this complexity.

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?

The input schema already provides 100% parameter coverage for run_id and integration. The description reinforces the semantic role of run_id in transcript correlation and mentions the integration id in the attribution ledger context, adding value beyond the schema descriptions.

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

Purpose5/5

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

The description opens with a specific verb+resource statement: 'Runnable, no-spend proof of the TWZRD buyer-side x402 trust gate.' It then concretely states what happens (block path ABORTS, allow path would proceed, ok=true), clearly distinguishing it from sibling tools that perform other x402/intel operations.

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

Usage Guidelines4/5

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

The description clearly conveys when to use this tool: as a no-install, no-human, no-spend proof/demo of the gate. It adds important context about the EXTERNAL_RUN candidate versus a real EXTERNAL_RUN, but it does not explicitly name alternative tools or provide when-not-to-use instructions.

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.