Import an ERC-8004 Identity Registry record (chain_id + ERC-721 token_id + agentURI + owner). Idempotent: re-import updates in place. Returns the canonical record with its deterministic bridge DID (did:viridis:erc8004::).
| Name | Required | Description | Default |
|---|---|---|---|
| owner | Yes | ||
| chain_id | Yes | ||
| metadata | No | ||
| token_id | Yes | ||
| agent_uri | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states idempotency ('re-import updates in place') and the return value (canonical record with deterministic bridge DID), which are important behavioral traits. It does not cover permissions or failure modes, but the disclosed traits are significant.
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 two concise sentences, front-loading the core action and then adding idempotency and return information. Every word contributes value with no redundancy.
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?
For a 5-parameter import tool with no annotations, the description covers the essential aspects: what it imports, how it behaves on re-import, and what it returns. The omission of the optional 'metadata' parameter and any permission context is a minor gap, but the core functionality is sufficiently described given the output schema exists.
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 description adds semantic context by explaining that the record consists of chain_id, token_id (ERC-721), agent_uri, and owner, which enriches the bare schema. However, it omits the 'metadata' parameter entirely and does not elaborate on field formats or constraints, leaving the description only partially compensating for the 0% schema coverage.
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 action ('Import') and the specific resource ('ERC-8004 Identity Registry record'), enumerating the key fields (chain_id, token_id, agent_uri, owner). This is distinct from sibling tools like import_feedback, making the purpose unambiguous.
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 indicates the tool is for importing or re-importing (updating) records, providing clear context for use. However, it does not explicitly mention alternatives or exclusions relative to siblings, so it does not fully achieve a 5.
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.
Each tool has a distinct role: bind_identity creates binding attestations, export_attestation exports trust-score payloads, verify_attestation checks integrity, and import/list/resolve/score each target different registry operations. No two tools appear to perform the same action.
All tools follow a verb_noun pattern with clear verbs (bind, describe, export, import, list, resolve, score, verify). The only minor variation is list_registrations using a plural noun, but this is conventional and does not cause confusion.
With 9 tools, the server covers identity import, listing, resolution, feedback import, scoring, attestation export/verification, binding, and self-description. This is appropriately scoped for a bridge service without excess.
The core ERC-8004 workflows (registration, feedback, scoring, attestation) are represented. Minor gaps include no direct listing of feedback records and no delete/removal operation, but these are workaroundable.