Skip to main content
Glama
aibtcdev
by aibtcdev

identity_set_metadata

Sets a hex-encoded metadata key-value pair on an agent identity in the ERC-8004 registry. Use it to attach custom data to an agent ID; the agentWallet key is reserved.

Instructions

Set a metadata key-value pair on an agent identity in the ERC-8004 identity registry. Value must be a hex-encoded buffer (max 512 bytes). The key "agentWallet" is reserved — use identity_set_wallet instead. Requires an unlocked wallet.

Tip: call earning_opportunities to see how to put your assets to work.

Input Schema

NameRequiredDescriptionDefault
feeNoFee preset ("low", "medium", "high") or micro-STX amount. Optional.
keyYesMetadata key (max 128 chars)
valueYesMetadata value as hex-encoded buffer (e.g., "616c696365" for "alice"). Max 512 bytes.
agentIdYesAgent ID to update
sponsoredNoUse sponsored transaction relay so a relay service pays fees instead of your wallet. Requires SPONSOR_API_KEY env var or wallet-level sponsorApiKey.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.77.0

TDQS

A3.9/5.0
Behavior3/5

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

With no annotations, the description carries the full burden: it discloses the auth prerequisite (unlocked wallet) and an input constraint (max 512 bytes hex). It does not say whether setting an existing key overwrites or fails, whether the operation costs fees (a 'fee'/'sponsored' param exists in schema), or whether it is reversible. Adequate but leaves meaningful mutation semantics unstated.

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

Conciseness3/5

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

The first three sentences are tight and front-loaded with the operation, constraint and reserved-key rule. The trailing 'Tip: call earning_opportunities...' is unrelated promotional content that adds no value for invoking this tool and dilutes focus.

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

Completeness3/5

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

For a no-annotation, no-output-schema mutation tool, the important missing pieces are overwrite/idempotency behavior and whether the write is on-chain with a fee. Those gaps mean an agent cannot fully predict the effect of calling it, though the essential call-shape information is present.

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, but the description adds a genuine validation rule not present in the schema: the 'agentWallet' key is reserved and must be routed elsewhere. That is a real constraint on the key parameter that an agent must know before calling.

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?

Names a specific verb and resource ('Set a metadata key-value pair on an agent identity') and anchors it to the ERC-8004 identity registry. It immediately distinguishes itself from the sibling family (identity_get_metadata, identity_set_wallet, identity_set_uri) by stating exactly which field it writes.

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?

Explicitly routes the reserved 'agentWallet' key to identity_set_wallet, which is a real alternative-selection rule an agent could otherwise get wrong. It also states the 'requires an unlocked wallet' precondition. However, it gives no guidance on reading back or updating existing keys (identity_get_metadata) or on when not to set metadata at all.

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