TWZRD Agent Intelligence

get_x402_directory

Read-onlyIdempotent

Wash overlay on ingested PayAI/CDP/Agentic listings (PayAI not_indexed).

Prefer HTTP GET /v1/intel/resources for the resource join SOT (callable URL +
discovery claim listed|live_402 + settlement reputation on pay_to). That
surface is HTTP-only. Use this tool when you need
the ingested listing overlay indexed by payTo. Not GET /v1/intel/bazaar/offers
(TWZRD Bazaar catalog) and not 402 extensions.bazaar.

Solana wash overlay is the only wash graph. Base listings additionally
carry high-confidence EIP-3009 corpus membership from x402_base_daily;
they remain wash_unknown. Polygon listings carry wash_unknown.

Query params — flagged_only, limit, source — mirror GET /v1/intel/x402-directory.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Max directory rows to return (1-500).
`source`	No	Source filter: payai_bazaar, cdp_bazaar, agentic_market, or None for all.
`flagged_only`	No	Return only wash-flagged listings.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedJul 11, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description is consistent with those. It adds meaningful behavioral context beyond the annotations: the PayAI surface is not_indexed, 'Solana wash overlay is the only wash graph,' Base listings only carry EIP-3009 corpus membership yet 'remain wash_unknown,' and Polygon listings 'carry wash_unknown.' This flags data-coverage limitations an agent must know before trusting wash-flag results.

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 dense but front-loaded: purpose first, then alternative routing, then data caveats, then params. Every sentence earns its place. The only knock is heavy domain jargon (wash overlay, SOT, not_indexed, EIP-3009 corpus, wash_unknown), which trades readability for compactness.

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?

Given output schema (return shape covered), annotations (safety profile covered), and 100% param coverage, the description fills the remaining gaps well: when to use it, what it is not, and chain-specific wash-coverage caveats. The main residual gap is that 'mirror GET /v1/intel/x402-directory' assumes external knowledge of an HTTP surface the agent may not have, though the output schema mitigates this.

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 coverage is 100%, so the schema already documents all three parameters (limit range 1-500, source filter values, flagged_only semantics). The description only adds a cross-reference that the params 'mirror GET /v1/intel/x402-directory,' which is marginal. Per the rubric, baseline 3 is correct since the schema carries the load.

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 states a specific resource and scope: a wash overlay on ingested PayAI/CDP/Agentic listings, retrieved 'when you need the ingested listing overlay indexed by payTo.' It explicitly distinguishes itself from GET /v1/intel/resources (resource join SOT), GET /v1/intel/bazaar/offers (TWZRD Bazaar catalog), and 402 extensions.bazaar, so an agent can route correctly without opening schemas.

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?

Usage guidance is explicit and contrastive: 'Prefer HTTP GET /v1/intel/resources for the resource join SOT' (with the reason: callable URL + discovery claim + settlement reputation), then 'Use this tool when you need the ingested listing overlay indexed by payTo,' and 'Not GET /v1/intel/bazaar/offers... and not 402 extensions.bazaar.' When-to-use, when-not-to-use, and the preferred alternative are all named.

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.