Skip to main content
Glama
dinggi5

Kura

by dinggi5
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

lookup_agent

Check an agent's on-chain ERC-8004 record to verify its registered wallet and domain. Compare pay_to and resource URLs against the registry to detect mismatches, signaling potential safety issues.

Instructions

Reads an agent's ERC-8004 record from the registry on the active Base network (read-only, on-chain only — the wallet never fetches the agent's website). Give it agent_id, the agent's number in the Identity Registry. Returns: registered, owner, wallet (the registered agentWallet), token_uri and the uri_domain read from it, declared_name (what the record calls itself), and feedback_clients (how many addresses left feedback). Pass pay_to and/or resource to also get a comparison: whether the address equals the registered wallet and whether the resource's domain equals the domain listed on-chain. IMPORTANT: registration is permissionless — anyone can register any name, domain, or wallet, and anyone can leave feedback. Being registered is NOT proof of safety. Only a mismatch is a strong signal, and only when the agent number came from a source you trust (the service's own docs), not from the payment response itself.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pay_toNoOptional: an address to compare against the agent's registered wallet.
agent_idYesThe agent's ERC-8004 number (agentId — the Identity Registry NFT token id).
resourceNoOptional: a resource URL whose domain is compared with the domain listed on-chain.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.4.1
    • removedInput schema / properties / pay_to / default
      Removed value: -null
    • removedInput schema / properties / pay_to / nullable
      Removed value: -true
    • removedInput schema / properties / resource / default
      Removed value: -null
    • removedInput schema / properties / resource / nullable
      Removed value: -true
  2. Addedv0.3.0

TDQS

A4.7/5.0
Behavior5/5

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 read-only behavior, that the wallet never fetches the agent's website, the exact return fields, the effect of optional params, and the critical caveat that registration is permissionless and not proof of safety.

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?

Long but well-structured: purpose first, return fields, optional usage, then critical warning. Every sentence serves a purpose, including the trust caveat which is essential for correct interpretation. No filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description provides a full return-field list and explains the trust implications of results. It covers network, parameters, and interpretation, making it complete for correct invocation and result understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds functional meaning for optional parameters by explaining that pay_to and resource trigger comparisons and what those comparisons determine, going beyond the schema's simple type descriptions.

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?

States a specific verb ('Reads') and resource ('agent's ERC-8004 record from the registry on the active Base network'), and clarifies it is read-only and on-chain only. This distinguishes it from sibling tools like x402_fetch, which likely involve off-chain fetching.

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?

Provides clear context for when to use the tool (verifying an agent's on-chain record) and what optional parameters trigger comparisons. It does not explicitly name alternatives or exclusions, but the read-only, on-chain-only scope and safety caveats give sufficient guidance.

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

Deploy Server

Other Tools