FREE pre-send check of an EVM address: EIP-55 checksum verification (catches typos, dropped characters, clipboard malware) + a note that a passing checksum is a spell-check, not payee verification. Run this before paying for check_address.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | EVM address, 0x + 40 hex characters (any casing) |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: it discloses that the operation is free and read-only, specifies exactly what is verified (EIP-55 checksum), lists failure modes it catches (typos, dropped characters, clipboard malware), and openly warns about its limitation. It does not mention return values, but that is a minor gap for a check-like 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?
Two sentences with no filler. The first sentence front-loads the purpose, cost, and key value; the second adds the critical limitation and usage ordering. Every clause carries useful information.
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 single-parameter tool with no output schema, the description covers what it does, what it catches, its limitation, and when to use it in the workflow. The only omission is the exact return format, which is not essential for such a simple validation tool.
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 schema already fully documents the address format (0x + 40 hex characters, any casing). The description adds meaning by explaining the EIP-55 checksum verification behavior, which tells the agent what will be done with the address beyond its format. It also clarifies that casing is relevant to the checksum check.
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 states a specific verb and resource: a free pre-send EIP-55 checksum check of an EVM address. It explicitly positions itself relative to check_address ('Run this before paying for check_address'), distinguishing it from that sibling, and its 'pre-send check' framing separates it from deep_scan's implied deeper analysis.
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?
It explicitly instructs when to use the tool: run before paying for check_address. It also provides a when-not-to-rely-on-it statement by noting that a passing checksum is not payee verification. However, it gives no guidance about deep_scan, leaving some ambiguity about when to choose this over that sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.