AssetFare USDC Bridge

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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true). The description adds genuine value beyond them by clarifying that no transaction is created and that the call consumes a single caller session slot — a non-obvious side effect and resource constraint. It omits auth requirements and idempotency-key behavior, so not 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?

Two tight sentences, zero filler, with the core action front-loaded before the constraint caveat. Nothing 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?

For a five-required-parameter, write-adjacent tool with 0% schema coverage and no output schema, the description leaves the inputs undocumented (access_token, idempotency_key, wallet roles). It explains the effect and slot limit but not enough for an agent to populate the call 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% across five required parameters. The description weakly implies quote_id and wallet parameters ('fresh quote', 'wallet-bound') but says nothing about access_token, idempotency_key, or the source/destination distinction, so it largely 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 verb and resource ('lock a fresh quote into a wallet-bound execution session') that clearly distinguishes it from read_session. However, it never names a sibling or explicitly contrasts with the read/prepare/observe family, so the agent must infer the boundary.

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 'reserves the caller's one active session slot' implies this precedes execution, giving implied usage context. But there is no explicit when-to-use/when-not guidance and no reference to when read_session or the prepare_* tools should be chosen instead.

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, idempotentHint=false, openWorldHint=true, so the non-read, non-idempotent nature is known. The description goes beyond them by disclosing that caller approval is required and that the returned token is sensitive, which is meaningful operational context. It stops short of describing token lifetime or what happens to the challenge after verification.

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 no filler; the core action is front-loaded and the approval/sensitivity caveat follows immediately. 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 and 0% parameter coverage, the description is the only documentation an agent gets, yet it omits all four parameter meanings and the sequencing relative to start_wallet_auth. For a token-minting, security-sensitive tool this leaves important gaps.

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% across all four required parameters (challenge_id, source_wallet, signature, terms_version), so the description carries the full explanatory burden. It only vaguely gestures at 'challenge message' and 'wallet signature' and never explains terms_version or the id/wallet fields, leaving the agent to infer formats and relationships.

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 ('Verify a wallet signature... return a wallet-bound access token'), so an agent can tell it is the second step of a wallet auth flow. It does not, however, name or distinguish itself from the sibling assetfare_start_wallet_auth, which is the obvious alternative an agent must choose between.

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 only implied: 'over the exact challenge message' hints that a challenge must already exist (i.e. start_wallet_auth ran first), but the description never states when to call this versus the start/read/verify siblings or what prerequisites must hold. It adds a single useful note ('Requires caller approval') but no explicit when-to-use routing.

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, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds one genuine behavioral fact beyond them: the manifest is Ed25519-signed, which tells the agent the payload is cryptographically verifiable. It says nothing about return shape, size, or whether any prior session/auth is required.

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 front-loaded sentence with no filler, boilerplate, or repetition of the tool name. Every clause (signature scheme, content categories) carries 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 zero-parameter read with rich annotations and no output schema, the description is adequate but thin: it does not say what a caller should do with the manifest, whether auth/session state is needed, or how this fits among the session-based siblings. The absence of an output schema means some return-value context would have helped.

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 by the rubric the baseline is 4. The description correctly implies a parameterless global read, and there is nothing further it could usefully say about inputs.

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 (Read) and a specific resource (manifest), then qualifies it with the manifest's content domains (capability, contract, release, mainnet-evidence) and its signature scheme (Ed25519). No sibling tool covers a manifest read, so it is distinguishable, but the description never explicitly contrasts itself with the assetfare_status or assetfare_read_session siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to call this rather than assetfare_status, assetfare_read_session, or the observe_* tools, nor any prerequisite (e.g. session establishment). Usage is only weakly implied by the verb 'Read'.

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, idempotentHint=true, and destructiveHint=false. The description adds that it is 'Read-only on chain, but advances the session record,' which explains the side effect on the session and clarifies the scope of read-only behavior. This is a valuable disclosure beyond the annotations, and it does not contradict 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?

The description is a single, dense sentence that front-loads the core action and scoping condition. Every word contributes to meaning, with 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?

For a 4-param tool with no output schema and no param descriptions, the description is insufficient. It lacks explanation of parameters, expected response, prerequisites (e.g., an existing session), and how it fits into the overall flow. The description does not provide enough for an agent to call the tool confidently without external knowledge.

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 four required parameters. The description only hints at 'burn_signature' (via 'already-submitted burn') and 'session_id' (via 'session record'), but does not explain access_token or idempotency_key at all. It fails to compensate for the missing schema documentation, leaving agents to guess parameter meanings.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Verify') and names precise resources ('Circle attestation', 'forwarded Base or Arbitrum USDC mint'), and scopes it to 'an already-submitted burn.' This distinguishes it from siblings like assetfare_verify_source_receipt or assetfare_observe_destination by focusing on the CCTP mint after a burn.

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 implies usage after a burn has been submitted ('for an already-submitted burn'), giving a clear precondition. However, it does not explicitly state when to prefer this over sibling tools (e.g., assetfare_observe_destination) or what alternatives exist, leaving some ambiguity.

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 idempotentHint=true, destructiveHint=false and openWorldHint=true, and the description reinforces this with 'never submits a transaction' — valuable confirmation for a tool whose readOnlyHint is false (it mutates workflow state). The 'requires caller approval' note adds an auth precondition the annotations do not convey. It does not describe rate limits, failure modes, or what state change 'finalize' performs.

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, zero filler, with the core action front-loaded and the safety caveat second. Nothing repeats the name or title.

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 four required, undocumented parameters, no output schema, and a state-mutating 'finalize' step, the description omits the essentials an agent needs: parameter intent, what finalization produces, and what happens on a verification failure. Purpose and safety are covered, but the operational contract is not.

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?

None of the four required parameters (access_token, session_id, transaction_hash, idempotency_key) are mentioned, and schema description coverage is 0% — the schema supplies only format/pattern constraints, not meaning. For example, the agent gets no hint of how transaction_hash relates to the receipt being verified or whether idempotency_key must be reused across retries.

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 ('Verify an already-submitted destination UserOperation receipt') plus the workflow outcome ('finalize the workflow'). The word 'destination' cleanly separates it from the sibling assetfare_verify_source_receipt, so an agent can route between them without opening either 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?

Positions the tool clearly in the workflow: it is used on an already-submitted receipt to finish the flow, and it explicitly notes caller approval is required. It does not name an alternative tool or state what to do if the receipt is not yet submitted, so it stops short of 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?

Annotations already cover safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true). The description usefully adds 'never signs or submits' – clarifying the boundary of what the tool does versus a submit step. Beyond that it adds little about idempotency semantics, retry behavior, or what the returned unsigned action contains.

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 compact sentences, front-loaded with the verb and resource, followed by the non-signing constraint. No wasted text.

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 4-required-param unsigned-action tool with 0% schema coverage, no output schema, and no annotations explaining param contracts, the description leaves too much unspecified – parameter contracts and sequencing relative to siblings are 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 0% and the four required parameters (access_token, session_id, event_signer_public, idempotency_key) carry no per-field documentation. The description mentions only event_signer_public being caller-generated; access_token, session_id, and idempotency_key remain undocumented in both schema and description, so it 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 verb (prepare) and resource (CCTP burn action) with the defining qualifier 'unsigned'. It is distinguishable from siblings like prepare_source_action and prepare_destination_action only by the 'CCTP burn' wording; no explicit contrast is drawn.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description gives no when-to-use guidance relative to the many prepare/observe siblings. It notes a precondition ('requires caller approval') but not the conditions selecting this tool over prepare_source_action or prepare_destination_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 declare non-destructive, idempotent, open-world, and not read-only, and the description adds the crucial behavioral fact that it never signs or submits and needs caller approval. That clarifies the prepare-only boundary beyond what the structured hints convey, though it says nothing about failure modes, expiry, 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?

Two short sentences, front-loaded with the deliverable and followed immediately by the safety boundary. No filler or 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 write-adjacent preparation tool with no output schema and no parameter documentation, the description covers the safety posture and the resulting artifact but omits prerequisites, ordering relative to the source step, and the meaning of the three required inputs. Adequate but with clear gaps.

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 description explains none of the three required parameters (access_token, session_id, idempotency_key). Names are largely self-explanatory, but with zero schema documentation the description should have compensated for formats or reuse expectations and does not.

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 ('Prepare') and two concrete artifacts: an exact-cap permit and an unsigned ERC-4337 destination settlement plan. It is clearly distinguishable from the source-side and CCTP siblings by the 'destination' scope, though it relies on domain jargon an agent may not resolve without other tool 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?

It states a constraint ('requires caller approval') but never says when to call this versus assetfare_prepare_source_action or assetfare_prepare_cctp_action, nor the ordering between them. There is no explicit when-to-use or when-not-to-use guidance.

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

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

Annotations cover the safety profile (readOnly=false, idempotent=true, destructive=false), so the bar is lower, yet the description still adds real context beyond them: the artifact is 'unsigned', it 'never signs or submits', and caller approval is required. That clarifies the human-in-the-loop boundary, which 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?

Two compact sentences with no filler; the core capability is front-loaded and the safety constraint 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?

There is no output schema, so return values need not be explained, but with both parameters undocumented and no link to the prepare/verify sibling workflow, the definition is only minimally complete. The safety disclosure is the strongest part; the operational context around it is thin.

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 description says nothing about either parameter. An agent gets no hint that session_id is a UUID session handle or that access_token is an auth credential, 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?

Specific verb ('Prepare') plus a qualified resource ('bounded unsigned Solana source action'), which implicitly distinguishes it from the destination and CCTP siblings via the word 'source'. It stops short of naming any sibling explicitly, so an agent must still infer the routing.

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 only process guidance is 'Requires caller approval', which is a precondition rather than a when-to-use rule. Nothing states when to choose this over assetfare_prepare_destination_action or assetfare_prepare_cctp_action, nor what must exist beforehand (e.g., an active session).

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 read-only, idempotent, and non-destructive behavior. The description adds meaningful context beyond those hints by flagging legacy status, the restricted corridor, and the wallet-auth/session prerequisite, which are not present in the annotations.

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

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

Two sentences, front-loaded with the key scoping fact ('Legacy v1 original-corridor'), and no filler. Every clause contributes either scope or routing guidance.

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 read-only quote tool with strong annotations, the description provides the corridor, workflow restriction, and v2 routing alternative. The main gap is that no output schema exists and the description does not hint at the returned quote shape, but this is minor for a generic quote 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 0%, so the description needed to compensate by explaining amount_usd and destination_chain. It only indirectly hints at destination_chain via 'Base or Arbitrum ETH' and never clarifies the meaning or scope of amount_usd.

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 identifies the exact purpose: a legacy v1 quote for Solana SOL to Base or Arbitrum ETH. It also distinguishes itself from assetfare_v2_quote, so an agent can select the right sibling without opening 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?

It explicitly states when to use the tool ('only with the legacy wallet-auth/session workflow') and when not to ('prefer assetfare_v2_quote for new evaluations'). This is clear routing guidance with no ambiguity about alternatives.

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 fully covered structurally. The description's 'Read-only' sentence merely restates readOnlyHint and adds 'wallet-bound' as the only new behavioral context; nothing about auth expectations 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 short, front-loaded sentences with no filler; the operation and its read-only nature appear immediately. The closing 'Read-only' is redundant with annotations but costs little.

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, three undocumented parameters, and multiple view modes, the description should explain what each view returns and how session_id/access_token are obtained. It leaves the agent unable to predict the response shape for any view.

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 burden, yet access_token and session_id are entirely unexplained (no format, provenance, or scope). Only the view enum is partially mirrored via the listed targets, and even then the 'next_action' default semantics are not tied to the enum.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Read a wallet-bound session/workflow/receipt/action') and the view targets map onto the enum options. It distinguishes itself from write-oriented siblings (create_session, prepare_*), though it doesn't name any sibling 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?

No guidance on when to choose this over siblings like assetfare_status or assetfare_manifest, nor any prerequisites beyond an implied token requirement. The description never explains what selects each 'view' target.

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, non-idempotent and openWorld, so the agent knows this mutates external state; the description adds value beyond that by clarifying the mutation is only a short-lived login challenge, cannot move funds, and requires caller approval. That directly defuses the risk implied by readOnlyHint=false and destructiveHint=false. It does not state challenge TTL or replay characteristics.

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, and the core action plus its safety profile are front-loaded before the approval caveat. 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?

For a single-parameter, no-output-schema auth trigger, the description covers the action, the safety profile, and the consent requirement well. The remaining gap is the undocumented source_wallet parameter and the absence of any statement about what the challenge response contains or how it feeds into finish_wallet_auth.

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?

There is one required parameter (source_wallet) with 0% schema description coverage and only min/max length constraints, so the description carries the full documentation burden — yet it never mentions the parameter. The agent gets no hint that this is a base58 Solana public key, who the wallet belongs to, or whether it must match a session.

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 non-transactional Solana signMessage challenge', and immediately scopes it as a short-lived login challenge, so the agent knows this is an auth-start operation rather than a transaction. It does not explicitly name the paired sibling finish_wallet_auth, so sibling routing rests on name similarity alone.

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: this is the entry point for a wallet login challenge, and 'Requires caller approval' signals the flow stops for user consent. However, there is no explicit when-to-use statement, no prerequisite (e.g. must be followed by finish_wallet_auth), and no exclusions relative to siblings like assetfare_create_session.

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, idempotentHint, destructiveHint false). The description adds contextual scope about legacy v1 compatibility and safety gates, but does not describe return shape, potential staleness, or any runtime behavior beyond the annotation-backed read-only nature.

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, with the core read purpose front-loaded and the sibling routing instruction in the second sentence. Every word earns its place; there is no fluff or repetition of schema fields.

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

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

For a parameterless, read-only status tool with annotations covering safety and an explicit alternative given, the description is complete. An agent can invoke it correctly without needing additional context about inputs.

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 has zero parameters, so no parameter explanation is needed. The empty schema provides full coverage, and the description appropriately omits parameter details that would be meaningless here.

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 opens with 'Read legacy v1 compatibility status and original-corridor safety gates,' giving a specific verb, resource, and scope. It distinguishes itself from assetfare_v2_capabilities by explicitly stating that the primary source quote/execution surface belongs to that sibling.

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 clearly states when to use this tool: to read compatibility status and safety gates. It also names the alternative, assetfare_v2_capabilities, and its broader purpose, giving an agent explicit 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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool's safety profile is well established. The description adds useful context by specifying 'no-sign/no-submit boundary' and 'live availability', which explains that this is a read-only informational endpoint. However, this is largely consistent with the read-only annotation, and the description does not disclose additional behavioral traits such as rate limits or response structure, so a 3 is appropriate given the annotation coverage.

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

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

The description is two sentences and front-loads the key capability in the first clause. It includes a dense list of route details that may be more than necessary, but each part conveys meaningful information about the tool's scope. It is suitably concise without sacrificing specificity, though it could be slightly tightened by moving route counts to an example or return value.

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

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

Given the tool has no parameters, no output schema, and read-only annotations, the description sufficiently explains what information the tool returns: live availability, fee model, and the no-sign/no-submit boundary. An agent can confidently invoke this tool knowing it is a pre-quote capabilities lookup. The only minor gap is that it does not explicitly state the response format, but for a capabilities endpoint the description is complete enough.

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 has zero parameters and the schema is an empty object, so there are no parameter semantics to clarify. The description instead explains the data the tool exposes (routes, fees, boundary), which is the closest equivalent to parameter semantics for a no-parameter tool. This earns the baseline of 4 for zero-parameter tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('Read') and resource: cross-chain bridge and swap capabilities, live availability, fee model, and the no-sign/no-submit boundary. It is differentiated from the quoting flow by the phrase 'before quoting' and from other tools by naming exact routes and fee components. This is not a tautology and gives an agent a precise idea of what the tool offers.

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 explicitly instructs to use this tool 'before quoting', which establishes a clear temporal context relative to the quote tool. It does not explicitly name alternatives or exclusions, but the 'before quoting' guidance is a concrete usage signal that helps an agent decide when to call this capability endpoint.

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 annotations (readOnlyHint=true, destructiveHint=false), the description discloses the non-network, local-only behavior and that each call yields a fresh CSPRNG token — consistent with idempotentHint=false. It adds security-handling guidance (sensitive capability, never a private key). The description enriches the annotation profile without contradicting 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?

Three dense sentences, each earning its place: generation spec, no-network guarantee, then storage and downstream use. The only waste is mild redundancy between 'Local-only' and 'Makes NO network call'. The primary purpose is front-loaded.

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 carries the full burden of explaining the return value — it specifies entropy, length, and URL-safety — and the downstream consumption chain (session create/read/observe/refresh). For a 0-param, 0-output-schema tool, everything an agent needs to call it and handle its result is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema is empty (0 properties, additionalProperties false), so schema coverage is trivially 100% and the baseline is 4. The description adds value by characterizing the tool's only output surface — token entropy, length, and character set — which is as much semantic meaning as a zero-parameter generator can convey.

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 opens with a specific verb+resource ('generate one caller-owned high-entropy session capability token') and pins down concrete constraints (>=256-bit CSPRNG, url-safe, 43-128 chars, local-only). This cleanly separates it from siblings like assetfare_v2_session_create (which consumes the token) and assetfare_v2_capabilities (capability management).

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 explicit workflow guidance: the generated token must be passed into assetfare_v2_session_create and every session read/observe/refresh operation, and stored as a SENSITIVE capability (never a private key). It stops short of naming a when-not-to-use alternative, but the storage and downstream-passing instructions make the invocation context clear.

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, the description discloses critical behaviors: AssetFare never signs or submits, the tool returns an unsigned event-account transaction that the caller must co-sign, and it is a one-shot operation. These details are non-obvious and valuable, and they do not contradict the annotations.

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

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

The description is dense but every sentence serves a purpose. It front-loads the core action and then delivers the Solana-specific signing requirement in a structured way. No filler or redundant information is present.

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?

The description covers the overall flow, approval guardrail, and Solana CCTP signing requirement well, especially given there is no output schema. However, it omits details about what the response contains and does not explain the semantic of the wallets map, leaving some ambiguity for a complex 8-parameter 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?

The description provides crucial guidance for event_signer_public, including generating a fresh ephemeral keypair, passing only the public key, and co-signing the returned transaction. However, with only 13% schema description coverage, other parameters like the wallets object and amount_usd rely on names and enums, which may leave meaning ambiguous for an agent.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool performs a caller-approved one-shot POST /v2/prepare for a route the live quote reports available, which is a specific verb, resource, and scope. It also differentiates itself by noting 'Never auto-called', which distinguishes it from session/observe tools, though it does not explicitly name a sibling tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context: use it after a live quote reports a route available and only with explicit caller approval. The 'Never auto-called' statement is also a strong exclusionary guideline. It does not explicitly list alternatives, but the conditions for appropriate use are unambiguous.

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 explicitly stating the tool 'never signs, submits, authenticates, creates a session, or prepares an action' and that it returns a 'caller-approved unsigned-action handoff'. This substantially clarifies the tool's safety boundaries and output nature.

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 with no filler: action is front-loaded, route scope is concrete, fee caveat is actionable, and behavioral boundaries are clear. 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 tool with no output schema and a complex sibling ecosystem, the description gives route examples, fee caveats, return-handoff semantics, and explicit non-behaviors. It does not detail the quote response structure, but it provides enough context for correct invocation and interpretation.

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 compensate. It provides route examples that map to from_chain/from_token/to_chain/to_token and mentions total token-path cost, but does not explicitly explain each parameter or the amount_usd field. Parameter names and enums are self-explanatory, giving 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?

Description uses a specific verb ('Get') and resource ('AssetFare cross-chain bridge/swap quote') and scopes it to 'any of 76 routes' with concrete examples. It clearly differentiates itself from session, auth, prepare, and observe siblings by stating what the quote call does not do.

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 for when to use this tool: for obtaining a fresh route quote and judging by total cost and live availability rather than the 1bp fee alone. It does not explicitly name alternative sibling tools or state exclusions, but the context is sufficient for selection.

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, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds meaningful behavioral context beyond annotations: it discloses that the tool requires caller approval, that it never auto-chains/signs/submits, and that the private key stays client-side. It does not contradict annotations. It could add more about what the response contains or what side effects occur, but the description's explicit non-behaviors are valuable.

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

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

The description is three sentences, each earning its place: the first states the tool's core purpose, the second explains the critical Solana-CCTP requirement, and the third states exclusions. It is front-loaded with the primary purpose. Slightly dense but not bloated.

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 10-parameter tool with no output schema, the description covers the most critical behavioral context: caller approval, ephemeral keypair handling, and non-chaining behavior. It does not describe the return value or what happens after creation, but the sibling tools (assetfare_v2_session_get, assetfare_v2_session_observe_output) suggest the follow-up flow is handled elsewhere. The description is complete enough for an agent to call it correctly without opening 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 description coverage is only 10%, so the description must compensate. It does: it explains the event_signer_public parameter's purpose and security model, and it clarifies the session_token requirement. However, it does not explain the wallets map, idempotency_key, or amount_usd semantics beyond what the schema provides. The description adds meaning for the most complex parameter (event_signer_public) but leaves other parameters to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('create'), a specific resource ('/v2/session'), and a distinctive qualifier ('Explicit caller-approved receipt-driven'). It also names the sibling it is not ('Never auto-chains, signs, or submits'), which distinguishes it from other session tools in the sibling list. The name alone is ambiguous, but the description resolves it.

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 explicitly states when this tool is appropriate: caller-approved, receipt-driven session creation. It names the Solana-CCTP route requirement (event_signer_public from a fresh ephemeral keypair) and the session capability token requirement. It also states what it does NOT do ('Never auto-chains, signs, or submits'), which implicitly routes the agent to sibling tools for those behaviors. This is strong usage 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 already mark it read-only, idempotent, and non-destructive; the description adds that it never signs or submits and requires the caller's session capability token, which is useful auth context. It does not over-promise side effects or contradict annotations.

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

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

Two short sentences front-load the action ('Read a v2 session's current workflow state...'), then add the auth requirement and safety guarantee. No filler or redundant restatement.

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 read-only tool with annotations covering the safety profile, the description names the returned content (workflow state, unsigned action) and the required precondition (session capability token). It doesn't describe the output shape or how to obtain/refresh the token, but the absent output schema and low parameter count keep this from being a major 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 coverage is 0%, and the description compensates only partly: it identifies session_token as the caller's session capability token, but it does not explain session_id's role or where the token comes from. The UUID format for session_id is left entirely to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the verb 'Read' and names a specific resource: 'a v2 session's current workflow state and current unsigned action.' The 'v2' qualifier and 'read-only; never signs or submits' help separate it from prepare/submit/observe siblings, though it does not explicitly name a sibling such as assetfare_read_session.

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 implies use for inspecting a v2 session's state before signing or submitting and states the precondition of a session capability token. However, it gives no explicit when-to-use/when-not-to-use guidance or named alternative, so selection still relies on 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?

The description adds valuable behavioral context beyond the annotations: it explicitly states 'Never submits a transaction', notes the requirement for the caller's session capability token, and says the tool 'advance[s] the workflow', indicating a state-changing effect consistent with readOnlyHint=false. This is useful and not a contradiction.

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

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

Three short, purposeful sentences. The main action is front-loaded, followed by the auth requirement and the key safety guarantee. No filler or repetition of schema details.

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?

The description covers purpose, auth, and transaction-safety, but with no output schema and 0% parameter documentation, it leaves meaningful gaps: what 'bridge/destination output' concretely refers to, how idempotency_key works, and when transaction_hash should be supplied. It is adequate for selecting the tool but not fully self-sufficient for invoking 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%, so the description bears the burden of explaining parameters. It only clarifies that a session capability token is required, which maps to session_token. It does not explain the meaning or purpose of session_id, idempotency_key, or the optional transaction_hash, leaving important semantics to inference from parameter names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the action (observe), the resource (caller's already-produced bridge/destination output for a v2 session), and the workflow side effect (advance the workflow). It is more specific than a tautology and the 'Never submits a transaction' line helps separate it from action/submission tools, though it does not explicitly name a sibling alternative such as assetfare_v2_session_observe_source.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context: this tool is for observing already-produced output in a v2 session, requires a session capability token, and advances the workflow without submitting a transaction. This implies when it should be used, but it does not explicitly state when-not to use it or name alternatives.

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 indicate readOnlyHint=false and destructiveHint=false, so the description adds value by clarifying the tool never submits a transaction yet still advances the workflow. It also discloses the auth requirement (session capability token). This goes beyond what annotations alone 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?

Two sentences with no filler. The core purpose is front-loaded, and the critical constraints (token requirement, no transaction submission) are stated immediately. 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?

The description covers purpose, auth, and the no-submission constraint, but with no output schema and no return-value description, it leaves the agent uncertain about the result or next workflow step. It also omits idempotency semantics despite an idempotency_key parameter. This is adequate but not fully 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 0%, so the description must compensate, but it only indirectly maps to session_token ('session capability token') and transaction_hashes ('source transaction hashes'). It does not explain session_id or idempotency_key, leaving significant semantic gaps for an agent invoking 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?

The description clearly identifies the action (observe), the resource (caller's already-submitted source transaction hashes), and the scope (v2 session). It distinguishes from sibling observe_output by explicitly mentioning 'source' transaction hashes, though 'advance the workflow' is somewhat vague.

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 'already-submitted source transaction hashes' implies the tool should be used after the caller has submitted transactions, and 'Never submits a transaction' clarifies it is not for submission. It provides clear context but does not explicitly name alternative tools or when-not-to-use conditions.

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 annotations already mark this as non-read-only, idempotent, and non-destructive. The description adds useful behavioral context: it requires the session capability token, produces an unsigned quote-bound action, and never signs or submits. It does not state whether the old action is invalidated, but the annotations cover the safety profile.

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, front-loaded with the core operation followed by requirement and safety exclusion. No filler or repetition of schema data.

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?

The core semantics are clear and annotations cover idempotency and destructiveness, so an agent can select the tool. However, there is no description of what the call returns or how the replacement affects the existing session, and the tool's place in the v2 flow is only implicit via 'quote-bound'.

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 0% schema description coverage, the description bears the burden of explaining parameters. It clarifies session_token as the caller's session capability token, but gives no meaning or constraints for session_id or idempotency_key, both of which are required.

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: replacing an expired unsubmitted v2 session action with a fresh quote-bound unsigned action. It immediately distinguishes the tool from siblings like assetfare_v2_prepare and assetfare_v2_quote by emphasizing refresh and non-submission.

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 specifies the trigger condition ('expired unsubmitted') and a hard boundary ('Never signs or submits'), which lets an agent know when not to call it. It does not name alternative sibling tools or explain ordering relative to quote/prepare, so it falls just short of explicit routing.

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 valuable context beyond annotations: it never submits a transaction and requires caller approval, which complements readOnlyHint=false (mutation) and destructiveHint=false. Clarifies that the operation is a safe verification step rather than a chain write. Does not disclose idempotency behavior, but the annotation idempotentHint=true covers that.

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 concise sentences with no waste, front-loading the action and then the key behavioral constraints. Every word 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 4-param mutation tool with no output schema and zero schema coverage, the description should explain parameter roles and return/effect semantics. It covers the high-level purpose and transaction safety but leaves parameter meaning and workflow advancement details unstated.

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 description provides no information about the four required parameters (access_token, session_id, signature, idempotency_key). The agent gets no format, source, or meaning guidance from the description; it must infer everything from names and types.

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 (verify) and resource (caller-submitted finalized Solana source signature) and notes it advances the workflow. It distinguishes itself from observation siblings (assetfare_observe_*) and preparation siblings (assetfare_prepare_*), though it doesn't explicitly name an alternative.

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?

Implies usage via 'caller-submitted finalized' and 'advance the workflow', suggesting it follows a source action. But no explicit when-to-use vs siblings, no prerequisites stated, and no exclusions. Adequate but with clear gaps.

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