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

Annotations already flag destructiveHint=true and non-idempotency, so the safety profile is declared. The description adds genuinely new context beyond that: no transaction is signed locally, and confirmPhrase must equal the tool name when DFM_MCP_CONFIRM_REQUIRED=1. It does not describe the rejection behavior's error surface or auth requirements further, but the added context is meaningful.

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 critical 'NOT AVAILABLE YET' warning is front-loaded, and every remaining sentence carries distinct information (reconciliation scope, no local signing, confirmPhrase rule). It is terse and structured, 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 high-sensitivity mutation tool with annotations covering the safety profile and no output schema, the description supplies the essential operational facts: it is a reconciliation-only path, no local signing, and the confirmation protocol. The main residual gap is the undocumented required vault parameter, but the schema pattern gives format guidance.

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 only 33% (only confirmPhrase is documented). The description mentions landedSignature's role and the exact confirmPhrase value, partially compensating. However, the required 'vault' parameter is left without any description or format hint beyond the schema pattern, so the description does not fully cover the gap.

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 specific operation: reconciling an already-landed admin acceptance via landedSignature, and explicitly contrasts this with the unavailable new-acceptance path. It clearly differentiates from the sibling transfer_admin by scoping itself to reconciliation only. The purpose is understandable, though framed negatively ('NOT AVAILABLE YET') rather than as a positive statement of what it does.

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 gives an explicit when-not-to-use ('new acceptances are refused') and an implied when-to-use (reconcile an already-landed acceptance). This is strong routing guidance for a niche tool. It stops short of naming an alternative tool path for landing a new acceptance, which would have made it 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 declare readOnlyHint and openWorldHint, so safety is covered. The description adds meaningful context beyond them: the balance is 'LIVE onchain' (freshness, not cached) and the wallet is 'the address the SERVER signs with on the user's behalf' (custody model). It does not mention rate limits or latency, so 4 rather than 5.

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?

Three sentences, zero filler, and it is front-loaded: identity of the resource first, the call trigger second, the negative disambiguation last. Every clause earns its place by either scoping scope or routing behavior.

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?

With no input params and no output schema, the description carries the burden of saying what comes back, and it does: existence, status, live balances, and next action. The four refusal causes also pre-empt the most likely follow-up question, so an agent has everything needed to call and interpret 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?

Zero input parameters, so there is no parameter semantics to document; baseline 4 applies. The description adds nothing parameter-related, but nothing is needed.

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 resource (the app/operating wallet) and exactly what it reports: existence, status, live SOL+USDC balances, next action required. It also explicitly negates the nearest confusable sibling — 'This is NOT the main wallet' — so an agent can separate it from get_portfolio/get_vault without reading schemas.

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?

Gives an explicit trigger condition: 'Call this BEFORE explaining why a write was refused,' plus the four possible causes (no wallet / not activated / revoked / empty float). This tells the agent both when to reach for it and what decision it feeds, which is stronger than a generic 'use for status checks.'

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 annotations (destructiveHint=false, openWorldHint=true), the description discloses that this is REAL-MONEY and gated, that it is the one signature the app-wallet model requires, that it needs a keypair and is signed locally, and that keyless/API-key users must use the web app. That is substantial non-obvious behavioral context the annotations alone do not convey.

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?

Front-loads the critical 'REAL-MONEY (gated)' warning and stays dense with operative facts. It is on the longer side and the final alternative-path sentence is slightly tangential, but nearly every sentence carries useful information.

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 real-money mutation tool with no output schema and sparse parameter documentation, it covers the safety profile, keypair requirement, keyless fallback, amount units, and an alternative funding path. It does not describe the result of a successful call, a minor gap given there is no 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 only 33%, so the description must compensate. It does so for sol/usdc by stating amounts are human units and giving concrete examples (usdc 12.5, sol 0.05), but it says nothing about confirmPhrase, which is only documented in the schema itself.

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 precise verb and resource: move USDC/SOL from the agent's own wallet into the app wallet. It clearly distinguishes itself from siblings like app_wallet_withdraw, withdraw_asset, and deposit by naming the source and destination wallets explicitly.

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?

Gives explicit conditions: use when the app wallet needs to pay for launches, deposits and fees; must be signed locally with a keypair; in KEYLESS mode go to the web URL instead. It also names an alternative path (plain USDC/SOL transfer from any wallet), so both when-to-use and alternatives are covered.

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 destructive/non-idempotent/open-world, but the description adds the operational consequences: the old wallet's balance is orphaned and only sweepable, and the tool refuses to run while the float is non-zero. It also discloses the human-confirmation gate and the exact phrase, which the annotations do not express.

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?

Warning is front-loaded, then what-changes, then the prerequisite, then the confirmation gate. Every clause is load-bearing: no restatement of the title and 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 destructive, non-idempotent wallet operation with no output schema, the description covers trigger, prerequisite, side effects, refusal condition, and confirmation mechanics. An agent has everything needed to decide whether 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?

With one parameter at 100% schema coverage the baseline is 3, but the description goes further by supplying the concrete required value (confirmPhrase="rearm_app_wallet") and the enabling env var, details the schema only hints at with a generic example.

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 the specific action (supersede the current app-wallet grant and mint a fresh one) and the concrete outcome (creates a NEW address with an empty balance). This clearly separates it from siblings like create_app_wallet, app_wallet_withdraw, and app_wallet_fund without needing the schema.

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?

Gives an explicit trigger (grant stamped with a superseded rebalancer id, 're-arm required') and an explicit prerequisite alternative (run app_wallet_withdraw FIRST), including the failure condition 'refuses while the float is non-zero'. It also states the confirm-phrase path required when DFM_MCP_CONFIRM_REQUIRED=1.

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 with annotations present, the description adds real behavioral context: REAL-MONEY gated, destination resolved server-side and immutable by the caller, fallback behavior when no withdrawal wallet is saved, and resilience to config problems that block other writes. Annotations confirm mutation (readOnlyHint=false) and no destructiveHint, and nothing here contradicts them.

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?

Front-loads the critical 'REAL-MONEY (gated)' signal and keeps to three dense sentences, each carrying distinct information (scope, destination resolution, failure resilience, ordering). Parentheticals add some density but no sentence is pure 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 one-param mutation tool with no output schema, the description covers destination resolution, fallback, gate conditions, and sequencing. An agent has everything needed to decide to call it and understand what it will do; return values are not required to be explained here.

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?

Only one parameter (confirmPhrase, optional) and schema description coverage is 100%, so the schema fully documents it, including the DFM_MCP_CONFIRM_REQUIRED=1 gate. The description adds no parameter-level meaning beyond the schema, which is the expected baseline 3 when coverage is high.

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 and resource ('Return the app wallet's USDC + SOL'), the exact destination rules (saved withdrawal wallet, or owner wallet as fallback), and explicitly notes the destination is server-side and non-choosable. This cleanly distinguishes it from siblings like withdraw_asset and transfer_admin.

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?

Gives an explicit sequencing rule ('Do this BEFORE app_wallet_rearm') and names a success condition not shared by peers (works even when writes are otherwise refused due to a stale rebalancer stamp or expired grant). It lacks a direct contrast with withdraw_asset, so it stops short of naming the alternative and the condition that selects 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?

Annotations already declare non-destructive, idempotent, open-world; the description still adds real value by disclosing the SOL cost (~0.014 SOL in the app wallet) and the safety nuance that the live vault is untouched and only on-chain metadata is added. It does not cover permissions or what the operation returns, but the cost and additive-only framing are strong context.

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?

Three tight sentences, front-loaded with the action and trigger, then prerequisites (vault live) and cost. Nothing is padded and every sentence adds decision-relevant information.

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?

With annotations covering the safety profile and no output schema to explain, the description covers the trigger, the resource, the prerequisite state, and the cost. The only gap is that it doesn't hint at the confirmation-phrase flow or the result of the retry, which an agent might want.

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 50% and the `vault` parameter has no schema description (only a pattern). The description partially compensates by tying it to 'a fund you launched,' implying the vault address, but gives no format or disambiguation guidance. Baseline 3 is appropriate given the schema already documents confirmPhrase in detail.

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 specific verb (retry/attach) plus resource (share-token metadata: name, symbol, logo) scoped to 'a fund you launched.' It also distinguishes the operation from launch_vault by clarifying the vault is 'already live' and this 'only adds its on-chain metadata,' so an agent can separate it from launch_vault and update_vault_assets.

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 gives an explicit trigger: use this 'when the launch note says that step failed or was skipped,' and implicitly rules out re-launching since the vault is already live. No alternative tool is named for the case where metadata needs editing rather than a failed-step retry, so it stops short of a full when/when-not/alternatives statement.

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?

Goes well beyond the annotations by disclosing the local decode/verification step (only CloseAccount, authority = the app wallet, rent to the chosen destination) performed before the owner key signs, and the blast radius ('Moves only rent'). This is exactly the kind of pre-signing safety context annotations cannot express.

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?

Three dense sentences, front-loaded with the scope and the non-empty exclusion before the mechanics. Slightly overloaded with parentheticals, but no sentence is wasted.

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?

With one optional param, annotations covering the safety profile, and no output schema, the description is nearly sufficient: it explains scope, exclusions, destination, and pre-sign verification. The only real gap is the destination-default conflict with the 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 parameter is already documented, but the description actively conflicts with it: it calls sign_in_wallet the default while the schema description says default app_wallet. That inconsistency can cause an agent to reason about the wrong default, which is worse than saying nothing.

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 precise verb (close), resource (EMPTY token accounts), and scope (this agent's own app wallet, owner = local P-256 key), plus what happens to the recovered rent. It also implicitly separates itself from app_wallet_withdraw, which it names as the follow-on SOL-moving step.

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 condition for inclusion is explicit ('A non-empty account is never included'), and the default destination plus the alternative flow via app_wallet_withdraw are stated. It stops short of an explicit 'use this when you want to reclaim rent' framing, so it is clear context rather than full when/when-not 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?

Goes well beyond the annotations: default 30-day expiry with 90-day max, the operator override flag DFM_ALLOW_WRITE_KEY_MINT=1, the file path and 0600 permissions, and the critical fact that the key value is NEVER returned to chat (only prefix and path). This is exactly the behavioral context an agent cannot infer from structured fields.

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?

Front-loads the action and its safety constraint in the first two sentences. The trailing pipeline chain is long but earns its place by orienting the caller within the onboarding sequence. Dense but not wasteful.

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 9-param mutation tool with no output schema, the description is unusually complete, covering auth requirements, lifetime, storage, and the fact that it returns only a prefix and path. Minor gap: several numeric/whitelist parameters remain undocumented.

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 only 22%, so the description should carry more of the burden. It clarifies readOnly (default true via "READ-ONLY") and expiresAt (30 default / 90 max), but leaves name, dailyNotionalUsdc, perOpNotionalUsdc, destinationWhitelist, and allowArbitraryPrograms unexplained. Partial compensation only.

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 ("Mint") and resource (a dfm_ API key) and scopes it to "this agent's owner". It is immediately distinguishable from siblings like create_app_wallet or set_profile, which are named in the pipeline context.

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?

Gives strong context: "SIWS session only" prerequisite, and the explicit chain showing it is the "Optional last step of" the onboarding flow. It does not name a competing alternative or a when-not condition, so it falls just short of 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 only carry readOnly/openWorld/idempotent hints; the description adds substantial context beyond them: exact key file path and 0600 mode, reuse-never-overwrite behavior, that only the public key is sent to DFM, the single policy-binding Privy signature, which ids are pinned locally vs trusted to DFM, and 'DFM never holds the key / moves no funds'. That is exactly the behavioral disclosure annotations cannot provide.

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?

Long and dense, but front-loaded with the core action and free of filler; each clause (key handling, auth, idempotency, no-funds) carries distinct operational meaning. Splitting the security/policy details into a second sentence would help readability slightly, but nothing is padding.

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 zero-parameter, no-output-schema tool, the description covers everything an agent needs: required auth (SIWS keypair), environment paths, what is returned on repeat calls, and the absence of fund movement. Nothing material is left for the agent to guess.

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 tool takes zero parameters, so the baseline is 4; there is no schema surface the description needs to compensate for, and the path override (DFM_APP_WALLET_OWNER_KEY_PATH) is described as an environment input rather than a call argument.

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 ('Create this agent's DFM APP WALLET') and immediately scopes it with the discriminator 'without a browser' / 'headless'. An agent can separate it from create_identity_wallet, app_wallet, and create_api_key without opening a schema, and the title reinforces the distinction.

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?

Clearly gives prerequisites ('Needs a SIWS sign-in ... a dfm_ API key cannot create custody') and a re-invocation rule ('Call it again when DFM reissues the policy'). It does not name the sibling alternative to use when a browser or identity wallet is intended, so it stops short of full when-not/alternatives coverage.

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?

Goes well beyond the annotations by disclosing filesystem behavior (0600 permissions, never overwritten, no restart required), the exact return value (only the public key), and a side-effect disclaimer ('Moves no funds'). This confirms and enriches the idempotentHint=true annotation rather than merely restating it.

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?

Front-loaded with the tool's identity in the first clause, then the reuse logic, then the pipeline. Sentences are dense but every one carries operational information — no filler or restatement of the name.

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?

With no output schema, the description explicitly states what is returned ('only the public key'), and it covers side effects, idempotency, file location, and downstream ordering. Nothing an agent needs to call this correctly is absent.

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 tool takes zero parameters, so the baseline of 4 applies; there is no parameter meaning for the description to add. Nothing here is misleading or missing.

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 ('The Solana keypair this agent signs in to DFM with (SIWS)') plus the reuse-vs-create branch, and clearly differentiates itself from create_app_wallet which appears later in the stated workflow. An agent can identify this as step 1 of onboarding without opening the schema.

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?

Explicitly names the conditions under which the keypair is REUSED (env vars set or ~/.config/dfm/agent-wallet.json present) versus created, and places the tool in a full ordered pipeline (create_identity_wallet → SIWS login → set_profile → create_app_wallet → app_wallet_fund → create_api_key). No ambiguity about when to call 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?

Annotations declare destructive/non-idempotent/openWorld, but the description adds behavior beyond them: real-money gating, asynchronous settlement semantics, what a 'pending' status means, server-side signing with the app wallet, and the ~$12 post-slippage minimum for a first deposit. Rich context that annotations alone do not convey.

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?

Front-loads the most important warning ('REAL-MONEY (gated)') and every sentence carries load, but the middle is a dense run of clauses that could be slightly more scannable.

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?

With no output schema and an async 5-param lifecycle, the description still supplies everything needed to call correctly: unit format, minimums, settlement semantics, and the poll/verify follow-up path.

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 40%, so the description must compensate. It does so strongly for the critical usdcAmount (RAW 6-decimal units with a concrete "12000000"=$12 example) and ties the ~$12 floor to slippage. However, vault and slippageBps receive no added meaning beyond the schema, leaving some gaps.

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 (open a zap-v2 USDC→vault deposit) and explains the full mint lifecycle. An agent can distinguish this from swap, redeem, and zap_status siblings purely from the description.

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?

Explicitly routes the agent: on a pending result, poll zap_status, then verify with get_portfolio, and explicitly warns 'Do not repeat deposit to poll.' Names the alternatives and the conditions that select them.

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 only declare readOnlyHint and openWorldHint; the description goes well beyond by identifying it as a search endpoint, enumerating the returned fields (mint, symbol, name, decimals, asset class), and warning about impersonation and the 1000x decimals pitfall. Nothing contradicts the annotations and substantive behavioral context is added.

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?

Front-loaded and every sentence is doing work: identity first, then usage, then the mint-address warning, then the decimals caveat. The all-caps emphasis (WORDS/MINTS, DECIMALS) is slightly loud, and the decimals paragraph is adjacent rather than core, but it is short and earns its place.

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 compensates by listing the returned fields. With annotations covering the read-only/open-world profile and only two parameters, the definition is nearly complete; the lone gap is that query's format expectations are shown only by example and assetClass is left to the 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 50%: assetClass is documented in the schema, but query has no schema description. The description's examples ('AI tokens', 'DePIN', 'something like JUP') usefully convey that query accepts fuzzy natural-language terms — value beyond the bare string type — but it never mentions the assetClass filter or its enum values. Partial compensation, so baseline 3.

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 and resource — 'Turn WORDS into MINTS via Jupiter (GET /assets/search)' — and makes the resource's role unambiguous. It is clearly distinguishable from siblings like get_token_price or swap, and the 'this is where any basket idea starts' framing pins the tool's scope precisely.

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?

Gives explicit when-to-use context ('Any basket idea — "AI tokens", "DePIN", "BONK"') plus hard when-not rules ('never type a mint from memory', 'always resolve a pasted one first'). It also names the failure mode (ticker collisions, impersonation) that motivates the guidance, leaving nothing to inference.

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=false (implying a state mutation) plus idempotentHint and openWorldHint. The description adds genuinely useful context beyond those flags: 'Moves no funds' reassures the agent that this write-like action has no financial side effects, resolving ambiguity created by readOnlyHint=false.

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?

Two short sentences, zero filler, with the core action stated first and the safety clarifier second. Every sentence earns its place.

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 low-complexity, single-parameter tool with no output schema, the description plus annotations cover the essential facts an agent needs. Minor gaps remain around what following actually changes and any relationship to trader_profile.

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 0% for the single required parameter, so the description carries the burden. 'By wallet address' clarifies that the wallet param is a wallet address rather than an ID or name, which compensates somewhat but stops short of format or length guidance.

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?

'Follow a trader by wallet address' gives a specific verb and resource, and the 'wallet address' qualifier tells the agent what identifier is expected. The contrast with the sibling unfollow_trader is inferable from the name but is not stated in the description.

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 offers no when-to-use or when-not-to-use guidance, and it never points the agent at alternatives such as trader_profile or unfollow_trader. Usage must be inferred entirely from the tool name.

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 cover the safety profile (readOnlyHint=true, openWorldHint=true), but the description adds genuinely non-obvious behavior: the wallet is derived from the authenticated identity rather than passed in, and it hits the live API. It stops short of describing return shape or any rate-limit/pagination behavior, so it is strong but not exhaustive.

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?

Two sentences, zero filler, with the core purpose front-loaded and the disambiguating constraint and auth requirement following. Every clause carries information an agent needs.

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 no output schema, so the description's 'positions + summary' phrasing carries the return-value burden and does so only at a high level. Combined with the auth and identity-derivation notes, an agent has enough to call it correctly, though a hint at the summary fields would complete 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?

The tool takes zero parameters, so per the rubric the baseline is 4. The description correctly adds no parameter detail because there is none to add, and instead clarifies the identity-derived scoping.

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 and resource ('Get the user's primary DFM app-wallet positions + summary') and even names the underlying endpoints, so an agent can distinguish it from siblings like app_wallet, list_app_wallet_assets, and get_vault. The explicit note that no portfolio-by-arbitrary-address endpoint exists removes the main ambiguity.

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 when to use it (fetching the authenticated user's own portfolio) and rules out the address-based variant, which is useful exclusion guidance. However, it never names a sibling alternative for the cases it excludes, and gives no explicit trigger conditions or prerequisites beyond 'AUTH required'.

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 only declare readOnlyHint/openWorldHint; the description adds crucial semantics they cannot: a missing price is data not a failure, unpriced mints are reported separately, and callers must never substitute zero. This directly shapes correct handling of an open-world lookup and is exactly the kind of context the annotations omit.

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?

Front-loads the core capability in the first clause, then the behavioral caveat. Every sentence carries meaning, though the emphatic caps-lock and embedded quote are slightly heavier than needed for the informational payload.

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 single-parameter read with no output schema, the description covers the one thing an agent most needs to get right (the unpriced field and non-failure semantics). Auth/rate-limit context is absent but not critical here.

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 0%, so the description must carry the param load. It explains the 20-mint limit and the per-mint GET semantics, but the 'up to 20 mints' limit is already stated in the schema (maxItems) and it never clarifies the expected base58 mint format. Partial compensation only.

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 (get) plus resource (USD token price), with explicit scope (up to 20 mints) and unit (USD). An agent can immediately tell this apart from portfolio/vault/swap siblings, which return different context than a single-mint price lookup.

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?

Usage is implied through the 'can this be a basket leg' framing, which hints at when it's relevant, but no alternatives are named (e.g., swap_quote for executable pricing) and no explicit when-not guidance is given. Adequate but leaves routing to inference.

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, so the safety profile is covered. The description usefully reinforces this by naming the live API endpoint (GET /vaults/:address) and detailing the response contents, though it says nothing about auth, rate limits, or error behavior.

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?

Two tight sentences with the purpose and return contents front-loaded, followed by the parameter source. No filler and nothing redundant.

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 single-parameter read tool with annotations covering safety and no output schema, the description supplies the purpose, return payload, and parameter source an agent needs to call it correctly.

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 0% and the single required param has no schema-level text, so the description carries the load. It adds real value by specifying the address is base58 and originates from list_dtfs, compensating well for the coverage gap.

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 (Get) and resource (full vault detail) and enumerates what is returned: the vault doc, current weights, deviations, fee structure, and TVL cap. This is clearly distinguished from siblings like list_dtfs (multi-vault listing) and the various update_vault_* mutators.

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?

Provides clear context by naming list_dtfs as the source of the required address, establishing the workflow relationship between the two tools. It stops short of stating explicit when-not-to-use conditions or contrasting against alternatives like get_portfolio.

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 declaring readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true, the description adds substantial context the annotations cannot: it is a gated REAL-MONEY operation, requires manager/admin rights, the creator pays rent, it runs as prepare → sign → submit, and it reverts if the config is already initialized.

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?

Front-loaded with the gating and authorization constraint first, then the effect, then the disambiguation of when it is required. Every clause carries information; nothing is repetitive or padded.

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?

With no output schema, the description still covers the full picture an agent needs: authorization requirement, cost/rent payer, execution flow, revert-on-reinit behavior, and the conditions under which the tool is unnecessary. Nothing material is missing for a correct invocation.

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 50% (vault has only a pattern, confirmPhrase is fully documented in the schema). The description still adds meaningful semantic constraints on the vault argument — it must be one the caller's app wallet ADMINS — which is not expressible in the schema and directly affects a valid call.

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 action and resource: it creates the vault's RebalancerConfig so the vault can be rebalanced, distinct from launch_vault (bundles it automatically) and rebalance_to_targets (performs the rebalancing). The agent can tell exactly what this tool produces without opening the schema.

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?

Explicitly scopes when this is needed (older vault, vault created with rebalancing skipped, or basket too large to bundle) and when it is not (vaults launched by this agent already get it bundled at create time). It also states the explicit precondition that the caller's app wallet must ADMIN the vault.

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 destructive/openWorld/non-idempotent, and the description adds substantial context beyond them: the signing/payment model, the refusal-instead-of-local-keypair behavior, creator-fixes-onchain semantics, factory-global fees that the creator cannot set, issuer-lock risk on freezable mints, the non-fatal metadata step (#47), and the mandatory first-deposit threshold. This is rich behavioral disclosure an agent could not infer from structured fields.

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?

Front-loaded with the gating and the core action, and nearly every clause carries operational meaning (bps total, count limits, uniqueness, rent). It is dense and laden with parentheticals, which slightly impedes scanning, but there is little true 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 an 8-parameter mutation with no output schema, the description covers the return value ('Returns the vault address'), the funding follow-up, gating, and the key parameter constraints. Only `category` and the generic `description` field go unexplained, leaving a small but real 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?

With only 25% schema description coverage, the description compensates well for the critical complex parameter — it defines `assets` shape (mint/symbol/allocationBps), the exact-10000 bps rule, and the 2–10 count — and explains `metadata:false` rent behavior and name/symbol uniqueness. Gaps remain for `category` and `description`, which are undocumented in both places.

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 and resource ('Create a new fund') immediately after the REAL-MONEY gating marker, and frames the on-chain consequence (app wallet becomes vault admin, creator fixed forever). An agent can distinguish this creation tool from update_vault_assets, deposit, or get_vault without opening a schema.

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?

Gives a clear precondition (active app wallet required, refuses otherwise) and routes the agent to the app_wallet sibling when a fund write is refused. It does not spell out alternate creation paths or an explicit when-not-to-use, but the context is unambiguous for a one-shot creation call.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond that: it clarifies that this view includes fund shares and that it is the source of the exact mint and exact raw balance, which `app_wallet` cannot see. It does not mention auth, rate limits, or ordering, but for a read-only list tool with annotations carrying the safety burden this is a solid addition.

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?

Three sentences, front-loaded with the differentiator ('EVERY token ... fund shares included') and then the sibling contrast and the call-to-action. Each sentence earns its place and there is 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?

There is no output schema, so the description carries some burden for describing returns; it does this by naming amount, decimals, USD value, exact mint and raw balance. It is complete enough for a simple read-only list tool, though it omits ordering, empty-wallet behavior, or response shape, which keeps it from a perfect score.

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 tool takes zero parameters and the schema is an empty object, so there is nothing for the description to disambiguate. Per the baseline for zero-parameter tools, 4 is appropriate; there are no parameter semantics the description could add value to.

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 (list) and resource (app wallet assets), and explicitly scopes the result as EVERY token including fund shares with amount, decimals and USD value. It distinguishes itself from the sibling `app_wallet` by stating that sibling only reports the USDC + SOL float, so the agent need not open either schema to tell them apart.

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?

Gives an explicit activation condition — 'Call this before proposing a withdrawal' — and names the alternative tool (`app_wallet`) plus the reason it is insufficient. The agent knows both when to reach for this tool and why another sibling is not a substitute.

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 cover the safety profile (readOnlyHint, openWorldHint), so the bar is lower, and the description adds real value by enumerating the returned fields (address, name/symbol, status, TVL, share price, fees, basket allocations) and noting the live API plus a limit cap of 50. It still omits pagination defaults and error behavior.

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?

Front-loaded with purpose, then returns, then filters — a logical three-part structure with no filler. The first sentence is somewhat long and parenthetical-heavy, but every clause earns its place.

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?

With no output schema, the description appropriately explains the return shape and covers all inputs adequately for a list tool. Minor gaps remain around pagination defaults and result-count/behavior at boundaries, but nothing essential to correct invocation is missing.

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 0%, so the description must carry the full burden, and it does: it documents category with concrete enum codes (7 Fun, 8 RWA, 3 AI, 9 Stocks, 4 Gaming, 1 DeFi, 255 custom), search (name), creator (wallet), sortBy + sortDir, page, and limit (max 50). This maps to all seven parameters and even supplies the category enum absent from 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?

States a specific verb (List) and resource (funds from the DFM v2 API, GET /vaults), clarifying that these are vault/marketplace entities. It is clearly distinguishable from singular siblings like get_vault, though the tool name 'list_dtfs' vs the description's 'funds'/'vaults' terminology introduces mild naming friction.

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 browse/discovery use case ('the same filter, sort and search surface the marketplace page uses') but never states when to prefer this over alternatives such as get_vault or get_portfolio, nor any exclusions. Usage is implied rather than directed.

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 flag this as a mutating, idempotent, open-world operation, and the description adds real value beyond them: it discloses that identity/app wallets are created if missing, that an API key is never minted, and that no funds move despite app_wallet_fund appearing in the sequence. This resolves the tension between the mutation hint and the 'moves no funds' guarantee, consistent with idempotentHint=true. It stops short of a 5 only because failure/auth specifics beyond 'stops and says which' are unspecified.

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 sentence, but it is front-loaded with the ordered pipeline and the most decision-relevant constraint ('stop at the first step that needs the operator') appears near the end. The arrow notation compresses the sequence efficiently 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 complex multi-step orchestrator with no output schema, the description covers the ordering, the stopping condition, idempotent creation of missing wallets, and the two key side-effect negatives. What an agent needs to invoke it correctly is present; only the exact returned shape/status detail is left implicit.

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?

Zero parameters, so the baseline is 4. The description usefully names the inputs consumed internally (set_profile {displayName}, avatar default behavior) even though the schema is empty, adding a little signal about what the operator must supply.

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 ('Run the headless onboarding') and enumerates the exact ordered sequence of operations it performs, ending with explicit scope boundaries ('never mints an API key', 'Moves no funds'). An agent can distinguish this orchestrator from its sibling step tools (create_identity_wallet, create_app_wallet, set_profile) without opening a schema.

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?

Clearly conveys when to use it (headless onboarding) and how it behaves at the boundary ('stop at the first step that needs the operator, saying which'). It implicitly supersedes the individual step siblings but never states that alternative explicitly, so it stops short of 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 flag destructiveHint, non-idempotent, open-world; the description adds substantial context beyond them: real-money gating, admin/rebalancer prerequisites, a 5s cooldown, manual-by-design policy, oracle-free guards (measured min_out, velocity ceilings, output-mint allowlist), and the conforming confirmPhrase protocol. It does not spell out reversibility/irreversibility of the swap legs explicitly, which keeps it just short of 5 for a destructive tool.

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?

Front-loads the critical 'REAL-MONEY (gated)' and duty warning before mechanics, and nearly every sentence earns its place (prereqs, cooldown, guards, routing). Some clauses are dense and interleaved, but no filler or repetition.

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?

With no output schema, the description still supplies the key return signal (`converged:true` when balanced), all prerequisites, the safety envelope, and the routing alternative. Nothing an agent needs to call it correctly is missing.

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 only 33%, with vault and slippageBps undocumented in the schema. The description compensates partially by clarifying that no mints or amounts are supplied (the API derives legs from drift), but slippageBps bounds and vault address format are never addressed in prose. Baseline 3 given partial compensation.

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 concrete verb+resource (converges live holdings to CURRENT config target weights) and explicitly separates itself from update_vault_assets, which changes targets rather than converging to them. An agent can tell exactly what state transition this tool performs.

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?

Gives explicit when-not guidance ('never fire this unasked', manual by design #35), prerequisites (vault you ADMIN, initialized rebalancer via launch_vault or init_rebalancer), and a named alternative for a different intent (update_vault_assets to change targets first). Routes the agent rather than leaving it to infer.

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 destructive=true, idempotent=false and openWorld, but the description adds genuinely new behavior: the call is asynchronous, returns status:"pending" that is not settled, requires app-wallet boundary signatures server-side, and is real-money gated. It does not explain slippage failure behavior or what happens on expiry/partial fill, which keeps it below a 5.

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?

Front-loaded with the gating warning and the operation, then lifecycle and follow-up in the right order; every sentence carries a distinct instruction. Slightly dense and jargon-heavy (zap-v2, escrow basket), but nothing is padding.

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, asynchronous, no-output-schema tool this covers the essential loop: invoke, expect pending, poll via zap_status, verify via app_wallet. It omits failure/rollback behavior and slippage bounds interpretation, which are the remaining gaps for an agent to call it safely.

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?

With only 40% schema description coverage, the description compensates for the most error-prone parameter by clarifying that `shares` is RAW 6-decimal units — meaning beyond the schema pattern. However `slippageBps` is unexplained in both schema and description, and `vault` semantics are left entirely to the pattern, so compensation is partial.

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 with mechanism: 'Open a zap-v2 redeem (burn shares → escrow basket, oracle-free pro-rata)'. It clearly separates itself from zap_v2_cancel/zap_v2_update_envelope and from deposit by naming the direction of the lifecycle.

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?

Explicitly tells the agent what to do after calling (poll zap_status, verify with app_wallet) and what NOT to do (do not repeat redeem to poll). It also flags the conditional confirmPhrase gate and its operator dependency, so the agent knows when human confirmation applies.

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=false, openWorldHint=true and idempotentHint=false, so the write/external/non-idempotent profile is covered structurally. The description adds genuinely new risk-relevant context — 'Moves no funds' — which is important in a toolset where 'write' calls usually mean on-chain value movement, reassuring the agent this side effect is non-financial.

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?

Two sentences, zero filler, front-loaded with the action and followed by the trigger and minimal required content. Every clause earns its place.

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 no output schema, and the description says nothing about what a successful call returns (ticket id, confirmation, whether a reply arrives via contact), which is the one thing an agent might want to relay back. Otherwise the definition is complete for a 4-parameter, 2-required reporting 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?

Schema description coverage is only 25% (contact only), so the description must compensate, and it does: it prescribes a 'short title', spells out the description content (what you did / expected / saw), and tells the caller to put error text or tx signature in context. Only 'contact' is unexplained, but the schema's own description ('email or X handle for a reply') covers that gap.

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 ('Send a bug report to the DFM team'), which no sibling tool duplicates in a toolset otherwise dominated by wallets, vaults and swaps. An agent can identify this as the sole support/escalation path without inspecting the schema.

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?

Gives an explicit trigger condition ('Use when something in DFM fails') plus the required content for a usable report (title, did/expected/saw, error text or tx signature). No alternative sibling exists for this purpose, so no when-not clause is needed.

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 only cover readOnly/idempotent/openWorld; the description goes well beyond by explaining avatar sourcing (operator path or ~/.config/dfm/avatar.*, ≤2 MB checked locally, model cannot point elsewhere), the deterministic identicon fallback, the `avatar.isDefault` result field, SIWS auth requirement, and 'Moves no funds'.

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?

Dense but front-loaded: purpose first, then avatar rules, then prerequisites and safety. The long parenthetical on avatar paths is justified detail, though a couple of clauses could be tightened.

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 covers the one return detail that matters (avatar.isDefault), the auth requirement, the mutation semantics, and the create_app_wallet prerequisite. An agent has everything needed to invoke it correctly.

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 50% (bio and displayName have no schema description). The description compensates by marking displayName required, username/bio optional, and explaining uploadAvatar behavior in depth (default true, uploads operator image or generated default). It adds little for bio beyond optionality, so not a full 5.

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: 'Set this agent's public DFM profile', then enumerates the fields it writes. It also ties itself to the sibling create_app_wallet by naming a prerequisite relationship, so an agent can place it in the workflow.

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?

Gives clear context: 'A chosen name AND an avatar are required before create_app_wallet' and 'Needs the SIWS sign-in (identity wallet)'. It does not name an alternative profile tool or state when not to call it, but the prerequisite framing is strong.

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 destructive/non-idempotent/open-world, but the description adds substantial context: real-money with no confirmation phrase, server re-quotes at execution so fill can move within slippage, and the fund output always returns to the same wallet. These are behavioral facts the agent cannot infer from the schema.

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?

Dense but front-loaded: the budget/real-money warning leads, followed by routing, use-case, exclusions, quote-first workflow, execution nuance, and verification. Every sentence carries actionable 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 money-moving tool with no output schema, the description covers the full burden: cost, routing, safety gating, quote-first workflow, execution re-quote, unit format, and a verification path via `app_wallet`. Nothing needed to invoke it correctly is missing.

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 restates that amounts are RAW base units as a string, which the schema already covers, and adds only the slippage re-quote context — marginal value beyond the structured fields.

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 and resource ('swap one token for another out of the app wallet') and immediately names the routing (Jupiter), the signing model (server-side), and where funds land (same app wallet). This cleanly separates it from siblings like swap_quote, deposit, and app_wallet_withdraw.

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?

Explicitly says when to use it ('whenever the user holds the wrong token'), names the negative case ('does NOT deposit into a fund (`deposit`)'), and mandates the quote-first flow with `swap_quote`. It even adds a safety rule about never acting on read text versus user instruction.

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 establish read-only, idempotent, non-destructive behavior, but the description adds what they cannot: that the quote already includes the DFM platform fee, that `outAmount` is therefore the net amount the user receives, and the explicit instruction not to subtract a fee again. That is real downstream behavioral context an agent would otherwise get wrong.

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?

Roughly four dense sentences with the read-only declaration and the core purpose front-loaded. Every sentence carries actionable information: fee semantics, amount encoding, sequencing with `swap`, and the `deposit` exclusion. 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?

There is no output schema, so the description must explain returns, and it does by defining `outAmount` semantics and the platform-fee inclusion. Combined with the sibling exclusions and sequencing guidance, an agent has everything needed to call this correctly and interpret the result.

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 goes beyond the schema by justifying the string type for amounts ('a u64 does not fit a JS number') and reinforcing the RAW base-unit convention for `amountRaw`, which reduces the most common input error for this tool.

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 action and resource: 'Price a swap of one token for another out of the app wallet, routed by Jupiter.' It is immediately distinguishable from the sibling `swap` (which executes) and `deposit` (which funds), and the leading 'READ-ONLY' makes the distinction from `swap` 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?

Explicitly prescribes the workflow: 'Use this before `swap` so the human sees the rate first.' It also names the exclusion and the correct alternative: 'For DEPOSITING into a fund use `deposit`, not this.' Both when-to-use and when-not-to-use are covered with named siblings.

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 and openWorldHint, so safety is partly covered, but the description adds genuinely new context: the bio is third-party untrusted text and instructions inside it must not be followed. That prompt-injection warning is valuable and not derivable from the structured fields.

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?

Two sentences, no filler. The resource and lookup keys are front-loaded, and the security caveat follows in a single tight clause. Every phrase earns its place.

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?

With no output schema, the description takes on the job of describing returns and does so by listing the profile fields. Combined with the readOnly/openWorld annotations, an agent has enough to call it correctly; only the both-keys-supplied edge case and required-ness remain unaddressed.

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 0%, so the schema alone (bare 'wallet'/'username' strings, both optional) leaves semantics unstated. The description partly compensates by framing them as alternative lookup keys, but it never clarifies precedence when both are supplied, whether one is required, or accepted formats like the '@' prefix.

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 resource ('A trader's public profile') with an explicit 'by wallet or @username' selector and enumerates the returned fields (display name, bio, funds created, TVL managed). This clearly separates it from write-oriented siblings like follow_trader and set_profile, though it never names an alternative tool directly.

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 lookup key ('by wallet or @username') implies how to call it and when it applies, but there is no explicit when-to-use vs an alternative, no statement of prerequisite conditions, and no exclusion guidance. Usage is implied rather than spelled out.

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 contradicts the destructiveHint=true annotation by asserting the tool never transfers anything and always refuses. The disclosure is genuinely useful (it saves the agent a dead call), but it directly negates the annotation's behavioral claim, so credit is heavily reduced per the contradiction rule.

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?

Two short sentences, front-loaded with the key fact (NOT AVAILABLE) before the rationale and the workaround. Every sentence earns its place 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 stub tool with no output schema, the description covers what happens on call and where to go instead, which is what an agent needs. It is slightly under-complete only because it leaves the parameter set entirely unaddressed and conflicts with the annotation metadata.

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 only 33% (only confirmPhrase is documented in-schema), so the description would need to compensate for vault and newAdmin. It says nothing about any parameter, leaving both required fields' semantics unexplained beyond their regex patterns.

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 specific verb+resource (admin transfer) and immediately clarifies the tool's actual behavior: it is not available and always refuses. An agent can tell exactly what this tool does and does not do without opening the schema.

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 gives an explicit when-not-to-use ('NOT AVAILABLE YET... always refuses; no control is transferred') and names the alternative ('Do it in the app'). Nothing is left to inference about whether to invoke 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?

Annotations declare readOnlyHint=false, openWorldHint=true, and idempotentHint=true. The description adds meaningful extra safety context beyond those annotations by clarifying that the operation 'moves no funds,' reducing ambiguity about whether unfollowing has financial 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?

Two short sentences with no wasted words. The core action is front-loaded, and the safety clarification follows immediately.

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 simple one-parameter tool with no output schema, the description plus annotations cover the essential action and side-effect profile. A mention of authentication or wallet-connection prerequisites would make it fully complete, but the current definition is adequate.

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 0% for the single required parameter, so the description must add meaning. 'By wallet address' clarifies that the wallet parameter is an address rather than a username or identifier, which is useful beyond the bare string 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?

States a specific verb and resource: 'Stop following a trader by wallet address.' The action is immediately distinguishable from sibling follow_trader, which performs the inverse. 'Moves no funds' further sharpens what the tool is not for.

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?

Usage is implied: call this to stop following a trader you currently follow. However, there is no explicit when-to-use guidance, no prerequisites such as requiring an existing follow, and no mention of follow_trader as the alternative action.

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 cover destructive/openWorld/non-idempotent, and the description adds substantial context beyond them: REAL-MONEY gated, ADMIN-only authorization, full-replacement semantics, and the staged removal procedure with an off-ramp to another tool. It discloses the key destruction behavior (complete replacement, not a trade) that annotations alone do not convey.

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?

Critical gating and replacement semantics are front-loaded, and the sentences are dense but each earns its place (constraints, removal procedure, mode parity). The multi-step drain sequence is somewhat lengthy but operationally necessary, so it stays efficient overall.

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 mutation with no output schema, it covers authorization, constraints, replacement semantics, and the removal workflow. It omits any note on the confirmPhrase gating and returns/verification behavior, but the schema handles confirmPhrase, so the gap is minor.

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 33% and only confirmPhrase is documented, so the description usefully compensates by defining the `assets` item shape plus constraints the schema does not enforce (sum to exactly 10000, no duplicates, 2-10 assets). The `vault` parameter itself is left undescribed, keeping it short of a 5.

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: it replaces the COMPLETE target configuration of a vault basket, and explicitly negates trading ('this does not trade'), which cleanly separates it from the sibling rebalance_to_targets. An agent can distinguish it without opening any schema.

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?

Spells out the precondition (MANAGER action, only on a vault your app wallet ADMINS) and gives an explicit when-not/alternative workflow: to remove a funded mint, keep it at 0%, call rebalance_to_targets, verify empty, then call this tool to drop it. This is exactly the routing information an agent needs.

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 only say the call is non-read-only, destructive, non-idempotent and open-world; the description adds far more: human-only authorization, the DFM_MCP_CONFIRM_REQUIRED gate, local vs keyless signing paths, post-write chain re-read and reconciliation, and the restricted meaning of landedSignature. It also discloses that the operation is a create-or-propose/accept transaction flow, which is exactly the kind of behavior an agent needs before invoking a destructive tool.

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 warning marker and human-only constraint are front-loaded, and every subsequent clause carries operational information rather than filler. It is dense but justified for a 13-parameter destructive tool, though the mode/retry sentences could be split for faster scanning.

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?

With 13 parameters, 11 required, no output schema, and no enums, the description covers the authorization model, both signing modes, constraint-zero semantics, the maxAssets cap, and post-write reconciliation. Remaining gaps are the meaning of assetMode values and what the caller receives on success, but the core calling contract is complete.

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 only 8% (one of 13 params documented), so the description must compensate and largely does: it explains that 0 disables min/max/interval/blackout constraints, that 0 on the daily/weekly rebalance cap selects the protocol default, and that maxAssets is capped at 10. It does not explain assetMode's 0-3 meaning or the BPS scale, leaving some gaps.

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 first sentence names a specific verb pair ('Create or amend') and resource ('onchain policy for a vault administered by the signing wallet'), which cleanly separates it from the sibling update_vault_assets (assets, not policy) and launch_vault (creation, not amendment). An agent can identify the operation without opening the schema.

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 states a hard precondition ('The human must explicitly ask for this') and the conditional confirm-phrase requirement, plus an explicit when-NOT clause for `landedSignature` ('retries reconciliation only and never emits another policy transaction'). It does not name alternative siblings such as update_vault_assets, so it falls just short of 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 declare readOnlyHint=true and openWorldHint=true, and the description adds useful detail by listing what is reported (wallet types, API base URL + cluster, real-money write-path status). It does not discuss auth requirements, failure modes, or rate limits, but for a no-side-effect diagnostic with annotations covering safety, this is solid added context.

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?

Two sentences: the first front-loads the report contents, the second delivers the usage instruction. No filler, no repetition, well structured for scanning.

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?

With no input parameters and no output schema, the description must carry the burden of explaining what comes back, and it does so precisely by listing the returned fields. Nothing an agent needs in order to invoke this diagnostic correctly is missing.

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 tool takes zero parameters, and the schema coverage is 100%, so there are no parameter semantics for the description to explain. Baseline 4 is appropriate for a no-param tool.

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 specific verb (Report) and enumerates the exact resources returned: profile, acting wallet, portfolio/app wallet, sign-in/funding wallet, API base URL + cluster, and write-path status. This is far more specific than a generic identity tool, but it does not explicitly name or exclude close siblings like trader_profile or app_wallet, leaving slight ambiguity about overlap.

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 phrase 'Call this first to confirm the agent is wired correctly' gives clear, actionable when-to-use guidance suitable for an initialization/health-check tool. It does not, however, mention alternatives or when not to call it, so it stops short of full routing 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?

Annotations only declare the generic safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true); the description adds real behavioral context: it is a REAL-MONEY gated action, the destination is resolved server-side so the caller controls WHAT but never WHERE, and an unheld mint errors rather than no-oping. That is substantial value beyond the structured fields.

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?

It is front-loaded with the most important constraint ('REAL-MONEY (gated)') and every sentence carries information, but several clauses are stacked with parentheticals and em-dashes, making it denser than it needs to be for quick scanning.

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 3-parameter, non-idempotent mutation tool with no output schema, the description covers what moves, the server-side destination resolution, amount semantics, the pre-read step, and the error behavior. Nothing an agent needs to invoke it correctly is missing.

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 only 33%, so the description must compensate, and it does: `mint` should come from list_app_wallet_assets, and `amount` is explicitly in RAW base units with a concrete rationale ('a 9-decimal token does not survive a UI float') and the omit-to-send-all default. Both undocumented-in-schema parameters gain precise meaning.

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 specific verb and resource ('Send ONE mint from the app wallet to the owner's saved withdrawal wallet') and explicitly distinguishes itself from app_wallet_withdraw by noting that tool 'sweeps only USDC + SOL.' An agent can tell exactly what moves and where it goes without opening any schema.

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 states when this tool is the right choice (fund shares, which app_wallet_withdraw cannot move), the prerequisite step ('Read the mint and balance from list_app_wallet_assets first'), and the failure mode for a mint not held ('an error, not a no-op'). Alternatives and preconditions are both named.

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, so the safety profile is covered. The description adds content scope (total plus four XP kinds, and the leaderboard) and hints the leaderboard is truncated to its 'top', but says nothing about auth requirements, whether the leaderboard is global or personal, or rate limits.

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 sentence with the resource front-loaded and the breakdown parenthetically scoped. No filler, 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 zero-parameter read tool with annotations covering safety and no output schema, the description does the essential job of stating what content is returned. The only real gap is that the 'top of the leaderboard' scope is left undefined.

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 tool takes zero parameters, so there is nothing for the description to clarify and the baseline is 4. No parameter confusion is possible.

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 names the specific resource (the user's XP) and enumerates the breakdown (deposit, launch, profile, referral) plus the leaderboard, so an agent knows exactly what data comes back. The verb is implicit rather than stated, and it doesn't explicitly distinguish itself from siblings, but the resource is unique enough among the vault/wallet/trading tools to avoid confusion.

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 when-to-use guidance, no prerequisites, and no mention of alternatives or related tools. An agent must infer that this is the way to check XP, with no routing help at all.

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 and openWorldHint, so the safety profile is covered, and the description adds real context: null when nothing is open, what fields are shown (mode, crank progress, readyToClose, expiry, failure reasons), and explicit auth/ownership behavior ('external keypair does not change escrow ownership', 'AUTH never permits an unrelated wallet').

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?

Front-loaded with verb, resource and route, then value details, then edge-case/auth notes. Dense with little waste, though the two trailing auth sentences add length that only marginally aids invocation.

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?

With no output schema, the description compensates by enumerating the returned fields and the null case, plus auth constraints. It is sufficiently complete for a read-only status tool, leaving only minor gaps like pagination (not applicable) or error behavior.

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 0%, so the description must carry param meaning, and it does explain the optional `user` parameter's semantics (omit to inspect the app wallet) beyond the schema merely marking it non-required. `vault` is only implied via the route, keeping it short of a perfect 5.

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?

Specific verb (Get) plus resource (decoded zap-v2 escrow) plus scope (vault, user), with the concrete API route. An agent can distinguish it from zap_v2_cancel and zap_v2_update_envelope without inspecting schemas.

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?

Gives clear context for the primary call and a notable usage variant (omit `user` to inspect the assigned app wallet, including existing escrows after revoke). It does not name alternative tools or explicitly state when-not-to-use, but the usage is unambiguous for this read operation.

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?

Adds meaningful context beyond annotations: 'REAL-MONEY (gated)', returns are 'as-is (no swaps, no oracle)', the escrow is closed, and authority depends on owner vs. post-expiry. This supplements destructiveHint, idempotentHint=false, and openWorldHint with concrete operational details about what is destroyed and who may invoke it.

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?

Four sentences, front-loaded with the gated real-money warning and the core action. Every sentence earns its place by covering purpose, safety context, authority, and return values without repetition or 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?

Given a destructive, real-money, gated operation with no output schema, the description covers what the tool does, when to use it, who can call it, what happens to the escrow, and what is returned (held balances + cancel signature). The only gap is parameter explanation, which is isolated to parameter semantics and does not undermine overall 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?

The description does not mention either parameter name or add meaning beyond the input schema. Schema coverage is 50% (vault has no description), and the required vault parameter is left undocumented by both description and schema, so the description fails to compensate for the coverage gap.

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 action (return balances, close escrow) on a specific resource (stalled zap-v2 escrow), with clear outcome. Distinguishes from siblings by framing the use case as the recovery path when a deposit/redeem is stuck, so an agent can tell it apart from deposit, redeem, or zap_v2_update_envelope.

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?

Explicitly says when to use it: 'when a deposit/redeem is stuck and you just want your funds back.' Also gives permission timing: 'Owner anytime; anyone after expiry.' No alternative tools are named and no when-not conditions are stated, which keeps it from 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 declare destructiveHint=true and non-idempotent, and the description adds context beyond them: real-money gating, that the tool reads live pinned minOuts rather than accepting absolute values, the monotonic onchain clamping rule for newSlippageBps, and the human-confirmation gate. This is high-value behavioral disclosure.

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?

Front-loaded with the risk warning and the core verb, and nearly every sentence adds operational information. Density is high and reads slightly like jargon-dense shorthand, but there is little waste.

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, non-idempotent mutation with no output schema, the description covers return content ('the exact loosening applied (old→new)'), the gating model, and the failure fallback. It does not describe side effects on the escrow beyond floors or any post-condition guarantees, which is a modest remaining 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 only 20%, so the description must compensate, and it largely does: it explains loosenPct semantics (relative relaxation, default 5), extendSecs (optional expiry extension), and the newSlippageBps clamp floor/ceiling. The upper/lower bounds it repeats for loosenPct and newSlippageBps already exist in the schema, and vault is left unexplained, so it falls short of full compensation.

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 (LOOSEN) and resource (per-leg min-out floors on a zap-v2 escrow), plus the triggering condition (stuck mid-crank escrow). An agent can distinguish it from zap_v2_cancel and the swap/deposit siblings without opening a schema.

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?

Gives explicit when-to-use ('so a stuck mid-crank escrow can finish'), a precondition ('REAL-MONEY (gated)'), and names the fallback route ('If it still will not fill, cancel'), which maps to the zap_v2_cancel sibling. Nothing is left to inference.

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