SolKnife

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

No annotations provided, so description must cover behavioral traits. It discloses upload action, max size (2 MiB), allowed content types, and return format. Lacks information on synchronicity, costs (though 'funded' hints at prepaid), failure modes, or persistence guarantees.

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, front-loaded with main action, each sentence adds distinct info. No redundant or vague language.

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

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

Given low parameter count (2), no output schema, and no annotations, description covers input constraints and expected output adequately. Missing error handling detail, but overall sufficient for basic use.

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

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

Schema covers 50% parameters with descriptions; the description compensates by enumerating allowed contentTypes and clarifying max size from schema. Adds meaning beyond schema by grouping constraints concisely.

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 uploads a base64-encoded file to Arweave via a funded Irys account, specifying resource (Arweave), verb (upload), and scope (JSON-only, agents without wallet). It distinguishes from siblings which handle on-chain Solana 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 states usage for agents without wallet-adapter integration and JSON-only, implying context. Does not explicitly state when not to use, but sibling tools are all different actions, so no ambiguity.

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 fully disclose behavior. 'Chunked' hints at splitting into multiple transactions but does not explain what 'chunked' means (e.g., batch size limit). There is no mention of side effects, signature requirements, or output 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 a single sentence with no wasted words. It conveys the core purpose efficiently, though 'chunked' 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 is provided, and the description does not indicate what the tool returns (e.g., transaction data). Given the tool builds transaction(s) for a complex blockchain operation, the description lacks critical context about the output and subsequent steps.

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% (only descriptions for addresses). The description does not explain how 'mints' relates to 'selected NFTs' nor the role of 'owner'. No additional context is provided beyond the schema.

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

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

The description uses a specific verb 'Build' and resource 'burn tx(s) for selected NFTs', which clearly indicates the tool prepares burn transactions. It also mentions pNFTs support. However, it does not explicitly distinguish from sibling tools like solknife_burn_nft_execute or solknife_burn_nft_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 guidance on when to use this tool vs alternatives. It does not explain that the built transactions are intended for subsequent execution by solknife_burn_nft_execute, leaving the usage flow ambiguous.

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 'pins the burn ixs + fee per tx' and returns outcomes, but does not disclose failure behavior, idempotency, or destructive nature (burning is inherently destructive but 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?

Two concise sentences, no unnecessary words. Front-loaded with the main action. Could be slightly more structured but very 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?

No output schema, but description only vaguely mentions 'Returns per-tx outcomes' without describing the format or error handling. For a submission tool in a large sibling group, more context is needed (e.g., what happens on failure, confirmation behavior).

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

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

Schema coverage is 100%, so parameters are well-documented in the schema itself. Description does not add significant new meaning beyond what's already in 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?

Clearly states 'Submit burn-nft tx(s) (signed)' with specific verb 'Submit' and resource 'burn-nft transactions'. Distinguishes from sibling tools like build and list by mentioning signed transactions and referencing the /build call.

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 use after building by referencing signed transactions and the /build call, but no explicit guidance on when to use or not use this tool vs alternatives like solknife_burn_nft_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?

With no annotations provided, the description carries full responsibility for behavioral disclosure. However, it only states 'List a wallet's NFT assets (DAS)' and does not reveal whether the operation is read-only, if there are side effects, rate limits, or any other behavioral traits. The term 'DAS' is unexplained, and the agent is left unsure about the tool's impact.

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 at one sentence, which is efficient. However, it might be too minimal, as it lacks details that could be added without expanding length (e.g., output hints). Still, it is well-structured and front-loaded.

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

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

Given the lack of annotations, no output schema, and only one parameter, the description is incomplete. For a list tool, it does not explain the format of returned data (e.g., metadata vs IDs), pagination, or any constraints like maximum items. The description does not fully equip the 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 100% for the single parameter 'owner', which already includes a pattern description. The description adds no further meaning beyond what the schema provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'List a wallet's NFT assets (DAS).' It uses a specific verb ('List') and resource ('wallet's NFT assets'), and adds context with '(DAS)' indicating the standard used. This distinguishes it from sibling tools like solknife_positions_list (token positions) and solknife_burn_nft_build/execute (burning NFTs).

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 usage guidelines are provided. The description does not indicate when to use this tool instead of alternatives such as solknife_positions_list or solknife_token_meta. There is no mention of prerequisites, context, or exclusions, leaving the agent to infer without 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, so description carries burden. Discloses it builds an unsigned transaction (no on-chain effect) and that new authority is pinned for verification. But doesn't mention authorization requirements (must be current authority) or that it's a Solana transaction structure.

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

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

Two concise sentences, front-loaded with purpose. No wasted words. Each sentence adds necessary 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 5 required params, no output schema, and medium complexity, the description covers core purpose but misses details like return format (unsigned transaction), what 'pinned' means, or that this is a Solana-specific tool. Adequate but not comprehensive.

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 is 3. Description adds context that changeMint/changeFreeze booleans control which authority transfers, but otherwise doesn't significantly augment schema descriptions. 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?

Description clearly states it builds an unsigned change-authority transaction for transferring mint/freeze authority. Verb 'build', resource 'unsigned change-authority tx', and purpose are specific. Distinguished from siblings like solknife_change_authority_execute (execute) and solknife_change_authority_read (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?

Implies usage for changing authorities but lacks explicit when-to-use vs alternatives like revoke_authority_build. No prerequisites or context about when this tool is appropriate versus others. Minimal 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, so description must cover behavior. Mentions 'structural re-verifier pins the reassign ix(s) + fee' but lacks disclosure on failure modes, side effects, or what happens after submission.

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. However, 'Structural re-verifier pin the reassign ix(s) + fee' is jargon-heavy and may confuse agents.

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

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

No output schema and no annotations; description should explain return value (e.g., transaction signature) and post-submission behavior. Missing critical information for an execute 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?

Both parameters have rich descriptions in the schema, explaining their origin and constraints. The signedTransaction description explicitly warns against double submission; lastValidBlockHeight explains expiry. These add significant 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?

Clearly states the action: submitting a wallet-signed change-authority transaction. Differentiates from sibling tools like build and read. However, 'change-authority' could be more explicit about what authority is changed.

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 vs alternatives. Implied it follows the build step, but no when-not or context 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?

Read-only operation is clear; no annotations exist, but description adequately discloses what is read without contradictory claims.

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 front-loaded purpose and useful parenthetical; no extraneous content.

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

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

Adequate for a simple read tool with two parameters; lacks output format details but implied by read nature.

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 provides full coverage with descriptions; the description adds meaning by specifying owner's role, but not significantly 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?

Description clearly states it reads mint and freeze authorities and checks owner using specific verbs, distinguishing it 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?

Parenthetical 'before transferring one' hints at usage context, but no explicit when-to-use vs alternatives like solknife_revoke_authority_read.

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 convey behavioral traits. It mentions the tool 'Rug-checks', implying a read-only analysis, but does not explicitly state it is non-destructive, nor does it disclose any side effects, permissions, 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?

Description is concise (one sentence plus a note on return shape) and front-loaded with the core purpose. Minor improvement could be structuring the listed aspects more formally.

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, the description fails to elaborate on the 'ReportResult' shape it returns. Given the tool's single parameter and no annotations, more detail on output fields would greatly aid an AI agent.

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

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

Schema description coverage is 100% for the single parameter 'mint', which is well-described in the schema. The tool description does not add further parameter guidance, 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?

Description clearly states the tool 'Rug-checks a Solana token' and lists specific aspects checked (freeze authority, sellability, holders, liquidity). This distinguishes it from sibling tools like solknife_pool_check and solknife_pool_compare, which focus on 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?

No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives, nor does it mention prerequisites or 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?

No annotations provided, so description carries burden. It states the tool is a build (returns unsigned tx) and is idempotent. This adds context about its side-effect-free nature. However, it does not disclose what happens if the ATA already exists (idempotent implies it might return existing), or any authentication needs.

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 waste. The acronym 'ATA' may be unclear to some agents, but it's a standard domain term. The description is front-loaded with action and resource.

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 tool without output schema, the description explains what it does but lacks details on return format, prerequisites (e.g., token account existence), or error conditions. It is adequate but not thorough.

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 each field (base58 addresses). The description adds the context that mints are the SPL token mints for which ATA are built, and owner/payer roles are implied. This provides some additional meaning but does not fully explain parameter semantics beyond what 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 explicitly states it builds an unsigned ATA-create transaction (idempotent) for one or more mints. This clearly identifies the verb (build), resource (ATA-create tx), and scope (for mints). It distinguishes from siblings like solknife_create_account_execute which likely executes the built 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?

No explicit guidance on when to use this tool vs alternatives. While 'idempotent' hints at safe re-use, the description does not state prerequisites or when not to use it. Among many sibling tools, lack of comparative context reduces usability.

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 submits a signed transaction and mentions a 'structural re-verifier' that pins ATA creation instructions and allowlist, hinting at validation. However, it does not explain what happens on success/failure, whether it blocks, or other 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?

The description is two sentences with no redundancy. The first sentence states the core function, and the second adds key context about verification. Every part 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 simple submit tool with two parameters and no output schema, the description is mostly complete. It explains the transaction type and mentions verification. However, it could clarify the return value or state changes, and the linkage to the build tool is implied but not explicit.

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 tool description adds context by specifying that the transaction is for ATA creation and mentioning the re-verifier, which enhances understanding of the 'signedTransaction' parameter 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 verb 'Submit' and the resource 'ATA-create tx', specifying that it handles a wallet-signed transaction for creating an associated token account. It distinguishes itself from sibling tools like 'build' and 'list' 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 a build-then-execute workflow by referencing 'the matching /build call' and instructing the agent not to submit the transaction manually. However, it does not explicitly state when to use this tool versus alternatives (e.g., other execute tools), and lacks explicit 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, so the description carries the full burden. It states the tool builds an unsigned transaction and returns specific data, implying no state change. However, it does not disclose requirements (e.g., payer must hold SOL), error conditions, or idempotency. The description is accurate but not rich.

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 is concise and front-loaded with the key purpose. It could be slightly more structured (e.g., listing return values explicitly), but there is no wasted information.

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

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

Given the lack of an output schema, the description does explain the return values (base64 tx, lastValidBlockHeight, mint address). However, it does not elaborate on how nested parameters like 'extensions' affect the build, which might be needed for full 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% with 5 of 6 parameters described), so the baseline is 3. The tool description does not add any extra meaning beyond what the schema already provides for parameters like 'extensions' or 'freezeAuthority'. It is adequate but not enhanced.

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 specifies the action ('Build an unsigned create-mint tx'), the resource ('create-mint'), and the output ('base64 v0 transaction + lastValidBlockHeight + derived mint address'). It distinguishes from sibling tools like solknife_create_mint_execute by noting it builds an unsigned 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 does not provide guidance on when to use this tool versus alternatives (e.g., solknife_create_mint_execute). It does not mention that the returned transaction needs to be signed and broadcast, or that this is a preparation step before execution.

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. The mention of 'structural re-verifier' and 'pins the mint creation ix + fee' hints at internal verification but is vague and doesn't explain side effects (e.g., on-chain state mutation), failure modes, or idempotency. Lacks important behavioral details for an execute tool.

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

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

Two sentences, no redundant information, front-loaded with the primary action. Every word serves a purpose; the second sentence adds context without verbosity.

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

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

Given no output schema, the description does not explain what the agent should expect after submission (e.g., transaction signature, confirmation status). It covers the input adequately but omits return value and post-submission behavior. Adequate for a simple execute tool but not fully 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 description coverage is 100% - both parameters have clear descriptions in the schema (signedTransaction: signed tx from build, not to resubmit; lastValidBlockHeight: expiration). The tool description adds no additional parameter semantics beyond restating the action. 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 'Submit a wallet-signed create-mint tx', which is a specific verb ('submit') on a specific resource ('create-mint tx'). The tool name suffix '_execute' distinguishes it from the '_build' sibling, indicating the execution phase of a two-step process.

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?

Implicitly indicates usage after building the transaction (sibling solknife_create_mint_build). No explicit when-not or alternatives, but the context of sibling tools and the description's focus on submission makes the intended use clear. Lacks explicit precondition (e.g., 'use after build') but adequate for an agent.

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

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

No annotations are provided, so the description carries the full burden. It only states 'Build the ApplyPending tx' without disclosing any behavioral traits such as side effects, required permissions, dependencies, or what happens upon execution. This is severely lacking.

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, concise and free of unnecessary words. It front-loads the main action. However, it sacrifices 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?

Given the complexity of Solana transaction building and the lack of output schema and annotations, the description is too minimal. It does not explain the transaction's purpose, prerequisites, or what the build output is, 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 75% (3 of 4 parameters have descriptions). The description adds a small extra detail about newDecryptableAvailable being a 36-byte AES base64 from a worker, but this largely echoes the schema. No additional meaning for mint, owner, or expectedPendingCounter. Baseline 3 is appropriate as schema does most of the work.

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' which clearly identifies the verb (build) and resource (ApplyPending transaction). It also specifies the key parameter's nature (AES base64 from worker). However, it lacks context on what 'ApplyPending' means in the Solana domain, making it less clear among 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 provides no guidance on when to use this tool versus other build tools like solknife_burn_nft_build or solknife_ct_deposit_build. No prerequisites or conditions 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 must disclose behavior. It mentions required inputs (proof and ciphertext) but does not describe side effects, mutability, permissions, or return value. Assumes a 'build' operation is non-destructive, but not explicitly 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?

Description is a single sentence that front-loads the purpose. It is concise with no redundant information, but could be slightly clearer. Efficient use of 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?

Without output schema or annotations, description fails to explain what the built transaction does or how it fits into the workflow. Niche concepts like 'PubkeyValidity proof' and 'decryptable-zero' are not explained, leaving agent unsure about when to invoke this tool.

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

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

Schema coverage is 100%, so baseline is 3. Description adds value by specifying that pubkeyValidityProof is 'agent-generated' and 96 bytes, and decryptableZeroBalance is 'worker computed' AES ciphertext of 36 bytes, aiding understanding of parameter provenance and format beyond schema constraints.

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

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

Description states 'Build the Configure tx' which is a clear verb and resource, but 'Configure tx' is ambiguous without context; it could refer to configuring a confidential token account or something else. It does not distinguish from sibling 'ct_build' tools like deposit or transfer, which have similar names.

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. No mention of prerequisites, conditions, or scenarios. The description only states what it does without context for selection among siblings.

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

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

No annotations are provided, so the description carries the full burden. It states 'Build the Deposit tx' but does not disclose whether the tool is read-only, destructive, or what side effects occur. Since it's a build step, likely it constructs a transaction without executing, but this is not explicitly 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 concise, consisting of one sentence plus a note on amount. It is front-loaded with the tool's purpose. Minor improvement could separate the parameter clarification for better 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?

The tool builds a deposit transaction but does not describe what the output is (e.g., serialized transaction or transaction ID). Given no output schema, the description should clarify the return value. Also missing prerequisites like owner authorization or account existence.

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

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

Schema description coverage is 100%, with each parameter already described. The description adds 'amount in base units (u64 string)' reinforcing the schema, but does not provide supplementary meaning beyond what the schema already offers. 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 builds a deposit transaction for moving assets from public to confidential pending. It distinguishes itself from sibling tools like solknife_ct_withdraw_build and solknife_ct_transfer_build by specifying 'Deposit' and the direction 'public → confidential pending'.

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 provide explicit guidance on when to use this tool versus alternatives (e.g., withdraw or transfer). It implies usage for deposits via the name and description, but lacks when-not-to-use or alternative suggestions.

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 carry all behavioral disclosure. It only says 'Build the combined ... tx', which implies transaction construction but omits details such as whether it requires specific permissions, what happens if the proof is invalid, or whether it mutates state (though as a build step, likely not directly).

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 with no wasted words. It front-loades the core purpose and the critical input constraint, making it 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 build tool with no output schema and no annotations, the description is too brief. It does not explain what the tool returns (e.g., a serialized transaction, a transaction hash), how to use the output, or how this build step relates to execution tools like solknife_ct_submit. This leaves gaps for an agent to correctly 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?

Schema description coverage is 100%, so parameters are already documented. The description adds the specific '96 B base64' constraint for zeroCiphertextProof, which provides useful context beyond the schema's general '96-byte' note. This is a minor improvement, justifying a 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 it builds a combined EmptyAccount + CloseAccount transaction, and specifies the key input (96 B base64 zero-ciphertext proof). However, it does not differentiate from sibling build tools like solknife_ct_deposit_build, though the name is already distinctive.

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 constructing an empty-and-close operation, but lacks explicit guidance on when to use this tool versus alternatives (e.g., separate empty/close steps) or any prerequisites (e.g., need for a pre-existing account).

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 only states the purpose, not behavior like side effects, permissions, or state changes. The agent is left guessing about construction 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?

Single sentence, no wasted words. However, the term 'chunked tx(s)' is somewhat ambiguous and could benefit from clarification.

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 provided. The description does not explain what the built transactions look like (e.g., an array) or how to use them. This is a significant gap for a build 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 50%, with basic format descriptions. The tool description adds context ('reclaim orphan ZK ctx rent') but does not fully explain the role of 'owner' or how 'addresses' relate to the rent reclaim process.

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

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

The description uses a specific verb ('Build') and resource ('chunked CloseContextState tx(s) to reclaim orphan ZK ctx rent'), clearly distinguishing the tool from siblings like 'solknife_ct_orphans_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 guidance on when to use this tool vs alternatives (e.g., 'solknife_ct_orphans_list' for listing orphans first). No mention of prerequisites or when not to use.

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

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

With no annotations, the description should convey behavioral traits. It only says 'List', implying read-only, but does not state side effects, permissions, or error behavior.

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 fluff, front-loads the key action and resource.

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 simple tool (one param, no output schema), the description covers the core functionality but could briefly note return format or ordering.

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 its parameter description is adequate. The tool description adds no extra semantics beyond 'wallet's' which is implied.

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), the resource (orphan ZK Proof context-state accounts), and the context (left by partial Withdraw or Transfer sagas), distinguishing it from siblings.

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

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

The description implies when to use (to find orphan accounts) but does not explicitly state when not to use or mention alternative tools.

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

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

No annotations are provided, so the description must disclose behavioral traits. It correctly states 'Read', indicating a non-destructive operation, and specifies the data returned. However, it does not mention whether any special permissions are required or if the call is rate-limited. The description is adequate but lacks depth for a tool with zero annotation coverage.

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

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

The description is a single sentence that is front-loaded and contains no extraneous words. It efficiently conveys the purpose and key data returned. Every part 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 that there is no output schema, the description compensates by listing what data is returned (mint extension flags, account configured, balance ciphertexts). It covers the essential aspects for a read tool with two parameters. Some missing details like pagination or error conditions would be nice, but the description is largely complete for the tool's complexity.

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

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

Schema description coverage is 100% (both 'mint' and 'owner' have descriptions stating they are Solana addresses). The description adds the context 'for owner + mint', which is essentially the same as the parameter names. Therefore, it provides minimal additional meaning beyond the schema, earning the baseline score of 3.

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

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

The description uses specific verb 'Read' and resource 'confidential-transfer state for owner + mint', and lists the data components (mint extension flags, account configured, balance ciphertexts). It clearly distinguishes this read tool from other solknife tools that are build/execute/list 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?

The description implies usage as a read query for confidential-transfer state, but provides no explicit guidance on when to use it versus alternatives like solknife_ct_orphans_list or solknife_multisig_state. 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 the full burden. It discloses that the server re-verifies the saga shape and fee per op before relaying, which adds behavioral context. However, it does not mention authentication requirements, rate limits, or what happens on failure (e.g., error responses). The description could be more comprehensive given the absence of annotations.

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

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

The description is extremely concise: two sentences that front-load the purpose and immediately follow with usage instructions. Every sentence earns its place; there is no filler or repetition.

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

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

The tool has 4 parameters, 2 required, no output schema. The description explains the core logic and server behavior, but it does not describe the return value or what the agent can expect after submission. For a tool that submits transactions, the response format (success/error) would be important context, especially with no output schema.

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

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

The schema already describes the parameters (75% coverage), but the description adds value by explicitly linking the parameter selection to the operation type ('op discriminates'). It clarifies that 'signedTransactions' (array) is for saga ops and 'signedTransaction' (single) for others. This goes beyond the schema's individual descriptions.

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

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

The description clearly states the tool's purpose: 'Submit a CT signed tx (single-tx ops) or saga (multi-tx ops).' It specifies that the operation discriminates between single-transaction and multi-transaction (saga) operations, aligning with the sibling build tools. The purpose is specific and well-defined.

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

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

The description provides explicit guidelines on when to use each parameter: for saga ops (withdraw, transfer, reclaim-orphans) supply 'signedTransactions' (an array), otherwise supply 'signedTransaction'. It also mentions server re-verification. However, it does not explicitly contrast with sibling tools (e.g., the corresponding build tools) or state when this tool should be used over others, such as after building transactions.

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 mention whether the tool submits on-chain or just builds, what side effects occur, or any permissions required (e.g., signing). The word 'build' implies construction only, but without confirmation, an agent may misuse it.

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

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

Single sentence front-loads purpose, then lists inputs compactly. At 43 words, it is dense but not redundant. Could be split for clarity, but remains 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?

Lists all required inputs (12 params) and their types (proofs, ciphertexts, accounts). However, with no output schema, it omits return values, next steps (e.g., execute), and prerequisites. For a complex saga builder, this is a notable gap.

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

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

Schema coverage is 100% (every parameter described). The description adds byte-size context (e.g., equality 320 B, validity 544 B) and clarifies relationships (e.g., 'three ephemeral ctx-state pubkeys' mapping to context accounts). This supplements the schema's base64 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 states 'Build the 5-tx Transfer saga' with a specific verb and resource, and lists required proofs and ciphertexts. It distinguishes itself from sibling tools (e.g., ct_deposit_build) by mentioning transfer-specific components, but could be clearer about the saga's purpose.

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, prerequisites (e.g., prior account creation, proof generation), or when not to use it. The description assumes agent already has proofs and accounts ready, but does not state this explicitly.

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

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

No annotations are provided, so the description carries full burden. It mentions building a saga but does not disclose side effects, authorization requirements, or what the built transaction does. Lacks behavioral context such as whether the operation is destructive or requires prior state.

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

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

Two sentences, front-loaded with the core purpose. No redundant information, every sentence adds value. Efficient for an AI agent to parse.

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

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

Given the complexity of a 5-tx saga and no output schema, the description is minimal. It does not explain return values or how the saga is constructed. While the inputs are listed, the agent may need more context on expected output or next steps.

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. The description adds value by identifying the two 'ephemeral ctx-state pubkeys' (equalityContextAccount and rangeContextAccount), which is not explicit in the schema. This slightly surpasses 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 states it builds a '5-tx Withdraw saga' with specific inputs: proofs, decryptable, and pubkeys. This is a specific verb+resource, clearly distinguishing it from sibling build tools (e.g., deposit, 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?

No explicit when-to-use or when-not-to-use guidance is provided. The purpose implies it is for withdrawing from a confidential token, but no alternatives like deposit or transfer are mentioned, 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?

With no annotations, the description adds some behavioral detail (the builder parses amount against decimals). However, it omits key traits like side effects (none, since unsigned) and prerequisites (e.g., mint must exist). The contradiction with the schema's parameter description reduces trust.

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 and to the point, with no filler. It could benefit from a second sentence about return value, but it remains efficient for its 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 lacks critical context: it does not specify that the tool returns an unsigned transaction (important for a build tool), nor does it mention the need for subsequent execution. Given no output schema, this omission hampers an agent's ability to chain calls correctly.

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

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

The description claims 'amount' is a whole-token decimal string that the builder parses, but the schema states it is in base units (user multiplies by 10^decimals). This contradiction misleads the agent; the description adds no useful meaning and conflicts with 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 builds an unsigned mint transaction, implying a build step. However, it does not differentiate from siblings like 'solknife_mint_supply_execute' or 'solknife_mint_supply_read', which could cause confusion for an AI agent.

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 versus its siblings (e.g., after building, use execute). The word 'unsigned' hints at a build-execute pattern, but no direct alternatives 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 the description must disclose behavior. 'Structural re-verifier pins the mint-to ix + fee' adds some internal context, but it does not mention side effects, authentication requirements, rate limits, or failure behavior.

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

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

Two short sentences with no redundancy. However, the second sentence is jargon-heavy and may be unclear to some agents, slightly reducing conciseness effectiveness.

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 is provided, yet the description omits any information about the return value (e.g., transaction hash, confirmation). Given the tool submits a transaction, this is a significant gap for an agent to understand the result.

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 parameter descriptions are clear and self-contained. The description adds no extra meaning beyond the schema, achieving the baseline score of 3.

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

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

The description states the verb 'Submit' and the resource 'wallet-signed mint-to tx', indicating the tool's action. It contrasts with sibling tools 'build' and 'read' by focusing on execution, but does not explicitly differentiate beyond the verb.

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 like 'build' or 'read'. The description implies it follows a build step, but does not state when not to use it or mention any prerequisites.

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 accurately describes the tool as a read operation, implying no side effects. However, it does not disclose error conditions, network requirements, or what happens if inputs are invalid, which would be helpful for a complete behavioral picture.

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 conveys all necessary information without any filler. It is front-loaded with the action and resource.

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

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

Given the tool has no output schema, the description hints at the return value ('authority state plus whether owner is its mint authority'). This is sufficient for a simple read tool with two parameters, though explicitly stating the output format (e.g., boolean or object) 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?

The schema already provides descriptions for both parameters (base58 addresses), achieving 100% coverage. The description adds meaning by clarifying that 'mint' is the mint address and 'owner' is the address to check for authority. This contextualizes the parameters beyond their syntax.

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 'Read', the resource 'mint's authority state', and the specific check 'whether owner is mint authority'. It also provides the use case 'prerequisite for mint-to', making its purpose unambiguous and distinguishing it from sibling tools 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?

The description explicitly states 'prerequisite for mint-to', which guides when to use this tool. While it doesn't explicitly list when not to use it or differentiate from other read tools like solknife_change_authority_read, the context is clear enough for the agent to decide.

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 states 'build an unsigned vote tx' but does not disclose permissions, side effects (likely none), or what to do with the output. Lacks details on the transactional flow.

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, efficient and to the point. Could be slightly more structured but not wasteful.

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

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

Given the complexity (4 params, no output schema, many siblings), the description is too minimal. It doesn't explain what an unsigned tx is, how to use the built transaction, or how this fits in the multisig 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 high (75%) and description restates the vote and transactionIndex purpose but adds no new meaning beyond 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?

Clearly states it builds an unsigned vote transaction to approve or reject a proposal at a given transactionIndex. The verb 'build' and resource 'vote tx' are specific, and it distinguishes from siblings like 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 this tool is for creating an unsigned vote, and that there is an execute counterpart, but does not explicitly state when to use this vs alternatives or provide a workflow hint.

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 carry the full burden. It only says 'submit', with no disclosure of side effects, confirmation behavior, or auth requirements. The schema for signedTransaction includes 'Do not submit it yourself; this endpoint submits it', but this is in the parameter description, not the main description.

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

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

Two short sentences, zero wasted words. The action and critical constraint are front-loaded.

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

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

For a submission tool with 3 parameters and no output schema, the description covers the essential vote matching but omits expected return values (e.g., transaction signature) and post-submission behavior. The schema provides some context (e.g., lastValidBlockHeight), but the description overall is minimally 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 description coverage is 67% (vote lacks a description). The tool description adds value by advising to use the same vote value from the build, compensating for the missing schema description. However, it does not add detail for other parameters 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 'Submit the signed vote tx', which is a specific verb+resource. It distinguishes itself from siblings like solknife_multisig_approve_build (builds the vote) and solknife_multisig_execute_execute (executes after approval).

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 instruction 'Pass the same vote value used in the build' provides clear context for when to use this tool—after building the vote. It implies not to use it without a prior build step, but does not explicitly list alternatives or exclusions.

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

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

With no annotations, the description bears the full burden. It states the tool builds an 'unsigned' proposal, implying no on-chain execution or state change, and restricts usage to m-of-n multisigs. However, it does not disclose authentication requirements (e.g., proposer must be a member) or potential side effects like temporary storage.

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 deliver the core purpose and operation-specific parameter requirements. Every sentence contributes necessary information, with no redundancy or filler. The structure is front-loaded with the action and resource.

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 input requirements well but omits what the tool returns (the unsigned proposal format). With no output schema, the agent has no clue about the return structure. It also lacks prerequisites (e.g., multisig must exist) or error conditions. For a build tool that likely returns a transaction, this is a noticeable gap.

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

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

The description adds value beyond the input schema by explaining how each parameter is used conditionally per operation (e.g., 'op=add-member needs member + optional permissions'). The schema provides basic descriptions and patterns, but the description clarifies dependencies among 7 parameters. Coverage is 57%, but the description compensates for the missing context on how parameters interact.

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 config-change proposal, specifies the three operations (add-member, remove-member, change-threshold), and distinguishes from single-config-authority multisigs. The verb 'build' and resource 'config-change proposal' are specific, and the sibling tools include other multisig actions, so the purpose is unambiguous.

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

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

The description explicitly notes that the tool only works on m-of-n multisigs (not single config authority), which guides the agent on when it is applicable. It also outlines required parameters per operation, but does not directly compare with sibling tools like solknife_multisig_propose_build for general proposals, missing a clear 'when-to-use' vs 'when-not-to'.

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

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

No annotations are provided, so the description must fully explain behavior. It only says 'submit' without detailing what happens post-submission (e.g., confirmation, errors, side effects). It does not disclose that submitting is a mutable operation or that the transaction could fail.

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 short sentence that is front-loaded with the action. It is concise, but could be slightly more informative without harming 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?

With no output schema and a lack of details about the response (e.g., transaction signature, status), the description is incomplete. Users do not know what to expect after submission, such as success indicators or error handling.

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

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

Both parameters have detailed descriptions that explain their origin (from /build call), constraints (e.g., lastValidBlockHeight must be under a certain value), and instructions (e.g., 'Do not submit it yourself'). Schema coverage is 100%, and the descriptions add significant practical guidance.

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 'Submit the signed config-change proposal tx' uses a specific verb (submit) and resource (signed config-change proposal transaction). The tool name includes 'multisig_config_execute', clearly distinguishing it from 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 it is used after building a signed transaction, but does not explicitly state when to use this tool versus alternatives, such as other execute tools. No exclusions or context about prerequisites 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?

With no annotations, the description carries the full burden. It explains the co-signing requirement, random key generation, and return data (multisig/vault addresses, tx). It doesn't describe side effects, but building an unsigned tx is inherently non-destructive.

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 redundancy. Purpose is stated first, then the key requirement and return values. Every sentence serves a purpose, and the structure is front-loaded.

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

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

Given no output schema or annotations, the description covers the essential purpose, key parameters, and return format. It could mention the follow-up step (using create_execute) but is otherwise complete for a build 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 high (80%), so baseline is 3. The description adds value by explaining the critical 'createKey' parameter's role and the return data, which helps the agent understand the output. Other parameters are adequately described in the schema.

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

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

The description clearly states the tool builds an unsigned create-multisig transaction, specifying the key requirement (two signers: creator + createKey) and listing return values. It distinguishes from siblings like 'execute' by emphasizing 'unsigned' and 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?

The description does not explicitly state when to use this tool or when to use alternatives. While the 'build' vs 'execute' naming hints at a two-step process, no guidance is provided on prerequisites or exclusions.

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

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

No annotations provided. The description only states 'submit' which implies a write operation. It lacks details on side effects, fees, confirmation behavior, or failure modes beyond what the schema descriptions provide.

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

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

The description is a single, clear sentence that front-loads the action. Every word serves a purpose; no redundancy.

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

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

Given the simple two-parameter tool with full schema descriptions and the clear sibling structure (build/execute pairs), the description is mostly sufficient. However, it does not mention return value or outcome, which an agent might need.

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 parameter descriptions are detailed; the tool description adds no additional parameter information 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?

The description clearly states the verb 'submit' and the resource 'signed create-multisig tx', and specifies the signing requirement (both creator wallet and createKey), which distinguishes it 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?

The description implies usage after building (references signed tx) but does not explicitly state when to use vs alternatives, nor does it mention prerequisite steps or exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds context by noting that the server detects vault vs config and returns executeKind, and that computeUnitLimit can raise CU cap. However, it lacks details on side effects, authentication requirements, or error conditions, leaving some 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 two sentences with no wasted words. It is front-loaded with the core purpose and immediately followed by actionable guidance, making it efficient and easy to parse.

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

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

Given no output schema, the description mentions the return of executeKind but does not detail the full output structure. For a build tool in a multisig workflow, it covers the key inputs and workflow step. It is fairly complete but could be enhanced with more about the returned transaction format.

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

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

Schema description coverage is 75% (3 of 4 parameters have descriptions). The description adds value by explaining that computeUnitLimit optionally raises the CU cap for heavy inner transactions (not described in schema) and clarifies that transactionIndex should come from /api/multisig/state. This goes beyond the schema alone.

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 execute transaction for an approved proposal at a given transactionIndex. It specifies the verb (build), resource (unsigned execute tx), and constraint (APPROVED proposal), and distinguishes from sibling tools 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 tells the agent to pass the result to execute.execute, indicating the next step in the workflow. It also mentions the optional computeUnitLimit for heavy transactions. However, it does not explicitly state when not to use this tool or list alternatives beyond the implied build/execute pattern.

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 says 'Submit the signed execute-proposal tx.' It does not disclose behavioral traits such as side effects, failure modes, or idempotency. For a mutation tool, this is insufficient, as the agent needs to know what happens after submission.

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

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

The description is exceptionally concise with two short sentences. It front-loads the core action and provides a critical usage hint, with 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?

Given the lack of output schema, the description does not explain what the tool returns after submission (e.g., transaction signature or confirmation). It also omits prerequisites beyond execute.build. While adequate for a simple execute step, it leaves some gaps for an agent unfamiliar with the pattern.

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 detailed descriptions for signedTransaction and lastValidBlockHeight. The overall description adds value by explaining that executeKind must come from execute.build, but does not expand on the other parameters 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 the action (submit) and the resource (signed execute-proposal tx). It references the specific parameter executeKind and ties it to the build step, distinguishing it from sibling tools like solknife_multisig_execute_build and 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?

The description instructs to pass the executeKind returned by execute.build, providing clear context on when to use this tool. It implies the prerequisite of having a signed transaction from the build step, but does not explicitly state when not to use it or mention 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?

With no annotations, the description carries the burden. It discloses that the transaction is unsigned, that the payer for inner instructions is the vault PDA, and that the proposer auto-approves if eligible. This adds meaningful behavioral context beyond the schema.

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

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

The description is concise—two sentences—with the primary purpose upfront, followed by kind-specific details. Every word adds value, no fluff.

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

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

The description covers core functionality but lacks information about return values (no output schema), error conditions, or prerequisites (e.g., existence of multisig). Given tool complexity and many siblings, more completeness would improve usability.

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%, but the description compensates by explaining the meaning of parameters per kind (e.g., lamports for sol-transfer, mint+recipient+amount for token-transfer, structure of raw instructions). It adds semantic value for the key 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 it builds an unsigned propose transaction, specifies three kinds (sol-transfer, token-transfer, instructions) and their required parameters, effectively distinguishing it from related tools like propose_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?

While the description explains the kind-specific inputs, it lacks explicit guidance on when to use this tool versus alternatives (e.g., propose_execute or other multisig tools). The auto-approval note is helpful but does not provide usage boundaries.

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 carry the burden. It only says 'submit', which is vague about side effects, idempotency, or network interaction. The parameter description for signedTransaction adds a warning about not submitting yourself, but the main description lacks behavioral context. Disclosing that this sends a transaction to the blockchain would improve 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?

Single sentence with no wasted words. Very concise. However, it could be slightly expanded with workflow context without becoming verbose. The brevity here is acceptable but not exemplary.

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 description should explain what the tool returns or what happens after submission. It does not mention the multisig workflow or that this is the execution step after proposing. The parameter descriptions supply some context, but overall the description is too sparse for a tool with many siblings and no annotations.

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

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

Schema coverage is 100%, and the parameter descriptions are detailed: they specify the format (base64 VersionedTransaction), source (/build call), and behavior (do not submit yourself; lastValidBlockHeight). The main description adds nothing about parameters but also does not detract. 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 'Submit the signed propose-transaction tx' clearly states the action and resource. The verb 'submit' and object 'signed propose-transaction tx' make the tool's purpose understandable. However, it does not differentiate from siblings like solknife_multisig_execute_execute or solknife_multisig_approve_execute, which also submit signed transactions but for different steps.

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 parameter descriptions hint that the signed transaction comes from a /build call, but the main description fails to mention prerequisites or relationships to build tools. With many sibling execute tools, this omission reduces the agent's ability to choose correctly.

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 uses 'Read' to indicate read-only behavior and details what is returned, including the null return case. However, since no annotations are provided, it does not cover aspects like cost, authorization, or side effects. Still, the read intent is clear and sufficient for most agents.

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 efficiently conveys the tool's purpose and return data. It is front-loaded with key information and contains 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 complexity of a multisig state read with multiple components, the description covers all essential return fields (members, permissions, threshold, vault balance, pending proposals with vote details) and the null behavior. No output schema exists, so the description compensates fully.

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

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

The input schema fully describes the single parameter 'address' with regex and description. The tool description does not add additional meaning beyond what the schema provides. Per the rule for high schema coverage, 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 reads a Squads v4 multisig by address and enumerates the specific data returned: members, permissions, threshold, vault balance, and pending proposals with vote tallies. It also mentions the null return for non-multisig addresses. This distinguishes it from sibling tools that create, approve, or execute proposals.

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 reading multisig state, but does not explicitly contrast with alternative tools like multisig_create_build or multisig_approve_execute. It provides context by listing what is returned, but lacks explicit 'when not to use' or alternative recommendations.

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 indicates a read-only operation ('Read') and lists the data returned, but does not disclose data freshness, cost implications, or authentication needs. With no annotations, more detail would be beneficial.

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, concise sentence that immediately conveys the tool's purpose and key outputs. 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?

For a simple read tool with one parameter and no output schema, the description adequately covers purpose and main return fields. However, it could elaborate on the structure of the returned data.

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?

Only one parameter (address) with 100% schema description coverage; the description does not add extra meaning beyond the schema's regex pattern and type.

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 reads a single Meteora DLMM pool and lists specific attributes (depth, volume, fee yield, token safety summary). It is distinct from the sibling 'solknife_pool_compare', which likely compares 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?

No explicit guidance on when or when not to use. It implies use for reading details on a specific pool, but does not mention alternatives or prerequisites.

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 does not disclose behavior beyond the action, such as whether it is read-only, rate limits, or what 'side by side' means in terms of output.

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?

Very short (8 words) and front-loaded, but under-specified for a tool that compares many pools. Could be more informative without being verbose.

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 detail on output format, what 'side by side' implies, and whether it covers all pools. No output schema provided, and description does not 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 high (100%), with the only parameter 'mint' having a clear schema description. The tool description adds no additional meaning beyond that, so baseline score of 3.

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

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

The description uses a specific verb ('Compare') and resource ('every Meteora DLMM pool for a token') and clearly indicates the side-by-side comparison. It distinguishes from siblings like solknife_pool_check.

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

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

No guidance on when to use this tool versus alternatives such as solknife_pool_check. No exclusions or context for usage 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, and the description only mentions 'best-effort' and fee charging. Lacks details on failure cases, return type, 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 concise sentences, front-loaded with purpose, and every word adds value. No unnecessary 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?

Given no output schema and no annotations, the description should explain what the tool returns (e.g., a transaction id) and any prerequisites. It is too minimal for a moderately complex build 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 description coverage is 67% (two of three parameters have descriptions). The tool description adds no parameter-specific info; slippageBps lacks description in both places.

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 the resource 'single auto-compose transaction for a target portfolio', distinguishing it from sibling tools like 'plan' 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?

Implied usage via 'best-effort' and fee disclosure, but no explicit when-to-use or when-not-to-use compared to alternatives like solknife_portfolio_compose_plan.

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 states 'submit' which implies a write operation, but does not disclose potential errors, fees, or side effects. Parameter descriptions add some context (e.g., lastValidBlockHeight), but the description itself is minimally transparent.

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

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

The description is a single concise sentence (12 words) that conveys the core purpose without extraneous information. 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 no output schema, the description should hint at the return value (e.g., transaction signature). It does not. The tool is part of a clear workflow, but the description could be more complete for agents without prior 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 coverage is 100% with each parameter already described in the input schema. The description adds no additional parameter meaning, 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 action ('Submit') and the resource ('portfolio compose transaction') with a specific precondition ('after top-level program allowlist verification'). It distinguishes from sibling tools like _build and _plan by using 'execute', but does not explicitly differentiate.

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

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

The description mentions a prerequisite (allowlist verification) but provides no explicit guidance on when to use this tool versus its siblings (_build, _plan). An agent must infer the workflow order, which is a gap for effective selection.

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 mentions the bps sum constraint, but does not disclose side effects, auth needs, or what the plan output contains. Minimal behavioral 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?

Extremely concise: one sentence plus a critical constraint. 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?

No output schema provided. Description does not mention return format or what the plan contains. For a planning tool, expected output is significant missing 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 covers 2 of 3 parameters (owner, targets) with descriptions. Description adds the bps total constraint, which is already in schema but reinforces. SlippageBps parameter lacks schema description and no additional explanation 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?

Clearly states verb and resource: 'Plan a USD-valued portfolio rebalance'. Distinguishes from siblings like 'solknife_portfolio_compose_build' and 'solknife_portfolio_compose_execute' by being the planning 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 over siblings or alternatives. Implicitly it's for planning, but lacks when-not-to-use or prerequisites.

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 carry the full burden of behavioral disclosure. It only states it lists holdings, implying read-only, but lacks details on prerequisites, rate limits, or any side effects. Minimal 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 a single, front-loaded sentence with no extraneous words. Every word contributes to the purpose, making it 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 tool is simple, but with no output schema, the description could have specified the return format (e.g., token symbols, balances, prices). It provides the essential purpose but lacks completeness for an agent to fully understand the outcome.

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 single parameter 'owner' is fully described in the schema with a clear pattern and description. The tool description adds no additional meaning beyond the schema, so a baseline of 3 is appropriate given high schema coverage.

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

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

The description uses a specific verb ('List') and clearly identifies the resource ('a wallet's priced token holdings'). It is distinct from sibling tools like 'solknife_positions_list' and portfolio compose tools, providing unambiguous purpose.

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 provide any guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. No context for selection 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 provided, so the description must disclose behavioral traits. It does not mention that this is a read-only operation, any side effects, rate limits, or error handling. Only states the action.

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, conveying the essential information in a single phrase. No redundant words or sentences. Every word serves a purpose.

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

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

For a simple list tool with one parameter and no output schema, the description minimally covers what the tool does and output includes PnL. However, it lacks details on output format, error conditions, or behavior when wallet has no positions.

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% for the single parameter 'owner', which includes a pattern and description. The tool description adds no extra meaning beyond what the schema already provides. 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?

The description clearly states the verb 'List', the specific resource 'wallet's open Meteora DLMM positions', and includes 'with PnL' indicating output. It distinguishes from siblings by narrowing to 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 when to use (to list positions for a wallet) but does not provide explicit guidance on when not to use or mention alternatives. No exclusion criteria or context about prerequisites.

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 the full burden of behavioral disclosure. It mentions chunking and the maximum accounts limit, but fails to disclose whether this operation is safe (read-only or mutation), required permissions, or what happens if accounts are not empty. This is insufficient for a build step that likely creates transactions.

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 main purpose. No unnecessary words or information, making it easy to parse quickly.

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 moderate schema coverage, the description is somewhat adequate but lacks completeness. It does not explain what the tool returns (likely built transactions), nor does it mention prerequisites or the workflow (e.g., must be followed by execute). The mention of MAX_RECLAIM_ACCOUNTS without definition is a minor gap.

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

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

Schema coverage is 50%, and the description adds minimal value beyond the schema. It mentions 'Up to MAX_RECLAIM_ACCOUNTS addresses' which echoes the maxItems constraint, but does not explain the purpose of 'owner' beyond being an address. The description does not meaningfully clarify parameter semantics.

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 the resource 'chunked close-batch tx(s) for the wallet's empty token accounts'. It distinguishes from sibling tools solknife_reclaim_rent_execute and solknife_reclaim_rent_list by indicating this is the build step for transactions.

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

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

The description implies usage for building transactions before execution, but it does not explicitly state when to use this tool vs alternatives, nor does it provide any exclusion criteria or prerequisites.

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 of disclosure. It mentions re-verification against fresh state and per-tx outcomes, but does not detail potential side effects (e.g., account closure, SOL deduction), failure modes, or authorization requirements.

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

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

Two sentences with zero wasted words. The description is efficiently structured to convey core action and a key behavioral note (re-verification).

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 is provided, and the description only vaguely states 'Returns per-tx outcomes.' Missing workflow context: relationship to the build step, prerequisite calls, and expected response format. For a tool that submits critical transactions, this is insufficient.

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

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

The input schema has 100% coverage with descriptions for all three parameters. The tool description adds minimal extra information, e.g., reiterating that transactions should be in the order from /build, but mostly the schema already provides necessary semantics.

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 reclaim-rent close-batch tx(s) (signed)') and the specific operation of closing batch rent reclaim transactions. It distinguishes from sibling tools like 'solknife_reclaim_rent_build' and 'solknife_reclaim_rent_list' 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 this is the execution step after building transactions (mentions 'signed' and re-verification), but it does not explicitly state when to use this tool versus alternatives, nor does it provide guidance on prerequisites or 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?

With no annotations provided, the description must fully disclose behavior. It only states 'list', implying read-only, but does not mention side effects, authentication requirements, or what qualifies as 'reclaimable'. The brevity leaves important behavioral traits unspecified.

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, direct sentence with no extraneous words. It is appropriately front-loaded but could benefit from slightly more context without becoming verbose.

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

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

Given the tool is a simple list operation with one parameter and no output schema, the description is minimally adequate. However, it does not clarify the return format or what defines 'reclaimable', leaving some gaps given the lack of annotations.

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

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

Schema coverage is 100% for the single parameter 'owner', which is already described in the schema as a base58 Solana address. The description adds no additional semantic value beyond the schema, meeting the baseline for high coverage.

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

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

The description clearly states the verb 'List' and the specific resource: 'reclaimable empty token accounts' for a wallet. It effectively differentiates from sibling tools like solknife_reclaim_rent_build and solknife_reclaim_rent_execute by indicating it is the listing variant.

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., before building or executing reclaim actions). It lacks prerequisites or context for use, which is needed given the existence of related sibling tools.

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

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

The description mentions 'Permanent on-chain,' indicating that the revocation is irreversible, which is a key behavioral trait. However, there are no annotations, and the description does not disclose other traits such as that the transaction is unsigned and requires further steps, or any authorization requirements. The schema descriptions for revokeMint and revokeFreeze already state 'irreversible,' so the description adds only marginal value.

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

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

The description is exceptionally concise: one sentence with no wasted words. It is front-loaded with the core purpose and key behavioral note ('Permanent on-chain'). 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 tool's simplicity (4 boolean/string params, no output schema) and the context from sibling tools, the description is minimally adequate. However, it omits the workflow context (this builds an unsigned tx that must be executed) and does not explain how the output is used, leaving the agent to infer from sibling names. A more complete description would reference the execute tool.

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

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

Schema coverage is 100% and each parameter already has a descriptive schema description (e.g., 'Permanently revoke the mint authority...'). The tool description adds no additional meaning beyond what the schema provides. Baseline 3 is appropriate since the schema does the heavy lifting.

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

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

The description clearly states the tool builds an unsigned revoke-authority transaction for mint and/or freeze. It specifies the action and the resource (authority). However, it does not distinguish itself from the sibling tools solknife_revoke_authority_execute and solknife_revoke_authority_read, which could confuse an agent about when to use this specific 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 provides no guidance on when to use this tool versus alternatives like solknife_revoke_authority_execute or solknife_revoke_authority_read. The sibling tool names imply a workflow (build -> execute), but the description does not mention that this tool produces an unsigned transaction that must be submitted via the execute tool.

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

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

No annotations provided, so description carries full burden. It mentions submitting a signed transaction but does not disclose behavioral traits like idempotency, failure modes, or state changes. The cryptic 're-verifier pins' phrase 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?

Very concise, front-loaded with the main action. The second sentence is cryptic but not redundant. Slightly could be improved by clarifying the cryptic phrase.

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 information about return values or outcomes. No output schema, and description does not mention what the response contains (e.g., transaction signature, status). For an execute tool, this is a notable gap.

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

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

Schema coverage is 100% with detailed parameter descriptions. The main description adds little beyond what the schema provides, but the parameter descriptions themselves add valuable context (e.g., 'Do not submit it yourself; this endpoint submits it.')

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 submits a wallet-signed revoke-authority transaction, distinguishing it from build and read siblings. However, 'Structural re-verifier pins the revoke ix(s) + fee' is somewhat cryptic and could be clearer.

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 solknife_revoke_authority_build or solknife_revoke_authority_read. It assumes prior knowledge of the 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 provided, the description carries full burden. It correctly frames the tool as a safe read operation ('Read') without side effects. It does not disclose error behavior (e.g., invalid mint) but the core behavioral trait is clear. No contradiction with annotations.

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

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

The description is a single sentence that conveys the entire purpose without redundancy. It is front-loaded with the verb and resource, making it efficient and easy to parse. Every word 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?

The tool is simple (read two values) and the description adequately covers what it does. No output schema is provided, but the description implies the output (authorities and ownership status). Minor gaps exist (e.g., error handling, return format), but these are acceptable for a low-complexity 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?

Schema coverage is 100% with descriptions for both parameters. The description adds meaning by linking 'mint' to 'current mint + freeze authorities' and 'owner' to 'whether owner holds either', explaining how the parameters are used in context, which goes beyond the schema's generic 'Solana address' 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 uses the specific verb 'Read' and clearly identifies the resource: 'a mint's current mint + freeze authorities and whether `owner` holds either'. It distinguishes from sibling tools like solknife_revoke_authority_build and solknife_revoke_authority_execute, which perform revocation actions, making its purpose unique and well-defined.

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

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

The description does not explicitly state when to use this tool versus alternatives. However, the purpose implies it should be used before performing a revocation to inspect current authorities. No explicit exclusions or alternative recommendations are provided, so guidance is only implied.

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

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

No annotations present. The description does not disclose behavioral traits such as authorization needs, irreversible effects, or failure behavior beyond listing possible outcomes. Agent must infer safety profile.

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

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

Two concise sentences with no filler. Every word adds value, clearly stating action and return type.

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 simple schema (two parameters) and no output schema, the description provides basic return type info but lacks guidance on prerequisites (e.g., must have called /build). Adequate but not comprehensive.

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 tool description adds no parameter semantics beyond what the schema already provides, but the schema descriptions are detailed.

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 submits a wallet-signed swap transaction, with specific verb and resource. The name 'solknife_swap_execute' and sibling 'solknife_swap_order' provide differentiation within the suite.

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 like 'solknife_swap_order' or other execute tools. Usage is only implied by the name and 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. Description clarifies it returns an unsigned tx (non-executing), but does not discuss authentication, rate limits, or other 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?

Extremely concise: one sentence plus a note on amount. Front-loaded with key action.

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?

Briefly describes output (unsigned tx, lastValidBlockHeight, quote details) but could benefit from more structure. Adequate 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 80% and parameter descriptions are already detailed. The description adds no extra meaning 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 provides a Jupiter quote and unsigned swap transaction. Differentiates from solknife_swap_execute which likely executes the swap.

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?

Implicitly suggests use for obtaining a quote before execution, but no explicit guidance on when to use versus alternatives like swap_execute.

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

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

Description describes action as fetch (read-only) and lists return fields. No annotations provided, so burden is on description. It doesn't disclose auth needs, rate limits, or error behavior, but for a simple read, it's 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?

One concise sentence that directly states purpose and output. 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?

Description covers the essential: what it does and what it returns. Lacks mention of edge cases or response format, but given the tool's simplicity and lack of output schema, it is nearly 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 already describes the 'mint' parameter with pattern and length info (100% coverage). Description adds value by listing returned fields but doesn't explain the meaning of name/symbol/decimals/image beyond their names.

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 'Fetch token metadata' and lists specific fields (name, symbol, decimals, image) for a mint. Distinguishes from sibling tools like solknife_token_metadata_build which imply transaction building.

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 vs alternatives like solknife_token_metadata_read. Implied from context (this is a simple fetch, while siblings have 'build'/'execute' suffixes) 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?

The description discloses the irreversible nature of the 'lock' parameter, which is critical behavioral context. However, it does not mention that this is a build step (no transaction execution) or other side effects, despite no annotations being present.

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 plus a short note about lock. Every word is purposeful 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?

The description is minimal for a 6-parameter tool. It does not explain the Metaplex context, that the output is an unsigned transaction, or how it fits into a workflow (build -> execute). Lacks output expectations.

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

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

With 100% schema coverage, the description adds no additional meaning beyond what the input schema already provides for parameters. The lock behavior is already described 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 'Build' and the resource 'unsigned set/update Metaplex metadata tx', distinguishing it from sibling tools like 'solknife_token_metadata_execute' and 'solknife_token_metadata_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?

The description implies usage for building a transaction, but lacks explicit guidance on when to use this tool versus other build/execute tools in the family. No exclusions or alternatives 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 bears full responsibility for disclosing behavioral traits. It mentions 'structural re-verifier pins the metadata ix + fee,' which hints at internal validation but does not explain consequences (e.g., idempotency, error behavior, side effects). The warning about self-submission is helpful, but critical aspects like whether the tool retries, logs, or modifies state beyond submission 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 two sentences long, front-loading the primary action. Every word serves a purpose, though the second sentence is cryptic and could be simplified. No redundant phrasing or unnecessary 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?

The tool has no output schema, so the description should clarify what is returned (e.g., signature, success status). It does not. The cryptic 'structural re-verifier' phrase leaves ambiguity about processing guarantees. For a critical submit operation, the description is insufficiently complete—an agent cannot fully assess expected outcomes or error states.

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%: both parameters have detailed descriptions linking them to the /build call and providing constraints (max length, exclusivity). The tool description adds no additional parameter semantics beyond the schema. Baseline score of 3 is appropriate as schema already does the heavy lifting.

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

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

The description clearly states the core action: 'Submit a wallet-signed Metaplex metadata tx.' This distinguishes it from sibling tools like solknife_token_metadata_build (which builds the tx) and solknife_token_metadata_read (which reads metadata). The cryptic phrase 'Structural re-verifier pins the metadata ix + fee' slightly obscures the purely submit nature but does not undermine overall clarity.

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 indicates usage context by mentioning 'the matching /build call' in the parameter descriptions, and explicitly warns 'Do not submit it yourself; this endpoint submits it.' However, it lacks explicit guidance on when not to use this tool (e.g., if the tx is expired or if a different execution path is needed). No alternatives or exclusions are 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?

No annotations exist. The description suggests a read-only operation ('Read') but does not explicitly state that the tool has no side effects, requires no special permissions, or what happens if the mint is invalid. The additional check on owner update capability adds some value.

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 that is very concise and front-loaded with the key action and resource. 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?

No output schema is provided, and the description does not explain what the tool returns (e.g., metadata fields, boolean value). For a read tool, this is a notable gap. Otherwise, the description covers the input and purpose adequately.

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

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

Schema coverage is 100% with clear descriptions for both parameters (mint, owner). The description does not add extra meaning beyond the schema; it simply mentions the parameters by name. 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 the action ('Read'), the resource ('mint's current on-chain Metaplex metadata'), and the additional boolean check ('whether owner can update it'). This distinguishes it from sibling tools like solknife_token_metadata_build and solknife_token_metadata_execute by focusing on reading.

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 reading metadata, but lacks explicit guidance on when to use this tool versus alternatives such as solknife_token_meta. No context about prerequisites or when not to use it is provided.

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