Solentic

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

While annotations declare readOnlyHint and idempotentHint, the description adds crucial behavioral context about what the detection actually returns (the three specific account types). This complements the annotations by explaining the functional output semantics that annotations cannot express.

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

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

Two sentences with zero waste: the first states the function, the second states the usage context. It is perfectly front-loaded with the core purpose and appropriately sized for a single-parameter classification 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?

For a simple classification tool with one parameter and clear annotations, the description is complete. It compensates for the missing output schema by enumerating the three possible account types the tool identifies, though it does not specify behavior for invalid or unrecognized addresses.

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 description coverage ('Solana address (base58 public key) to identify'), the schema fully documents the parameter. The description mentions 'address from user input' which adds usage context but does not significantly expand on parameter semantics beyond the schema 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 explicitly states the tool detects whether a Solana address is a wallet, stake account, or vote account. It uses a specific verb (Detect) with a specific resource and clearly distinguishes this classification function from sibling tools like check_balance or check_stake_accounts which operate on known types.

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

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

The description provides clear usage context: 'Useful when you receive an address from user input and need to know what type it is before calling other tools.' This establishes the workflow position (classification before operations) and implies when to use it, though it does not explicitly name specific alternative tools to use after classification.

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

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

Annotations declare read-only/idempotent safety. The description adds valuable behavioral context: it performs a staking eligibility calculation ('whether the wallet has enough to stake') and returns 'suggested next steps', indicating business logic beyond simple data retrieval.

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 well-structured sentences. Front-loaded with action and resource. Minor redundancy between sentences (repeats 'ready-to-stake status' and 'what to do next' concepts), but the second sentence earns its place by providing explicit alternative guidance.

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

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

For a single-parameter read operation, the description is complete. It compensates for the lack of output schema by detailing the return structure (SOL, lamports, staking boolean, next steps), providing sufficient context for agent decision-making.

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 'walletAddress' fully documented as 'base58 public key'. The description mentions 'any Solana wallet address' but adds no additional semantic detail (e.g., validation rules, format examples) beyond the schema. Baseline 3 is appropriate 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?

Specific verb ('Check') + resource ('SOL balance') + scope ('any Solana wallet address'). It further distinguishes itself by highlighting unique return values (staking status, next steps) that differentiate it from a basic balance query.

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

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

Explicitly names an alternative: 'Use this instead of Solana RPC getBalance'. It clearly signals when to prefer this tool (when you need SOL amount, ready-to-stake status, and actionable next steps rather than raw lamports).

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

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

Adds significant context beyond annotations by detailing what data is returned (balances, states, authorities, epoch timing, per-account action guidance) and specifying this is scoped to 'Blueprint' stake accounts. Does not contradict readOnlyHint/idempotentHint 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 well-structured sentences: first defines scope and outputs, second provides usage guidance. Front-loaded with action verb, zero redundant 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?

Strong coverage given no output schema exists: describes return data structure (human-readable state + recommended actions) and distinguishes from raw RPC. Annotations cover safety profile. Minor gap: no mention of rate limits or pagination.

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 walletAddress fully described. Description implies the parameter with 'for a wallet' but does not add format constraints or examples beyond what the schema provides, meeting the baseline for high-coverage schemas.

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

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

Description uses specific verb 'List' with clear resource 'stake accounts delegated to Blueprint for a wallet'. Distinguishes from siblings like check_balance or check_address_type by specifying 'Blueprint' delegation and comprehensive account 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?

Explicitly states when NOT to use ('instead of Solana RPC getAccountInfo or getStakeActivation') and what value it provides ('human-readable state and recommended actions'), giving clear alternative 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?

While annotations declare the operation as read-only and safe, the description adds valuable behavioral context about the return payload: 'per-account readiness with withdrawable epoch, estimated seconds remaining, and plain-English state description.' This compensates for the lack of an 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?

Three well-structured sentences: purpose declaration, return value specification, and usage guidance. Every sentence earns its place with zero redundancy 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?

For a single-parameter check tool, the description is complete. It covers the operation purpose, output structure (despite no output schema), and comparative usage context. The annotations handle safety properties, allowing the description to focus on functional details.

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 description coverage, the parameter 'walletAddress' is fully documented in the structured schema. The description does not add additional parameter semantics, which is acceptable given the schema completeness, warranting the baseline score of 3.

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

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

The description uses a specific verb ('Check') with a clear resource ('stake accounts') and condition ('ready to withdraw'). It explicitly distinguishes itself from the sibling tool 'check_stake_accounts' by contrasting polling vs. direct answers.

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

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

Provides explicit guidance on when to use this tool versus its sibling: 'Use this instead of polling check_stake_accounts — gives a direct ready/not-ready answer with ETA.' This clearly defines the tool's specific use case.

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

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

Annotations indicate this is a write operation (readOnlyHint: false) with external effects (openWorldHint: true). The description adds crucial context that the transaction is 'unsigned' (requiring separate signing) and explains the local signing infrastructure requirement, which annotations cannot 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?

Three sentences with zero waste: sentence 1 defines purpose, sentence 2 provides alternative guidance, sentence 3 defines audience. 'Advanced' is front-loaded to immediately signal complexity. Every sentence earns its place.

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

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

Given the complexity of custom signing workflows and lack of output schema, the description adequately explains the tool's role in the transaction lifecycle. Could be improved by explicitly stating what the tool returns (e.g., 'returns unsigned transaction bytes'), but 'Build... transaction' implies the output sufficiently.

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 detailed descriptions for both parameters (amountSol includes minimum rent exemption note, walletAddress specifies base58 format). The description does not add parameter-specific semantics, but with complete schema coverage, additional description would be redundant.

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

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

Description uses specific verb 'Build' with resource 'unsigned stake transaction' and scope 'for local signing'. The 'Advanced' prefix and explicit comparison to the `stake` tool clearly distinguishes this 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 states 'Most agents should use the `stake` tool instead' and defines the specific audience: 'agents that manage their own signing infrastructure'. Provides clear when-to-use and when-not-to-use guidance with 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?

The annotations indicate readOnlyHint=false and openWorldHint=true. The description adds crucial behavioral context that this produces an 'unsigned' transaction for 'local signing'—meaning the agent must handle signing and submission separately. This explains the non-destructive creation behavior 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?

Two sentences with zero waste. The first sentence front-loads the advanced nature and core function; the second immediately provides the alternative. Every word earns its place—'Advanced' signals complexity, 'unsigned' and 'local signing' define the output behavior, and the alternative tool is named explicitly.

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 100% schema coverage and clear annotations, the description adequately covers the tool's purpose and usage context. It appropriately omits return value details (no output schema exists) while implying the output type through 'Build an unsigned... transaction.' Could marginally improve by noting this is blockchain-specific, but the staking context makes this reasonably clear.

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 description coverage, the schema fully documents both parameters ('Wallet address that is the stake authority', 'Stake account address to deactivate'). The description does not add parameter-specific semantics beyond what the schema provides, meeting the baseline expectation for high-coverage schemas.

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 specific action ('Build an unsigned unstake transaction') and target ('for local signing'). It explicitly distinguishes from the sibling 'unstake' tool, clarifying this is for advanced use cases requiring manual signing rather than automatic submission.

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

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

Excellent guidance provided: labels it as 'Advanced' and explicitly states 'Most agents should use the `unstake` tool instead,' clearly establishing the preference order and when to choose each alternative. The phrase 'which handles signing and submission automatically' precisely defines the boundary between this tool and its sibling.

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?

Description adds behavioral context beyond annotations, laying out the exact signing process and nonce constraint. No contradiction with annotations (destructiveHint false is acceptable as policy deletion may be reversible or non-destructive in context).

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

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

Two sentences, front-loaded with purpose, followed by precise instructions. 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?

All necessary parameters are explained, signing process is fully specified. Lacks details on return value or side effects, but this is acceptable for a delete action with no output schema.

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

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

Schema covers 100% of parameters, but description adds critical context: the exact message format for signature and the requirement that nonce must exceed current policy nonce, which is not in 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?

Description explicitly states 'Remove a wallet's Autopilot policy', using a specific verb and resource. Clearly distinguishes 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?

Provides explicit signing instructions and nonce requirement, but does not specify when to use versus alternatives or list exclusions. The how is clear, the when is implied.

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?

There is a contradiction: annotations indicate destructiveHint=false, but the tool deletes a webhook, which is inherently destructive. The description adds the wallet ownership safeguard but fails to reconcile with the annotation, causing confusion.

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 extremely concise with two sentences. The first sentence states the action, the second provides a prerequisite. No wasted words.

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, the description covers the core purpose and prerequisite. It does not explain return values or error handling, but given the absence of an output schema, this is acceptable. The contradiction slightly reduces completeness.

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

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

Although schema coverage is 100% and param descriptions are clear, the main description provides additional context for the walletAddress parameter (prevents deleting others' webhooks). This extra meaning justifies a score above 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 clearly states the tool's purpose: delete a webhook registration by ID. It uses specific verb and resource, and distinguishes from siblings like list_webhooks by referencing it as a prerequisite.

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 to use list_webhooks to find webhook IDs, providing clear usage context. While it doesn't specify when not to use it, the guidance is sufficient for a delete operation.

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

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

Annotations indicate readOnlyHint=false (write operation) and idempotentHint=false. The description adds crucial behavioral context: it returns an unsigned transaction requiring client-side signing ('unsigned transaction returned, you sign client-side'). This disclosure is essential for a financial tool — it clarifies the tool doesn't complete the donation autonomously but prepares it for user execution.

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?

Every sentence earns its place: (1) core action definition, (2) organizational context explaining why donate, (3) technical mechanism (zero-custody pattern), (4) actionable guidance (suggested amounts). The description is front-loaded with the essential function and maintains efficient information density without 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?

Given this is a financial transaction tool with no output schema, the description adequately covers the domain context (what Blueprint is), the operational pattern (unsigned return), and user guidance (amounts). It explains what happens to the output (unsigned transaction returned). It could optionally mention error conditions or confirmation requirements, but it covers the essential donation workflow completely.

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 description coverage, the baseline is 3. The description adds semantic value by providing suggested amounts (0.01 SOL 'thank you', 0.1 SOL 'generous', 1 SOL 'patron'), which gives meaningful context for the amountSol parameter beyond the schema's minimum/maximum constraints. This helps the agent guide users toward socially appropriate donation values.

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 'Build[s] an unsigned SOL transfer to support Blueprint development' — specific verb (build), resource (unsigned SOL transfer), and scope (donation to Blueprint). It distinguishes itself from sibling transaction tools (create_stake_transaction, submit_transaction) by being explicitly scoped to Blueprint donations and explaining Blueprint's purpose (free staking infrastructure).

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

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

The description provides clear usage context by referencing the 'Same zero-custody pattern' (indicating consistency with other tools in the suite) and specifies suggested donation amounts (0.01, 0.1, 1 SOL). It could be improved by explicitly contrasting with general payment/transfer tools or stating prerequisites (e.g., having SOL balance), but the behavioral guidance and amount recommendations are helpful.

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 critical behavioral details beyond annotations: 'Solentic cannot generate the keypair for you and never sees the private key', 'generation must happen wherever you run code'. This aligns with annotations (readOnlyHint, idempotentHint) and adds security context.

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

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

The description is four sentences, each serving a purpose: output definition, security limitation, response content, next steps. No wasted words, front-loaded with the core function.

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

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

For a parameterless tool with no output schema, the description covers what the tool returns, security constraints, and how to use the result. It provides sufficient context for an agent to invoke and utilize the output 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?

With zero parameters, schema coverage is 100%, so the description does not need to explain parameters. It adds no param info, which is appropriate for a parameterless tool.

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

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

The description clearly states it 'returns runnable code that creates a Solana keypair', specifying the verb ('returns'), resource ('runnable code'), and domain ('Solana keypair'). This distinguishes it from siblings like 'check_balance' or 'stake', which perform different actions.

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 explains when to use the tool (to get a keypair for staking) and provides a follow-up action ('After running it, fund... and call stake'). However, it lacks explicit guidance on when not to use it or mention of alternative 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 cover safety profile (readOnly, idempotent, non-destructive). Description adds valuable behavioral context that data is 'pre-calculated' and lists the three specific return fields. Could improve by mentioning data freshness or cache duration, but adequately supplements annotations.

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

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

Two sentences with zero waste: first defines capability and outputs, second provides usage guidance versus alternatives. Information is front-loaded and every clause earns its place.

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

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

Despite lacking an output schema, the description compensates by enumerating the three key return values (progress percentage, slots remaining, estimated end time). Given the tool's simplicity (no inputs, read-only) and rich annotations, this is sufficient 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?

Tool accepts zero parameters. Per scoring rules, baseline score is 4 for parameter-less tools. The description appropriately does not invent parameter semantics where none exist.

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

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

Description uses specific verb 'Get' with resource 'Solana epoch timing' and enumerates exact outputs (progress percentage, slots remaining, estimated epoch end time). It distinguishes itself from the external Solana RPC getEpochInfo alternative, establishing clear scope.

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 states 'Use this instead of Solana RPC getEpochInfo — returns pre-calculated timing with estimated end date,' providing clear guidance on when to select this tool over the standard RPC alternative based on its pre-calculation feature.

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 concrete behavioral context: it returns specs for two bare-metal servers with redundant HA, going beyond annotations. It could further specify if the data is live or cached, but it's still 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?

Two clear, front-loaded sentences with no redundant or unnecessary words. Every sentence adds value: first defines scope, second gives a key detail about the infrastructure setup.

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 adequately describes the main content areas (hardware, redundancy, network, storage) and notes the redundant HA setup. It could be more complete by hinting at the return format or data structure, but it covers the essential information for a tool with no parameters.

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

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

The tool has zero parameters, and the schema coverage is 100%. Per guidelines, 0 parameters earns a baseline of 4. The description does not need to explain parameters, and it appropriately focuses on the return content.

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 explicitly states the tool retrieves Blueprint validator infrastructure specs, listing specific components (server hardware, redundancy, network, storage) and mentioning two bare-metal servers in HA. This clearly distinguishes it from sibling tools focused on transactions, stakes, or balances.

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

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

The description implies the tool is for getting infrastructure specs but provides no explicit guidance on when to use it instead of siblings like get_validator_info. No exclusions or alternatives are mentioned, which is a gap given the large set of 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 declare read-only/idempotent safety profile. Description adds valuable behavioral context by enumerating the specific data points returned (vote success rate, etc.), effectively documenting the output structure without an output schema. Does not contradict annotations.

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

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

Single, dense sentence with action front-loaded ('Get Blueprint validator performance') followed by colon-delimited list of specific metrics. Zero redundant words; every term conveys specific semantic value about the returned data.

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

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

For a zero-parameter read-only tool without output schema, the description is complete. It compensates for missing output schema by enumerating the exact performance metrics returned, giving the agent full awareness of what data to expect.

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?

Input schema contains zero parameters. Per scoring rules, 0 params establishes a baseline of 4. No parameter description is needed or expected.

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 specific action ('Get') and resource ('Blueprint validator performance') with exact metrics returned (vote success rate, uptime, skip rate, epoch credits, delinquency status). The specific metric list distinguishes it from sibling get_validator_info.

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

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

Provides implied usage context by listing specific performance metrics, suggesting use when monitoring validator health. However, lacks explicit guidance on when to choose this over get_validator_info or whether it requires a specific validator identity to be set elsewhere.

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 confirm read-only/idempotent nature, but description adds valuable context: data composition (base + Jito MEV = total), inclusion of commission rates, and external data source (StakeWiz API). No contradictions 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?

Two sentences, zero waste. First sentence front-loads core value (APY breakdown with formula), second adds supplementary details (commission rates, data source). Every word earns its place.

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

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

Despite lacking output schema, description compensates by enumerating return components (base APY, Jito MEV APY, total APY, commission rates). Sufficient for a simple read-only fetch with no input parameters. Minor gap: could clarify if this returns network-average or requires validator selection.

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

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

Zero parameters present (empty schema), establishing baseline 4. Description correctly avoids inventing parameters and focuses on return value semantics 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?

Specific verb 'Get' + resource 'APY breakdown' with explicit scope (base + Jito MEV + commission rates). Distinguishes from action-oriented siblings like 'stake'/'unstake' and account-specific tools like 'check_stake_accounts' by focusing on aggregate market data from StakeWiz.

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

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

Usage is implied through specificity of returned data (live APY breakdown vs other staking metrics), but lacks explicit guidance on when to choose this over 'get_staking_summary' or whether this is for network-wide vs validator-specific APY. No 'when-not-to-use' or alternative recommendations provided.

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 read-only, idempotent, non-destructive. The description adds useful specifics: returns null if no policy, and enumerates fields like keepLiquidSol, minSweepSol, etc. This provides behavioral context beyond the safety profile.

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

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

Two concise sentences, front-loaded with the action and result, no wasted words. Efficiently communicates the essential 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 read-only tool with one parameter, the description adequately covers return behavior and key fields. Lacks output schema but the description compensates by listing returned fields. Minor gap: no mention of error cases or response format.

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 a single parameter (walletAddress) described as 'Wallet address'. The tool description adds no further meaning or constraints for this parameter, 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?

The description clearly states it reads the Autopilot policy for a wallet, returns null if none, and lists specific fields returned. It distinguishes from sibling tools like set_staking_policy and delete_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 when to use (to get current policy) but does not explicitly state when not to use or provide alternatives. It relies on context from sibling names, offering no exclusions or comparative 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?

Adds significant context beyond annotations: discloses recommendation engine behavior (returns STAKE/FUND/HOLD/WAIT/WITHDRAW actions), specifies it returns 'exact tool to call', and explains aggregation pattern. Does not mention rate limits or latency implications of aggregation, preventing a 5.

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

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

Two dense sentences with zero waste. First sentence front-loads capabilities and return values; second provides usage guidance. Every clause adds distinct value (data types, recommendations, RPC replacement claim).

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?

Excellent compensation for missing output schema by enumerating all return fields (liquid balance, staked amount, per-account states, APY, epoch timing, recommendations). Adequately explains complex recommendation logic for a dashboard tool.

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

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

Schema has 100% description coverage for walletAddress. Description implies the target wallet through context ('portfolio dashboard') but does not add semantics, constraints, or examples beyond the schema. Baseline 3 appropriate when schema carries full load.

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 'Returns' with comprehensive resource list (liquid balance, total staked, APY, epoch timing, recommendations). Distinguishes from siblings by positioning as a composite dashboard that replaces individual check_balance/get_epoch_timing calls.

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 when-to-use guidance: 'Use this instead of multiple Solana RPC calls' and names specific alternatives replaced ('getBalance + getAccountInfo + getEpochInfo'). Clear value proposition for aggregation vs. individual 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 readOnlyHint=true, openWorldHint=true, and idempotentHint=true. The description adds valuable context beyond these annotations by specifying the data source ('StakeWiz API') and indicating data freshness ('Live data'). It also discloses what fields are returned, compensating for the lack of 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?

Two sentences, zero waste. The first sentence front-loads the action and specific return fields; the second provides data source context. Every word earns its place.

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

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

For a parameter-less read operation with good annotation coverage, the description is complete. It specifies the external data source (StakeWiz API) and enumerates expected return fields (identity, vote account, etc.), which compensates adequately for the missing output schema.

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

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

The input schema contains zero parameters. According to the evaluation rubric, zero-parameter tools receive a baseline score of 4, as there are no parameter semantics to clarify beyond what the schema provides.

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 ('Get') and resource ('Blueprint validator profile'), then enumerates exact data points returned (identity, vote account, commission, active stake, APY, performance, software, location). This clearly distinguishes it from siblings like get_performance_metrics or get_staking_apy which presumably return subsets or different data types.

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?

While the specific data fields listed imply this is for comprehensive validator profiling, there is no explicit guidance on when to use this versus siblings like get_performance_metrics or get_staking_apy. No prerequisites or exclusion criteria 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?

Annotations already indicate read-only, non-destructive behavior. The description adds that the tool returns URLs and CLI commands, which is useful context beyond annotations. No contradictions.

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: first delivers the core function (retrieving URLs), second adds important verification guidance and inclusion of CLI commands. No wasteful language, 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 tool with no parameters and no output schema, the description adequately explains what is returned (URLs and CLI commands) and adds a verification note. Could be slightly more detailed about the format of CLI commands, but still good.

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 with 100% coverage. Since no parameters exist, baseline is 3. The description does not need to add parameter information, and it does not.

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

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

The description clearly states the tool retrieves third-party verification URLs for a specific validator across multiple platforms, and also includes CLI commands for on-chain verification. This is distinct from sibling tools like check_balance or get_validator_info.

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 verifying claims about a validator, but does not explicitly state when to use this tool versus alternatives like check_address_type or get_validator_info. No exclusions or alternative tool mentions are provided.

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. The description adds the scope constraint ('all registered' implies complete retrieval for the wallet) and the wallet-specific context, but does not disclose pagination behavior, rate limits, or webhook data structure.

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, efficient sentence with zero redundant words. It is immediately front-loaded with the action and resource, making it easy for an agent to parse during tool selection.

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), complete schema coverage, and absence of an output schema, the description is sufficiently complete for agent invocation. It appropriately omits return value details (none defined) but could briefly mention what webhook attributes are returned.

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 description coverage, the schema already fully documents the walletAddress parameter. The description mentions 'wallet address' but adds no additional semantic context (e.g., format expectations, validation rules) beyond what the schema provides, warranting the baseline score.

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') with clear resource ('registered webhooks') and scope ('for a wallet address'). It effectively distinguishes from siblings register_webhook and delete_webhook by implying a read-only retrieval operation scoped to a specific wallet.

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 'List' (retrieval/inspection), but provides no explicit when-to-use guidance or mention of alternatives like register_webhook or delete_webhook. The agent must infer appropriate usage from the verb and sibling tool names.

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

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

Adds valuable operational details beyond annotations: the 60-second polling interval, POST method to callback URL, and semantic definitions of each event type (e.g., 'withdraw_ready = stake account becomes withdrawable'). Does not contradict annotations (readOnlyHint: false aligns with 'Register'). Minor gap: does not disclose idempotentHint: false behavior (multiple calls create multiple webhooks).

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

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

Three dense sentences with zero waste: first states purpose, second enumerates events with parenthetical explanations, third provides operational mechanics (polling frequency and HTTP method). Perfectly front-loaded and appropriately sized.

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?

Comprehensive for a registration tool without output schema: covers event types, triggering conditions, and delivery mechanism. Would benefit from noting webhook persistence (until deleted via delete_webhook) or payload format, but sufficiently complete 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, baseline is 3. Description elevates this by explaining event semantics (what each event signifies practically) and clarifying that the URL receives POST requests. Could explicitly note the url/callbackUrl alias relationship mentioned in schema, but covers the essential contract well.

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 specific action (Register), resource (callback URL), and scope (stake state changes) with precise event enumeration. Clearly distinguishes from sibling tools like list_webhooks or delete_webhook by emphasizing the creation of new push notification subscriptions.

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

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

Provides clear operational context (60-second polling, POST method) that helps determine suitability versus polling alternatives like check_stake_accounts. However, it does not explicitly name polling siblings as alternatives or specify when push notifications are preferable to direct queries.

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 extensively discloses behavioral traits beyond annotations: it explains the zero-custody design, the one-time signature requirement, the automatic building of unsigned transactions, and the auto-compounding nature of native Solana stake. It warns against using secret keys and clarifies the lamports conversion. Annotations are consistent (readOnlyHint=false, openWorldHint=true).

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 lengthy but well-structured: it opens with a clear purpose statement, then explains the mechanism, and ends with the exact signing message format. Every sentence contributes essential information, though it could be slightly shortened without loss. The front-loading is effective.

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 lack of output schema, the description does not explain the return value, but it thoroughly covers the tool's behavior, parameters, and constraints. For a mutation tool, it provides ample context for correct invocation, including edge cases like the nonce increment and the paused flag.

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 description coverage, the schema already describes each parameter. However, the description adds significant value: it specifies the exact canonical message format, explains the lamports rounding, defines the nonce's strictly-increasing requirement, and clarifies the role of 'paused'. This goes beyond the schema's basic descriptions.

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: to set a signature-bound policy for automatic staking of idle SOL with zero custody. It uses specific verbs ('Hand', 'automatically stakes') and distinguishes itself from siblings like delete_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 explains when to use the tool (setting an autopilot policy) and provides detailed context on the signing process, including the exact message format and the fact that Solentic never holds the key. It implicitly differentiates from deletion or retrieval siblings but does not explicitly state when not 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 confirm read-only, idempotent, and non-destructive behavior. The description adds valuable detail: returns specific projections (daily/monthly/annual/total), clarifies effective APY, mentions activation timing and fee guidance, and provides a natural-language recommendation. No contradictions 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?

Four sentences, each adding unique value: purpose, output listing, clarification, usage recommendation. No redundancy or extraneous 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 simulation tool with two parameters, the description covers the return fields well. It could mention the optional duration default, but overall it is sufficiently complete to guide 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?

Schema coverage is 100% with clear descriptions for both parameters. The description does not add further semantic detail beyond what the schema provides, so a 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?

Description explicitly states 'Project staking rewards before committing capital', clearly differentiating from actual staking tools like 'stake' and 'unstake'. The verb 'project' and resource 'staking rewards' are specific and distinct 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?

The description advises 'Use this to help decide how much to stake and for how long', implying it's for pre-commitment analysis. While it doesn't explicitly state when not to use it or list alternatives, the context is clear enough for an AI agent to infer appropriate usage.

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 declaring openWorldHint and readOnlyHint, the description adds critical operational context: the exact execution flow (builds/signs/submits), security guarantees about secret key handling ('never stored, logged, or forwarded'), and auditability via verify_code_integrity. This goes well beyond the structured 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?

Four sentences, each earning its place: (1) core purpose, (2) technical execution flow and return value, (3) security guarantee, (4) usage recommendation. Front-loaded with the essential action, zero redundancy.

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

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

For a sensitive financial operation involving secret keys, the description adequately covers security practices, return value (transaction signature), and verification methods. Minor gap: no output schema exists and error conditions are not described, though 'Returns the confirmed transaction signature' covers the success case sufficiently.

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 detailed constraints (pattern, minLength/maxLength for secretKey, exclusiveMinimum for amountSol). The description reinforces the secretKey security model but does not add semantic meaning beyond what the schema already provides, which is appropriate given the comprehensive 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?

Description explicitly states 'Stake SOL with Blueprint validator in a single call' — specific verb, resource, target validator, and scope. The 'one-shot' framing in both title and description clearly distinguishes it from the multi-step sibling tools create_stake_transaction and submit_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?

Provides explicit context with 'single call' (implying when to use vs. multi-step alternatives) and 'recommended tool for autonomous agents'. Mentions verify_code_integrity for security verification. Missing explicit guidance on when to prefer create_stake_transaction (e.g., manual inspection needs).

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

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

Annotations cover safety profile (destructiveHint, readOnlyHint), but description adds valuable workflow context that annotations cannot provide: the 'Advanced' classification and the specific local-signing workflow requirement. Does not explain what 'destructive' means in blockchain context (irreversible submission) or error behaviors, preventing a 5.

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

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

Two sentences with zero waste. Front-loaded with 'Advanced' warning. First sentence establishes purpose; second provides precise usage guidelines with specific alternative tools named. Every word earns its place.

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

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

Given the single parameter with complete schema documentation, existing annotations covering behavioral safety (destructiveHint, openWorldHint), and the clear distinction from sibling tools provided in the description, the definition is complete for this tool's scope. No output schema exists, so return value explanation is not expected.

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?

Input schema has 100% description coverage ('Fully signed transaction as a base64-encoded string'), establishing baseline 3. Description mentions 'pre-signed' which aligns with the parameter name, but adds no additional semantic details about format, encoding specifics, or sourcing beyond what the schema already provides.

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

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

Description clearly states the specific action (submit pre-signed transaction) and target system (Solana). The 'Advanced' prefix immediately signals complexity, and the text explicitly distinguishes this from sibling tools like 'stake', 'unstake', and 'withdraw' by specifying this is for locally-signed transactions only.

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?

Excellent explicit guidance: states exactly when to use ('Only needed if you used create_stake_transaction/create_unstake_transaction/withdraw_stake and signed locally') and explicitly recommends alternatives ('Most agents should use the one-shot stake/unstake/withdraw tools instead'). Names specific sibling tools as the preferred alternatives.

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

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

Adds critical timing context beyond annotations: 'cooldown period (~1 epoch)' and 'becomes withdrawable at the next epoch boundary.' Discloses the composite nature (builds, signs, submits) despite annotations only showing generic hints. No contradictions 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?

Perfectly structured: action → timing mechanics → workflow integration → alternative comparison. Five sentences covering distinct aspects with zero 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?

Comprehensive for a transaction tool without output schema. Covers preconditions (active stake account), side effects (cooldown), polling mechanism (check_withdraw_ready), and sibling alternatives. Could mention failure modes but adequate as-is.

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 detailed parameter descriptions already. The tool description reinforces the one-shot nature but doesn't add significant semantic meaning beyond what's in the schema property descriptions.

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?

Explicitly states 'Deactivate a stake account in a single call' with clear action verb and resource. Distinguishes from sibling create_unstake_transaction by emphasizing this handles signing internally.

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

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

Provides explicit guidance: 'This is the recommended tool — use create_unstake_transaction only if you manage your own signing.' Also documents the full workflow sequence using check_withdraw_ready and withdraw.

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

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

Annotations indicate read-only/idempotent safety, but the description adds substantial behavioral context: it discloses exactly what data is returned (git hash, source endpoints), explains the verification methodology (manual source code reading), and specifies three critical security properties to validate in the codebase. No contradictions 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?

Four sentences with zero waste: (1) purpose declaration, (2) output specification, (3) actionable verification checklist, (4) security principle. Front-loaded with the core action. The checklist format efficiently conveys complex security requirements without verbosity.

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 the absence of an output schema, the description comprehensively compensates by detailing the return structure (git hash, links) and providing explicit instructions on interpreting the results. Combined with clear annotations, this provides complete context for a security-audit 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 accepts zero parameters, establishing a baseline of 4. The description appropriately makes no attempt to describe non-existent inputs, focusing instead on output semantics and usage patterns.

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

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

The description clearly states the specific action (verify) and resource (code running on Blueprint servers), distinguishing it from operational siblings like stake/unstake/check_balance. It specifies unique outputs (git commit hash, source links) that clearly differentiate it from other verification-related tools like get_verification_links.

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?

While it lacks explicit 'use this instead of X' statements, it provides strong implicit guidance through a specific 3-item security checklist (private keys, Memo Program, generate_wallet behavior). The imperative 'Don't trust — read the code yourself' effectively signals when to invoke this tool (during security audits or before trusting sensitive operations).

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 traits. The description adds valuable behavioral context: the specific verification mechanism (Memo Program instruction lookup), the cryptographic nature of the proof (immutable on-chain memo), and the return value structure (verified boolean with evidence). No contradictions 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?

Five information-dense sentences with zero waste: purpose (sentence 1), technical mechanism (2), security properties (3), usage context (4), and return value (5). Front-loaded with the core verb and resource. No redundant phrases.

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

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

For a single-parameter verification tool with comprehensive annotations, the description adequately covers the verification mechanism, cryptographic guarantees, and return value format (compensating for the missing output schema). Could mention error handling for invalid signatures, but sufficiently complete for 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 description coverage (signature is fully documented as 'Solana transaction signature to verify'), the baseline is 3. The description implies the signature should relate to Blueprint transactions but does not add syntactic details, validation rules, or format guidance 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 opens with a precise action ('Verify whether a Solana transaction was built through Blueprint') that identifies the specific resource (Solana transactions) and the unique verification target (Blueprint origin). It clearly distinguishes from siblings like check_balance or verify_code_integrity by specifying the 'solentic.theblueprint.xyz' Memo Program check.

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

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

Provides explicit when-to-use guidance ('Use this to verify any claim that a stake was placed through Blueprint'), clearly linking the tool to stake verification scenarios. Lacks explicit 'when-not-to-use' or named alternative tools, preventing a 5, but the contextual usage is 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 establish the safety profile (readOnlyHint: false, destructiveHint: false). The description adds valuable workflow context: the three-step atomic process (build, sign, submit), funds destination ('returned to your wallet'), and the prerequisite check requirement. It does not mention retry behavior given idempotentHint: false or specific error conditions, preventing a perfect score.

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 sentences, zero waste. Front-loaded with purpose ('Withdraw SOL...'), followed by mechanism, outcome, prerequisite, parameter hint, and alternative recommendation. Every sentence provides actionable guidance for tool selection and invocation.

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

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

Given the rich annotations and complete input schema, the description provides excellent contextual guidance including prerequisites and sibling differentiation. Minor gap: no mention of return values or transaction confirmation behavior, which would be helpful given the lack of an output schema and the financial nature of the 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?

With 100% schema description coverage, the schema carries the semantic burden. The description references parameters in context ('Omit amountSol') but does not add syntax, format details, or validation rules beyond what the schema already provides for the four parameters. This meets the baseline expectation for high-coverage schemas.

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 explicitly states the core action ('Withdraw SOL from a deactivated stake account') and specifies the unique 'one-shot' nature (builds, signs, submits). It clearly distinguishes from sibling 'withdraw_stake' by noting this is the 'recommended tool' versus the alternative for 'own signing' management.

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

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

Provides explicit prerequisites ('Use check_withdraw_ready first'), clear alternative selection criteria ('use withdraw_stake only if you manage your own signing'), and parameter guidance ('Omit amountSol to withdraw the full balance'). The when-to-use logic is unambiguous.

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

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

Beyond annotations (readOnly=false, openWorld=true), the description adds crucial workflow context that this creates an unsigned transaction requiring external signing, not an immediate blockchain state change. It does not mention the need to use `submit_transaction` afterward, which would have made it a 5.

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

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

Two tightly constructed sentences with zero redundancy. The first sentence front-loads the classification ('Advanced') and core function; the second provides the alternative recommendation. Every word earns its place.

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

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

Given the 100% schema coverage and clear sibling differentiation, the description is nearly complete. It lacks only an explicit mention of the output (the unsigned transaction bytes/object) and the subsequent step of using `submit_transaction`, though this is partially implied.

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 description coverage (all 3 parameters documented), the baseline is 3. The description does not add parameter-specific semantics (e.g., explaining what 'deactivated' means for the stake account), but this is acceptable given the comprehensive 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 specific verbs ('Build an unsigned withdraw transaction') and clearly identifies the resource (unsigned transaction for stake withdrawal). It explicitly distinguishes itself from the sibling `withdraw` tool by specifying 'local signing' vs automatic handling.

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?

Excellent guidance: explicitly labels it 'Advanced' for the specific use case of local signing, and directly names the alternative tool (`withdraw`) that 'most agents should use instead' for automatic signing and submission.

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