Solentic

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by disclosing the specific classification outputs and the typical use case (pre-processing addresses), which goes 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?

Two sentences, front-loaded with the core purpose, and every phrase adds value. It is concise without being under-specified.

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

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

With only one parameter, no output schema, and clear annotations, the description covers purpose, usage, and expected outputs. It is sufficiently complete for a simple classification 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 coverage is 100% and the parameter description is already clear ('Solana address (base58 public key) to identify'). The tool description doesn't add further parameter meaning beyond what the schema states, so the 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 uses a specific verb ('Detect') and identifies the exact resource (address type). It clearly distinguishes this tool from siblings like check_balance or check_stake_accounts by stating the three possible classifications (wallet, stake account, vote account).

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 says this is useful for user-supplied addresses needing type identification before calling other tools. While it doesn't name alternatives or exclusions, the context is clear enough to guide appropriate use.

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 destructiveHint=false, establishing a safe read-only profile. The description adds behavioral context by specifying the return format (SOL and lamports), stake sufficiency status, and suggested next steps, which goes beyond the annotation baseline without contradicting it.

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

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

The description is two sentences, front-loaded with the primary action, and every sentence adds value: the first defines the core function, the second explains the output and the alternative. No wasted 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?

With a single well-documented parameter, a simple read-only operation, and no output schema, the description fully covers what is needed. It states the return values (SOL, lamports, stake status, next steps) and provides a comparison to RPC, making it sufficient for an agent to choose 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?

Schema coverage is 100% for the only parameter (walletAddress), with a clear description. The tool description adds little about the parameter itself beyond restating 'any Solana wallet address,' so it does not significantly augment the schema's meaning. 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 opens with a specific verb+resource: 'Check the SOL balance of any Solana wallet address.' It clearly distinguishes from RPC getBalance by noting the return includes SOL amount, stake-readiness status, and suggested next steps. This fully clarifies the tool's scope and 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 directs users to 'Use this instead of Solana RPC getBalance' and explains the added value (stake-readiness status and next steps). However, it does not reference sibling tools like check_stake_accounts or check_address_type, which could be confused with this tool, leaving some ambiguity about when to prefer this over those alternatives.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds value by disclosing the returned content (balances, states, authorities, epoch timing, and action guidance) and noting it returns 'human-readable state and recommended actions'—useful context beyond 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 sentences long, front-loads the core action, and avoids redundancy. Every sentence contributes—first states the function and output, second provides an alternative and benefit. 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?

Given low complexity (1 parameter), rich annotations, and no output schema, the description adequately describes the tool's return content and use case. It omits details like pagination or formatting, but for a list tool with these annotations, this is sufficient.

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 the single parameter walletAddress already described as 'Wallet address to check for Blueprint stake accounts'. The tool description mentions 'for a wallet' but adds no additional parameter meaning, so 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 with a specific verb and resource: 'List all stake accounts delegated to Blueprint for a wallet.' It also lists the output categories (balances, states, authorities, epoch timing, action guidance) and distinguishes itself from Solana RPC alternatives, making the purpose unambiguous within the sibling set.

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 getAccountInfo or getStakeActivation', providing an alternative. It implies the context (when you need stake accounts for a wallet with human-readable state) but does not explicitly state when not to use it or mention sibling tools like get_staking_summary.

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 and idempotent hints. The description adds valuable behavioral context such as returning per-account readiness, withdrawable epoch, estimated seconds remaining, and a plain-English state description, going beyond the 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 concise sentences: first states purpose, second lists return contents, third gives usage guidance. Every sentence earns its place; 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?

Given the tool's simplicity (one parameter, no output schema), the description explains return values enough for an agent to understand what to expect. It also mentions ETA, making it self-contained for 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?

The sole parameter 'walletAddress' is fully documented in the schema with a clear description. The tool description does not add extra parameter details, but schema coverage is 100%, so 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 opens with a specific verb ('Check') and resource ('stake accounts'), clearly stating the tool's function. It differentiates from sibling 'check_stake_accounts' by directly comparing and noting it provides a direct readiness 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?

Explicit guidance is given: 'Use this instead of polling check_stake_accounts', with a reason (direct ready/not-ready answer and ETA). This clearly indicates when to prefer this tool over the 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 description adds valuable behavioral context beyond the annotations by stating the transaction is unsigned and intended for local signing. This explains why readOnlyHint is false (it creates a transaction) but also that it does not submit or affect state immediately, which is not directly inferable from annotations. The gap is minor—it doesn't detail what happens after signing, but the core behavior is clear.

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 efficiently structured in three sentences, each earning its place. The first states the purpose, the second gives the primary alternative, and the third clarifies the target user. No filler or repetition; every sentence adds new 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 complexity (advanced, manual signing) and the presence of strong annotations and a complete schema, the description covers all essential context: what it does, when to use it, who should use it, and how it differs from the standard `stake` path. The lack of an output schema is not an issue because the unsigned transaction is a local artifact, not a return value to be documented.

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% parameter coverage with detailed descriptions for both `amountSol` (including min amount for rent exemption and max) and `walletAddress` (base58 public key). The description itself does not add 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's function: 'Build an unsigned stake transaction for local signing.' This is a specific verb ('Build') and resource ('unsigned stake transaction') that directly distinguishes it from the sibling `stake` tool, which handles signing and submission. The term 'Advanced' further signals a specialized use case.

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 provides usage guidance: 'Most agents should use the `stake` tool instead, which handles signing and submission automatically. This tool is for agents that manage their own signing infrastructure.' This clearly states when to use this tool versus the primary alternative and identifies the target audience.

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

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

The description adds meaningful behavioral context by specifying the transaction is 'unsigned' and for 'local signing', implying no automatic submission. While annotations indicate readOnly=false, the description clarifies the output is a locally-signed transaction, but it does not fully disclose all potential side effects, such as whether the transaction is persisted or if external calls are made.

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. It front-loads the 'Advanced' caveat and immediately follows with the core function and the recommended alternative, making it highly scannable.

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 sufficiently covers the tool's purpose, use case, and alternative. It doesn't specify the exact return format, but 'Build an unsigned unstake transaction' strongly implies a transaction object suitable for local signing, and the absence of an output schema is offset by the clarity of the description.

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

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

Schema coverage is 100%, and the schema already includes descriptive parameter definitions for 'walletAddress' and 'stakeAccountAddress'. The description adds no parameter-level detail, 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 ('Build') and resource ('unsigned unstake transaction'), clearly stating the tool's scope and distinguishing it from the sibling 'unstake' tool that handles signing and submission. It unambiguously defines the tool's function for an advanced audience.

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 tells agents when to use this tool vs. the alternative: 'Most agents should use the unstake tool instead, which handles signing and submission automatically.' This provides clear usage context and a direct 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 description directly contradicts the annotation destructiveHint=false by stating 'Remove a wallet's Autopilot policy.' Removing a policy is a destructive action, but the annotation claims it is not destructive. This is a serious inconsistency that undermines trust in the tool's 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?

The description is a single sentence plus an inline quote, providing essential signing details without unnecessary wording. It is tightly packed and easy 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?

The description thoroughly explains the signing mechanism and nonce condition, but it omits what happens after deletion (e.g., success/failure responses). Additionally, the contradiction with annotations creates a gap in understanding the tool's actual safety and side effects, making it only partially 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 description adds substantial meaning beyond the input schema by specifying the exact newline-separated message to sign and the condition that nonce must exceed the current policy nonce. This is critical operational detail not present in the schema 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 'Remove a wallet's Autopilot policy,' which is a specific verb+resource. It distinguishes from sibling tools like set_staking_policy and get_staking_policy by indicating this is the deletion operation.

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 gives clear context for when to use the tool (to remove a wallet's Autopilot policy) and provides critical signing instructions. However, it does not explicitly mention alternatives or exclusions, which would be the only improvement for a perfect score.

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 that the tool 'deletes' a webhook, which is an inherently destructive operation. Yet the annotation destructiveHint is false, directly contradicting the description's implied behavior. This mismatch could mislead an agent about side effects, and the description fails to add any mitigation (e.g., irreversibility warning).

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 clean, front-loaded sentences with zero redundancy. It states the action first, then provides a practical pointer. Every word earns its place, making it an exemplary concise description.

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 deletion tool with no output schema, the description covers the essentials: what is deleted, the identifying parameter, and how to retrieve valid IDs. It does not mention irreversibility or ownership checks, but those are partially covered by the schema's walletAddress description. The misleading annotation increases the need for extra context, so a 4 is appropriate.

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?

Both parameters are already fully described in the schema (100% coverage), so the baseline is 3. The description adds value by pointing to list_webhooks as the source for webhookId, enriching that parameter's semantics. The walletAddress parameter is well-covered by the schema, so no further description 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 names the action (Delete) and the resource (webhook registration by ID). It distinguishes this tool from siblings like register_webhook and list_webhooks by specifying the deletion operation. The phrase 'by ID' also hints at the key parameter.

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 gives explicit practical guidance: use list_webhooks to find webhook IDs, which establishes the prerequisite workflow. However, it does not discuss when not to use this tool or mention alternative deletion tools (e.g., delete_staking_policy). This is clear context but lacks exclusionary 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 the crucial behavior that the transaction is unsigned and requires client-side signing, which is not captured in the annotations. This explains the zero-custody pattern and sets expectations for the return value. 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?

The description is three sentences, each contributing value: the action, the mission, and the usage pattern. 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?

For a simple two-parameter tool, the description covers the action, return behavior (unsigned transaction), and purpose. It doesn't detail the return format, but the absence of an output schema and the description's clarity about the unsigned transaction make it 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?

The schema already describes both parameters, but the description adds suggested donation amounts (0.01, 0.1, 1 SOL) which provide practical guidance for the amountSol parameter, going beyond schema constraints.

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 an unsigned SOL transfer to support Blueprint development', using a specific verb and resource. It distinguishes itself from sibling transaction builders by specifying the donation context and the unsigned/custody pattern.

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 this tool: when someone wants to donate to Blueprint. It references the 'same zero-custody pattern' as other transaction builders, implying segmentation from staking transaction tools, but doesn't explicitly name alternatives 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable context beyond annotations: that Solentic never sees the private key, the response is a runnable snippet, and generation must happen on the user/code side. This clarifies the tool's non-mutating, code-generation 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 three sentences, front-loaded with the core purpose, then provides necessary context about execution location and next steps. Slightly longer than the minimal viable but each sentence adds crucial information for correct use.

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

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

Given the tool has no parameters, no output schema, and simple behavior, the description is complete: it explains what is returned (runnable snippet), where to run it, and the immediate next steps. It covers the essential behavioral aspects beyond the annotations.

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 schema coverage is vacuous at 100%. The description need not explain parameter details. It provides no parameter semantics, but with no params, the baseline of 4 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 and resource: 'Returns runnable code that creates a Solana keypair.' This distinguishes it from all sibling tools, none of which generate keypair code.

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 that Solentic cannot generate the keypair and that generation must happen external to the agent, providing clear context for when to use this tool. It also gives an explicit follow-up action (fund and call stake), though it doesn't state exclusions or alternative tools explicitly.

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 disclose the tool is read-only, idempotent, and non-destructive. The description adds value by detailing the specific return fields and the 'pre-calculated' nature of the timing, which is behavioral context beyond the annotations. It does not mention any caveats or response format details, but the strong 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?

Two sentences, front-loaded with the core purpose and followed by a directive about the alternative. Every word contributes; 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?

Even without an output schema, the description enumerates the key returned values (progress percentage, slots remaining, estimated end time), making the tool's output clear. The strong annotations cover safety context, and the tool's simplicity means no further details are essential.

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 correctly adds no parameter-specific guidance since none exist, and the schema coverage is trivially 100%.

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: retrieving current Solana epoch timing, specifying the exact data fields (progress percentage, slots remaining, estimated epoch end time). It also explicitly contrasts with Solana RPC getEpochInfo, making its purpose distinct from external alternatives and 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?

The description provides explicit guidance: 'Use this instead of Solana RPC getEpochInfo', with a clear reason ('returns pre-calculated timing with estimated end date'). This directly tells the agent when to choose this tool over a known alternative, satisfying the when-to-use criterion.

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, covering the safety profile. The description adds a concrete detail about two bare-metal servers with HA redundancy, which is contextual but not deeply behavioral (e.g., no mention of response format or error scenarios). It adds some value beyond annotations, but not a large amount.

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, front-loaded with the main purpose and followed by a specific infrastructure detail. Every word contributes meaningful information without 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 simple zero-parameter read-only tool with no output schema, the description adequately specifies what infrastructure components are covered (hardware, redundancy, network, storage). It is complete enough for an agent to select and invoke the tool appropriately, though it does not describe the exact return structure.

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, and schema coverage is 100% vacuously. The description adds no parameter-specific semantics, but none are needed. The baseline for 0 params is 4, and the description appropriately focuses on the tool's purpose rather than parameters.

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 infrastructure specs' with specific components (server hardware, redundancy, network, storage), and distinguishes it from sibling getters focused on balances, transactions, and epochs. The verb 'Get' is specific and the resource is well-defined.

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 needing infrastructure details of the validator, and there is no direct sibling alternative for this exact resource. However, it lacks explicit 'when not to use' or alternative tool references, making the guidance implicit rather than explicit.

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 non-destructive, so the safety profile is covered. The description adds the specific metrics returned but does not disclose behavioral traits like caching, pagination, or data freshness. With rich annotations, this is acceptable but not exceptional.

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

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

A single, front-loaded sentence that states the purpose and enumerates key output fields. 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 no-parameter, read-only tool with strong annotations, the description adequately covers the intended use and output content. It doesn't explain the exact return format, but the list of metrics gives sufficient context for an agent to infer the response structure.

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

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

The tool takes zero parameters, so the schema is trivially fully covered. The description doesn't need to explain parameters, and the baseline for zero-parameter 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 uses a specific verb ('Get') and resource ('Blueprint validator performance'), and lists concrete metrics (vote success rate, uptime, skip rate, etc.), distinguishing it from sibling tools like get_validator_info which likely covers broader validator data.

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 clearly implies when to use it—when validator performance metrics are needed—but does not explicitly state alternative tools or exclusions. It lacks explicit 'when not to use' guidance, so it earns a 3.

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 description's mention of 'live' and 'Data from StakeWiz API' adds useful context about external dependency. Yet it does not elaborate on potential latencies, failure modes, or data update frequency, leaving behavioral disclosure slightly thin.

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 one concise sentence that front-loads the core action ('Get live APY breakdown') and then provides essential details in a structured formula. 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?

Given the tool has no parameters, no output schema, and simple read-only semantics, the description fully covers the key output components and the data source. It is complete enough for an agent to understand what this tool returns.

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 adds meaning by breaking down what the APY consists of, which is more than just the schema's empty parameter list requires.

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 a 'live APY breakdown' with specific components (base staking APY + Jito MEV APY = total APY) and includes commission rates. This precisely distinguishes it from sibling tools like get_staking_summary or get_validator_info by its focus on APY composition.

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 indicates the data comes from StakeWiz API and describes the output, making it clear the tool should be used when APY breakdown is needed. However, it does not explicitly mention alternatives or exclusions, so it misses the 'when-not-to-use' guidance that would push it to 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, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable return behavior details: it names the specific fields (keepLiquidSol, minSweepSol, paused, nonce, last epoch) and explicitly states the null-if-none case. This goes beyond the annotations and the schema, which lacks 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?

The description is two terse sentences: the first states the action and null behavior, the second enumerates the returned fields. Every word earns its place, with no redundancy or irrelevant detail.

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

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

For a single-parameter read tool with no output schema, the description fully conveys the return payload and the null case. It provides sufficient information for an agent to invoke the tool and interpret the result correctly, given the supportive annotations.

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 sole parameter walletAddress is fully described in the schema as 'Wallet address.' The description merely repeats the word 'wallet' without adding constraints, format, or disambiguation. With 100% schema coverage, the description does not meaningfully enhance parameter understanding 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 clearly states a specific verb-plus-resource: 'Read the current Autopilot policy for a wallet.' It also lists the exact fields returned, distinguishing it from sibling operations 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 the tool (when you need to read the current policy) but does not explicitly contrast it with alternatives like set_staking_policy or delete_staking_policy. No when-not-to-use guidance is provided, though the read-only nature is clear from the name and annotations.

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 destructiveHint=false, so safety is covered. The description adds meaningful behavioral context: it returns a consolidated recommendation with the exact tool to call, and clarifies the aggregated nature (single call replacing multiple RPC calls). It does not mention any limitations, but given the read-only and idempotent annotations, the transparency is solid.

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, packed with essential information, front-loaded with the core function ('complete staking portfolio dashboard'), and no filler. The structure efficiently communicates both the return contents and usage 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?

Given the tool is a single-call aggregation and there is no output schema, the description enumerates all key returned data (balances, states, rewards, APY, timing, recommended action). This is sufficiently complete for an agent to understand what to expect without needing further 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?

The only parameter, walletAddress, is fully described in the schema as a base58 public key. The description adds no additional parameter semantics beyond that, but because schema coverage is 100%, 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 aggregates staking data into a single dashboard call, listing all returned elements (liquid balance, staked amount, rewards, APY, epoch timing, next action). The verb 'get' and resource 'staking summary' are specific, and the description differentiates it from sibling tools by emphasizing it replaces getBalance + getAccountInfo + getEpochInfo.

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 to use this instead of multiple Solana RPC calls and names the specific alternatives it replaces. This gives clear when-to-use guidance and implicitly contrasts with the more granular sibling tools, which is strong guidance for an AI agent.

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 and idempotent behavior; the description adds the live StakeWiz API source, which is useful context. It does not disclose rate limits, caching, or error behavior, but with annotations covering safety this is adequate.

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 sentence, tightly packed with the essential fields and data source, with 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 zero-parameter tool with no output schema, the description lists the profile fields and data source, giving a clear picture of what will be returned. It is complete for the tool's simplicity.

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 there are no parameter details to explain. Baseline for zero parameters is 4, and the description does not need to compensate.

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

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

The description clearly identifies the verb 'Get' and the resource 'Blueprint validator profile', listing key data fields (identity, vote account, commission, etc.). This differentiates it from sibling tools focused on specific metrics like APY or performance.

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 by enumerating the returned fields, but it does not explicitly contrast with alternatives like get_staking_apy or get_performance_metrics, nor does it 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 declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds context about the content (third-party URLs and CLI commands) without contradicting annotations. It does not describe output format, but for a simple link-retrieval tool with annotations, this is adequate.

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 main purpose, and includes no unnecessary details. Every sentence adds value: the first states what URLs are provided, the second adds verification guidance and CLI commands.

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 covers essentials: the specific validator, the list of platforms, and the inclusion of CLI commands. It could mention how to interpret the links or any external dependencies, but the openWorldHint annotation covers the external nature. Overall, 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?

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and no schema details are required. The description's focus on output content 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 function: retrieving third-party verification URLs for the Blueprint validator, listing specific platforms. It distinguishes itself from sibling tools like verify_transaction or check_address_type by focusing on URL retrieval rather than direct verification 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 provides clear context: this tool is for obtaining verification links and includes CLI commands for on-chain verification. The phrase 'Verify every claim independently' implies a usage context, though it does not explicitly name alternatives or exclusions. This is clear guidance, but not as explicit as naming a specific alternative 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 readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds minimal extra behavioral context (registered vs all webhooks), but no additional disclosure beyond annotations is needed or provided.

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

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

A single, front-loaded sentence that clearly states the action and scope with zero wasted words. It is appropriately concise for a simple list operation.

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

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

For a simple read-only list tool with one parameter and no output schema, the description is complete. It tells the agent exactly what to expect: a list of registered webhooks for the given wallet address.

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 documents the walletAddress parameter fully. The description does not add extra meaning beyond the schema, matching the baseline for full 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 ('List') and resource ('webhooks') with a clear scope ('for a wallet address'). It distinguishes from sibling tools like delete_webhook and register_webhook by clearly stating the listing 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 gives clear context that this is for listing webhooks for a wallet address, but it does not explicitly mention alternatives or when-not-to-use conditions. Sibling tool names (delete_webhook, register_webhook) imply contrasts, but the description itself offers no usage guidance.

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

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

Beyond the annotations, the description discloses that Solentic polls every 60 seconds and POSTs to the provided URL when events fire. This adds meaningful behavioral detail about delivery mechanism and polling interval. It also explains the meaning of each event, giving context not present in annotations. 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?

The description is concise and well-structured: the first sentence states the purpose, followed by a compact list of events with explanations, and ends with the delivery mechanism. Every sentence adds value, no redundancy or 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?

The description covers the tool's purpose, event triggers, and polling delivery behavior, which is adequate for a registration tool with good schema and annotations. It lacks explicit return-value or error-handling information, but no output schema exists and the tool is relatively simple, so this is a minor gap.

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

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

The schema has 100% parameter coverage with descriptions, providing a good baseline. The description adds extra semantic value by explaining when each event fires (e.g., 'withdraw_ready (stake account becomes withdrawable)'), which is not fully captured in the schema's generic 'Event types to subscribe to'. It also reinforces the url/callbackUrl alias.

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 'Register a callback URL to receive push notifications when stake state changes', which specifies the action (register), resource (callback URL/webhook), and purpose (push notifications for stake state changes). The event list further clarifies the scope, distinguishing it from sibling tools like delete_webhook and list_webhooks.

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: use this when you need to receive push notifications for stake state changes. While it doesn't explicitly mention alternatives or when not to use, the sibling tools (delete_webhook, list_webhooks) make the intended use obvious, and no prerequisites or exclusions are needed.

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 far beyond the annotations by disclosing the security model: 'NEVER your secret key', 'Solentic never holds your key', zero custody, and the exact signing message format. It also explains replay protection via 'nonce must strictly increase on each update' and the lamport conversion rule, providing crucial behavioral 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 long but dense and well-organized: it front-loads the purpose, then covers security, processing flow, and the exact signed message. Every sentence contributes necessary detail for a security-critical signing operation; 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?

Given the tool's complexity (crypto signing, policy management) and lack of output schema, the description covers the workflow thoroughly: what triggers staking, how the signature is produced, how the callback works, and replay protection. It does not mention return values or error conditions, but these are less critical for a 'set' operation with such explicit process detail.

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%, so parameters are individually documented. The description adds meaningful cross-parameter semantics: the lamport conversion from SOL, the canonical message format that includes each parameter, and the 'strictly increase' nonce requirement. This enriches understanding beyond the schema field 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 opens with a specific verb+resource: 'Hand Solentic a standing, signature-bound policy' and clearly states the outcome: 'automatically stakes your IDLE SOL'. It distinguishes itself from sibling tools like get_staking_policy and delete_staking_policy by focusing on the 'set' action and the autopilot/staking-automation context.

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

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

It describes the trigger condition ('When idle SOL above keepLiquidSol exceeds minSweepSol') and the intended workflow (sign once, Solentic builds unsigned transactions, POSTs to callbackUrl). It implies this is for setting up automated staking, though it does not explicitly name alternatives like manual stake or create_stake_transaction.

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 indicate readOnly, idempotent, and non-destructive behavior. The description adds valuable context beyond these, such as clarifying that the effective APY equals the stated APY because total_apy is already annual, and detailing the outputs (activation timing, fee reserve guidance, natural-language recommendation). This enriches understanding of what the simulation actually computes.

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, with a front-loaded purpose ('Project staking rewards before committing capital') followed by a detailed list of outputs. The second sentence is somewhat dense but every clause adds information. It is well-structured and avoids redundancy, though the enumerative list could have been simplified without losing significant meaning.

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 output schema, the description appropriately covers return values (reward projections, effective APY, activation timing, fee reserve guidance, recommendation). It also provides usage context. However, it is slightly vague on what 'fee reserve guidance' entails and does not mention edge cases or limitations. Overall, it is fairly complete for a simple read-only simulation 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 already covers both parameters (amountSol and durationDays) with descriptions, so the baseline is 3. The description does not add much beyond the schema, though it implicitly ties them to the decision of 'how much to stake and for how long.' No new semantic meaning is provided beyond schema descriptions, 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 tool 'Project staking rewards before committing capital', using a specific verb and resource. It distinguishes itself from actual staking tools (like 'stake') by emphasizing the simulation nature and explicitly lists the outputs (reward projections, effective APY, activation timing, etc.). This makes it unmistakably a simulation/estimation tool.

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

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

The description provides direct usage guidance: 'Use this to help decide how much to stake and for how long.' This sets a clear context for when it should be used. However, it does not explicitly mention when not to use it or name alternative tools, so it 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 far beyond annotations by detailing in-memory signing, submission to Solana, and the return of a confirmed signature. It also discloses secret key handling (never stored, logged, or forwarded) and suggests verification via verify_code_integrity, adding significant trust context beyond the basic readOnly/destructive flags.

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 long, front-loaded with the core purpose, and every sentence earns its place: workflow, return value, and security/verification. No redundancy or 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?

For a single-call staking tool, the description covers the essential behavioral elements: what it does, how it handles the key, what it returns, and who should use it. Without an output schema, mentioning the confirmed transaction signature is sufficient. The description also differentiates from many sibling tools by noting it is one-shot and recommended for autonomous agents.

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 crucial semantic meaning for the secretKey parameter, explaining it is used only for in-memory signing and never stored, which enriches the schema's generic description. It does not add much for walletAddress or amountSol beyond what 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?

The description clearly states 'Stake SOL with Blueprint validator in a single call' and describes the full workflow (build, sign, submit). It distinguishes from sibling tools like create_stake_transaction and submit_transaction by emphasizing the one-shot nature and the confirmed transaction signature return.

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 identifies this as 'the recommended tool for autonomous agents,' providing clear context for when to use it. However, it doesn't explicitly name alternatives or state when not to use this tool versus simulated or multi-step 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?

The description adds context beyond the annotations by clarifying the tool is for advanced, local-signing workflows and should be avoided by most agents. It does not contradict the annotations (readOnly=false, destructiveHint=true) and provides a cautionary framing. However, it does not discuss post-submission behavior or irreversibility, which is a minor gap given the destructive hint.

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

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

Two sentences, front-loaded with 'Advanced' and a clear purpose. Every word earns its place—no filler, direct and 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?

The description is complete for a simple one-parameter tool, clearly explaining the workflow context and alternatives. The absence of an output schema means return values are not described, but for a submit action this is a minor gap; the tool's role in the broader flow is well documented.

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 provides 100% coverage for the single parameter, including a clear description ('Fully signed transaction as a base64-encoded string'). The tool description adds no new parameter semantics, so the 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 the verb 'Submit' and the resource 'pre-signed transaction to Solana'. It also distinguishes this tool from siblings by explicitly referencing the create_* flow and positioning it as an advanced alternative to one-shot 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 explicitly states when to use this tool ('Only needed if you used create_stake_transaction/create_unstake_transaction/withdraw_stake and signed locally') and provides a direct alternative ('Most agents should use the one-shot stake/unstake/withdraw tools instead'). This is exemplary usage guidance.

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

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

Annotations indicate a write operation (readOnlyHint=false) and not idempotent. The description adds crucial behavioral context: the tool builds/signs/submits the transaction and describes the cooldown period (~1 epoch) before withdrawal becomes possible. This exceeds what annotations alone convey, though it does not mention return values.

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 succinct and front-loaded with the core action. Each sentence adds essential information about the process, lifecycle, or alternative usage, with no waste 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 tool's purpose, process, post-action state, and alternative workflow, which is sufficient for selecting and invoking it. Since no output schema exists, a brief mention of return value (e.g., transaction signature) would strengthen completeness, but the current description still provides adequate 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?

Schema description coverage is 100%, so baseline is 3. The description does not add param-specific details beyond what the schema already provides; it only contextualizes the overall workflow. Thus it meets the baseline without extra semantic value.

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 'Deactivate a stake account in a single call,' using a specific verb and resource. It also distinguishes itself from the sibling tool create_unstake_transaction by positioning itself as the recommended one-shot option.

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 lifecycle guidance: use check_withdraw_ready to poll readiness, then withdraw to reclaim SOL. It also explicitly states when to use the alternative tool (create_unstake_transaction) — only if managing your own signing, making the usage context clear.

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

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

Annotations already declare readOnly, idempotent, and non-destructive. The description adds critical behavioral context: the tool returns raw source links and a commit hash, not a verification verdict, and the agent must perform the actual verification by reading the code. This goes beyond annotations and prevents misuse.

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: purpose, return value, verification checklist, and a caution against blind trust. The most critical information is front-loaded, and the description is free of 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?

The tool is simple (no parameters, no output schema), but annotations cover safety. The description fully specifies the output (commit hash + source links), the exact verification steps, and the caveat that the agent must read the source itself. This is complete for successful invocation and correct use.

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, the schema trivially covers everything. The description correctly focuses on what the tool returns and how to interpret it, which is the only relevant semantic information. No parameter explanations are 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 verifies code integrity on Blueprint servers, returns a git commit hash and source links, and distinguishes it from siblings like verify_transaction by focusing on server code rather than transactions. The verb 'verify' plus the specific resource and output make the 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?

The description explicitly tells the agent to read the source code to confirm specific conditions (no private keys logged, Memo Program present, generate_wallet local generation), and advises 'Don't trust — read the code yourself.' It establishes a clear use case and workflow, though it does not explicitly name alternatives or exclusions beyond what is implicit in the context 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 already state readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context: it checks for a specific Memo Program instruction, emphasizes that the proof is immutable on-chain, and states the return format (verified: true/false with evidence). This goes beyond the structured metadata.

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 front-loaded with the core purpose and consists of five sentences, each serving a distinct role: function, mechanism, proof rationale, usage, and return value. There is no redundant or excessive text, making it efficient 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?

Given the tool's simplicity (one parameter), the absence of an output schema is compensated by the description's explicit statement of the return shape ('verified: true/false with the on-chain evidence'). Combined with comprehensive annotations and a clear usage scenario, the description fully equips the 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 only parameter, 'signature', is fully described in the schema ('Solana transaction signature to verify'), giving 100% coverage. The description does not add further syntax or constraints. With such high schema coverage, the baseline score of 3 is appropriate—the schema carries the semantic 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?

The description opens with a specific verb and resource: 'Verify whether a Solana transaction was built through Blueprint.' It then details the exact on-chain evidence (the 'solentic.theblueprint.xyz' Memo Program instruction), clearly distinguishing this from sibling tools that check balances or addresses. The purpose is unambiguous and action-oriented.

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 use case: 'Use this to verify any claim that a stake was placed through Blueprint.' This tells when to invoke the tool. It does not explicitly mention exclusions or alternative tools, but the context is sufficient to understand its role versus other verification/check 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?

Annotations already declare it's not read-only, not idempotent, and open-world, and the description adds the full process: 'Builds the transaction, signs it, and submits it' and that funds are returned to the wallet. This adds context beyond annotations, though the safety profile is already well-covered, so a 4 is appropriate.

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: main action, process, prerequisite, default behavior, and sibling comparison. It's front-loaded and concise.

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 one-shot withdrawal tool with no output schema, the description covers the prerequisite, the action, the default, and the alternative, but doesn't mention the return type or error conditions. That's a minor gap, so 4.

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 (e.g., secretKey 'used in-memory for signing only, never stored'). The description repeats the amountSol default ('Omit amountSol to withdraw the full balance') but doesn't add new semantics. Baseline 3 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 states 'Withdraw SOL from a deactivated stake account in a single call,' using a specific verb and resource, and explicitly distinguishes from sibling 'withdraw_stake' by labeling itself the recommended tool and specifying when to use the 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?

It explicitly instructs to 'Use check_withdraw_ready first to confirm the account is ready' and contrasts with 'withdraw_stake only if you manage your own signing,' providing clear 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 adds meaningful behavioral context beyond annotations: it states the transaction is unsigned and intended for local signing, implying it does not submit or execute on-chain actions. The annotations already indicate readOnlyHint=false and destructiveHint=false, but the description clarifies the tool's non-submitting nature. It could additionally disclose the output format (e.g., serialized transaction), but the current level is solid.

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—two sentences, front-loaded with 'Advanced.' Every word contributes: it states the function, the target audience, and the preferred alternative. No wasted or redundant 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?

The tool has no output schema, so the description should communicate the return value or behavior. The phrase 'build an unsigned withdraw transaction' implicitly indicates the output is the transaction itself, and the explicit comparison with 'withdraw' clarifies its place in the workflow. Combined with a well-described schema and sibling context, the description is complete enough for an agent to use correctly, though it could be slightly more explicit about what the agent receives back.

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% coverage with clear descriptions for all three parameters (amountSol, walletAddress, stakeAccountAddress). The description itself adds no extra parameter-level meaning, so the baseline of 3 is appropriate given that the schema carries the full semantic burden.

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: 'Build an unsigned withdraw transaction for local signing.' It specifies the verb 'build' and the resource 'unsigned withdraw transaction', and it directly distinguishes itself from the sibling tool 'withdraw' by noting that it is for advanced/local signing use cases.

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: 'Most agents should use the `withdraw` tool instead, which handles signing and submission automatically.' This tells agents when to use this tool vs. the alternative, and implies this is only for special local-signing workflows.

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