GotSOL.app

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

With zero annotations, the description carries the full burden, and it does add real value: it names the three artifacts produced (pay URL, QR page, x402 URL) and discloses the fee economics (no 0.25% transfer fee on incoming payments). However, it says nothing about link lifetime/expiry, single-use vs reusable behavior, required auth scope, or whether creation is idempotent — significant gaps for a mutating tool with no 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?

Three short sentences, purpose front-loaded, then return values, then a decision-relevant fee note. No filler, no repetition of the tool name or schema, and each sentence contributes information an agent cannot get from structured 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?

No output schema exists, and the description partially compensates by enumerating return artifacts. But for a creation tool with no annotations and one undocumented parameter, an agent still lacks auth requirements, link expiry semantics, and whether the link is shareable/reusable — enough missing that it is only minimally adequate.

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

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

Schema coverage is 67%: amount and memo are documented in-schema, but bearerToken has no description anywhere. The description mentions 'signed-in wallet,' which loosely hints at auth, but does not explain the bearerToken parameter or add format/unit detail beyond the schema's 'USDC amount.' Baseline 3 is appropriate at this coverage level.

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 + resource + scope: 'Create a GotSOL.app USDC payment link for the signed-in wallet.' The create-vs-get-vs-list distinction against siblings (get_payment_link, list_payment_links) is implicit in the verb and unambiguous. It does not explicitly name a sibling to disambiguate from, keeping it just below a 5.

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 statement of when to use this versus send_usdc, prepare_transfer, or the existing payment-link read tools. The only usage signal is the phrase 'for the signed-in wallet,' which implies auth context but gives no prerequisites, exclusions, or alternative 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?

With zero annotations the description carries the full burden and does well: it discloses that the API key is revealed 'once', that no email signup or delegation click is required, and that the key must be stored and sent as a Bearer token later — the critical one-time-secret behavior. It stops short of saying what happens on repeat calls without an idempotency key, or whether a wallet is destructible/recoverable.

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

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

Four short sentences, front-loaded with the action and immediately followed by the return value and the credential-handling instruction. No filler.

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

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

No output schema exists, and the description compensates by stating the return payload (address plus API key, once). The only gap is repeat-invocation behavior without an idempotency key, which the param description partially covers.

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

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

Schema coverage is 100%, and the schema already explains that 'name' is a label and that 'idempotencyKey' prevents minting a second API key. The description adds nothing beyond that, so baseline 3 applies.

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 and resource: 'Open a GotSOL.app Solana wallet for this agent' — unmistakable and clearly distinct from the sibling payment/balance/profile tools. An agent can tell immediately this is the onboarding/provisioning step.

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

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

Sequencing is implied by 'send it as Authorization: Bearer on later calls', which signals this is a prerequisite step, and 'for this agent' scopes the caller. However, no alternative is named and there is no explicit statement of when not to call it (e.g. if a wallet already exists), leaving the agent to infer.

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

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

No annotations exist, so the description carries the full burden, and it discloses little: it implies a read but never states read-only behavior, auth requirements (bearerToken is optional in schema but unaddressed), or error handling when no identifier is given. Return shape is only vaguely gestured at as 'goal and progress'.

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 resource and followed by the lookup method; no padding. It is arguably too terse rather than too long.

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 annotations, the description should cover return value shape and error/identifier requirements, which it mostly doesn't. It gives the minimum an agent needs to attempt the call but leaves auth and missing-identifier behavior ambiguous.

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

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

Schema coverage is 33% (only bearerToken documented), so the description must compensate somewhat. Mentioning merchantPubkey or merchantId adds meaning beyond bare property names, but it doesn't clarify that these are alternative identifiers, whether both may be passed, or which one wins.

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+resource: 'Get revenue goal and progress for a merchant' tells an agent exactly what is returned and for whom. It is clearly distinct from siblings like get_merchant_metadata or get_usdc_balance, though it doesn't explicitly name them.

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?

'Query by merchantPubkey or merchantId' implies the two lookup modes but doesn't say when to prefer one, whether either is required, or what happens if both/neither are supplied. No alternatives or exclusions are mentioned.

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?

No annotations are provided, so the description carries the full behavioral disclosure burden. It only restates that metadata is fetched; it does not mention auth requirements, permission scope, error behavior, rate limits, or return shape. The read-only nature is implied by 'Get' but not elaborated.

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, front-loaded sentence with no wasted words. The resource and key input are stated immediately. It is appropriately sized for a simple lookup tool.

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 tool is low complexity, but there is no output schema and the description does not explain what 'metadata' contains or what auth behavior to expect. It is complete enough to invoke with the required merchantPubkey, but leaves gaps an agent may care about.

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

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

Schema description coverage is 100%, so both merchantPubkey and bearerToken are already documented in the schema. The description mentions merchantPubkey but adds no format or usage detail beyond the schema. Baseline 3 is appropriate when the schema does the parameter documentation.

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: get metadata for a merchant. It also names the key input, merchantPubkey, making the operation clear. It does not explicitly differentiate itself from the sibling list_merchant_metadata, so it falls short of a 5.

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 does not state when to use this tool versus alternatives such as list_merchant_metadata or get_profile. There is no guidance on prerequisites, auth needs, or exclusions. The singular phrasing implies lookup for one merchant, but that is not explicit 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?

With no annotations, the description carries the full disclosure burden and largely drops it: it doesn't state that a bearerToken may be needed for auth, whether the call is read-only (only implied by 'Get'), what pagination defaults or ordering look like, or anything about rate limits. 'Paginated' is the sole behavioral hint.

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 action and resource, with zero filler. It is efficient, though the brevity is closer to under-specification than disciplined concision.

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?

A four-parameter tool with an auth parameter, no annotations, no output schema, and only 50% schema coverage needs a description that fills gaps around auth, pagination behavior, and return shape. The description addresses none of these, leaving the agent to guess.

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

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

Schema coverage is 50%, with merchant and bearerToken described in the schema. The description adds only 'Paginated', which loosely maps to page/limit but gives no meaning for the numeric parameters, and says nothing about merchant identification beyond the schema's 'Merchant pubkey'.

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 ('Get payment history for a merchant'), which is enough to distinguish it from siblings like create_payment_link or get_usdc_balance. It stops short of naming a sibling or scoping the resource further, so it lands at a clear-but-undifferentiated 4.

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 indication of when to use this tool versus alternatives such as get_payment_link or list_products, and no prerequisites are stated. The only usage cue is 'Paginated', which hints at iterative calls but is not framed as 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?

With no annotations, the description carries the full burden, and it does disclose the one non-obvious behavior: check=true triggers an on-chain payment lookup. It says nothing about authentication (the bearerToken parameter exists but is unexplained), latency or failure behavior of the on-chain check, or what statuses can come back.

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 primary action and scope, with the conditional usage note second. Nothing is redundant or padded.

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

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

For a three-parameter read tool with no annotations and no output schema, the description should explain the bearerToken/auth expectation and at least hint at the returned shape beyond 'status'. It covers the core retrieval and the check flag adequately, but leaves the auth parameter and response contents ambiguous.

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

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

Schema coverage is 33%: id has only a trivial description and both check and bearerToken are undocumented. The description compensates for check by explaining that true means an on-chain lookup, but bearerToken remains entirely unexplained in both schema and description.

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

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

States a specific verb and resource ('Get one GotSOL.app payment link') plus the payload content ('including status'), which clearly separates it from list_payment_links. It does not explicitly name the sibling it differs from, but 'one' implies single-record retrieval.

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 use this versus list_payment_links or get_payment_history; retrieval-by-id is only implied. The one conditional sentence ('Set check to true...') is parameter guidance, not tool-selection guidance, and no exclusions or prerequisites are given.

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?

With no annotations, the description carries the full burden and does disclose the return payload in detail (userId, emails, wallets on two chains, merchants with their fields), which is valuable given there is no output schema. It implies a read operation via 'Get' and mentions auth scoping, but does not state error behavior or whether the token is strictly required despite the schema calling it 'Optional'.

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 zero filler; scope and return contents are stated before any detail. Every clause contributes to selection or interpretation.

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 no-argument read tool with no output schema, enumerating the returned fields covers the essential gap. Missing only minor context such as auth failure behavior or whether the bearer token is mandatory, which is a small residual gap rather than a blocking omission.

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

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

Schema coverage is 100% and the single parameter (bearerToken) is already documented. The description still adds meaning by tying that token to account identity ('for the authenticated API key'), clarifying that the token selects whose profile is returned rather than being a generic optional auth header.

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

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

States a specific verb and resource ('Get the profile') scoped explicitly to 'the authenticated API key' and enumerates the exact contents (userId, emails, wallets, merchants). No sibling tool in the list does anything comparable, so an agent can distinguish it immediately.

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 'for the authenticated API key' makes clear this is a self-scoped lookup with no target user argument, which is the main selection criterion. It does not name alternatives or exclusions, but none of the siblings overlap, so the context is sufficient.

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?

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only balance lookup for a signed-in wallet but does not disclose authentication requirements, return format, error behavior, or whether it requires an existing wallet.

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

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

The description is a single front-loaded sentence with no wasted words. It is appropriately sized for a simple read tool, though it could be slightly more structured by naming the authentication requirement.

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 an undocumented input parameter, the description is incomplete. It does not explain the return value shape (e.g., amount and denomination), authentication mechanics, or error cases, leaving significant gaps for the agent.

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

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

Schema description coverage is 0% for the single bearerToken parameter, and the description never mentions it. The description must compensate for the low coverage but does not explain how authentication is passed or what the parameter is for.

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

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

The description states a clear resource and scope: the USDC balance of the signed-in GotSOL.app wallet. It does not explicitly differentiate from siblings like get_payment_history or get_profile, but the resource is distinct enough for an agent to recognize.

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 guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The agent is left to infer usage solely from the purpose statement.

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

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

No annotations are provided, so the description carries the full disclosure burden. It implies a read-only listing and states that results are scoped to the authenticated user, but says nothing about pagination, result volume, ordering, auth failure behavior, or what a merchant record with heatmap coordinates contains — all material for a list endpoint with zero 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?

A single front-loaded sentence with no filler; the scope-defining phrases come in the right order. The parenthetical "(heatmap)" is slightly cryptic but compact enough not to be wasteful.

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

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

With no annotations and no output schema, the description should explain what the listing yields and how it behaves, but it only names the resource. It is adequate to identify the tool but leaves an agent without enough to predict the response shape or scale for a data-returning list 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 coverage is 100% and the single bearerToken parameter is fully documented in the schema, so baseline 3 applies. The description's phrase "for the authenticated user" loosely contextualizes the optional token but adds no format, precedence, or fallback detail beyond what the schema already states.

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 gives a specific verb and resource ("List merchants") plus the data scope ("location data (heatmap)") and ownership scope ("authenticated user"), which distinguishes it from the singular get_merchant_metadata sibling by name convention. It never explicitly states the relationship to get_merchant_metadata, so differentiation is inferred rather than declared.

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

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

There is no when-to-use or when-not-to-use guidance, and no sibling is named as an alternative. The agent must infer that this is the multi-merchant, location-oriented listing versus the single-merchant lookup based on the verb alone.

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?

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only listing scoped to the signed-in wallet, but it does not disclose authentication requirements, pagination behavior, return format, 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?

The description is a single, front-loaded sentence with no wasted wording. It is appropriately sized for a simple list operation.

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 annotations, the description should say more about what the agent gets back and how authentication works. It identifies the resource and scope but leaves key operational details unspecified.

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 one optional bearerToken parameter with 0% schema description coverage, and the description does not explain it. 'Signed-in wallet' hints at authentication context, but the bearerToken parameter remains undocumented in both schema and description.

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: list GotSOL.app payment links. The scope is also clear: signed-in wallet. It does not explicitly distinguish itself from get_payment_link or create_payment_link, but list vs get/create is inferable.

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: use this to see payment links for the signed-in wallet. There is no explicit when-to-use guidance, no exclusions, and no mention of alternatives such as get_payment_link.

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?

No annotations are provided, so the description carries the full burden. It implies a read operation but says nothing about authentication requirements despite the bearerToken parameter, nor about pagination, result limits, or what happens when search matches nothing.

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 core action. 'Optional search term' is slightly redundant given the schema's optionality but overall there is 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 simple list tool with one required param and no output schema, the definition is minimally adequate, but it leaves out auth behavior and any indication of return shape or pagination that an agent would need to call it confidently.

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 67%: merchantPubkey and bearerToken are already documented in the schema, while 'search' has no schema description but the description clarifies it is an optional search term. This adds modest value but does not compensate for the remaining gaps.

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

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

States a specific verb and resource ('List products') scoped to a merchant, which is enough to distinguish it from siblings like list_payment_links and list_merchant_metadata that list other resources.

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 mentions an optional search term but gives no guidance on when to use this tool versus alternatives, no prerequisites (e.g., auth via bearerToken), and no exclusions. Usage is only implied by the verb.

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?

With no annotations, the description carries the full burden and does well: it discloses the 0.25% fee deducted from the amount, that the transaction is unsigned and must be signed/broadcast externally, and who pays the network fee in which token. It does not address what the unsigned transaction looks like when returned or whether authentication (the bearerToken parameter) 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?

Three short sentences, each doing distinct work: purpose, fee/flow mechanics, alternative routing. Front-loaded with the core action and free of filler.

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

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

For a fee-bearing, multi-party flow the description covers the economics, the signing step, and the sibling alternative, which is most of what an agent needs. The missing piece is what the tool actually returns (an unsigned transaction payload) and whether the bearerToken parameter is required for authenticated merchants.

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 75%, so the baseline is 3; the description adds real meaning by clarifying that 'amount' is debited from the sender and the recipient nets amount minus 0.25%. That fee arithmetic is not in the schema. The undocumented bearerToken parameter is left unaddressed.

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

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

The first sentence states a specific verb and resource ('Build an unsigned USDC transfer'), plus the crucial modifier 'unsigned' that separates it from a broadcast tool. The final sentence names the sibling send_usdc and what distinguishes it, so an agent can choose 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?

It gives an explicit routing rule: use this when the sender pays the Solana network fee in SOL, use send_usdc when the fee should be paid in USDC. It also states the required follow-up ('The sender must sign and broadcast it'), which is the key precondition for using the output.

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?

With no annotations, the description carries the full disclosure burden and does real work: it names the 0.25% transfer fee with an end date, explains the Solana network fee is paid in USDC so no SOL is needed, and notes that a missing recipient USDC account is opened in the same send. It still omits irreversibility, whether the amount is fee-inclusive or fee-on-top, and what a balance shortfall produces.

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

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

Four short sentences, front-loaded with the action and source wallet, then the fee, the SOL-free property, and the account-opening side effect. Nothing is redundant, though the fee sentence and the USDC-network-fee sentence could be tightened into one.

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

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

No output schema and no annotations mean the description must cover safety and results, and it does not say what a successful send returns (e.g., a signature) or what happens on failure. The fee/ATA side effects are well covered, but the agent is under-informed about the return value and amount semantics for an irreversible value transfer.

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 67%; 'to' and 'amount' are documented in the schema, while bearerToken is undocumented in both places. The description adds the useful fact that the network fee is drawn in USDC, which affects how much is debited, but it never clarifies whether the stated amount includes the 0.25% fee or has it added on top.

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 (send USDC) plus the source wallet scoping (the GotSOL.app wallet for this API key). It does not explicitly distinguish itself from the sibling prepare_transfer, which is the most likely confusion point, so it stops short of 5.

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 use this tool versus prepare_transfer, which appears in the sibling list and plausibly covers a two-step prepare/execute flow. No preconditions (sufficient balance, required bearerToken) or exclusions are given; usage is left entirely to inference.

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