SolKnife

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

No annotations provided, so description bears full burden. States that upload uses SolKnife's funded account, and returns txId and url. Discloses size and type constraints but omits potential errors, rate limits, or side effects.

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 redundancy. First sentence states core action, second adds constraints and output. Highly efficient.

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

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

With no output schema, description provides return keys. All parameters are covered. Lacks mention of prerequisites like network connectivity or authorization, but for a simple upload tool, it 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?

Description adds value beyond schema: clarifies fileBase64 max size (2 MiB) and repeats allowed contentType values. Schema coverage is 50%, but description compensates well for fileBase64 parameter.

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?

Clearly states action (upload), target (Arweave via Irys), and context (JSON-only, for agents without wallet-adapter). Distinguishes from sibling tools which follow build/execute patterns.

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 to use: for agents without wallet-adapter. Lists allowed content types and file size limit, guiding correct usage. Could be more explicit about when not to use (e.g., for other content types).

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

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

No annotations are provided, so the description carries full weight. It mentions 'chunked' but does not explain what that entails, nor does it disclose side effects, required permissions, or whether the tool is read-only. The behavioral traits are insufficiently described.

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, very concise and front-loaded. However, it omits important details that would warrant a higher score, but there is no wasted text.

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

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

Given the lack of annotations and output schema, the description is insufficient. It does not explain the output, prerequisites (e.g., ownership of mints), or the role of 'chunked'. More context is needed for a build tool that is part of a multi-step process.

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 50% (owner and mints have basic descriptions). The tool description adds no additional meaning beyond the schema, so it meets the baseline 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 clearly states the tool builds chunked burn transactions for selected NFTs and supports pNFTs. It uses the specific verb 'build' and resource 'burn tx(s)', distinguishing from sibling tools like 'execute' and 'list'.

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

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

No explicit guidance on when to use or not, or alternatives. It is implied that this tool is part of a build-execute workflow, but no prerequisites or exclusions are mentioned.

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

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

No annotations provided, so description carries full burden. Mentions structural re-verification and per-tx outcomes but omits details on failure, idempotency, or confirmation.

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

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

Two sentences with no fluff. First sentence states action, second adds key behavioral detail and output. Highly 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?

Complete enough for an execution tool with sibling context. Vague on return format (per-tx outcomes) but acceptable given 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 coverage is 100%, and description adds no extra meaning beyond the schema's own detailed descriptions. 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 clearly states the tool submits signed burn-nft transactions, distinguishing it from sibling tools like build and list. The verb 'submit' is specific, and it mentions returning per-tx outcomes.

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?

Schema descriptions explicitly state inputs come from /build, providing clear context on when to use. Lacks explicit exclusions but is sufficient given sibling context.

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

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

No annotations provided, so description must convey behavior. Only states 'List a wallet's NFT assets (DAS)' without indicating read-only nature, permission requirements, pagination, or whether it returns full asset details. For a list tool, this is insufficient.

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 sentence, no unnecessary words. However, it is borderline under-specified given the lack of behavioral details. Still efficient for a simple list 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?

Tool is part of a burn NFT workflow (siblings: solknife_burn_nft_build, solknife_burn_nft_execute), but description does not place it in that context. No output schema, so agent cannot infer return format. Needs more information to be fully useful.

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 'owner' already well-described in the input schema (base58 address). The description adds no extra meaning beyond what the schema provides. Baseline 3 is appropriate.

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

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

Description clearly states verb 'List' and resource 'wallet's NFT assets (DAS)'. Specific enough to distinguish from siblings like 'solknife_positions_list' or 'solknife_reclaim_rent_list', but could be more precise about what 'list' entails (e.g., returns mint addresses, metadata, etc.).

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

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

No guidance on when to use this tool vs alternatives like 'solknife_burn_nft_build' or 'solknife_positions_list'. Does not mention that it is typically used as a first step before burning or for inventory checks.

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

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

No annotations provided. The description notes the transaction is unsigned and client-verified, but lacks details on required permissions, side effects, or failure cases.

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, concise and front-loaded with key purpose and behavior, 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?

With 5 parameters and no output schema, the description explains the core intent and unsigned nature. Could mention payer's role or transaction 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?

Schema coverage is 100%; the description repeats parameter roles (mint, changeMint, changeFreeze) but adds no new semantic detail 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 clearly states the tool builds an unsigned transaction to change mint and/or freeze authority, distinguishing it from execute and read 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 implies this is a build step before signing by mentioning 'unsigned' and 'client verifies before signing', but does not explicitly contrast with execute/read variants.

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

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

No annotations provided, so the description must disclose behavioral traits. It indicates submission (a write operation) but does not explain side effects, reversibility, permissions, or what 'pins' means. The cryptic second sentence adds 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 very short (two sentences) and front-loaded with the primary action. However, the second sentence is jargon-heavy and decreases clarity.

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

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

No output schema, so the description should explain return values or success/failure indicators. It mentions the transaction must come from /build but does not describe what happens after submission or error conditions.

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 parameter descriptions. The description adds no extra meaning beyond stating the parameters come from the matching /build call, which is already implied by 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 states 'Submit a wallet-signed change-authority tx' which identifies the action and target, but the phrase 'Structural re-verifier pins the reassign ix(s) + fee' is cryptic and may confuse the agent. It lacks differentiation from the sibling 'build' 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?

No guidance on when to use this tool versus the 'build' or 'read' siblings, no prerequisites or exclusions mentioned. The description simply states what it does without context.

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

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

No annotations provided. Description indicates read-only by 'Read', but does not disclose other behavioral traits like network calls, costs, or permissions. Adequate but could be richer.

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 sentence, front-loaded with verb, no wasted words. Highly efficient.

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 2-parameter read tool without output schema, the description explains what it does and when to use it. Lacks return value details but is sufficient for the task.

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

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

Schema coverage is 100% with descriptions for both parameters. Description adds no additional meaning beyond the schema, so baseline score 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?

Clearly states 'Read a mint's current mint + freeze authorities and whether owner holds either' with a specific purpose 'before transferring one'. Differentiates from sibling build/execute 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?

Implies usage before transferring authority, providing clear context. No explicit when-not-to-use or alternatives, but the one-liner gives sufficient guidance for this simple read 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?

No annotations provided, so description must disclose behavioral traits. It mentions it returns a report shape but does not state whether it is read-only, requires permissions, or has side effects. Insufficient for safe invocation.

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

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

Two sentences that are direct and front-loaded with the purpose. No unnecessary words, though the structure could be improved with more explicit sections.

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 mentions return shape but lacks details on what 'rug-check' entails. For a single-parameter tool, it is adequate but not thorough; missing info on output fields or error conditions.

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% coverage on the 'mint' parameter with regex pattern and description. The description mentions output aspects (freeze authority, etc.) but does not add meaning to the parameter beyond what schema provides. Baseline 3 is appropriate.

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

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

The description clearly states it performs a rug-check on a Solana token and lists specific aspects (freeze authority, sellability, holders, liquidity). This distinguishes it from sibling tools like solknife_pool_check, though not explicitly.

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

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

Implied usage for checking token safety, but no explicit guidance on when to use this tool versus alternatives like solknife_pool_check or solknife_token_meta. Lacks when-not-to-use or prerequisite info.

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?

Discloses 'unsigned' and 'idempotent', but no details on side effects (e.g., no submission to chain), permissions, or prerequisites. With no annotations, the description provides minimal 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?

Single sentence with 10 words, zero fluff. Front-loaded with key information: action, output type, idempotency, and input scope.

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

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

Given no output schema, no annotations, and a moderately complex array parameter, the description is too brief. It does not explain what 'ATA' means, the return value, or that the transaction must be executed separately.

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

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

Schema coverage is 67% with descriptions for owner and payer but none for mints as a whole. The description adds no new meaning beyond the schema's address pattern 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 it builds an unsigned ATA-create transaction for one or more mints, with idempotency noted. This distinguishes it from sibling build tools like solknife_create_mint_build or solknife_burn_nft_build.

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

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

No guidance on when to use this tool versus alternatives, such as solknife_create_account_execute. The description lacks when-not-to-use or how it fits in a workflow.

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

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

With no annotations, the description must carry behavioral transparency. It adds context about a 'structural re-verifier' and 'pins the ATA creation ix(s) + allowlist,' but does not disclose potential side effects, failure modes, or permission requirements. It is adequate but not thorough.

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 (two sentences) and front-loaded with the primary action. No extraneous information, though it could be slightly expanded without losing conciseness.

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 and 100% schema coverage, the description is adequate but incomplete. It fails to mention that the signed transaction must come from the corresponding build call (though this is in parameter descriptions), and it does not describe what the tool returns (e.g., transaction signature).

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 baseline is 3. The tool description does not add any additional meaning beyond what the schema already provides for the two 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's action: 'Submit a wallet-signed ATA-create tx.' It uses a specific verb (submit) and resource (signed ATA creation transaction), and distinguishes itself from sibling tools like solknife_create_account_build by indicating it's the execution step.

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

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

Usage context is implied through phrases like 'returned by the matching /build call' in the parameter descriptions, but the main description does not explicitly state when to use this tool versus alternatives or what prerequisites exist. No when-not-to-use guidance is 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?

No annotations are provided, yet the description does not disclose behavioral traits beyond 'build an unsigned tx'. It does not mention that the operation is safe/non-destructive, nor does it describe any side effects, permission requirements, or rate limits.

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

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

The description is a single concise sentence that front-loads the action and lists return values. It has no fluff, but could slightly clarify the relationship between the input 'mint' and the output 'derived mint address'.

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 build-only tool, the description covers the output (base64 tx, block height, mint address). However, it lacks clarity on how the input 'mint' relates to the derived address, and does not mention prerequisites like payer SOL balance or other context needed for a complete understanding.

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 high (83%), so the schema already explains the parameters. The description adds no additional parameter semantics, making a baseline score of 3 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 it builds an unsigned create-mint transaction and lists specific return items (base64 v0 transaction, lastValidBlockHeight, derived mint address). This distinguishes it from the sibling 'solknife_create_mint_execute' tool, which presumably signs/sends the transaction.

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

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

The description implies it is a pre-execution step by naming itself a 'build' tool and mentioning an unsigned transaction. However, it does not explicitly state when to use it vs. alternatives, nor does it mention prerequisites like needing a funded payer.

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

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

No annotations are provided, so the description carries full burden. It describes a write operation ('Submit') but does not disclose side effects, failure behavior, or confirmation details. The phrase 'Structural re-verifier pins the mint creation ix + fee' is vague and does not clarify behavioral traits.

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 short (two sentences) and to the point, front-loading the main action. However, the second sentence is somewhat technical and may be unclear to some users.

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 two well-described parameters and no output schema, the description provides adequate information about what the tool does. However, it lacks details on return values or post-submission behavior, leaving some gaps in 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?

Schema description coverage is 100%, so the schema already documents the parameters well. The description adds no new semantic meaning beyond what the schema provides, thus 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 submits a wallet-signed create-mint transaction, indicating a specific verb and resource. However, it does not explicitly differentiate from the sibling 'solknife_create_mint_build', though parameter context implies it is the execute counterpart.

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

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

No explicit guidance on when to use this tool versus alternatives (e.g., build step). The parameter description hints that it should be used after a /build call, but no clear usage context is 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?

No annotations provided; description only says it builds a transaction without disclosing side effects, permissions, or output. Minimal behavioral insight.

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, brief but not overly verbose; however, conciseness sacrifices clarity and completeness.

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

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

No output schema; description does not mention what the tool returns or how it integrates with other build/execute tools. Incomplete for an agent to use 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 covers 75% of parameters; description adds that newDecryptableAvailable is 'what the worker computed' but schema already includes similar detail. expectedPendingCounter remains undocumented.

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 'Build the ApplyPending tx' but 'ApplyPending' is cryptic and not explained. It does not distinguish from sibling build tools like solknife_ct_deposit_build.

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

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

No guidance on when to use this tool versus alternatives, nor any prerequisites or context for applying the pending 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?

No annotations are provided, so the description carries the full burden. It mentions input requirements but does not disclose side effects, permissions, or what happens after the 'build' (e.g., whether execution is needed). The behavioral implications are under-specified.

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 just two sentences with no extraneous information. It is front-loaded with the core action and then specifics. 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?

There is no output schema, and the description does not explain what the built transaction looks like or how it should be used (e.g., execution step). Given the domain complexity and lack of output specification, the description feels incomplete for a tool that generates a transaction.

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 each parameter already has a detailed description explaining its nature (e.g., base64 of proof from ZK worker). The tool description adds 'agent-generated' but adds little beyond the schema. 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 'Build the Configure tx', which identifies the specific verb and resource. It is distinct from siblings like ct_deposit_build, though it could be more explicit about what 'Configure' means in this 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?

The description specifies required inputs (agent-generated proof and ciphertext), providing prerequisite context. However, it does not explain when to use this tool versus alternatives like ct_deposit_build or ct_withdraw_build, nor does it mention 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?

No annotations are provided, so the description bears full responsibility. It only states it builds a deposit transaction without disclosing side effects, return value, or whether it is a read-only or mutation operation. Critical behavioral context is missing.

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 no wasted words. The key action and a critical note about amount format are front-loaded. 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?

For a tool with 4 parameters, no output schema, and no annotations, the description is too sparse. It fails to explain what 'public → confidential pending' means, what the build step produces, or how it fits into the broader workflow (e.g., submission via ct_submit). The agent lacks essential 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 adds minimal value beyond the schema (only noting amount is in base units, which the schema already states). No new parameter insight is provided.

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 ('Build') and resource ('Deposit tx (public → confidential pending)'), distinguishing it from siblings like ct_transfer_build or ct_withdraw_build. It is specific and 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?

No guidance on when to use this tool versus alternatives. It does not mention prerequisites, contexts, or exclusions. The agent must infer usage from the name alone.

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

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

No annotations provided, so description must carry the load. It only states the action (build) but does not explain side effects, permissions needed, or whether the transaction is ready for submission. Lacks transparency on what the build output is.

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 sentence with no redundant information. Front-loaded purpose and essential input requirement. Highly 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?

Given the lack of output schema and annotations, the description is adequate but incomplete. It does not mention the result type (e.g., serialized transaction) or next steps like using ct_submit, which would help the agent understand the workflow.

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 baseline 3. The description repeats the schema's mention of the zero-ciphertext proof but adds no new constraints or formatting details 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?

Clearly states it builds a combined EmptyAccount + CloseAccount transaction and specifies the required proof input. Distinguishes from other ct_*_build tools by naming specific account 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?

No guidance on when to use this tool versus alternatives like ct_transfer_build or when not to use it. No mention of prerequisites or post-conditions.

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

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

With no annotations, the description carries the full burden. It indicates that the tool builds transactions (not executes them) and reclaims rent, implying a non-destructive preparatory action. However, it does not disclose potential side effects, prerequisites, or what 'chunked' means, leaving gaps.

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 sentence that directly states the action. No unnecessary words. It could benefit from slight expansion (e.g., 'chunked' meaning), but overall it is concise and front-loaded.

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

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

Given the complexity of the domain and the presence of many sibling tools, the description is too minimal. It lacks explanation of preconditions (e.g., prior use of solknife_ct_orphans_list), what 'chunked' implies, and how the output is used. No output schema exists, so the description should provide more context.

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

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

The schema has descriptions for both parameters (100% coverage), so the descriptive text adds little extra meaning. It does not explicitly connect the parameters to the action (e.g., that 'addresses' are the orphan context states). This is acceptable but not enhancing.

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

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

The description clearly states the action: building chunked CloseContextState transactions to reclaim orphan ZK context rent. This is specific and distinguishes from siblings like solknife_ct_orphans_list (which lists orphans). However, it is jargon-heavy and may not be clear to non-Solana users.

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

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

No guidance is provided on when to use this tool versus alternatives. It does not mention that it should be used after listing orphans or before any execute step. There are no exclusions or context hints.

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

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

No annotations provided, so description carries full burden. It clearly states it lists accounts, implying a read operation, but does not explicitly confirm read-only nature or mention permissions. Adequate but not explicit.

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 sentence, front-loaded with verb and resource, no redundant words. Efficient.

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 1-param list tool without output schema, the description is fairly complete. Could mention return type (list of accounts) but context 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 covers 100% of parameters with a description for 'owner'. Tool description adds no additional meaning beyond the schema. Baseline of 3 applies.

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

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

The description specifies a clear verb 'List' and resource 'orphan ZK Proof context-state accounts' with context of a wallet and cause (partial Withdraw or Transfer sagas). It distinguishes from siblings like 'solknife_ct_orphans_build' and 'solknife_ct_state' by focusing on listing.

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 cleaning up orphans from partial sagas but does not explicitly state when to use this tool over alternatives like 'solknife_ct_orphans_build'. No when-not or prerequisite 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?

No annotations provided. Description correctly identifies the tool as read-only with no side effects, but offers no additional behavioral context such as authentication needs, rate limits, or potential errors.

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 sentence, front-loaded with verb and resource, followed by parenthetical specifics. 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?

With no output schema, description hints at return values (flags, configuration, ciphertexts), which is helpful. Could mention return type or error conditions, but adequate for a simple read 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?

Input schema already documents both parameters with clear type and format (Solana base58 addresses). Description adds context about what the state is for but does not enhance understanding of the parameters 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?

Description clearly states it reads confidential-transfer state for owner + mint, listing specific data included (mint extension flags, account configured, balance ciphertexts). This distinguishes it from sibling tools that perform mutations like configure, deposit, or withdraw.

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

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

Description implies when to use (to read CT state before other operations), but provides no explicit guidance on when not to use or mention of alternative tools for similar read tasks.

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

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

No annotations are provided, so the description bears full responsibility. It reveals that the server re-verifies saga shape and fee before relaying, which adds transparency. However, it does not disclose potential side effects (e.g., state changes on-chain), failure modes, idempotency, or response format. For a submission tool, these are important gaps.

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, each adding essential information: purpose, conditional parameter usage, and server behavior. No redundant or irrelevant content. Front-loaded with the core action ('Submit a CT signed tx'). 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 complexity (conditional parameters, no output schema, lack of annotations), the description covers the key conditional logic and hints at prior steps (transactions from /build). It does not explain return values or error handling, but the workflow context (build then submit) is implied. It is complete enough for an agent to use correctly in most cases.

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 value beyond the schema: it explains that 'op' discriminates between single-tx and saga ops, and specifies which ops require 'signedTransactions' vs 'signedTransaction'. The schema already has descriptions for three parameters (75% coverage), but 'op' lacks a schema description, so the tool description compensates well. The conditional logic is clearly explained.

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?

Clearly states the tool submits CT signed transactions, distinguishing single-tx and multi-tx (saga) operations. The verb 'submit' and resource 'CT signed tx' are specific, and the description differentiates it from build tools (implicitly) and other sibling execute tools by focusing on CT operations.

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 when to use 'signedTransaction' vs 'signedTransactions' based on the op value, and mentions saga ops where array is needed. However, it does not explicitly state when not to use this tool (e.g., if the transaction hasn't been built yet), nor does it compare to other submit tools for non-CT operations. The guidance is clear for the conditional case but lacks 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?

No annotations are provided, and the description only lists required inputs without disclosing behavioral traits such as side effects, output, or ownership requirements. The tool presumably creates Solana transactions but this is not stated.

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 that packs many items, but it is relatively concise. However, listing items in a sentence makes parsing harder; a structured list would be clearer.

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 12 required parameters and no output schema, the description fails to explain what the build produces (e.g., transaction bytes, instruction) or the next steps. It also does not describe the overall purpose of the transfer saga.

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 supplements the schema by providing byte sizes for proofs and ciphertexts, and summarizes the three context accounts. Since schema coverage is 100%, this additional context is valuable but not essential.

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 'Build the 5-tx Transfer saga' which clearly indicates the tool constructs a transfer operation consisting of five transactions. The verb 'build' differentiates from execution tools. However, it does not elaborate on what the saga accomplishes, leaving some ambiguity.

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

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

No guidance on when to use this tool versus sibling ct_build tools (e.g., deposit, withdraw). No prerequisites or alternatives mentioned.

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

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

No annotations provided, so description carries full burden. It discloses that it's a 5-tx saga and lists input sizes, but does not mention side effects, permissions, or whether building modifies state. The '_build' suffix hints it only constructs transactions, but this is not explicit.

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 sentence, extremely concise, front-loads purpose, then lists key inputs. 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?

For a complex 9-parameter tool that builds a 5-tx saga, the description is too brief. It does not explain what the saga does, prerequisites, or what the output is. Missing behavioral context that an agent needs for correct usage.

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

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

Schema coverage is 100% with descriptions for all 9 parameters. The description adds value by specifying exact byte sizes for proofs (320 B, 936 B, 36 B) and clarifying the 'two ephemeral ctx-state pubkeys' correspond to equalityContextAccount and rangeContextAccount, which aids the agent in correct invocation.

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 builds the '5-tx Withdraw saga', specifying the verb 'Build' and the resource 'Withdraw saga'. This distinguishes it from sibling tools like deposit or transfer.

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 name 'withdraw' and the description imply usage for withdrawing tokens, but there is no explicit guidance on when to use this tool vs alternatives (e.g., deposit, transfer). It is clear from context but lacks explicit when-not statements.

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

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

With no annotations, the description must disclose behavior. It states the tool builds an unsigned transaction, implying no immediate on-chain effect. However, a major flaw exists: the description says `amount` is a whole-token decimal string parsed against decimals, while the schema says amount is in base units. This contradiction misrepresents input handling and undermines transparency.

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 short sentences and front-loaded purpose. However, conciseness is undermined by inaccurate content regarding `amount`. A concise but correct description would score higher.

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

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

For a 4-required-param tool with no output schema and no annotations, the description is severely lacking. It does not explain the output format (no return values), prerequisites (e.g., mint must exist), or the relationship to execute/read steps. The contradictory param info further 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?

The description adds harmful contradictory information for the `amount` parameter (whole-token vs base units). For other parameters (mint, payer, recipient), it adds nothing beyond the schema's existing descriptions. Given 100% schema coverage, baseline is 3, but the contradiction reduces this to 1.

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

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

The description clearly states 'Build an unsigned mint-to tx', which is a specific verb-resource pair. It distinguishes from siblings like solknife_mint_supply_execute and solknife_mint_supply_read, making the tool's role obvious.

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

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

The description provides no guidance on when to use this tool versus alternatives (e.g., other build tools or the execute/read variants). No context about prerequisites or typical workflow is given.

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

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

No annotations are provided, and the description only mentions a 'structural re-verifier pins the mint-to ix + fee', which is vague. It does not disclose behavioral traits like idempotency, error handling, or prerequisites beyond the signed transaction, leaving significant gaps.

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, no redundant information, and directly states the core function. 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 complex workflow (build-execute-read) and lack of output schema, the description is insufficient. It does not explain return values, confirmation details, or what happens after submission, leaving the agent underinformed.

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 parameters. The tool description adds no additional meaning beyond what the schema provides, making a baseline score of 3 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 submits a wallet-signed mint-to transaction, using the verb 'submit' and specifying the resource 'mint-to tx', distinguishing it from the sibling build and read 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 implies usage as the execution step after building a transaction, but does not explicitly state when to use it or mention alternatives. The sibling names hint at a workflow, but the description lacks explicit guidance.

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

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

With no annotations, the description adequately discloses that this is a read operation checking authority, but could mention idempotency or lack of side effects.

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?

One concise sentence with front-loaded purpose, zero 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?

Complete for a simple read tool, explaining what is read and the prerequisite relationship; lacks output format but that's not required without 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 coverage is 100%; the description contextualizes parameters as mint and owner, but adds no syntax details 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?

Clearly states it reads a mint's authority state and checks if owner is the mint authority, distinguishing it from write operations like solknife_mint_supply_build/execute.

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

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

Implies usage as a prerequisite for mint-to, but does not explicitly state when to use vs alternatives or provide 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?

With no annotations, the description mostly restates the purpose without disclosing behavioral traits such as side effects, prerequisites, or output nature. It only implies no execution occurs.

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?

Extremely concise single sentence that front-loads the core action. No unnecessary 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?

Despite having multiple related sibling tools and no output schema, the description fails to explain the two-step process or the format of the built unsigned transaction, leaving the agent underinformed.

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

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

Schema coverage is 75%, and the description adds marginal value by reiterating the vote enum purpose. It does not clarify the meaning of 'member' or 'multisig' beyond 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 indicates the tool builds an unsigned vote transaction for approving or rejecting a proposal, which differentiates it from sibling execute tools. However, it could be more explicit about the distinction.

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

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

No guidance is provided on when to use this tool versus alternatives like the execute counterpart. The description lacks context about the two-step build-execute workflow.

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

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

No annotations; description indicates submission but does not detail side effects, permissions, or error states. The schema's instruction not to submit yourself adds some transparency.

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

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

Two concise sentences with no fluff; essential information 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?

Sufficient for a post-build execute tool but lacks details on output, confirmation, or potential failures. No output schema to supplement.

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?

Adds context for the vote parameter (use same as build). Schema covers 67% of parameters; description provides minimal extra beyond schema for signedTransaction and lastValidBlockHeight.

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?

Clearly states it submits the signed vote transaction, distinguishing from sibling build tools like solknife_multisig_approve_build.

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?

Specifies to use the same vote value as in the build step, implying sequential usage. Lacks explicit when-not or alternatives but sufficient for context.

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

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

No annotations exist, so the description must fully disclose behavior. It does not clarify side effects, whether the proposal is written to chain, or the return type (e.g., an unsigned transaction). The term 'unsigned' hints at a transaction object, but the description does not explicitly state the output format or the need for subsequent 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?

The description is concise, with three sentences front-loading the purpose, then detailing operation-specific requirements, and ending with a constraint. No unnecessary information.

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

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

With 7 parameters, a nested object, no output schema, and no annotations, the description should explain the tool's role in a two-step process (build then execute). It does not mention that the output is likely an unsigned transaction to be signed and submitted via an execute tool, leaving an important gap for the agent.

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

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

The description adds significant value beyond the schema by clarifying conditional parameter requirements per operation (e.g., 'op=add-member needs member (+optional permissions)'). This helps the agent understand which parameters are required based on the op value, which the schema does not capture.

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 'Build an unsigned config-change proposal' and lists operations. It distinguishes from execute tools via 'unsigned' and mentions multisig type constraint. However, it doesn't explicitly differentiate from the propose tool, which is a sibling.

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 some usage guidance by mapping operations to required parameters and stating the multisig type constraint. However, it lacks explicit when-to-use or when-not-to-use instructions and does not mention alternatives like solknife_multisig_propose_build.

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

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

No annotations provided, so description carries full burden. Only states 'Submit', implying a write operation, but does not disclose effects, permissions needed, irreversibility, or return behavior. Minimal 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?

Single short sentence conveying core action. Front-loads verb. Could include more relevant context without being verbose, but current brevity is acceptable.

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?

Description lacks critical workflow context. Does not indicate that this is the second step of a two-step process (build then execute), nor does it explain what happens after submission. No output schema, but description doesn't hint at success confirmation.

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 (including warnings). Description adds nothing extra beyond the schema, so 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 clearly states action ('Submit') and resource ('the signed config-change proposal tx'). Distinguishes from sibling execute tools like solknife_multisig_execute_execute but could be more explicit about which build it corresponds to.

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

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

No guidance on when to use this tool vs alternatives. Does not mention the prerequisite build step (solknife_multisig_config_build) or that the signed transaction comes from a prior call. The schema warns about not submitting yourself, but the description itself lacks usage context.

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

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

With no annotations provided, the description fully discloses behavioral traits: it builds an unsigned transaction, requires two signers (creator + createKey), and returns derived addresses, base64 v0 tx, and lastValidBlockHeight. This is comprehensive and adds significant value beyond the schema, especially the signing requirement and return format.

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: the first states the tool's purpose, the second explains a critical parameter and the return values. It is front-loaded with the most important information, every word earns its place, and there is no redundancy or 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?

The tool has 5 parameters (4 required), no output schema, and is relatively complex (multisig creation). The description covers the key aspects: what it builds, signing requirement, and return values. However, it omits explanation of the timeLock parameter (integer, min 0, max 7776000), which could affect transaction timing. For a complete picture, a brief mention of timeLock would be beneficial, but the description still provides sufficient context for an agent to use 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 description coverage is high (80%), and the description adds semantic meaning for the createKey parameter, clarifying its role as a fresh random pubkey and co-signer. The description does not mention the timeLock parameter (which lacks a schema description), but the other required parameters are well-defined in the schema. The extra context on createKey raises the score above the baseline 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 clearly states 'Build an unsigned create-multisig tx,' specifying the action (build), resource (unsigned tx), and context (create-multisig). This distinguishes it from sibling tools like solknife_multisig_create_execute (which executes the built tx) and solknife_multisig_propose_build (which builds a proposal tx). The verb-resource combination is specific and 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 explains that createKey is a fresh random pubkey the agent generates and must co-sign the transaction, providing clear usage context. It implies the tool is a preliminary step before signing and execution, but does not explicitly state when to use this tool over alternatives (e.g., when to use build vs execute). However, the guidance on the two-signer requirement is 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?

No annotations are provided, so the description must fully disclose behavioral traits. It mentions submission and signing but does not explain side effects (e.g., the transaction creates an on-chain multisig, is irreversible, consumes fees, or requires a valid block height). This is minimal transparency for a mutation tool.

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

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

A single sentence that efficiently conveys the core purpose without redundancy. Every word adds value, and no information is missing given the short length.

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 purpose and param usage but omits important behavioral aspects: there is no mention of return values, side effects, failure modes, or prerequisites (e.g., funds, signatures). While the schema covers param details, the lack of output schema or behavioral notes leaves room for ambiguity about what happens after submission.

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 descriptions go beyond type constraints. They explain the origin of values (from `/build` call), provide a warning for `signedTransaction` ('Do not submit it yourself'), and clarify the purpose of `lastValidBlockHeight`. This adds meaningful context.

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

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

The description clearly states the action ('submit') and the specific resource ('signed create-multisig tx'), with additional detail about the signing requirement involving both wallets. This distinguishes it from sibling tools like the build step.

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

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

The description implies this is the execution step after signing, but it does not explicitly state when to use this tool versus alternatives (e.g., when not to use it or when to use a different `execute` tool). No contrast with sibling tools is 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?

No annotations are provided, so the description carries the full burden. It explains that the tool builds an unsigned transaction (no state mutation) and returns executeKind, and that computeUnitLimit is optional. However, it lacks details on error conditions, permission requirements, or what happens if the proposal is not approved.

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 that efficiently convey the purpose, key behavior, and next steps. Every word adds value with no repetition 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 basic function and links to the follow-up tool, but the return format (executeKind) is not described. No output schema exists, so the agent needs more detail on what is returned. Prerequisites (proposal must be approved) are implied but not explicitly stated. Given the tool's role in a multi-step process, more context would be helpful.

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 3 of 4 parameters with descriptions (member, multisig have patterns, transactionIndex has a description). The description adds meaning for computeUnitLimit (optional, raises CU cap) and reinforces transactionIndex as the proposal index from the API. This compensates for the missing schema description on computeUnitLimit.

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 builds an unsigned execute transaction for an approved proposal, specifying the action (build), target (execute tx), and condition (APPROVED). It also mentions detecting vault vs config and returning executeKind, which distinguishes it from siblings like solknife_multisig_execute_execute.

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 (for an approved proposal) and tells the agent to pass the result to execute.execute, providing a clear next step. However, it does not explicitly exclude non-approved proposals or compare with other build tools like propose_build or approve_build, though the context makes it 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?

No annotations are provided, so the description carries the full burden. It does not disclose that this is a write operation, irreversible, involves fees, or requires permissions. The schema parameter descriptions contain some behavior notes (e.g., 'Do not submit it yourself'), but the main description lacks these critical details.

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 that front-load purpose with no wasted words. Every sentence is necessary.

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 submitting a multisig transaction, the description lacks context: no mention of return values, error handling, prerequisite steps (must build and sign), or the workflow sequence. The hint about executeKind is helpful but incomplete.

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

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

Schema description coverage is 67% with two params having detailed descriptions. The description adds meaning for executeKind by tying it to the build output, which the schema lacks. For other params, it provides no additional value beyond schema.

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

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

The description clearly states the tool's action: 'Submit the signed execute-proposal tx.' It specifies the verb (submit) and resource (signed execute-proposal tx), and distinguishes from siblings like solknife_multisig_execute_build by referencing the build step.

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

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

The description implicitly tells when to use by referencing 'executeKind returned by execute.build', but does not explicitly state when not to use or provide alternatives. No guidance on prerequisites or postconditions.

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

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

With no annotations, the description carries full behavioral burden. It explains that the transaction is unsigned and that the vault PDA is the payer for instructions kind. However, it does not disclose what happens after building (e.g., how to submit), potential failure states, or any permission requirements. The auto-approve note is helpful but incomplete.

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 two sentences covering all key aspects. The first sentence is dense but efficient, and the second adds an important behavior note. 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 10 parameters and no output schema, the description covers the three main kinds but omits explanation of memo, ephemeralSigners, and what the built tx looks like. The lack of linkage to sibling tools (e.g., next step) 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?

Schema coverage is only 40%, so the description must compensate. It clarifies that amount is in base units and provides structure for instructions. However, parameters like memo and ephemeralSigners are not mentioned, leaving their purpose unclear. The description adds value for kind-specific params but not globally.

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 builds an unsigned propose transaction and explains the three kinds with their required parameters. However, it does not explicitly distinguish from sibling tools like solknife_multisig_propose_execute or solknife_multisig_approve_build, which could cause confusion about the tool's role in the proposal lifecycle.

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 conditional requirements for each kind, guiding the user on which parameters are needed. It also mentions auto-approval if the proposer can vote. However, it lacks explicit guidance on when to use this tool versus sibling tools, such as when to use solknife_multisig_approve_build instead.

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

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

No annotations are provided, so the description carries full burden. It only states the action without disclosing side effects (e.g., transaction submission, potential fees, finality), success/failure conditions, or permission requirements. Critical behavioral traits are missing.

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 very short (one sentence) with no extra words. However, it is too terse for effective guidance, lacking important usage and behavioral context. Could be expanded without losing conciseness.

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

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

No output schema exists, yet the description does not explain what the tool returns or how to interpret the result. It also lacks workflow context (e.g., that this is step 2 of a propose-execute pair). The description is incomplete for a transaction submission 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%, providing a baseline of 3. The description adds significant value: for signedTransaction, it explains it's from /build and must be signed, and warns not to submit manually. For lastValidBlockHeight, it clarifies it's from /build and that past this height the tx cannot land. This goes 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 is specific: 'Submit the signed propose-transaction tx.' It clearly identifies the verb (submit) and the resource (signed propose-transaction transaction). Among many execute siblings, this uniquely targets multisig propose execution.

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

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

No guidance on when to use this tool versus alternatives like solknife_multisig_execute_execute or other execute tools. No mention of prerequisites, such as needing to call solknife_multisig_propose_build first. The context of being the execution step after building is implied but not stated.

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

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

With no annotations, the description carries full burden. It discloses that the tool is read-only (returns data, no side effects implied) and returns null for invalid addresses. It does not mention authentication, rate limits, or potential errors, but this is acceptable for a simple read operation.

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: the first details the return content, the second handles the null return case. Concise, front-loaded, no redundant information.

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

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

Despite no output schema, the description fully explains the returned fields (members, permissions, threshold, vault balance, pending proposals with vote tallies, voters, executable status) and covers the null case. This is sufficient for an agent to understand what 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?

The input schema provides 100% coverage with a pattern description. The description adds meaning by stating the address should be a Squads v4 multisig, which is helpful context beyond the generic base58 format.

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 a Squads v4 multisig by address and enumerates the returned data: members, permissions, threshold, vault balance, and pending proposals with details. It differentiates from sibling tools like solknife_multisig_*_build/execute by focusing on reading state.

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

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

The description explicitly states when to use the tool (to read multisig state) and includes the edge case of returning null for non-multisig addresses. Although it does not explicitly list when not to use it, the sibling tool names imply alternatives for creation, approval, execution, etc.

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

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

No annotations provided, so the description must fully disclose behavior. It states 'Read' implying non-destructive, but does not explicitly guarantee no side effects, mention authentication needs, rate limits, or other behavioral traits. Minimal disclosure.

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 very concise, front-loading the key information in a single sentence. While efficient, it could benefit from a more structured format (e.g., bullet points) for readability.

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 tool with one parameter and no output schema, the description covers the essential functionality. However, it lacks context such as whether the data is live or cached, or any limitations, which would be helpful for 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?

Schema description coverage is 100%, providing full documentation for the single parameter. The tool description adds no additional semantic value beyond what the schema already provides, 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 clearly states it reads a single Meteora DLMM pool and lists specific data fields (depth, volume, fee yield, token safety summary). It distinguishes itself from siblings like solknife_pool_compare which likely compares multiple pools.

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 as a read tool for a single pool, but no explicit guidance on when to use this versus alternatives like solknife_pool_compare or when not to use it. No exclusions or prerequisites 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?

With no annotations, the description must disclose behavioral traits but only states the purpose. It does not mention read-only nature, required permissions, response format, or potential costs/limitations (e.g., number of pools). The term 'compare' is vague without clarifying what data is shown.

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?

Extremely concise at one sentence and 8 words, with key information front-loaded. However, it may be too terse, sacrificing needed detail for brevity.

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 simplicity (1 param, no output schema, no annotations), the description lacks completeness. It does not explain output structure, prerequisites (e.g., token must have DLMM pools), or what aspects are compared. The tool is minimally 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?

Schema coverage is 100%, so the single parameter (mint) is well-defined by the schema. The description adds no extra meaning beyond confirming the token is identified by its mint address, which is already clear from 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?

Description clearly states the tool compares every Meteora DLMM pool for a given token side by side, using a specific verb ('compare') and resource ('every Meteora DLMM pool'). It distinguishes from siblings like solknife_pool_check (likely checks a single pool) and solknife_positions_list.

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 you want to compare all pools for a token, but does not explicitly state when to use this tool versus alternatives (e.g., solknife_pool_check for a specific pool). No exclusion or prerequisites 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?

With no annotations, the description must disclose behavior. It notes 'best-effort' and that a fee is charged when SOLKNIFE_FEE_ACCOUNT is set. However, it does not detail other side effects, if any, or the nature of 'build' (e.g., no execution side effects). This is adequate but not comprehensive.

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 the main action upfront. No redundant information, every sentence adds value (purpose and fee side effect). 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 no output schema and 3 parameters, the description is missing details about return type, failure modes, and what 'best-effort' entails in practice. It covers the core purpose but leaves gaps for a complete understanding.

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 67% (slippageBps lacks description). The tool description adds no parameter-level information beyond what the schema provides. For a tool with moderate coverage, the description should compensate but does not, leaving slippageBps ambiguous.

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 builds a 'best-effort single auto-compose transaction for a target portfolio'. The verb 'build' and resource 'auto-compose transaction' are specific. The sibling tools include plan and execute versions, so the role is implied, but no explicit differentiation is given.

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

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

The description does not specify when to use this tool versus siblings like plan or execute. No prerequisites, exclusions, or alternative guidance is provided, leaving the agent to infer usage context.

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

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

No annotations are provided, so the description must fully disclose behavior. It states it 'submits' a transaction, but does not describe what happens on success or failure, potential side effects (e.g., changes to wallet state, fees), or idempotency. The parameter descriptions add some caution ('do not submit it yourself'), but overall transparency is minimal.

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, concise and front-loaded with the core action. However, it could be slightly more informative without losing conciseness, such as hinting at prerequisites. 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?

Despite good schema coverage and a clear purpose, the description lacks information about return values (e.g., transaction signature, status). For an execution tool, this is a significant gap. It also does not mention the relationship to the build step, leaving agents without workflow context. With no output schema, the description should compensate.

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% and all parameters have detailed descriptions covering format and purpose (e.g., 'Do not submit it yourself'). The description itself adds context about 'allowlist verification' but does not significantly enhance parameter understanding beyond the schema. 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 uses the verb 'submit' and names the resource 'portfolio compose transaction'. It adds context about 'after top-level program allowlist verification', which distinguishes it from a pure execution step. However, it does not explicitly differentiate from sibling tools like solknife_portfolio_compose_build or solknife_portfolio_compose_plan, missing a chance to clarify it is the final execution step.

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

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

No explicit guidance on when to use this tool versus alternatives. The description mentions 'after ... verification' but does not state prerequisites (e.g., must have a signed transaction from a build call) or when not to use it. Sibling tools suggest a workflow, but the description leaves usage context implicit.

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

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

No annotations provided; description is minimal. It mentions constraints (targets sum to 10000, USD-valued) but does not disclose behavioral traits such as whether the plan is a dry run, what side effects exist, or what the plan output format is. Lacks transparency for a tool with no 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 purpose, no redundant words. Every sentence adds value. Highly concise and well-structured.

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

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

Given no output schema and moderate complexity (3 params, one optional), the description is incomplete. It does not explain what the plan output looks like, how to use the result with build/execute tools, or clarify the role of slippageBps. More detail is warranted.

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?

Description explicitly adds the critical constraint that 'targets[].bps must total 10000', which is not fully clear from the schema (even though schema says sum to 10000, it's reinforced). Also adds 'USD-valued' context. For slippageBps, no additional info beyond schema, but overall adds value beyond structured data.

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 verb 'Plan' and resource 'USD-valued portfolio rebalance from target mint percentages'. It differentiates from sibling tools like solknife_portfolio_compose_build/execute (action steps) and solknife_portfolio_holdings (current state).

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

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

Description implies usage for planning rebalances but does not explicitly state when to use this tool vs alternatives like solknife_portfolio_compose_build or solknife_portfolio_holdings. No exclusion or comparison given.

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

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

With no annotations, the description carries full burden but only states 'List... holdings.' It does not clarify read-only behavior, data freshness, pagination, or any side effects, leaving significant gaps.

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

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

The description is a single, front-loaded sentence with no fluff. 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 a simple tool with one parameter and no output schema, the description is minimal but adequate. It lacks details on output format, whether prices are real-time, and error conditions, so completeness is moderate.

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 the schema already documents the owner parameter. The description adds no extra meaning beyond the schema; it implies the wallet address but does not explain 'priced' or output details, resulting in marginal added 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 uses a specific verb ('List') and resource ('wallet's priced token holdings'), clearly distinguishing it from siblings like solknife_positions_list which likely lists all positions without price information.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or comparative context with other portfolio or holding 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?

No annotations are provided, so the description carries the full burden. It discloses that it returns positions with PnL but does not specify behavior for empty wallets, authentication needs, or performance implications.

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 concise sentence with no superfluous words, efficiently conveying the tool's purpose.

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

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

Since there is no output schema, the description adequately hints at the return content ('with PnL'). It could mention the return format but is sufficient for a simple list operation.

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

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

Schema description coverage is 100%, so the parameter 'owner' is already well-documented in the schema. The description adds no additional meaning beyond what is in the schema.

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

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

The description clearly states the verb 'List', the resource 'a wallet's open Meteora DLMM positions', and the data included 'with PnL'. It distinguishes from siblings like solknife_portfolio_holdings by specifying 'Meteora DLMM' positions.

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 listing a specific type of positions but provides no explicit guidance on when to use this tool versus alternatives such as solknife_portfolio_holdings.

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?

Mentions 'chunked' and 'up to MAX_RECLAIM_ACCOUNTS' but does not explain the constant or disclose safety, side effects, or confirmation requirements. With no annotations, description provides insufficient 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?

Two sentences, front-loaded with purpose, no redundant information efficiently conveys core functionality.

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?

Lacks explanation of return type (what 'build' produces), no output schema, and does not mention side effects or prerequisites. Description is too brief for a tool with no annotations or 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 coverage is 50% with only pattern descriptions. Description hints that 'accounts' should be empty token accounts and 'owner' is the wallet, but does not add substantive meaning beyond schema for either parameter.

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 it builds chunked close-batch transactions for reclaiming rent from empty token accounts, distinguishing it from siblings like solknife_reclaim_rent_execute and solknife_reclaim_rent_list.

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

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

Implies usage for reclaiming rent from empty token accounts but lacks explicit guidance on when to use this tool versus its siblings (build, execute, list) and no prerequisites or context.

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

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

The description discloses re-verification against fresh state and per-tx outcomes, which is good. However, it lacks details on side effects (e.g., account closure, rent reclaim), failure handling, and authorization requirements. Since no annotations are provided, the description carries the full burden and falls short.

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

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

Two sentences with no wasted words. The first sentence states the action, the second adds key behavioral detail. Highly efficient.

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 main action and outcome, but lacks details on outcome format, error handling, or what happens if re-verification fails. For a mutation tool with no output schema, it is mostly complete but could be enhanced.

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?

All three parameters have descriptions in the schema, covering owner, signedTransactions, and lastValidBlockHeight. The description adds no additional semantics beyond the schema, 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 clearly states the tool submits signed reclaim-rent close-batch transactions, with re-verification against fresh on-chain state. It distinguishes itself from sibling tools like solknife_reclaim_rent_build (builds unsigned tx) and solknife_reclaim_rent_list (lists reclaimable accounts) by focusing on execution.

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 after building, and the parameter description for signedTransactions explicitly warns not to submit the transactions manually. However, it does not explicitly name the build tool or provide 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?

No annotations are provided, but the description correctly identifies a read-only listing operation with no side effects, which is consistent with the tool's purpose.

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: a single sentence of six words that directly states the tool's function without superfluous details.

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 simplicity of the tool (single parameter, no output schema), the description adequately communicates the core functionality, though it could hint at the output format (list of 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?

The schema description already fully documents the single parameter (owner). The tool description adds no additional parameter information 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 clearly states the action ('List') and the resource ('reclaimable empty token accounts') scoped to a wallet, distinguishing it from sibling tools like solknife_reclaim_rent_build.

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 description doesn't explicitly state when to use vs alternatives, the sibling tool names (solknife_reclaim_rent_build, solknife_reclaim_rent_execute) imply this is the listing step before building a reclaim 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?

No annotations are provided, so the description carries the full burden. It discloses the irreversible, permanent nature of the action. However, it does not mention that the transaction is unsigned and requires later execution, nor does it discuss permission requirements or other behavioral details beyond the schema descriptions.

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

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

The description is a single, front-loaded sentence with no wasted words. It effectively communicates the core purpose in minimal space.

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 basics but lacks context about the build-execute workflow (e.g., that the output is an unsigned transaction meant for later execution). Given the absence of an output schema and the complexity of permanent actions, additional context would improve completeness without significant verbosity.

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 each parameter. The description adds no additional meaning beyond what the schema already provides. 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 action (build), the resource (unsigned revoke-authority transaction), and the scope (mint and/or freeze). It distinguishes from sibling tools like solknife_revoke_authority_execute and _read by including 'build' and 'unsigned'. The phrase 'Permanent on-chain' adds specificity.

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

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

Usage is implied: use when you want to permanently revoke mint or freeze authority. However, no explicit guidance on when to use this tool versus alternatives like solknife_change_authority_build or solknife_revoke_authority_execute. No when-not or prerequisites 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?

With no annotations provided, the description carries full burden of behavioral disclosure. It mentions 'Structural re-verifier pins the revoke ix(s) + fee' but does not clarify side effects, success/failure outcomes, or safety concerns (e.g., destructive nature).

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

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

The description is concise with only two sentences, avoiding unnecessary fluff. However, the second sentence is somewhat cryptic and could be clearer, slightly detracting from structure.

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 incomplete for a tool with no output schema and no annotations. It does not mention return values, error behavior, or post-conditions, leaving significant gaps for an agent to safely invoke the tool.

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

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

The input schema already provides detailed descriptions for both parameters (signedTransaction and lastValidBlockHeight), achieving 100% coverage. The main description adds no additional semantic value beyond the schema's 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 action ('Submit a wallet-signed revoke-authority tx'), which distinguishes it from sibling build and read counterparts. However, the phrase 'Structural re-verifier pins the revoke ix(s) + fee' adds jargon that may obscure the purpose slightly.

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

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

No explicit guidance on when to use this tool versus alternatives such as the build or read versions. The description assumes prior knowledge that the transaction must be built first, but does not state this directly.

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 correctly identifies the operation as read-only, but it does not disclose other behavioral traits such as error conditions, return format, or any potential side effects. Given no annotations, the description carries the burden but only provides basic functionality info.

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

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

The description is a single, well-structured sentence that front-loads the action ('Read'). It contains no extraneous information and is highly efficient.

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?

Considering the tool's simplicity (two straightforward parameters, no output schema), the description is nearly complete. It explains what is read and what is returned. Minor omission: no mention that it is a read-only operation, but that is implied by 'Read'.

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 the schema already documents the parameters. The description adds little beyond the schema's descriptions, simply naming the parameters 'mint' and 'owner' without additional context about their role in the operation.

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 mint and freeze authorities and checks if the owner holds either. It uses a specific verb ('read') and resource ('mint's authorities'), and distinguishes itself from sibling tools like 'build' and 'execute'.

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

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

No explicit when-to-use or when-not-to-use guidance is provided. The sibling tool names (e.g., 'solknife_revoke_authority_build', 'solknife_revoke_authority_execute') imply this is the read counterpart, but the description does not clarify that it is for inspection only, not for making changes.

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

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

No annotations are provided. The description discloses that the tool submits the transaction (warning in signedTransaction parameter not to submit it yourself) and returns an outcome type. However, it does not disclose potential failure modes, fees, or other behavioral details beyond what is minimally required.

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

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

The description is a single sentence that clearly states the action and return value. It is front-loaded with the verb and resource, and every word adds value. 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?

Given there is no output schema, the description covers the return type. However, it lacks context about prerequisites (e.g., needing a prior build step), error handling, or edge cases. For a simple execute tool, it is marginally complete but could be improved.

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

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

Schema description coverage is 100% with both parameters having explicit descriptions. The tool description adds no new information about parameters beyond what the schema already provides. 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 submits a wallet-signed swap transaction and specifies the return type (ExecuteOutcome). The verb 'Submit' and resource 'wallet-signed swap transaction' are specific and distinguish it from sibling tools, which include other execute operations like solknife_burn_nft_execute.

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 it should be used after building a swap transaction (references '/build call' in parameter descriptions), but does not explicitly state when to use or not use this tool versus alternatives. No exclusion criteria or comparisons to sibling tools 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?

No annotations are provided, so the description must fully disclose behavior. It states the tool returns an unsigned tx and quote details, implying no on-chain mutation, but does not explicitly confirm read-only nature, authorization needs, or failure modes. This leaves gaps for a tool that likely produces a quote.

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: one sentence with key details and an inline clarification about amount and return. It front-loads the purpose and uses no filler 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 no output schema, the description mentions return values (unsigned tx, lastValidBlockHeight, quote details), but does not elaborate on quote contents (e.g., price impact, route). The tool has 5 parameters and no output schema, so more detail would improve 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?

Schema coverage is 80%, and the description adds meaning to 'amount' ('in input-mint base units') and clarifies return values. The optional 'slippageBps' parameter is not mentioned in the description, but the schema provides its details. Overall, the description adds value 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 clearly states it returns an unsigned swap transaction and quote details, distinguishing it from execution or other tools. The verb 'swap' and resource 'order' indicate a quote/tx builder, which differs from siblings like 'solknife_swap_execute'.

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 it's for getting a quote and unsigned tx before execution, but does not explicitly state when to use it over alternatives (e.g., 'use this when you need a quote before executing, otherwise use solknife_swap_execute'). No exclusions or prerequisites are mentioned.

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

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

No annotations are provided, so the description carries full burden. It discloses the tool is a read operation (fetch) but doesn't mention rate limits, auth requirements, or side effects. For a simple query, this is minimally 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, front-loaded sentence that efficiently conveys the tool's purpose and output. No extraneous 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 simplicity (one parameter, no nested objects, no output schema), the description is nearly complete. It specifies the action, input, and returned fields. However, it could optionally mention the output format or provide an example.

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 clear parameter description. The tool description adds value by listing the metadata fields returned (name, symbol, decimals, image), which are not in the input schema, thus enhancing understanding.

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 fetches token metadata (name, symbol, decimals, image) for a mint. The verb 'Fetch' and resource 'token metadata' are specific, and it implicitly distinguishes from sibling tools with different verb prefixes like 'build', 'execute', 'read'.

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

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

No guidance on when to use this tool versus siblings like solknife_token_metadata_read. The description does not mention context, prerequisites, or 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 discloses that the 'lock' parameter makes metadata immutable and irreversible, which is a critical behavioral trait. However, it does not explain that the output is an unsigned transaction that must be signed and executed later. Since no annotations are provided, the description carries the full burden, and while it covers the lock aspect, it omits the overall build-execute lifecycle.

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 followed by a brief note on the 'lock' parameter. It is concise and front-loaded with the core purpose. Every word serves a purpose, making it efficient without unnecessary elaboration.

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 lacks information about the tool's output (e.g., the unsigned transaction object). It also does not place the tool in the broader workflow (build, then execute). For a build tool that produces an artifact for later use, this missing context 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?

Schema coverage is 100%, with each parameter described in the schema itself. The tool description only adds context for the 'lock' parameter, but that information is already present in the schema. Thus, the description adds minimal additional meaning beyond what the schema provides, meeting the baseline expectation.

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 builds an unsigned transaction for setting or updating Metaplex metadata. It uses a specific verb ('build') and resource ('Metaplex metadata tx'). The presence of sibling tools like 'solknife_token_metadata_execute' naturally distinguishes this as the build step, and the description reinforces that by calling it an unsigned tx.

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

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

The description provides no explicit guidance on when to use this tool vs alternatives (e.g., when to use set vs update, or prerequisites like needing an existing mint). It does not mention that this is part of a build-then-execute workflow or any conditions that would make this tool inappropriate.

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 mentions 'Structural re-verifier pins the metadata ix + fee', adding some behavioral context beyond the schema. However, with no annotations, it should disclose more about side effects, auth needs, or error states.

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

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

Two concise sentences with front-loaded action. Every word is meaningful and no waste.

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 tool with no output schema, the description is adequate but incomplete. It doesn't explain what 'pins' means or what the response looks like.

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 3. The description adds no additional parameter info beyond what's in the schema.

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

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

The description clearly states the action ('Submit') and resource ('wallet-signed Metaplex metadata tx'). It distinguishes from siblings by being the execute counterpart but does not explicitly differentiate from other execute 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?

No guidance on when to use this tool versus alternatives, no preconditions or exclusions. It merely states what it does without contextual usage advice.

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

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

With no annotations provided, the description accurately conveys that the tool is read-only and non-destructive by stating 'Read' and describing the return value. It does not mention additional behavioral traits (e.g., auth requirements, rate limits), but for a simple read operation this is sufficient and transparent.

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

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

A single, front-loaded sentence that conveys the tool's purpose and output succinctly. Every word is information-dense with no filler.

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

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

Given the lack of output schema, the description adequately explains what the tool returns (metadata and update capability). However, it does not cover potential edge cases (e.g., mint not found) or performance considerations, but for a straightforward read operation this is reasonably complete.

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

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

Schema coverage is 100% with both parameters described individually. The description adds value by explaining that `owner` is used to check update permission, which is not explicitly stated in the schema. This helps an AI agent understand the parameter's role in the output.

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

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

The description uses the verb 'Read' and specifies the exact resource ('mint's current on-chain Metaplex metadata') along with a specific output aspect (whether `owner` can update it). This clearly distinguishes it from sibling tools like `solknife_token_metadata_build` and `solknife_token_metadata_execute`, which imply write operations.

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

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

No guidance is provided on when to use this tool versus alternatives (e.g., `solknife_token_meta` or `solknife_change_authority_read`). There is no mention of prerequisites, context, or exclusions.

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