Look up an ERC-8004 on-chain agent and get their AgentStamp trust score. Free. Returns on-chain identity + trust verdict.
| Name | Required | Description | Default |
|---|---|---|---|
| erc8004_agent_id | Yes | ERC-8004 agent ID (numeric token ID from the Identity Registry) |
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 available, the description must carry the full burden of behavioral disclosure. It does add useful context by noting the tool is free and that it returns on-chain identity and a trust verdict, implying a read-only operation. However, it omits details about side effects, error handling, authentication requirements, or rate limits, leaving notable gaps.
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 is exceptionally concise, consisting of two short sentences that front-load the core purpose ('Look up an ERC-8004 on-chain agent') and efficiently add the key facts 'Free' and 'Returns on-chain identity + trust verdict.' Every sentence earns its place with no redundancy or fluff.
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?
This is a simple lookup tool with one parameter and no output schema, so the description's high-level summary of returns may be adequate. However, it does not specify the exact structure of the 'on-chain identity' or 'trust verdict,' nor does it address edge cases like invalid agent IDs or differentiates from sibling trust-check tools. This is a clear but incomplete picture for an agent selecting the 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 fully describes the single parameter (erc8004_agent_id as a numeric token ID from the Identity Registry) with 100% coverage. The description adds no additional information about the parameter, so the baseline score of 3 is appropriate because the schema already handles the semantics.
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 the tool looks up an ERC-8004 on-chain agent and retrieves their AgentStamp trust score, with output including on-chain identity and a trust verdict. It specifies a clear verb ('look up') and resource, but it does not explicitly distinguish itself from the closely named sibling bridge_erc8004_trust_check, so it falls short of a 5.
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 implies the tool is used for looking up ERC-8004 agent trust scores, but it offers no explicit guidance on when to choose this tool over alternatives like bridge_erc8004_trust_check or verify_stamp. There are no stated exclusions or alternative recommendations, so it only provides implied usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Several tools overlap in purpose, such as bridge_erc8004_lookup and bridge_erc8004_trust_check, trust_check, get_agent, and get_agent_reputation all returning trust or reputation data. Descriptions help clarify the distinctions, but the similarities could lead an agent to select the wrong tool.
Naming uses a mix of conventions: verb-noun (get_agent, search_agents), noun-first (compliance_report, dns_discovery), and prefix-based groupings (trust_*, bridge_*). While snake_case is consistent, the inconsistent verb/noun ordering and synonyms (lookup, check, verify) make it less predictable.
With 19 tools, the set is slightly heavy but still justified by the platform's broad feature set covering trust checks, reputation, teams, wishes, compliance, and credentials. Some tools could be merged (e.g., bridge_erc8004_lookup and bridge_erc8004_trust_check), but the count is not excessive for the apparent scope.
The tool surface focuses heavily on reading and checking trust data, but lacks obvious lifecycle operations such as updating or deleting agents, creating wishes, or managing endorsements. The presence of create_team without corresponding team management (update/delete) leaves a notable gap.
