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

With readOnlyHint: true already in annotations, the bar is lower, and the description adds genuine value on top: the mainnet-specific behavior (reporting $THREE balance and deploy-fee tier) and the derivation mechanism (Metaplex Core Asset Signer PDA). The closing 'Read-only; never moves funds' reinforces the annotation rather than contradicting it, which is appropriate emphasis for a financial read operation.

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 front-loaded with the core purpose in the first sentence, then systematically walks through each mode. At ~135 words it's longer than ideal, but the three-mode structure and network-specific behavior justify the length. Every sentence serves a distinct purpose with zero filler.

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 tool with 3 optional params, 3 usage modes, and network-dependent behavior, the description is admirably complete. It covers the default behavior, the derivation case, the raw address case, network-specific output, and points to `three_status` for more details. Minor gaps: no mention of what happens when both `asset` and `address` are passed, and the output format isn't hinted at without an output schema.

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 coverage is 100%, so the baseline is 3, and the description goes beyond this: it explains the derivation behavior of `asset`, distinguishes it from `address`, and documents the default when neither is passed (configured signing wallet). The semantics around parameter precedence and meaning are materially enhanced.

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?

"Show a wallet address and its live SOL balance" is a specific verb+resource statement that clearly distinguishes this from siblings like `send_signed_transaction` and `prepare_agent_mint`. The three explicit invocation modes (asset, address, neither) map directly to the params, making the tool's role unmistakable.

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 embeds a concrete workflow example: "confirm it is funded before mint_onchain_agent", which tells agents when this is the right tool in their task sequence. It also cross-references `three_status` for the deploy-fee tier info. It stops short of naming explicit alternative tools or saying 'use X instead', so it gets a 4 rather than a 5.

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

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

Annotations already mark this as read-only and idempotent, and the description reinforces and expands on that by saying it does not touch Solana and instead produces a local JSON document and self-contained data URI. This makes the behavioral contract clear, including the fact that the output can be previewed before actual on-chain registration without side effects.

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 compact—two sentences—and front-loaded with the core output artifact before moving to usage scenarios. Every sentence adds useful information, and there's no redundant restating of the schema or annotation fields.

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?

Despite having 12 parameters, the schema covers them and the description provides the missing operational context: what artifact is produced, that it is self-contained data URI, how it relates to on-chain sibling tools, and how to use it in the hosting flow. The lack of an output schema doesn't hurt because the description names the concrete output format clearly.

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 input schema achieves 100% coverage of paramater descriptions, so the schema does the heavy lifting. The description does not add parameter-level semantics beyond the schema, though it connects the resulting artifact to registration_uri. This lands at the baseline for high 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 tool's purpose: 'Build the Genesis-style EIP-8004 registration-v1 JSON document and its self-contained data:application/json;base64 URI.' It also differentiates from sibling tools by explicitly noting 'without touching Solana' and by referencing what mint_onchain_agent / register_agent_identity will write on-chain.

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?

It explicitly tells the agent when to use the tool: to preview what mint_onchain_agent / register_agent_identity would write on-chain, or to host the document independently and pass it back as registration_uri. The 'without touching Solana' phrase also communicates the when-not: this is the offline/read-only path, not the on-chain execution path.

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

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

Annotations already declare readOnlyHint:true and openWorldHint:true. The description adds behavioral context beyond annotations: checks whether the identity PDA exists, the built-in agent wallet (Asset Signer PDA) with live SOL balance, and mentions EIP-4 registration documents. No contradictions with annotations.

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?

A single dense paragraph separates the return fields by semicolons. The content is valuable and specific but no section breaks, bullets, or formatting are used; every item in the catalog is described in a single run-on style.

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?

There is a rich annotation (readOnly, openWorld) and an ample description that enumerates the returned data (identity, plugins public roles, decoded metadata, EIP-4 documents, existence, wallet balance). There is no output schema, so for a complete result the narrative is required, but it covers all relevant data and edge cases of a high-complexity 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?

Input schema covers 100% of parameters with descriptions ('Core asset address (base58)', 'Cluster. Defaults to configured network.'). The description reinforces the schema (base58,maxLength) and adds the network default value, but does not explain address format or usage details beyond the schema.

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?

Description begins with a specific verb ('Fetch') and a specific resource ('asion of a Metaplex Agent by its core address. It lists distinct data items: name, update authority, plugins, decoded metadata, EIP-4 registration documents, PDA existence, and wallet live SOL balance. It also distinguishes itself from sibling tools by stating it is read-only and targeting a single agent, not listing all agents.

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?

Description conveys clear context for use: 'Read-only. Works on any registered agent, e.g. the three Genesis mints.' It does not name explicit alternatives, but its read-only designation and focus on a single address versus listing agents provides reasonable use guidance.

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

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses the live source (three.ws /api/deployments feed), that it indexes external registrations, the newest-first ordering, and the fields returned in each entry. It adds meaningful behavioral detail without contradicting annotations.

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 three tigh t sentences: purpose and source, return fields, and optional parameter plus read-only note. It is front-loaded and every sentence contributes essential information with no filler.

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 read-only list tool with no output schema, the description covers the key completeness aspects: data source, sorting, per-entry fields, cross-chain option, and safety. Pagination is missing but cursor is documented in the schema, and the openWorldHint aligns with the live feed statement.

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 the baseline is 3. The description adds minor semantic value by explaining all_chains as 'same stream' and referencing limit/cursor context indirectly, but most parameter behavior is already fully documented in the schema.

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 what the tool does: it lists the latest on-chain agent registrations in the Metaplex Agent Registry, newest first, from a specific live feed. It differentiates from sibling tools like get_onchain_agent by emphasizing the list/stream nature and the source, making its 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 provides clear context for when to use the tool: to see the most recent agent registrations, with a note on including EVM registrations via all_chains. It implicitly contrasts with single-fetch tools and declares the operation read-only, but does not explicitly name alternatives or state when not to use it.

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

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

Despite annotations already marking this as non-read-only and destructive, the description adds substantial behavioral detail: atomic transaction with a create-then-register fallback (Genesis-333), signing via SOLANA_SECRET_KEY or per-call secret, ~0.007 SOL costs plus a fee funding $THREE buybacks, the fee riding in the same transaction so a failed mint pays nothing, and confirm:true gating the broadcast. It also names the wallet-user alternative.

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 a single dense paragraph with six sentences, each covering a different aspect (purpose, execution, signing/costs, fee safety, preview behavior, alternative). It is efficient for the tool's complexity, but bullet points or short sections would improve scannability.

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 tool with 28 parameters and no output schema, the description covers execution strategy, costs, fee behavior, preview contents, and an alternative tool. The main gap is that it does not describe what is returned when confirm:true is set (e.g., transaction signature or mint address), which would significantly improve completeness.

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 the baseline is 3. The description reinforces the confirm:true preview/broadcast behavior but does not add meaning beyond the schema's own parameter descriptions, and it does not clarify interactions among the 28 parameters.

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 it deploys an AI agent on-chain by minting a Metaplex Core asset and registering its EIP-8004 identity, with specifics like Genesis-333 style and a built-in wallet. It uses a precise verb+resource structure and distinguishes itself from siblings by describing the full mint+register flow and by explicitly sending Phantom/Solflare users to prepare_agent_mint.

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 provides an explicit alternative for Phantom/Solflare users ('use prepare_agent_mint') and implies the primary use case of direct server-side signing via SOLANA_SECRET_KEY. However, it does not explicitly differentiate from register_agent_identity or build_registration for workflows that need only part of the process, so it is not fully exhaustive.

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

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

The description reveals key externally observable behaviors: no broadcast is performed, the result is co-signed by a new asset keypair, the wallet is the fee payer, blockhash expiry imposes a signing-time constraint, and fee pricing uses the wallet's live balance. This substantially enriches the tool annotations, and there is no contradiction.

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 packed with useful operational details, including transaction splitting, fee quoting, no broadcast, and expiry caveats, and yet remains easily readable. It is longer than a single sentence, but every clause serves to guide correct use and proper next steps.

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?

Given the high complexity, lack of an output schema, and a large input schema, the description covers a lot of the needed context: output fields, fee payer, fee response fields, signing limitations, and atomicity boundary. It leaves minor ambiguity around the exact type and structure of txs_base64, but takes the tool reasonably close to being self-explanatory.

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 has 100% per-parameter description coverage across all 27 parameters, so the tool description does not need to explain every field. It adds a little meaningful context by describing how wallet is used as signer and fee payer, but this is only a small supplement to the already-complete schema.

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 a specific verb and bounded purpose: building unsigned Genesis-style mint and registration transactions for an external Solana wallet, with no secret key required. It names the output fields and distinguishes itself from the sibling tools like mint_onchain_agent and send_signed_transaction.

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?

It explicitly declares the intended context: external wallets (Phantom, Solflare, etc.), no secret key needed, and a defined handoff to send_signed_transaction after signing. It does not explicitly contrast conditions like 'use mint_onchain_agent when you have a secret key', so the alternative recommendation remains partially implied.

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

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

Even though annotations already capture read-only/write/destructive/idempotent traits, the description adds substantial behavioral context: exact side effects (writing the EIP-8004 document, creating the identity PDA), cost, one-time registration semantics, and the already_registered error/handling behavior. It strikes at the right level beyond the annotation flags.

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 compact and front-loaded with the main action, then covers prerequisites, costs, idempotence, preview behavior, and alternatives. Every clause adds meaningful information without 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?

Despite having 16 parameters and no output schema, the description covers the essential operational context: what the tool writes, when it is usable, what happens in failure, what confirm controls, what it costs, and what related tools do. The full suite of parameters is sufficiently documented through the schema, so the description does not need to repeat them.

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%, and each parameter has field-level descriptions, so the baseline is 3. The description adds useful context around confirm:true previews and authority requirements for collection-bound assets, but it does not materially supplement the parameter semantics beyond what the schema already provides.

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 specifies an exact verb and resource: 'Give an ALREADY-MINTED Metaplex Core asset its Agent Identity.' It distinguishes itself from siblings by explicitly directing new-agent work to mint_onchain_agent or prepare_agent_mint, making the tool's purpose unmistakable.

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 clearly states when to use this tool (registering existing assets), what prerequisites are required (asset authority or collection authority), and what not to use it for ('To mint a NEW agent...'). It also includes hands-on operational guidance about confirm:true and confirmation requirements.

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

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

Annotations already mark this as destructive and non-read-only, and the description adds meaningful behavior: sequential broadcasting with polling before each next transaction, handling of the propagation race, and an explicit warning that on-chain effects are real. It does not cover failure-handling behavior, but the annotations lower the burden and the added context is valuable.

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 compact and front-loaded with the core action and object. Each sentence earns its place: one for mechanics, one for workflow integration, one for the safety warning. There is no redundant filler.

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 destructive broadcasting tool with no output schema, the description covers purpose, ordering, confirmation polling, workflow integration, and risk. It does not specify failure behavior or response shape, but the schema and annotations provide enough surrounding structure that this is not a critical gap.

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 the schema already defines network, tx_base64, and txs_base64 clearly. The description adds some context by tying txs_base64 to the wallet-signed prepare_agent_mint array and to create/register sequencing, but it does not add substantial meaning beyond what the schema already provides.

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 uses a specific action ('Broadcast') with a clear resource ('fully signed Solana transactions (base64)') and a distinctive behavior ('IN ORDER, polling each to confirmation before the next'). It also situates the tool within the prepare_agent_mint flow, distinguishing it from sibling tools that build or register rather than broadcast.

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?

It explicitly says to use the tool to complete the prepare_agent_mint flow and instructs the user to pass the wallet-signed txs_base64 array. It gives clear context but does not explicitly state when not to use it or name an alternative tool, though the flow integration implies the surrounding steps.

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

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

Annotations declare readOnlyHint=true and openWorldHint=true, and the description reinforces these by stating 'Read-only: it moves nothing and needs no key.' It also adds useful context: the data comes from the public three.ws ledger and includes live market/buyback figures, which is beyond what annotations alone provide. No contradiction.

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 three sentences and front-loaded with a clear headline. It enumerates outputs compactly and provides usage instructions without redundancy. Every sentence earns its place, and the construct is easy to scan.

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?

Given the tool's complexity (returns multiple distinct data points) and lack of output schema, the description sufficiently explains what will be returned: fee schedule, balance, tier, wallet, and market/buyback figures. It also covers parameter behavior and read-only nature, making it complete for an agent to decide when and how to call it.

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 coverage is 100%: both wallet and network have descriptive strings, including defaults and behavior (devnet always free). The description reiterates the wallet default and adds the 'omit it' wording, but this is already in the schema. Since the schema fully documents parameters, the description adds minimal value beyond what structured data already provides.

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 states a clear purpose: it tells what the next on-chain deploy costs and why, listing specific outputs (deploy-fee schedule, $THREE balance, tier, wallet, market/buyback figures). This clearly distinguishes it from sibling tools like get_onchain_agent or send_signed_transaction, which focus on different operations.

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 provides clear usage context: it explains how to pass a wallet to price a specific payer or omit it to use the configured signer. It also states it is read-only and needs no key, implying it is for inquiry before deployment. However, it does not explicitly mention when to use this over siblings or when not to use it, so it lacks explicit exclusions.

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