Reads a single metadata value by key from an agent's ERC-8004 identity and returns the raw buffer as a hex string.
Read a single metadata value by key from an agent's ERC-8004 identity. Returns the raw buffer value as a hex string.
Tip: call earning_opportunities to see how to put your assets to work.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Metadata key to read | |
| agentId | Yes | Agent ID to query |
Changes observed during successful MCP inspections.
v1.77.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden; it does disclose the return representation (raw buffer returned as a hex string), which is genuinely useful. It does not say what happens for a missing key (error vs empty) or whether this is a pure read with any auth/rate constraints.
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 core sentence is front-loaded and efficient, but the appended 'Tip' about earning_opportunities is off-topic noise that does not earn its place in a metadata-read tool definition.
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?
No output schema exists, and the description does cover the return format (hex string), which is the most important thing. It still leaves the failure mode for an unset key and the relationship to sibling identity tools unexplained.
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?
Schema description coverage is 100%, so both agentId and key are already documented; baseline 3 applies. The description adds only that the value is looked up 'by key' without clarifying key namespacing or case sensitivity.
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?
States a specific verb+resource (read a single metadata value by key) scoped to an agent's ERC-8004 identity. The key-granularity distinguishes it implicitly from identity_get (whole record) and identity_set_metadata (write counterpart), though it never names those siblings.
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?
There is no guidance on when to use this versus identity_get or the other identity_* siblings, and no stated prerequisites. The only cross-reference is an unrelated promotional tip pointing at earning_opportunities, which does not help tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.