Skip to main content
Glama

x402-tools

by dev.workers.kikoribera03.flat-rate-llm
OverviewDiscussionsAdmin

Plain-language verdict on an ERC20, with the evidence under it

evm_verdict

Use when an agent needs one answer it can act on: a verdict on any ERC20 on five chains - a machine-readable label for who can act on your balance (no-owner-powers, owner-can-intervene, owner-controls-balances, not-a-token), a headline, a plain reading and a paste-ready card, with the evidence selector by selector. Label and card come from the bytecode and live state, never from a model. A repeated requestKey is never charged twice. Research, not investment advice. $0.02 per call, paid over x402 (USDC).

Input Schema

NameRequiredDescriptionDefault
chainNobase | ethereum | polygon | arbitrum | optimism.
tokenYesERC20 contract address to judge.
requestKeyNoOptional idempotency key you choose, 8 to 128 characters of letters, digits, dot, dash, colon or underscore. Send the same key with the same input and you get your first answer back and are NOT charged again: the repeat comes back with HTTP 409, the stored answer in the body and "charged": false, because any status at or above 400 is what cancels the payment on this service. Keys are bound to the paying address and kept 24 hours. Reusing a key with a different input is rejected, also without charge.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / requestKey
      Added value: +{
+  "description": "Optional idempotency key you choose, 8 to 128 characters of letters, digits, dot, dash, colon or underscore. Send the same key with the same input and you get your first answer back and are NOT charged again: the repeat comes back with HTTP 409, the stored answer in the body and \"charged\": false, because any status at or above 400 is what cancels the payment on this service. Keys are bound to the paying address and kept 24 hours. Reusing a key with a different input is rejected, also without charge.",
+  "type": "string"
+}
  2. Added

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses provenance ('label and card come from the bytecode and live state, never from a model'), cost ($0.02 per call over x402/USDC), and idempotency ('a repeated requestKey is never charged twice') which is the key non-obvious billing behavior. It stops short of stating failure modes (non-ERC20 address, unsupported chain) or latency, so not a 5.

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?

Front-loaded with the trigger ('Use when...') followed by output shape, provenance, billing and disclaimer in that priority order — every clause carries information. It is one long colon-and-dash chain, though, and the four-label enumeration occupies a large share of the sentence.

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?

There is no output schema, so the description must describe the return: it does (label, headline, plain reading, paste-ready card, per-selector evidence). Cost and idempotency are covered. What an agent still cannot infer is the default when 'chain' is omitted and what happens on an unsupported chain or a non-contract address.

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% and the requestKey description already spells out the 409/stored-answer/charged:false mechanics and the 24-hour paying-address binding. The description only echoes the idempotency promise and adds the 'five chains' count, so the schema is doing the heavy lifting. Baseline 3 is right.

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?

States a specific verb+resource ('a verdict on any ERC20 on five chains') and enumerates the exact output vocabulary (no-owner-powers, owner-can-intervene, owner-controls-balances, not-a-token), which is unusually precise. It never names or contrasts the obvious siblings evm_token_safety and evm_token_info, so an agent cannot tell from this text alone which of the three to pick.

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?

'Use when an agent needs one answer it can act on' gives a situational trigger, and the phrase 'Research, not investment advice' bounds expectations. But there is no explicit when-not, no named alternative for a deeper scan (evm_token_safety) or raw metadata (evm_token_info), and no stated prerequisite such as needing the token address already resolved.

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

All x402-tools toolsInspect
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.

Resources