Fabler x402 Tools

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

No annotations are provided, so the description carries the full burden. It discloses that the tool is free and requires no wallet/payment, and notes that it also exposes a free bounded secret-scan preview. It does not mention rate limits or data freshness, but for a simple read-only list tool, the transparency is adequate.

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 front-loads the main purpose but becomes verbose with a long note about other tools and HTTP endpoints. While the extra context is valuable, it could be restructured or placed in a separate section, making it less concise than ideal.

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?

Given no output schema, the description sufficiently hints at the return value: a list of products with per-call USDC price. It also covers behavioral aspects like being free and no wallet. The additional context about the MCP setup and paid tool alternatives adds completeness, though it exceeds the minimum needed.

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 tool has no parameters, so the schema coverage is 100% by default. The description does not need to add parameter info, and the baseline score of 4 is appropriate. The extra info about the secret-scan preview does not pertain to parameters.

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 explicitly states the verb 'list' and the resource 'Fabler Labs' x402 products with their current per-call USDC price on Base'. It differentiates from the sibling tool 'fabler_scan_secrets_preview' by focusing solely on product listing, despite also mentioning a free secret-scan preview as an additional feature.

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 clearly indicates when to use this tool: 'Free, no wallet or payment required.' It also provides alternatives for paid tools: 'call them directly over HTTP with x402' or use the wallet-capable stdio MCP server, thus giving explicit when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

No annotations are provided, so the description carries the full burden. It discloses that scanning is limited to 2,048 characters, returns only masked matches, is free, and requires no account. It does not mention if data is stored or if it's read-only, but it adequately describes the behavior for a simple scanning tool.

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?

Three sentences, each adding essential information: purpose and limit, cost, alternative for larger inputs. No fluff, front-loaded, earns each sentence.

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?

For a simple tool with one parameter and no output schema, the description sufficiently explains the tool's purpose, usage, limits, and alternative. It does not detail return format but says 'return only masked matches', which is adequate.

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?

Schema coverage is 100% for the single parameter 'text', including maxLength and description. The description adds context that scanning looks for 'common credential patterns', which is not in the schema, adding value beyond what the schema provides.

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?

Description clearly states the tool scans text for credential patterns and returns masked matches. The verb 'scan' and resource 'text' are specific. It distinguishes itself from the sibling tool 'fabler_list_products' which is about listing products, not scanning.

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?

Explicitly states the tool is free, requires no wallet or account, and provides a clear alternative for larger inputs via a wallet-capable client with pricing. This guides the agent on when to use this tool vs. alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.