AssetFare

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?

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds useful behavioral context beyond annotations by explicitly stating this does not create a session or transaction, which clarifies the operational boundary relative to sibling tools. The 'fee-inclusive' detail also adds meaningful behavioral semantics.

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

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

The description is compact and front-loaded: the core purpose is in the first sentence, and the critical side-effect disclaimer is in the second. Every sentence earns its place without unnecessary detail.

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 clear annotations and a small schema, the description is largely complete. It would benefit from mentioning what the returned quote contains or that quote validity/expiration may apply, but the absence is not critical for a non-destructive quote operation.

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 does not mention amount_usd at all. It does add some meaning by mapping destination_chain to 'Base or Arbitrum ETH' and implicitly identifying the source as Solana SOL, but this is partial compensation for the missing parameter 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?

The description states a specific verb ('Get') and a specific resource: a fee-inclusive Solana SOL to Base or Arbitrum ETH quote. It also explicitly distinguishes the tool from transaction/session-creating siblings by saying it does not create a session or transaction, so an agent can identify the right 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 implies the tool is for obtaining a quote without side effects, and it tells the agent what the tool does not do. However, it does not name alternatives or provide explicit when-to-use versus when-not-to-use guidance, such as 'use before create_session' or 'use instead of prepare_*_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 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 declare readOnly, idempotent, openWorld, and non-destructive, so safety is covered. The description adds value by naming the exact queryable state (pause state, RPC quorum), but says nothing about freshness, caching, or what quorum failure looks like.

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 that lists the four returned facets without filler. Nothing could be cut without losing 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 no output schema and no parameters, the description carries the burden of telling the agent what it gets back, and it does so by enumerating the four state categories. It is adequate for a no-arg read tool, though it omits why an agent would call it versus checking state elsewhere.

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. There is nothing for the description to compensate for, and it does not introduce any misleading parameter references.

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 enumerates the concrete resources returned: capabilities, caps, pause state, and RPC quorum. This clearly distinguishes it from the mutation-oriented siblings (prepare_*, create_session) and the observation tools, though it doesn't explicitly differentiate from assetfare_manifest, which could also be a read-only status surface.

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 when-to-use guidance, no prerequisites, and no alternatives named. The agent must infer from the description alone that this is a pre-flight/health-check tool rather than, say, a manifest query.

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.