TWZRD Agent Intelligence

get_counterparties

Read-onlyIdempotent

Free discovery (capped teaser): the top-N merchants a wallet actually pays, by
event count, with per-edge tx_count / total_usdc / first+last timestamps.

See WHO a counterparty transacts with before trusting it. The list is capped
(default 10, max 25) and `capped`/`total_distinct_merchants` disclose how much
is withheld; the FULL deduped payment graph and numeric edge weights are part
of the paid intel surface (GET /v1/intel/trust/{wallet}). Fail-open.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No	Max counterparties to return (default 10, hard cap 25 - this is a capped teaser).
`wallet`	Yes	Payer Solana wallet public key (32-44 base58 chars) whose counterparties (merchants paid) to list.

Output Schema

TableJSON Schema

Name	Required	Description
`error`	No	Present only on the degraded path.
`capped`	No	True if the full merchant set exceeds the returned list.
`wallet`	No	The payer wallet looked up.
`returned`	No	Number of counterparties returned (<= limit).
`teaser_note`	No	States that the full deduped graph + edge weights are paid.
`total_events`	No	Total observed payment events for this payer.
`counterparties`	No	Capped top-N merchants paid, each with tx_count, total_usdc, first_at, last_at.
`data_available`	No	False when the corpus/DB was unavailable.
`total_distinct_merchants`	No	Total distinct merchants this payer has paid (full, uncapped).

Schema Changelog

Changes observed during successful MCP inspections.

First observedJul 11, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Beyond annotations (readOnlyHint, idempotentHint), the description adds behavioral traits: it's a capped teaser, returns top-N by event count, includes 'capped' and 'total_distinct_merchants' fields, and mentions 'fail-open'. This adds context about data completeness and potential partial success.

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 well-structured with a clear lead sentence and subsequent details. It is somewhat verbose but contains no wasted sentences. It front-loads the main purpose.

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?

Given the tool has 2 parameters and an output schema, the description is complete. It explains the return format (per-edge details, capped/total fields), notes the paid alternative, and mentions failure behavior ('fail-open'). No critical information is missing.

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 baseline is 3. The description adds meaning by clarifying the 'wallet' parameter is a payer and the 'limit' is a cap (teaser). It also provides context about the default and maximum. This adds value beyond the schema descriptions.

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 clearly states the tool lists top-N merchants a wallet pays, with per-edge details. It uses specific verbs ('discover', 'list') and resources ('merchants', 'wallet'). However, it does not explicitly differentiate from sibling tools like get_merchant_card or get_provider_reputation, though the context suggests it's a counterparty discovery tool.

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 provides usage guidance: it's a free capped teaser, useful before trusting a counterparty, and notes that the full graph is paid. It implicitly suggests when to use (free discovery) and when not (if full graph needed). It does not explicitly mention alternative tools, but the context is clear.

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.