Skip to main content
Glama

Genexxis paid agent tools (x402)

chainread_resolve

ENS (Ethereum) and Basename (*.base.eth on Base) resolution: name to address with avatar, url, twitter, github, description records, or address to forward-verified primary names. Price: $0.005 USDC per call, paid with x402 on Base.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "chainread_resolve"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoENS name (vitalik.eth) or Basename (alice.base.eth)
addressNo0x address for reverse lookup (ENS + Basename)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations supplied, the description still discloses important behavior: the supported chains, the $0.005 USDC per-call price, and x402 payment on Base. It does not cover rate limits or error behavior, but it gives enough cost and payment context to avoid surprise charges.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The definition is a single front-loaded sentence with no wasted setup, and the pricing/payment detail is compactly appended.

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?

For a simple two-parameter resolver, it covers the operation, networks, returned record types, reverse-resolution behavior, and payment cost. The main remaining gap is that it does not explicitly state that callers should provide either name or address, though the 'or' wording implies it.

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%, so the input schema already documents name and address. The description adds some semantic detail such as record types and forward-verified primary names, but it does not clarify mutual exclusivity or requiredness beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the specific operation (resolution), both resources (ENS on Ethereum and Basename on Base), and both directions (name to address with records, address to forward-verified primary name). It is specific enough to separate this resolver from generic contract-read siblings such as chainread_read_contract.

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?

It clearly states the two supported use cases: forward resolution with profile records and reverse lookup for verified primary names. It does not name an alternative sibling or state exclusions, but the context for choosing this tool is explicit.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources