Blueprint Agentic Staking (Solentic)

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint, covering the safety profile. The description adds behavioral detail by specifying the three categories the tool outputs, which is novel beyond the structured annotations. It doesn't describe the exact return format, but that is not required given the annotations and no output schema.

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

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

The description is two sentences with no wasted words. The first sentence states the action and scope, the second provides a practical use case. Every sentence earns its place, making it highly concise and well-structured.

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 single-parameter, read-only classification tool with rich annotations, the description is complete. It explains what the tool does and when to use it, and the absence of an output schema is compensated by the clear implication that the result is one of the three listed address types. This aligns with the complexity level.

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 already covers the sole parameter with a description ('Solana address (base58 public key) to identify'), giving 100% schema coverage. The tool description does not add additional parameter-level semantics, so the baseline score of 3 is appropriate.

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 specific verb 'Detect' and clearly identifies the resource as a Solana address, listing three concrete classification outcomes (wallet, stake account, vote account). This distinguishes it from sibling tools like check_balance and check_stake_accounts, which serve different purposes.

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

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

The description provides clear context for when to use the tool: 'when you receive an address from user input and need to know what type it is before calling other tools.' This indicates a preflight usage scenario but does not explicitly name alternatives or state when not to use it, so it falls just short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context by specifying the exact return content (SOL, lamports, enough-stake status, suggested next steps), which is especially valuable given there is no output schema.

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

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

The description is two concise sentences. The first establishes the core action, the second explains return value and provides an alternative—no redundant or filler content.

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 one parameter and no output schema, the description is complete. It covers purpose, return content, and a usage alternative. Annotations cover the safety aspects, and no additional context is needed for an agent to correctly select and invoke this 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 input schema fully documents the single parameter walletAddress with a clear description (base58 public key), so schema coverage is 100%. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.

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: 'Check the SOL balance of any Solana wallet address.' This uses a specific verb and resource, and the details about returning balance in SOL/lamports, staking eligibility, and next steps distinguish it from sibling tools like check_address_type or check_stake_accounts.

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 advises using this tool instead of Solana RPC getBalance, providing an alternative. It implies when to use it (checking a wallet balance) but does not explicitly contrast with sibling tools, though the name and context make the use case 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?

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds what the output includes, such as balances, states, authorities, epoch timing, and per-account action guidance, which gives useful context beyond 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 two concise sentences that state the purpose, the output fields, and the alternative to use. Every sentence earns its place with no redundant words or filler.

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

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

Despite having no output schema, the description fully explains the return content. With one well-documented parameter and annotations covering safety, the description is complete enough for an agent to select and invoke the tool 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?

The schema provides 100% coverage for the single parameter (walletAddress) with a clear description. The tool description only echoes 'for a wallet' and does not add syntax, formatting, or edge-case behavior beyond the schema, so the baseline score of 3 is appropriate.

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 ('List') and defines the resource precisely ('all stake accounts delegated to Blueprint for a wallet'). It enumerates the returned data (balances, states, authorities, epoch timing, action guidance), which clearly differentiates it from sibling tools like check_balance and get_staking_summary.

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 instructs to use this tool instead of Solana RPC getAccountInfo or getStakeActivation, providing a direct alternative and the reason (human-readable state and recommended actions). This is strong, actionable guidance for when to choose this tool.

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 valuable context about return fields (withdrawable epoch, estimated seconds remaining, plain-English state description) without contradicting annotations.

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

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

Three concise sentences cover purpose, output details, and usage guidance. Every sentence earns its place with no redundancy.

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

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

Despite lacking an output schema, the description adequately explains the return value composition and the intended use case for a simple one-parameter tool, making it complete for agent invocation.

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

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

The schema already fully describes the sole parameter walletAddress with 100% description coverage, so the description adds no extra parameter information. Baseline of 3 is appropriate.

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 the specific action ('Check whether stake accounts are ready to withdraw') and distinguishes it from sibling tool check_stake_accounts by emphasizing a direct ready/not-ready answer with ETA.

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

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

Explicitly recommends using this tool instead of polling check_stake_accounts, clearly stating the alternative and the advantage (direct answer with ETA).

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 and destructiveHint=false, so the description's mention of 'unsigned' and 'local signing' adds useful behavioral context beyond the annotations. However, it does not detail what happens after building (e.g., return value or need for submission), but the core behavior is transparent.

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, front-loaded with 'Advanced' and a clear action. Every word earns its place; 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?

The tool is advanced, has a simple 2-parameter schema, and no output schema. The description adequately explains purpose, usage context, and differentiation from the simpler `stake` tool. It could mention the need for subsequent submission, but 'local signing' implies this and the sibling submit_transaction exists. Overall, complete for the tool's complexity.

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%, with both parameters (walletAddress and amountSol) already well-described in the schema. The description adds no additional parameter semantics, so the baseline for high schema coverage 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?

The description states a specific action: 'Build an unsigned stake transaction for local signing.' It clearly identifies the resource (stake transaction) and distinguishes from the `stake` tool that handles signing and submission. This is a specific verb+resource with clear differentiation from 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?

Explicitly directs most agents to use the `stake` tool instead, and states this tool is for agents managing their own signing infrastructure. This provides clear when-to-use and when-not-to-use guidance with a named alternative.

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 indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds meaningful context beyond annotations by specifying the transaction is 'unsigned' and intended for 'local signing', which implies it does not submit or sign automatically. This gives agents a clearer behavioral model than annotations alone, though it doesn't elaborate on potential side effects like network queries.

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 exceptionally concise—two sentences that immediately state the core purpose and provide usage contrast. It front-loads the key information without any filler, making it easy for an agent to quickly parse.

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 no output schema, the description does enough by indicating the output is an unsigned transaction for local signing. It also mentions the primary alternative. However, it could be slightly more explicit about what the agent should do with the transaction (e.g., submit via a separate tool), but for a tool focused on construction, this is adequate.

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

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

The input schema has 100% description coverage for both parameters, with clear descriptions ('Wallet address that is the stake authority' and 'Stake account address to deactivate'). The tool description does not add extra meaning or usage details for the parameters, so it appropriately relies on the schema. Baseline of 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?

The description clearly states the tool's purpose with a specific verb ('Build') and resource ('unsigned unstake transaction'), and immediately distinguishes it from the sibling `unstake` tool by noting it's for local signing. This goes beyond a generic restatement and effectively differentiates it from alternatives.

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 provides usage guidance: it labels the tool as 'Advanced' and tells most agents to use the `unstake` tool instead, which handles signing and submission automatically. This names the alternative and clarifies when to use this tool (local signing) versus when not to.

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 says 'Remove a wallet's Autopilot policy', which is destructive, but the annotations declare destructiveHint: false, directly contradicting the described behavior. The signing and nonce details are useful, but the contradiction is a serious issue that fails to disclose the true destructive 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?

The description is two sentences, front-loaded with the purpose, and includes essential technical details. It is concise, though the inlined signing message could be formatted more clearly.

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 core action and signing requirement but omits what happens on success (e.g., return value) and does not mention error cases. The annotation contradiction further undermines completeness for an AI 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?

While schema descriptions cover all three parameters, the description adds the exact signing message format and the critical requirement that nonce must exceed the current policy nonce, providing semantic context beyond the schema.

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

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

The description uses a specific verb and resource: 'Remove a wallet's Autopilot policy'. This clearly distinguishes it from sibling tools like set_staking_policy and get_staking_policy.

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 usage through the verb 'Remove' but does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites (e.g., policy must exist) or exclusions.

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 states the tool deletes a webhook, which is a destructive action. However, annotations set destructiveHint to false, creating a direct contradiction. No other behavioral traits (e.g., irreversibility, permission requirements) are disclosed. This warrants a score of 1 due to the 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?

Two short sentences, both purposeful. The first states the core action and object, the second provides necessary guidance for finding the ID. No filler or redundant 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 simple delete tool with two parameters and no output schema, the description is mostly sufficient: it says what it deletes and how to find IDs. However, the contradiction between the destructive description and destructiveHint=false creates confusion, and there is no mention of error conditions or return value. This leaves the context incomplete.

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

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

Schema description coverage is 100%, so the schema already fully documents both parameters. The description adds minimal value by saying 'by ID' and referencing list_webhooks, but it does not explain the walletAddress ownership requirement beyond what the schema states. Baseline 3 is appropriate when the schema does the heavy lifting.

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 'delete' and clearly states the resource ('webhook registration') and the identifier ('by ID'). It distinguishes itself from sibling tools like list_webhooks and register_webhook by describing a distinct action.

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 instructs to use list_webhooks to find webhook IDs, providing clear context and a recommended prerequisite. However, it does not mention when not to use the tool (e.g., cannot delete webhooks owned by other wallets), though the schema partially covers that.

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 indicate non-read-only and non-destructive behavior. The description adds valuable context by disclosing the zero-custody pattern: it builds an unsigned transaction and returns it for client-side signing. This goes beyond the annotations and explains the tool's non-custodial nature, which is essential for understanding its side effects. It does not detail any additional side effects or error conditions, but the core behavior is well conveyed.

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 sentence states the purpose, the second provides context about Blueprint, and the third gives practical donation amounts. It is succinct, well-structured, and free of redundancy, making it easy for an agent to quickly understand and act on.

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

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

Given the tool's simplicity (two parameters, no output schema) and existing annotations, the description is complete. It explains what the tool does, how it behaves (returns unsigned transaction), and even offers suggested inputs. The coverage is sufficient for an agent to select and invoke the tool correctly without ambiguity.

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% with descriptions for both parameters, so the baseline is a 3. The description adds value by suggesting specific amounts (0.01, 0.1, 1 SOL) that map to the amountSol parameter, giving practical guidance beyond the schema's min/max constraints. It does not elaborate on walletAddress beyond what the schema provides, but the overall enrichment justifies a 4.

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 primary action: 'Build an unsigned SOL transfer to support Blueprint development.' It uses a specific verb ('build') and resource ('unsigned SOL transfer'), and distinguishes itself from sibling tools by focusing on donations to Blueprint, which is unique among the listed transaction tools.

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

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

The description provides clear context for when to use the tool: when making a donation to support Blueprint development. It also explains the zero-custody pattern ('unsigned transaction returned, you sign client-side'), aligning with similar tools. However, it does not explicitly name alternatives or state when not to use it, so it falls short of a 5.

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

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

Despite annotations indicating readOnlyHint, idempotentHint, and non-destructive behavior, the description adds valuable context: Solentic never sees the private key and cannot generate it server-side. This explains the privacy model and execution requirements, going beyond what annotations state.

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 four sentences long and each sentence adds necessary information: what it does, why it must be run locally, what the response includes, and how to use it afterwards. It is slightly verbose but still well-structured and 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?

Given the zero-parameter schema, no output schema, and the tool's simple nature, the description is complete. It covers the purpose, usage context, privacy implications, and next steps, leaving no critical 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?

The tool has zero parameters, so the baseline is 4 per the rubric. The description does not need to explain parameter meanings, and it effectively describes what the response contains (runnable code) instead.

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 'Returns runnable code that creates a Solana keypair,' using a specific verb and resource. It distinguishes itself from sibling tools by focusing on keypair generation rather than balance checks, staking, or transactions.

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 explains when to use this tool: whenever a Solana keypair is needed, and clarifies that generation must happen in the agent process or user shell. It also provides a follow-up workflow: fund the publicKey and call the stake tool with specific parameters, giving clear contextual 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, idempotentHint, and non-destructive behavior, covering the safety profile. The description adds value by specifying the return fields and noting the pre-calculated nature with an estimated end date, which is not present in 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 concise sentences: the first states the core function and outputs, the second gives usage guidance. No redundant words, and the most important information 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?

For a zero-parameter, read-only tool with no output schema, the description fully explains what is returned and when to use it. It is self-contained and leaves no significant 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?

The tool has zero parameters, so the empty schema is fully covered. The description appropriately adds no parameter details since none exist, and the baseline for 0-param tools is 4.

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 action (Get), the resource (current Solana epoch timing), and the specific outputs (progress percentage, slots remaining, estimated end time). It also distinguishes from Solana RPC getEpochInfo, making it unique among sibling tools.

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

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

Explicitly directs the agent to use this instead of Solana RPC getEpochInfo, naming the alternative and providing the reason (pre-calculated timing with estimated end date). This gives clear when-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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the fact that there are two bare-metal servers in redundant HA, offering some context about what the specs describe, but does not elaborate on return format or any additional behavioral traits, which is adequate given 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 concise, front-loaded with the core purpose, and the second sentence adds a specific detail (two bare-metal servers). Every word earns its place; no fluff 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?

Since there is no output schema, the description carefully lists the returned information categories (hardware, redundancy, network, storage) and adds the HA detail. While it does not specify the exact format or data types, it is sufficiently complete for a simple, parameterless getter 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 tool has zero parameters, so the empty schema fully covers the input contract. The description mentions the content of the specs but does not need to explain parameter semantics. With no parameters, a baseline of 4 is warranted.

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

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

The description specifies a clear verb ('Get'), a specific resource ('Blueprint validator infrastructure specs'), and the scope ('server hardware, redundancy configuration, network, and storage'). It distinguishes itself from sibling tools that deal with balances, transactions, or staking by focusing on infrastructure details.

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 usage when infrastructure specifications are needed, but does not explicitly state when not to use the tool or mention alternatives. The context is clear (retrieving infrastructure specs), but there are no exclusions or alternative guidance, so it falls short of a 5.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is established. The description adds context about the specific metrics included, which is useful. However, it does not disclose additional behaviors such as data freshness, failure handling, or whether results are per-validator or aggregated. Given the strong annotation coverage, the added value is moderate.

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, focused sentence that directly states the purpose and key output fields, with no unnecessary words. It is well-structured and 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?

For a zero-parameter tool with clear annotations and no output schema, the description sufficiently communicates the return value by listing the performance metrics. It could specify whether data is for a single validator or all validators, but this is a minor gap given the context.

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 are zero parameters in the input schema, so schema coverage is trivially complete. The description does not need to elaborate on parameter semantics, and with no parameters, a baseline of 4 is appropriate.

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 retrieves Blueprint validator performance with specific metrics (vote success rate, uptime, skip rate, epoch credits, delinquency status). The verb 'Get' and resource are specific, and it distinguishes from sibling tools like get_validator_info by focusing on performance metrics.

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 is provided on when to choose this tool over alternatives. Sibling tools like get_validator_info or get_infrastructure exist, but the description does not mention them or offer comparisons. Usage is only implied by the name and description.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds valuable behavioral context: data is 'live', sourced from 'StakeWiz API', and includes commission rates. This goes beyond the structured annotations by explaining the data's origin and composition.

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 fluff. The main action and formula are front-loaded, and the data source is stated in the second sentence. Every word contributes to understanding the tool's behavior.

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

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

Given the tool has no parameters and no output schema, the description fully covers what the agent needs: what it returns (APY breakdown), how it's computed, and where it comes from. For a simple read-only informational tool, this is complete.

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

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

There are zero parameters, so the baseline is 4. The description doesn't need to explain parameters since the input schema is empty, and it doesn't attempt to invent any.

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: 'Get live APY breakdown' and specifies the components (base staking APY + Jito MEV APY = total APY). This distinguishes it from siblings like get_staking_summary and get_staking_policy, which address different concerns.

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 usage context by mentioning 'live APY breakdown' and 'Data from StakeWiz API', which tells the agent when this is relevant (fetching APY data). It does not explicitly contrast with alternatives, but the specificity of the purpose provides sufficient contextual guidance for a read-only informational tool.

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=true, idempotentHint=true, and destructiveHint=false, providing safety context. The description adds value beyond annotations by specifying return fields (keepLiquidSol, minSweepSol, paused, nonce, last sweep epoch) and the 'null if none' edge case, which is useful behavioral detail.

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, front-loaded with the verb and resource, and every word contributes meaning. It efficiently communicates the purpose, null-case behavior, and the specific fields returned without unnecessary 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 simple read-only tool with one parameter, good annotations, and a clear return field list, the description is nearly complete. It could optionally mention that the wallet may not exist, but the openWorldHint and 'null if none' cover that implicitly, so no major gaps remain.

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 already covers the single parameter 'walletAddress' with a description ('Wallet address') at 100% coverage. The description reinforces that the policy is per-wallet but does not add new parameter-related semantics, so it stays at the baseline for high schema coverage.

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

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

The description uses a specific verb ('Read') and resource ('Autopilot policy for a wallet'), clearly stating the tool's function. It also distinguishes from sibling tools like set_staking_policy and delete_staking_policy by focusing on reading the current policy, and mentions the null return case for no policy.

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 usage for retrieving the current Autopilot staking policy for a wallet, and the read-only nature is clear. However, it does not explicitly mention when to use this versus alternatives like get_staking_summary or when not to use it, leaving the guidance to inference.

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

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

Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, fully covering the safety profile. The description adds no additional behavioral context such as error conditions, rate limits, or side effects beyond what is implied by 'returns', so it meets only the baseline for a well-annotated read-only tool.

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

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

Two sentences, front-loaded with the core value proposition ('Complete staking portfolio dashboard'), then a detailed list of return fields and a concrete usage example. Every sentence is informative and has no fluff.

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

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

Despite no output schema, the description enumerates all the key return values (liquid balance, total staked, per-account states, rewards, APY, epoch timing, recommended action) and explains when to use it. This makes the tool's purpose and results fully clear for an agent, even without more formal 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?

The schema covers 100% of the single parameter (walletAddress) with a clear description. The tool description does not add any additional meaning beyond the schema, so it gets the baseline score for high schema coverage without extra parameter detail.

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

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

The description clearly states a specific verb and resource ('get staking summary') and details the comprehensive nature of the output (liquid balance, total staked, per-account states, APY, epoch timing, recommended action). This clearly distinguishes it from sibling tools that focus on individual metrics.

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

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

Explicitly tells the agent to use this instead of multiple Solana RPC calls, naming the exact calls it replaces. While it doesn't explicitly mention when not to use it or compare to sibling tools, the context makes it clear this is the aggregate dashboard alternative, so the guidance is strong but not exhaustive.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds that data is 'Live data from StakeWiz API,' which implies an external call and potential latency, but it does not disclose details like rate limits, caching behavior, or failure modes. This adds some value beyond annotations but remains limited.

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, well-structured sentence that front-loads the purpose ('Get Blueprint validator profile') and then enumerates the included fields. Every phrase adds value, 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 zero-parameter, read-only information tool, the description is fairly complete. It lists what data will be returned and notes the live source. However, it does not describe the response format or any potential limitations, and with no output schema, a brief note on structure could improve completeness. Overall, it covers the essentials.

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 has zero parameters, so per the calibration guidance the baseline is 4. The description does not need to explain parameters, and there is nothing else to add. The description appropriately focuses on the result content rather than 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?

The description clearly states the tool gets a 'Blueprint validator profile' and enumerates the specific data points (identity, vote account, commission, active stake, APY, performance, software, location). This uses a specific verb and resource, and the field list distinguishes it from sibling tools like get_staking_apy or get_performance_metrics, which focus on individual metrics.

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 no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, use cases, or exclusions. The only additional context is the data source ('Live data from StakeWiz API'), which hints at external dependency but does not clarify when to choose this over sibling tools.

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 the tool as read-only, idempotent, and non-destructive. The description adds value by specifying the exact data returned (URLs for a list of platforms and CLI commands), and includes an instruction to 'Verify every claim independently.' It does not contradict annotations and sheds light on the tool's output scope, which is sufficient given the strong 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 long, front-loaded with the main purpose, and lists all relevant verification sources and CLI commands without any redundant information. Every sentence adds meaningful detail, making it highly concise and well-structured.

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 has no parameters and no output schema, so the description carries the burden of explaining what the tool returns. It does so by naming the verification URL sources and mentioning CLI commands, which is sufficient for a simple informational tool. The description could be slightly more explicit about the format of returned URLs, but it is generally 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?

The input schema is empty, so there are no parameter semantics to clarify. With 0 parameters, the baseline is 4, and the description appropriately focuses on the tool's function rather than parameter details. No additional parameter explanation is needed.

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

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

The description clearly states the tool's function: 'Get third-party verification URLs for Blueprint validator' and enumerates specific platforms (Validators.app, StakeWiz, Solana Beach, Solscan, JPool, SVT.one, Jito steward dashboard). It also mentions including Solana CLI commands, making the purpose explicit and distinct from sibling tools like get_validator_info or verify_transaction.

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

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

The description provides a clear context for use—retrieving verification URLs and CLI commands for on-chain verification. The phrase 'Verify every claim independently' implies using this tool when independent verification is needed, giving practical usage guidance. However, it does not explicitly mention when not to use it or name alternatives, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds the scope of listing 'all registered webhooks for a wallet address', but does not disclose additional behavioral traits such as whether it returns full webhook objects or only summaries, pagination, or ordering. It does 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 a single, front-loaded sentence with zero waste. Every word adds value: 'List' identifies the operation, 'all registered webhooks' specifies the resource, and 'for a wallet address' sets the scope.

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 one parameter and no output schema, the description is nearly complete. It states what it lists and the required scope. The only minor gap is the lack of explicit return shape (e.g., array of webhook objects), but the phrasing 'List all' implies this naturally.

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%: the sole parameter walletAddress is fully described in the schema. The description mentions 'wallet address' but does not add any additional meaning beyond what the schema already provides. Baseline 3 is appropriate.

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 specific verb 'List' with the resource 'webhooks' and scope 'for a wallet address'. This clearly distinguishes it from sibling tools like register_webhook and delete_webhook, which perform different actions on the same resource.

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 this tool is for displaying webhooks of a given wallet, but it does not explicitly state when to use it instead of alternatives such as register_webhook or delete_webhook. The context is clear enough for a simple read operation, but lacks explicit 'when 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?

The description discloses key behavioral details beyond the annotations: Solentic polls every 60 seconds and POSTs to the URL when events fire. This adds meaningful context about the delivery mechanism. It does not cover error handling, idempotency, or duplicate registration, so it isn't fully transparent, but it's well above the minimum.

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 exceptionally concise: two sentences, front-loaded with purpose, and every phrase contributes (events, polling interval, POST method). No unnecessary wording or repetition. It is a model of efficient writing.

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 four parameters and no output schema, the description provides the essential semantic information: what events exist and how notifications are delivered. It doesn't explain the return value or how registration interacts with existing webhooks, but that's partially covered by sibling tools and the schema. Good overall coverage.

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%, giving the baseline of 3. The description adds significant value by explaining each event enum value (e.g., 'withdraw_ready (stake account becomes withdrawable)'), which helps the agent choose appropriate event subscriptions. This goes beyond the raw schema and justifies a 4.

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 action ('Register a callback URL') and resource ('to receive push notifications when stake state changes'). It distinguishes itself from sibling tools like delete_webhook and list_webhooks by explicitly being the registration operation. The event list adds specificity and depth.

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 on when to use the tool: when push notifications for stake state changes are needed. However, it does not explicitly mention alternatives or when not to use it, such as using list_webhooks to view existing subscriptions or delete_webhook for removal. This falls short of a full 5.

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

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

The description goes well beyond annotations by disclosing key behavioral traits: Solentic never holds the user's key, it builds an UNSIGNED transaction and POSTs it to callbackUrl, amounts are in integer lamports to avoid float ambiguity, and nonce must strictly increase. These details explain side effects and security guarantees, giving the agent a complete mental model of what happens on invocation.

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 long but every sentence earns its place. It starts with the core purpose, then explains the signing mechanism, the operational flow, the unit convention, and finally gives the exact canonical message. No redundant fluff; the structure leads from high-level to low-level details, making it efficient for an agent to parse.

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

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

Given the tool's complexity (signature requirement, policy semantics, recurring behavior) and the absence of an output schema, the description is remarkably complete. It covers what the tool does, prerequisites (signing with Ed25519), the message format, conversion rules, callback behavior, and update semantics (nonce increase). No critical gaps remain for correct invocation.

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

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

With 100% schema coverage, the baseline is 3, but the description adds substantial meaning by showing the exact canonical message format, the conversion rule (round(SOL*1e9)), and the role of each parameter within that message (wallet, amounts, callbackUrl, paused, nonce). It also clarifies that nonce must increase each update and that callbackUrl receives unsigned transactions—details not fully in the schema.

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

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

The description clearly states the tool's function: 'Hand Solentic a standing, signature-bound policy so it automatically stakes your IDLE SOL with Blueprint.' This uses a specific verb ('hand', meaning set), names the resource (staking policy), and distinguishes it from sibling tools like delete_staking_policy, get_staking_policy, and stake by implying automatic recurring action.

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

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

The description provides clear context for when to use the tool: to set up automatic staking with ongoing policy enforcement. It implies this is for recurring automation rather than one-off staking (which could be done with 'stake'), but does not explicitly name alternatives or state when not to use it. The 'zero custody' and 'sign once' details clarify the operational model.

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, and non-destructive behavior. The description adds substantial value by detailing the output (daily/monthly/annual/total rewards, effective APY, activation timing, fee reserve guidance, recommendation) and clarifying a subtle aspect: effective APY equals stated APY because total_apy is already annual. This goes beyond what annotations provide.

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

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

Two sentences pack a wealth of information: what the tool does, what it returns, an important APY clarification, and a use case. Every sentence earns its place, and the description is front-loaded with the core purpose.

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 no output schema, the description compensates by enumerating return types (reward projections, effective APY, activation timing, fee guidance, recommendation). Parameters are simple and fully documented. The tool's complexity is well covered for an agent to decide invoke it.

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

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

Schema coverage is 100% with clear descriptions for both parameters (amountSol, durationDays). The description's reference to 'how much to stake and for how long' echoes the schema but adds no new semantic detail. Baseline 3 is appropriate since the schema already does the heavy lifting.

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 function: 'Project staking rewards before committing capital.' It uses a specific verb (project) and resource (staking rewards), and distinguishes itself from siblings like stake/unstake by focusing on pre-commitment simulation. This is a distinct purpose from other tools like get_staking_apy or get_staking_summary.

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 to use the tool: 'Use this to help decide how much to stake and for how long.' It provides clear context for decision-making but does not explicitly state when not to use it or mention alternatives, though the sibling list makes those alternatives evident.

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 (readOnly=false, openWorld=true), the description details the full flow: builds transaction, signs with secret key in-memory, submits to Solana, and returns the confirmed signature. It also adds a strong security guarantee (never stored, logged, or forwarded) with a verification path, exceeding what annotations 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?

The description is compact, front-loaded with the core action, and every sentence adds value (one-shot flow, security guarantee, and agent recommendation). 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?

The description covers the essential context: purpose, security, return value, and usage recommendation. It lacks explicit alternatives or exclusions, but for a tool with 3 well-schema'd parameters and no output schema, it is sufficiently complete for an agent to select and invoke it correctly.

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

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

Schema description coverage is 100%, with each parameter well-described in the schema. The description does not add additional parameter-specific semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.

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 stakes SOL with a specific validator in a single call, distinguishing it from manual transaction construction. It also positions itself as the recommended tool for autonomous agents, differentiating it from siblings like create_stake_transaction and simulate_stake.

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 recommends this tool for autonomous agents and emphasizes the one-shot nature, providing clear context for when to use it. However, it does not name specific alternatives or state when not to use it, so it stops short of a full 5.

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

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

Annotations already convey readOnlyHint=false and destructiveHint=true, so the destructive nature is disclosed. The description adds valuable context about the 'Advanced' nature and the prerequisite local-signing workflow, which goes beyond the annotations without contradicting them. It doesn't detail failure modes or side effects, but the existing annotation coverage lowers the bar.

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 concise, front-loaded with the purpose, and each sentence adds essential context (what it does, when it's needed, and when to avoid it). No fluff, and the 'Advanced' flag is a useful signal.

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

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

Given the tool's low complexity (single parameter, no output schema) and strong annotation coverage, the description adequately explains the workflow and alternatives. It lacks an explicit mention of return values, but for a transaction submission this is a minor gap, and the description otherwise provides a complete picture of when and how to use the 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 schema already fully describes the parameter (signedTransaction as a base64 string), and the description does not add additional semantic meaning beyond the schema. With 100% schema coverage, the baseline of 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?

The description clearly states the tool's purpose: submitting a pre-signed transaction to Solana. It distinguishes itself from sibling tools by explicitly mentioning the create_stake_transaction/create_unstake_transaction/withdraw_stake workflow and directing most agents to the one-shot stake/unstake/withdraw tools instead.

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 explicit when-to-use guidance (after local signing of create_* transactions) and when-not-to-use guidance (most agents should use one-shot tools). It names the specific alternatives, making it clear how this tool fits among siblings.

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

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

Beyond the minimal annotations, the description discloses critical behaviors: it 'builds the transaction, signs it, and submits it,' and explains the cooldown period ('~1 epoch') and withdrawal timing. This adds meaningful lifecycle context without contradicting 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 four sentences, each earning its place: the core action, the cooldown lifecycle, the next-step workflow, and the tool recommendation. It is front-loaded with the primary purpose and contains no redundant 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?

Despite lacking an output schema, the description provides an end-to-end understanding: one-shot deactivation, cooldown timing, polling via check_withdraw_ready, and subsequent withdrawal. It also names the alternative tool for custom signing, making it fully actionable for an 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?

The input schema already fully describes all three parameters (wallet address, secret key, stake account address) with specific details, such as the secret key being base58-encoded and used for signing only. The description adds minimal parameter-level meaning beyond the schema, so the baseline 3 is appropriate.

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 action: 'Deactivate a stake account in a single call,' naming the resource (stake account) and the specific behavior. It also distinguishes itself from the sibling tool create_unstake_transaction by describing itself as the recommended one-shot 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?

The description explicitly provides when to use this tool: 'This is the recommended tool — use create_unstake_transaction only if you manage your own signing.' It also gives a clear follow-up workflow: 'Use check_withdraw_ready to poll readiness, then withdraw to reclaim SOL.'

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, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it returns a git commit hash, provides direct source links, and guides the user on how to interpret the returned data. It does not contradict any 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 well-structured and efficient: a single opening sentence states the action, followed by a clear list of verification points and a concluding directive. Every sentence contributes to understanding the tool's purpose and usage 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?

Given the tool's simplicity (no parameters, no output schema), the description is fully complete. It explains what the tool returns (hash + links), why it is useful (confirm specific code properties), and how to use the returned links. There are no significant 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?

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameters, and it correctly focuses on the tool's output and usage. No parameter-related ambiguity exists.

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 the code running on Blueprint servers.' It also specifies what the tool returns (git commit hash and direct links to source) and lists concrete verification goals, clearly distinguishing it from sibling tools like check_balance or verify_transaction.

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

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

The description provides clear context for when to use the tool ('Don't trust — read the code yourself via the source endpoints') and gives specific verification scenarios (private keys logged, Memo Program instruction, generate_wallet behavior). It does not explicitly name alternative tools, but the purpose is clear enough that an agent can infer when to use it.

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

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

Annotations already indicate a safe, read-only operation, lowering the burden. The description adds meaningful behavioral context beyond annotations: it explains the on-chain mechanism (Memo Program instruction), the cryptographic and immutable nature of the evidence, and the return value ('verified: true/false with the on-chain evidence'). This is rich and helpful.

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 (three sentences) and front-loaded with the primary purpose. Every sentence adds value: the first states what it does, the second explains the technical proof, and the third provides usage guidance and expected output. No waste or irrelevant 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?

Given the tool's simplicity (one parameter, no output schema), the description fully covers the operation's purpose, method, use case, and return value. It is complete and self-contained, likely sufficient for an agent to invoke it correctly without additional context.

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 already fully describes the single required parameter ('signature' with description 'Solana transaction signature to verify'), achieving 100% schema coverage. The description does not add significant new parameter semantics beyond what the schema provides, so the baseline of 3 is appropriate.

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 ('Verify'), a specific resource ('a Solana transaction'), and a distinctive method (checking for the Blueprint Memo Program instruction). This clearly distinguishes it from sibling tools like verify_code_integrity or check_balance.

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 says 'Use this to verify any claim that a stake was placed through Blueprint,' providing clear guidance on when to apply the tool. It does not explicitly compare with alternatives, but the use case is strongly defined and relevant to the sibling context.

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 explains the transaction flow ('Builds the transaction, signs it, and submits it') and outcome ('Funds are returned to your wallet'), which is beyond the annotation hints (readOnlyHint=false, destructiveHint=false). It also clarifies the optional amount behavior ('Omit amountSol to withdraw the full balance'). No contradiction with annotations.

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

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

Six short sentences, each with a distinct purpose: scope, process, outcome, prerequisite, optional param, and alternative. No fluff or redundancy; front-loaded with the core purpose.

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 non-trivial signing/submission tool, the description addresses the essential workflow, prerequisites, and alternatives. Lacks explicit error/failure discussion, but given the check_withdraw_ready prerequisite and schema richness, it is sufficiently 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 covers all four parameters with descriptions (100% coverage), including the optional amountSol. The description's note about omitting amountSol duplicates the schema's own description, adding no new parameter semantics beyond the baseline.

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 'Withdraw SOL from a deactivated stake account in a single call' – a clear verb+resource+scope. It further differentiates from the sibling withdraw_stake by noting it is the recommended tool and that withdraw_stake is only for manual signing.

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

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

Explicitly instructs 'Use check_withdraw_ready first to confirm the account is ready' and provides a direct alternative: 'use withdraw_stake only if you manage your own signing.' This gives both when-to-use and 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?

The description discloses that the tool builds an unsigned transaction for local signing, which is a key behavioral trait not captured by annotations. It also signals it is an 'Advanced' operation. However, it does not detail potential side effects or prerequisites, but given the annotations already provide safety hints, this is sufficient.

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 fluff. The first sentence immediately states the purpose and mode, the second provides usage guidance. Every word earns its place, and the 'Advanced' prefix sets expectations upfront.

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 is complete for a tool of this complexity (3 params, no output schema). It explains the tool's role in the withdrawal flow, differentiates it from the sibling tool, and notes the local signing use case. No further details are necessary to invoke or select 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?

The input schema already provides full descriptions for all 3 parameters with 100% coverage. The description adds context that this is an unsigned transaction, which clarifies why parameters like 'amountSol' are part of the transaction-building process, but it does not go beyond the schema's parameter-level detail. Baseline 3 applies 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 clearly states 'Build an unsigned withdraw transaction for local signing,' specifying the exact action and output. It also distinguishes itself from the sibling 'withdraw' tool by noting that most agents should use that tool instead, making its unique purpose unambiguous.

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

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

Explicit guidance is provided: 'Most agents should use the `withdraw` tool instead, which handles signing and submission automatically.' This directly tells the agent when to choose this tool over an alternative, making the usage context very clear.

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