TWZRD Agent Intelligence

get_merchant_card

Read-onlyIdempotent

Free merchant card: observed inbound payment-graph quality around a Solana
or Base receive wallet.

Dual input (PR-3): pass ``wallet`` and/or ``resource_id``. Resource resolves via
the first-party registry (TWZRD seed) to a pay_to, then the same graph card.
Does NOT claim service quality (resource_listing_only / catalog_listing_only).

HTTP twin: GET /v1/intel/merchant_card/{wallet_or_resource_id}.
Compact (default) includes observed_at, stale, corpus_complete_day,
corpus_age_days. Catalog services stay behind full=true.

wash_flagged is tri-state: true (flagged) | false (evaluated clean) |
null (never evaluated - NOT clean). wash_flagged=true never soft-allows
(next_action.decision=refuse; no warn/allow/quick). Unlabeled leftover
0.05 / leftover=0 is not a unit price; cheapest_listed_price_usdc omits
leftover and upto_cap amounts. Route on next_action.decision
(refuse | insufficient_evidence | no_negative_signal); the card is
down-only and never returns allow. `reason` carries the specific
finding (e.g. a soft wash risk collapsed into "refuse", or a corpus
outage collapsed into "insufficient_evidence") when the 3-value
decision alone is not enough context.

Input Schema

Name	Required	Description
`full`	No	If true, include catalog services. Default is the compact decision surface.
`wallet`	No	Receive wallet (x402 pay_to / merchant pubkey). Observed payment-graph card only — not a business, demand, or identity attestation.
`resource_id`	No	Optional registry resource_id (HTTP path template or mcp:tool). Resolved to merchant_wallet via PR-3 seed; claim resource_listing_only.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 8, 2026

addedInput schema / properties / full

Added value: +{
+  "default": false,
+  "description": "If true, include catalog services. Default is the compact decision surface.",
+  "title": "Full",
+  "type": "boolean"
+}

Changed1 schema field changedJul 22, 2026

changedInput schema / properties / wallet / description

Previous value: -"Receive wallet (x402 pay_to / merchant pubkey). Graph demand-quality card only — not a business attestation."New value: +"Receive wallet (x402 pay_to / merchant pubkey). Observed payment-graph card only — not a business, demand, or identity attestation."

First observedJul 11, 2026

TDQS

A4/5.0

Behavior5/5

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

Annotations only cover readOnly/idempotent, so the description carries the load and delivers real behavioral contract: tri-state wash_flagged semantics (null is NOT clean), that wash_flagged=true can never soft-allow, that the card is down-only and never returns 'allow', and that `reason` disambiguates a collapsed 3-value decision. This is exactly the kind of non-obvious behavior an agent needs before trusting the output.

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?

Purpose is front-loaded in the first line and the rest is dense, high-value contract detail rather than filler. The density and unexplained internal tokens ('PR-3', 'corpus_complete_day', 'upto_cap') cost it some readability, but no sentence is redundant.

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?

With an output schema present, return values needn't be explained, yet the description still pre-empts the key output semantics (decision routing, stale/corpus fields). It does omit what happens when both optional inputs are omitted (0 required parameters) and gives no rate-limit/free-tier caveat beyond the word 'Free'.

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?

Schema coverage is 100%, so the baseline is 3, and the description adds meaning: it establishes that wallet and resource_id are interchangeable paths to the same card ('resolves ... to a pay_to, then the same graph card'), and clarifies that catalog services are gated behind full=true while the compact surface is the default decision view.

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?

'Free merchant card: observed inbound payment-graph quality around a Solana or Base receive wallet' states the resource and the scope precisely. It also carves out what it is not ('Does NOT claim service quality'), which separates it from catalog/listing tools. However, the heavy jargon ('PR-3', 'TWZRD seed', 'payment-graph quality') leaves the core purpose legible only to an agent already steeped in this domain.

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?

The description does specify input combinations ('pass wallet and/or resource_id') and how to consume the result ('Route on next_action.decision'), which implies usage. But it never states when to pick this tool over close siblings such as score_wallet_for_intel, compare_wallets, or check_listing, and the 'HTTP twin' line gives no actionable routing advice.

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.