The honest x402 trust index: merchants ranked by real unique payers (facilitator-verified), not raw volume. Free, keyless.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | optional service-type filter | |
| limit | No | rows to return (default 25, max 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full disclosure burden. It does state 'Free, keyless' (addressing cost/auth), but it does not explicitly mention that the operation is read-only, nor does it describe the response format or any additional behaviors like pagination or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the core purpose and the key differentiator (facilitator-verified, not raw volume), plus the 'Free, keyless' benefit. There is no wasted wording or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two optional parameters and no output schema. The description conveys the primary concept of a leaderboard ranking merchants. It would be slightly improve with an explicit statement that it returns a ranked list of merchants, but overall it is largely complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents both parameters ('type' as optional service-type filter, 'limit' with default and max). The description adds no complementary parameter information beyond what the schema provides. With 100% schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's purpose: it ranks merchants by real unique payers (facilitator-verified), not raw volume. This distinguishes it from related x402 tools like x402_profile (likely individual merchant details) and x402_verdict (likely a verdict on a merchant).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context (e.g., 'honest x402 trust index') indicating the tool is for comparing merchant trustworthiness, but it does not explicitly state when to use this versus alternatives like x402_profile or x402_verdict. No exclusions or alternative guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Many tools share the same core purpose (safety checks) differentiated mainly by chain or asset type, and descriptions are detailed enough to distinguish them most of the time. However, pairs like rug_check/rugcheck and deployer_check/deployer_reputation have overlapping purposes that could lead to misselection.
Most tool names follow a lowercase snake_case pattern with clear descriptors, but there are notable exceptions like 'rugcheck', 'defillama', and 'verify'. Additionally, the 'rug_check' vs 'rugcheck' pair is an obvious naming inconsistency.
44 tools is excessive for any server. Even for a broad security/due-diligence purpose, many tools (especially the robinhood_* series) are highly specialized and could be consolidated into fewer actions.
The tool surface is impressively comprehensive, covering token/NFT safety, transaction simulation, whale/address tracking, stock analysis, prediction markets, and project validation. Minor gaps exist (e.g., no ENS resolution or stock price history), but they are not critical for the server's core purpose.
