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

Annotations already declare the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), so the bar is lower. The description adds useful context beyond them by stating the return value is a bech32 address and that out_file writes the address to disk, but it omits prerequisites (keys must pre-exist) and any network/era assumptions.

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?

Front-loaded purpose sentence followed by a compact args list and a one-line return note. It does re-list parameter descriptions that already exist in the schema, a mild redundancy, but nothing is bloated.

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

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

There is no output schema, and the description partially compensates by naming the returned bech32 address. However, for an address-building tool that writes a file it omits notable details such as network/era assumptions and the fact that keys must be generated beforehand.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds real meaning beyond the schema by noting the stake verification key is for base addresses, which explains why that optional parameter exists and when to supply 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?

States a specific verb (Build) and resource (Cardano address) plus the input class (verification keys). This distinguishes it from siblings like cardano_stake_address_build and cardano_address_info, though it does not name an alternative explicitly.

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

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

There is no when-to-use guidance or mention of alternatives such as cardano_stake_address_build. The only routing hint is the parenthetical '(for base addresses)' on the stake key, which implies but does not state the selection condition.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds no behavioral context beyond that: it does not say whether the address must be valid/testnet/mainnet, whether decoding can fail, or what 'credential information' concretely includes.

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?

Front-loaded with the core action and format is compact. The 'Args:' block duplicates the schema, which is minor waste, but overall it is efficient and readable.

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 read-only single-parameter inspector with no output schema, the description is minimally adequate: it names what is returned (address type, network, credentials) but doesn't specify the shape of that output or error conditions. With no output schema, some return-format detail would have been valuable.

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

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

Schema description coverage is 100%, and the description merely repeats the schema's parameter description ('Bech32-encoded Cardano address'). Baseline 3 applies because the schema already fully documents the single parameter.

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

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

States a specific verb (decode/display) and resource (Cardano address), and the return summary (address type, network, credentials) adds precision. It is not differentiated from the sibling tools that build or derive from addresses (cardano_address_build, cardano_address_key_hash), which could confuse an agent choosing among address-related tools.

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

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

No when-to-use or when-not-to-use guidance is given. With ~60 sibling tools and several address-related siblings (build, key_hash, key_gen), the description never explains when to call this inspector versus those generators.

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

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

Annotations already declare destructiveHint=false, idempotentHint=false and openWorldHint=false, so the safety profile is supplied structurally. The description adds that the operation writes keys to disk paths and returns only a confirmation, but it omits important behavior such as whether existing files at those paths are overwritten and whether the keys are written to a specific network/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?

Front-loads the purpose in the first sentence and uses a tight Args/Returns layout with no filler. Minor redundancy: the Args block restates exactly what the schema already documents.

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 two-parameter, no-output-schema tool the description is minimally sufficient — the args are covered and the return is characterized as a confirmation. It stops short of the details that matter for a key-generation write (file overwrite behavior, key format, downstream use of the generated keys).

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

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

Schema description coverage is 100%, and the description reproduces the two parameter descriptions verbatim ('Output path for the verification/signing key') without adding format, overwrite, or directory-existence semantics. Baseline 3 applies since the schema already carries the parameter meaning.

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

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

States a specific verb (generate) and resource (a payment address key pair of verification + signing keys), which is more precise than the title alone. However, it never distinguishes itself from the closely named siblings cardano_key_generate_payment and cardano_stake_address_key_gen, leaving an agent unsure which key-pair generator applies.

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?

There is no guidance on when to use this versus the other key-generation tools, nor any prerequisite or ordering advice (e.g. that the resulting signing key feeds cardano_transaction_sign). The only context is the implicit 'payment' qualifier.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds the return format ('key hash as hex string'), which is genuinely useful since there is no output schema, but says nothing about file-access requirements or failure modes.

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

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

The description is short and front-loads the purpose before the Args/Returns block. The Args section duplicates the schema field description, which is minor waste but does not obscure the definition.

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

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

For a single-parameter, read-only derivation tool with no output schema, stating the return type (hex string) covers the main gap. What is missing is only routing versus the near-identical sibling tool and any precondition on the key file.

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

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

Schema description coverage is 100% and the single parameter is fully documented in the schema; the description merely restates the same text verbatim. Baseline 3 is appropriate since it adds no 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?

The description states a specific verb and resource ('Get the hash of a payment verification key'), which is unambiguous on its own. However, it does not differentiate from the very similar sibling cardano_key_verification_hash, leaving the agent to guess which one applies to a payment verification key.

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?

There is no when-to-use guidance, no prerequisites (e.g., the key file must exist locally), and no mention of alternatives such as cardano_key_verification_hash. The agent is left to infer usage entirely from the name.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=false, telling the agent this is a non-destructive write. The description adds no behavioral context such as deposit handling, whether the action needs to be submitted separately, or what out_file produces. It merely restates parameters, so it fails to add value beyond annotations.

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

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

The description is a single sentence followed by a bulleted list of parameters that repeat the schema. The parameter list is redundant and adds no new information, making the description longer than necessary without improving clarity.

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

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

For a governance action creation tool with 10 parameters, no output schema, and no usage context, the description is incomplete. It omits how the returned transaction should be used (e.g., signing/submission), deposit return mechanics beyond the parameter name, and any relation to sibling query tools like cardano_query_constitution.

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

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

Schema description coverage is 100%, so the schema fully documents all ten parameters. The description's args list duplicates the schema descriptions verbatim (e.g., 'Deposit in lovelace', 'Anchor URL') without adding syntax, format, or constraint details. Baseline 3 is appropriate when the schema does all 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?

States a specific verb and resource ('Create a new constitution governance action'), distinguishing it from sibling tools like cardano_governance_action_create_info or _create_hard_fork. 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?

No guidance on when to use this tool versus alternatives, nor any prerequisites (e.g., needing a signed transaction, deposit requirements, or governance context). The description only lists parameters, leaving invocation conditions to inference.

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

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

Annotations already cover the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), so the bar is low, but the description adds nothing behavioral beyond a restated arg list. It does not mention that this likely builds an unsigned action requiring signing/submission, nor how the optional prev_governance_action_* fields chain actions, nor anything about the deposit lifecycle.

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

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

The leading sentence is tight and front-loaded, but the nine-line Args block is fully redundant with a schema that already has 100% coverage, adding length without adding information.

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

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

For a 9-parameter, 7-required governance-action constructor with no output schema, the description omits the transaction lifecycle (signing, submission), the role of the optional prev-action chaining inputs, and the deposit/return_addr flow that dominates the required parameters. An agent has the field list but not enough to use the tool correctly in context.

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

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

Schema description coverage is 100%, so the schema already documents every parameter, and the description merely repeats those identical one-line descriptions verbatim. No extra meaning (formats, constraints, the significance of the optional prev-action pair) is added. 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?

States a specific verb and resource: 'Create a hard fork initiation governance action.' An agent knows exactly what it produces. However, it offers no differentiation from the many sibling create-* governance actions (info, no_confidence, constitution, protocol_params_update, update_committee, treasury_withdrawal) beyond the tool name itself.

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

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

The description gives no guidance on when to use this action versus other governance action constructors, no prerequisites (e.g. a registered DRep/SPO/stake key, sufficient deposit), and no note about what happens after creation. Usage is left entirely to inference from the name.

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

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

Annotations already declare the mutation/idempotency profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false). The description adds genuinely useful context beyond that: the action has 'no on-chain effect' and the tool emits a local 'action file' via out_file rather than submitting to chain, which an agent would otherwise not know from the annotations alone.

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 opening sentence is front-loaded and efficient, but the five-line Args block duplicates the schema's own descriptions word-for-word at 100% coverage, adding length without new information. Structure is fine; the redundancy is the problem.

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 creation tool with no output schema, the description covers the purpose, all required inputs, and the fact that output lands in a file, which is enough for an agent to invoke it correctly. It stops short of covering prerequisites like deposit funding or anchor hosting requirements.

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 every parameter's meaning is already documented in the schema, and the Args block in the description restates those same definitions verbatim without adding formatting, constraints, or examples. Baseline 3 is appropriate when the schema does all 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?

States a specific verb and resource ('Create an informational governance action') and immediately qualifies the scope with 'no on-chain effect, used for signaling,' which cleanly distinguishes it from the sibling create_no_confidence, create_constitution, and create_hard_fork tools that all share the same 'create governance action' phrasing.

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 parenthetical 'no on-chain effect, used for signaling' implies the appropriate use case, but the description never explicitly says when to choose this over the other action-create siblings or what prerequisites (funds, signing keys, anchor hosting) are required. Usage is inferred rather than 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?

Annotations cover the behavioral profile (not read-only, idempotent, non-destructive), lowering the bar. The description adds no context beyond the parameter list about deposit handling, output file behavior, or the significance of the optional prev_governance_action fields.

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 purpose is front-loaded in a single sentence, then a clean Args list. No wasted words, though the parameter repetition is redundant with the schema.

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 governance action creation tool with no output schema, the description conveys what it does and the required inputs but omits critical context like deposit minimums, output file purpose, and how the optional previous action fields are used.

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 all seven parameters are documented in the schema. The description merely repeats the schema descriptions verbatim in an Args block, adding no extra semantic value.

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

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

States a specific verb ('Create') and resource ('motion of no confidence in the current constitutional committee'), clearly distinguishing it from sibling governance action creators like create_info, create_constitution, create_hard_fork, etc.

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

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

No guidance on when to use this over sibling governance action tools or prerequisites for submitting a no-confidence motion. The description only lists parameters.

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

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

Annotations already declare the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=false), so the bar for added context is that the description should explain the workflow, e.g. that this constructs an action requiring a deposit and later signing rather than submitting anything. The description adds none of this and merely lists parameters, so it does little beyond structured data.

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 purpose sentence is front-loaded and clear, but the full Args block is largely redundant given 100%-covered schema descriptions and occupies most of the text without adding information. Structure is fine; content efficiency is poor.

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

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

For a complex 9-parameter governance action with no output schema and no annotations explaining lifecycle, the description omits critical context: whether it submits or only builds, the role of the deposit/return address, and the relationship between the optional previous-action fields. It is not sufficient for an agent to invoke this 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%, so the schema already documents all nine parameters. The Args block repeats those descriptions nearly verbatim ('Anchor URL', 'Deposit in lovelace', 'Output path') without adding format, valid ranges, or JSON structure for protocol_parameters_update. Baseline 3 is appropriate since the schema does 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 first sentence states a specific verb and resource: 'Create a governance action to update protocol parameters.' An agent can tell it apart by subject from query tools, but it offers no differentiation from the many sibling create actions (create_info, create_constitution, create_hard_fork, create_update_committee, create_treasury_withdrawal). Good but no sibling routing.

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?

There is no guidance on when to use this action versus the other governance action creators, no prerequisites, and no mention of what must happen after creation (signing/submission). The description only states what it does, leaving selection entirely to inference.

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

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

Annotations declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the agent knows this is a non-destructive write that is safe to retry. The description adds little beyond that: it does not explain on-chain submission vs. file output, required signing keys, or what the output artifact is. With annotations carrying the safety profile, a 3 is appropriate.

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

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

The description is a single functional sentence followed by a neatly formatted argument list. It is front-loaded and free of filler, though the args list duplicates schema information without adding value.

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 seven-parameter, required-everything mutation tool with no output schema, the description is adequate but thin. It omits how the action is finalized (file, signing, submission), whether deposit amounts depend on protocol parameters, and what the out_file will contain, leaving meaningful gaps for an agent to close by trial.

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

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

Schema description coverage is 100%, so the schema already documents all seven parameters. The description repeats the same field labels with no added formatting, constraints, or examples. Baseline 3 applies when the schema does the heavy lifting.

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

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

The description states a clear verb and resource: 'Create a governance action to withdraw funds from the treasury.' This distinguishes it from other governance action creators (info, no_confidence, constitution, hard_fork, protocol_params_update, update_committee) by specifying the treasury withdrawal type. It loses the top score only because the name itself already conveys most of this and the description doesn't add scope details like limits or prerequisites.

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?

There is no guidance on when to use this tool versus alternatives in the rich governance action family, nor any mention of prerequisites. The description only states what the tool creates, leaving an agent to infer when treasury withdrawal is the right action.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds no behavioral context beyond what the annotations and schema provide—it does not explain permissions, on-chain effects, or that it writes to a file rather than submitting.

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 purpose is front-loaded, but the subsequent Args list is entirely redundant with the 100%-covered input schema. This bloats the description without adding value, making it less concise than it could be.

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 10-parameter governance action creation tool with no output schema, the description omits critical context: when to use this action versus other create actions, what the output file contains, and whether the action is submitted on-chain. It is insufficient for an agent to call it correctly without further inference.

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

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

Schema description coverage is 100%, and the description's Args list merely duplicates schema descriptions (e.g., 'Anchor URL', 'Deposit in lovelace'). No extra meaning, format hints, or constraints are added beyond the schema, so the baseline of 3 applies.

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

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

The description states a specific verb (Create) and resource (governance action to update the constitutional committee), clearly distinguishing it from other governance action creation siblings like create_info or create_constitution. However, it does not explicitly name alternative tools or conditions for preferring them, so a 4 rather than 5.

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 when-to-use or when-not-to-use guidance is provided. The description does not mention prerequisites (e.g., required committee keys or stake address), nor does it compare this action to other governance action creation tools. It merely lists arguments.

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

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

The annotations already declare the safety profile (readOnly, idempotent, non-destructive, closed-world), but the description adds meaningful behavioral details beyond them: the specific hash algorithm (blake2b-256), the return value format, and the mutual-exclusivity constraint on inputs. It does not cover error behavior or file-size limitations, but for a simple hashing utility that is a minor gap.

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

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

The description is front-loaded with the purpose, follows with concise argument descriptions, states the critical mutual-exclusivity constraint, and closes with the return value. Every sentence earns its place with no redundancy.

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

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

For a read-only utility with no output schema, the description supplies the algorithm, the return value, the input options, and the exclusivity rule. An agent has everything needed to call the tool correctly without additional inference.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds the important semantic rule that exactly one of the two path parameters must be supplied. That rule is not encoded in the input schema (both are optional with no oneOf), so the description meaningfully compensates.

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

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

The description states a specific verb ('Compute the hash'), a clear resource ('anchor data from a file'), and the exact algorithm ('blake2b-256'). It is unambiguous relative to all sibling tools, which cover querying, key generation, and certificate creation rather than anchor-data hashing.

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

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

The description provides a critical input constraint ('Exactly one of file_binary or file_text must be provided') but gives no guidance on when to use this tool versus any alternative. It does not mention prerequisites, context, or related workflows, leaving the agent to infer usage entirely from the name and parameters.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds nothing beyond that profile — no file-not-found behavior, no error handling, no note that the key is only read locally.

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 one-line purpose is front-loaded and the arg list is compact. The Args and Returns blocks largely duplicate the schema and title, which is minor redundancy but not bloat.

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

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

For a simple two-parameter read tool with complete annotations and no output schema, the definition covers the essential facts: input file, optional format, and that a DRep ID is returned. Only the prerequisite chain to key generation is unstated.

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

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

Schema description coverage is 100% and both parameters are documented in the schema, including the enum and default for output_format. The description merely restates the same parameter text (including the bech32/hex enum) without adding format examples or constraints, so baseline 3 applies.

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

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

States a specific verb (Get) and resource (DRep ID) plus the input source (verification key file), so the operation is unambiguous. It does not differentiate itself from nearby siblings such as cardano_governance_drep_key_gen or cardano_governance_drep_registration_certificate, which also operate on DRep keys.

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 never says when to use this tool versus alternatives, nor does it state the prerequisite that a DRep verification key file must already exist (e.g., produced by cardano_governance_drep_key_gen). Usage is only inferable from the parameter name.

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

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

The annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=false, covering the basic safety and side-effect profile. The description adds no further behavioral context such as file overwrite behavior, authentication needs, or error conditions, so it does little beyond the structured hints.

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

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

The description is short and front-loaded with the primary purpose. The Args list is somewhat redundant with the schema, but it does not bloat the definition. Overall structure is efficient for a simple two-parameter tool.

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

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

For a simple key-generation tool with complete schema coverage, no output schema, and annotations covering the safety profile, the description gives enough to invoke it correctly. The main omission, usage context relative to siblings, is a minor gap for an otherwise straightforward operation.

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

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

Schema description coverage is 100%, and the description repeats the same parameter descriptions verbatim. It adds no format, path conventions, or other semantic detail beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description states a specific verb and resource: generate a DRep key pair. It clearly distinguishes this tool from the many other key-generation siblings by naming DRep explicitly, so an agent can identify its function without opening the schema.

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 offers no when-to-use guidance, prerequisites, or alternatives. It does not explain when a DRep key pair is needed versus other key types or where in a governance workflow this tool fits. Usage must be inferred entirely from the tool name and title.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that: it does not say the certificate is only written to a file and still needs to be wrapped in a transaction, nor what the output artifact looks like.

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 purpose sentence is properly front-loaded, but the following args list duplicates all five parameters that the schema already documents completely, adding length without information. Half the text is redundant.

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 mutation tool with no output schema, the description omits what file is produced, how it integrates with transaction_build/transaction_sign, and whether an existing out_file is overwritten. The required-vs-optional anchor pairing is also unaddressed.

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

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

Schema description coverage is 100%, and the description simply restates each schema property description verbatim. With the schema fully documented, the baseline of 3 applies — no extra meaning such as deposit-source rules or anchor pairing constraints is added.

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

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

The description states a specific verb+resource ("Create a DRep registration certificate"), which is enough to distinguish it from the retirement/update certificate siblings that appear in the tool list. However, it never names or contrasts those siblings explicitly, so the differentiation is left implicit.

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?

There is no guidance on when to use this versus cardano_governance_drep_update_certificate or the retirement variant, nor any prerequisites (e.g., that a DRep key must first be generated, or where the deposit amount comes from). An agent must infer the whole 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?

The annotations already declare that the tool is not read-only, idempotent, and destructive, which is critical safety information. The description adds no further behavioral context, such as what happens to the DRep's registration, whether the deposit is automatically refunded, or any side effects. It merely restates the title and lists parameters already present in 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 short and front-loaded with the core action, but the 'Args' section duplicates the input schema's parameter descriptions without adding value, which is redundant. While not verbose, the second half does not earn its place given the 100% schema coverage.

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 destructive nature of the tool and the absence of an output schema, the description should explain the return value or the side effects of creating a retirement certificate (e.g., de-registration). Instead, it only provides the name and repeats schema parameters, leaving the agent without necessary context about what the certificate accomplishes or how to interpret results.

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

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

Schema description coverage is 100%, so the schema fully documents all three parameters. The description repeats the same parameter descriptions verbatim, adding no new meaning or formatting details beyond what the schema provides. This meets the baseline of 3 when the schema does the heavy lifting.

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

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

The description states a specific verb 'Create' and a specific resource 'DRep retirement certificate', which clearly distinguishes it from sibling tools like cardano_governance_drep_registration_certificate and cardano_stake_pool_retirement_certificate. An agent can immediately identify the tool's function without opening the schema.

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, such as when a DRep should be retired versus updated. There are no prerequisites or contextual conditions mentioned, leaving the agent to infer usage solely from the tool name.

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

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

Annotations already declare the full safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=false), so the description is not the sole source of behavioral truth. However, it adds nothing beyond them: it never states that the produced certificate must be embedded in a transaction to take effect, what permissions a DRep needs, or what happens to prior anchor data. It does not contradict the annotations.

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

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

The opening sentence is well front-loaded, but the 'Args:' block duplicates the schema descriptions word-for-word and therefore earns no place given 100% coverage. Half the description is redundant rather than concise.

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

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

For a certificate-generation tool with no output schema, the description adequately covers inputs and the file output via the schema, and annotations cover safety. The remaining gap is workflow context: it never explains that the certificate file is meant to be consumed by transaction_build/transaction_sign, which an agent in this large sibling set would benefit from knowing.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters, and the description merely repeats those exact strings verbatim. Per the baseline rule for high coverage, a 3 is the correct ceiling when the description adds no syntax, format, or constraint detail beyond the schema.

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

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

States a specific verb and resource ('Create a DRep update certificate') and adds the distinguishing purpose ('to update anchor metadata'), which separates it from the sibling registration and retirement certificate tools. It stops short of naming those siblings, so an agent must infer the boundary from the resource name alone.

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?

There is no when-to-use guidance, no prerequisites, and no alternatives mentioned. The argument list documents inputs but gives no condition under which this certificate should be created versus a registration, retirement, or vote-delegation certificate.

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

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), so the bar is lower. The description adds one genuine behavioral rule not in the schema: exactly one voter key file must be supplied. It does not clarify whether the vote is submitted on-chain or merely written to disk, which would be useful for a mutation tool.

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

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

The purpose is front-loaded and clear, but the entire 'Args:' block re-lists all nine parameters that are already 100% described in the schema, which is redundant padding. The only non-duplicative line is the voter-key exclusivity rule, so much of the text does not earn 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?

With no output schema, the description should ideally explain the return/result, but it does identify the out_file artifact. It covers the required inputs and the voter-key constraint, but omits whether the tool submits anything or the file's downstream role, leaving moderate gaps for a governance mutation 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 the per-parameter descriptions are already fully documented (baseline 3). The description adds genuine cross-parameter meaning beyond the schema by stating the mutual exclusivity of the DRep/SPO/CC key files, which the schema does not express.

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

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

States a specific verb and resource ('Create a governance vote file') and scopes it to 'a governance action'. This clearly distinguishes it from the sibling set of cardano_governance_action_create_* tools, which create actions rather than votes on them.

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

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

Usage is implied rather than stated: it presumes a governance action already exists (via governance_action_tx_id/index) and that a voter key is available. The closing rule 'Exactly one voter key file must be provided' gives partial operational guidance, but no explicit when-to-use versus alternatives and no mention of how or where the resulting vote is used.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the safety profile is known. The description adds only that files are written and a confirmation is returned, but says nothing about whether existing files at those paths are overwritten, what encoding/format the keys use, or whether permissions are required.

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

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

The one-sentence purpose is front-loaded and clear, but the Args section is pure duplication of a 100% covered schema and consumes roughly half the text without earning its place. The Returns line is short but useful.

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

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

For a simple two-parameter, no-output-schema tool this is minimally adequate, but the description never addresses the file-overwrite behavior implied by destructiveHint=false or any failure modes. Given how many key-gen siblings exist, a routing hint would have been cheap and valuable.

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

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

Schema description coverage is 100% and the schema already defines both parameters. The Args block repeats the schema text verbatim ('Output path for the signing key' / 'Output path for the verification key') adding no format, permissions, or overwrite semantics. Baseline 3 is appropriate when the schema carries the load.

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

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

States a specific verb (generate) and resource (payment signing/verification key pair), which cleanly separates it from siblings like cardano_key_generate_stake, cardano_stake_pool_key_gen, and cardano_node_key_gen. It does not explicitly name those siblings or the 'payment' vs 'stake' distinction as a routing rule, so it falls just short of a 5.

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?

There is no statement of when to use this tool rather than the many other key-generation siblings, no prerequisites, and no exclusions. The agent is left to infer usage purely from the name.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the agent knows this is a non-repeatable write. The description adds the file-output nature and the return value, but never addresses what happens if the target files already exist, whether directories must exist, or key file permissions — meaningful gaps for a write-to-disk 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?

Front-loaded with the core action in one sentence, then compact Args/Returns sections. Efficient and easy to scan, though the Args block is pure duplication of the schema.

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 does supply a minimal return statement, and annotations cover the safety profile. Still missing file-overwrite behavior and environment assumptions, which matter for a key-material write operation, so it is only minimally adequate.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema, and the description repeats them verbatim without adding format, permission, or overwrite semantics. Baseline 3 is appropriate when the schema does all 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?

States a specific verb and resource ('Generate a stake signing and verification key pair'), which is clear and unambiguous on its own. However, it offers no differentiation from the many adjacent key-generation siblings (cardano_key_generate_payment, cardano_stake_address_key_gen, cardano_stake_pool_key_gen), leaving the agent to infer selection from the name alone.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. Nothing tells the agent when a stake key is the right choice versus a payment or stake-address key, which is a real risk given the crowded sibling set.

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

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

Annotations already declare this as a read-only, idempotent, non-destructive operation, so the description does not need to restate safety. It adds the return format (hex string), which is useful, but does not describe error handling or file validity constraints.

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

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

The description is short and front-loaded, stating the purpose before listing arguments and return value. The Args/Returns structure is clear, though the Args section merely restates the schema.

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 one-parameter read-only tool, the description covers the key return value despite no output schema. It omits some operational details, but annotations and schema already provide what an agent needs to invoke it correctly.

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

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

The input schema has 100% description coverage and the description repeats the schema text for verification_key_file without adding further semantics. With the schema already documenting the sole parameter, 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 states a specific verb and resource: get the hash of a verification key. It is clear enough for an agent to distinguish from most siblings, but it does not explicitly differentiate itself from similar hash tools such as cardano_address_key_hash.

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 only the operation and its arguments, with no guidance on when to use this tool versus alternatives. It does not mention prerequisites such as needing a valid verification key file or when hashing is appropriate.

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

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

Annotations declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=false, so the safety/immutability profile is partly covered. The description adds nothing operational: it doesn't say that the op cert counter file is consumed/incremented, that out_file is written or overwritten, or that kes_period must match the current chain period. For a mutating, non-idempotent key-material tool this is thin.

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

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

The opening sentence is well front-loaded, but the trailing Args list duplicates the input schema one-for-one and occupies the majority of the text without adding information, which is padding rather than earned 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?

All five required parameters are named and there is no output schema, so return values need not be explained. Still missing for a five-required-param key-material tool: operational prerequisites, counter-file semantics, and any note on KES period validity — leaving the invocation context only 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 100%, so the schema already documents all five parameters; baseline is 3. The description's Args block merely restates those same parameter descriptions verbatim (e.g., 'Path to KES verification key file'), adding no format hints, mutual constraints, or file-existence expectations.

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 first line states a specific verb+resource ('Issue an operational certificate') plus a scoping phrase ('for a block-producing node'), which is clear on its own. However, the sibling tool cardano_stake_pool_issue_op_cert exists and the description makes no attempt to distinguish the node-level path from the stake-pool path, so an agent cannot disambiguate from the text alone.

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?

There is no when-to-use guidance, no prerequisite chain (node key gen, KES/VRF key gen, counter init must precede this), and no statement of when to prefer this over cardano_stake_pool_issue_op_cert. The agent is left to infer all workflow ordering.

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

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

Annotations already declare this is a non-read-only, non-idempotent write (readOnlyHint=false, idempotentHint=false), and the description's file-output paths reinforce that it writes to disk. However, it does not say whether existing files at those paths are overwritten or fail, which is the key behavioral risk for a non-idempotent key generator.

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?

Short and front-loaded with the action sentence first, which is the important part. The parameter listing is pure duplication of the schema, but it costs little 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?

For a three-required-parameter key generator with no output schema, the description covers what is generated and where it lands, and annotations cover the write profile. It is still missing overwrite behavior and any hint about the sequencing with cardano_node_issue_op_cert, which is the natural next step.

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

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

Schema description coverage is 100%, so the baseline is 3. The Args block merely repeats the schema's own descriptions verbatim and adds no format, path convention, or overwrite semantics beyond what the schema already states.

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

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

States a specific verb and resource: generates a node cold key pair plus an op cert counter. It is clear what is produced, but it does not distinguish itself from close siblings like cardano_node_key_gen_kes, cardano_node_key_gen_vrf, or cardano_node_new_counter, so an agent must infer which key-generation variant applies.

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?

There is no when-to-use guidance, no prerequisites, and no routing to alternatives, despite a crowded sibling set of key-gen tools. The agent gets no help deciding between cold, KES, VRF, and counter operations.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the agent knows this is a non-destructive, non-idempotent write operation. The description adds that it generates a key pair for a block-producing node, which is useful context, but it doesn't mention overwrite behavior, key storage security, or whether files are created if they don't exist. With annotations covering safety, a 3 is appropriate.

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

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

The description is front-loaded with the core purpose and then lists parameters, though the parameter list duplicates schema information without adding value. It is concise overall but the Args section is redundant given the schema.

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 two-parameter key generation tool with no output schema and full annotation coverage, the description is minimally adequate. It could mention what the generated keys are used for (e.g., operational certificate), whether existing files are overwritten, and how it relates to sibling key generation tools. The absence of these details leaves gaps for an agent to correctly infer usage.

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

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

Schema description coverage is 100%, so both parameters are already fully documented in the schema. The description repeats the same parameter descriptions in its Args section, adding no new semantics beyond path meaning. Baseline 3 is correct when the schema does the heavy lifting.

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

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

States a specific verb and resource (generate KES key pair) and specifies the domain (block-producing node). It is distinguishable from siblings like cardano_stake_pool_kes_key_gen, though the description doesn't explicitly explain the difference between node KES keys and stake pool KES keys, which would require domain knowledge.

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

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

The description implies usage by mentioning 'block-producing node', but it does not state when to use this tool versus alternatives like cardano_stake_pool_kes_key_gen or other key generation tools. The requirement for a block-producing node is implied but not framed as a condition.

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

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

Annotations declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the agent knows this is a non-idempotent write that creates new files. The description adds that these are output paths (i.e., files are written), which is useful, but doesn't state whether existing files are overwritten or what happens on failure.

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-sentence purpose plus a two-item Args list. Front-loaded and compact, though the Args section is redundant with the schema.

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?

Covers purpose and parameters, but for a file-writing key generation tool with no output schema, it omits return value, file overwrite behavior, and permissions or environment requirements. Annotations cover the safety profile, so the gap is moderate rather than severe.

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 both parameters are already fully documented in the schema. The description's Args section merely duplicates the schema descriptions verbatim, adding no new semantic value.

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

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

States a specific verb (Generate) and resource (VRF key pair) with the target scope (block-producing node). Distinguishable from siblings like cardano_stake_pool_vrf_key_gen and cardano_node_key_gen_kes by the node/VRF combination.

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 vs the many sibling key-gen tools (cardano_node_key_gen, cardano_node_key_gen_kes, cardano_stake_pool_vrf_key_gen). The 'block-producing node' hint implies context but no explicit when/when-not or alternatives are named.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety and repeatability profile is covered structurally. The description adds only the fact that a file is written to operational_certificate_counter_file; it says nothing about whether an existing counter file is overwritten, what permissions or node state are required, or the counter's role in op-cert issuance.

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 single purpose sentence is front-loaded and clear, but the Args list is a straight duplication of the input schema and therefore does not earn its place. The overall size is small, so the waste is moderate rather than severe.

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 three-parameter, all-required tool with no output schema, the description covers the inputs but is silent on return behavior and on the operational workflow linking this counter to op-cert issuance. It is minimally adequate rather than 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%, so the baseline is 3. The Args block in the description restates the three schema descriptions verbatim (counter value, key file path, output path) and adds no format, range, or domain detail beyond the schema.

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

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

The description names a specific verb and resource (create a new operational certificate counter) and specifies the output artifact, so an agent can identify the operation. It does not differentiate itself from nearby siblings such as cardano_node_issue_op_cert, which also revolves around operational certificates, leaving the boundary to inference.

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?

There is no when-to-use guidance, no prerequisites, and no mention of how this tool relates to the sibling cardano_node_issue_op_cert that consumes such a counter file. The description only states what happens, not when an agent should choose this over alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds nothing behavioral beyond that (no indication of what the state snapshot contains, freshness, or whether it can be empty), so it contributes little that the annotations don't.

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

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

A single short sentence with the resource front-loaded and no filler. Nothing needs to be trimmed.

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

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

There are no parameters and no output schema, and annotations cover the safety profile, but the description never says what 'committee state' comprises (members, term expiry, thresholds), which is exactly the gap the description should fill when no output schema exists. Adequate but thin for a state-query tool.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to clarify on the parameter side.

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

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

Specific verb (Query) plus a precise resource (current constitutional committee state). It implicitly separates itself from siblings like cardano_query_constitution and cardano_query_drep_state by naming the committee rather than the constitution or DREPs, but it does not explicitly contrast with them or with cardano_query_gov_state.

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

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

Usage is implied by the name and description — call it to inspect the constitutional committee — but there is no statement of when to prefer it over cardano_query_gov_state or cardano_query_constitution, and no prerequisites or exclusions are 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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is fully covered. The description adds 'current on-chain', implying fresh ledger state rather than cached/local data, but says nothing about what the constitution response contains (text, hash, anchor) or any failure modes.

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

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

A single front-loaded sentence with no wasted words, appropriate for a zero-parameter query. It is terse to the point of being a bit bare, but not padded.

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

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

For a no-param, read-only query with annotations covering the safety profile, this is nearly adequate, but with no output schema the description never indicates what the returned constitution looks like, leaving an agent guessing about the response shape.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4; the empty schema means there is nothing for the description to compensate for.

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

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

States a specific verb (Query) and resource (the current on-chain constitution), which is clearly distinguishable from siblings like cardano_query_gov_state or cardano_query_committee_state by resource name. It does not, however, explicitly contrast itself with those adjacent governance-query 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?

There is no guidance on when to use this versus the many other governance query tools (gov_state, committee_state, drep_state, ratify_state), nor any prerequisites or exclusions. Usage is only implied by the tool name.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so safety behavior is covered elsewhere. The description adds nothing beyond this and does not describe filtering behavior when drep_key_hash is omitted (e.g., full listing vs error), but it does not contradict the annotations.

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

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

The description is short, front-loaded with the purpose, and organized into Args and Returns sections. However, the Args section simply repeats the schema at 100% coverage, which is low-value padding rather than earning 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 one-parameter read tool with full annotations and complete schema coverage, the description covers purpose and the filter. Without an output schema, it only says "Returns: DRep state information" without characterizing the return shape, and it does not address what happens when no filter is supplied.

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 single parameter's description is identical to the description's arg note, so no additional meaning is added beyond the schema. With zero required parameters and one fully documented optional parameter, the baseline of 3 is appropriate.

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

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

The description states a specific verb+resource ("Query DRep state") and expands the acronym, making the purpose clear. It does not differentiate from similarly-named siblings like cardano_query_gov_state or cardano_query_committee_state, leaving some ambiguity in a crowded governance-family namespace.

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?

There is no guidance on when to use this tool versus alternatives such as cardano_query_gov_state or cardano_query_committee_state. The only usage signal is the word "Optionally," which implies the filter is not required but offers no conditions for when to apply it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety and reproducibility profile is fully covered by structured data. The description adds only the content scope (proposals, DReps, committee), with no notes on cost, latency, or freshness of the state returned.

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

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

A single short sentence with no filler and the resource front-loaded. It is efficient, though the content list could have been spent instead on differentiating 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?

There is no output schema, so the description carries the burden of describing what comes back. Listing three broad categories is a start, but an agent gets no sense of the shape, granularity, or size of the returned governance snapshot.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter explanation is needed or missing.

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?

It states a specific verb and resource ('Query the current governance state') and lists the content categories (proposals, DReps, committee info). However, it does not distinguish itself from the many siblings that query the same domain more narrowly (cardano_query_drep_state, cardano_query_committee_state, cardano_query_ratify_state, cardano_query_constitution), leaving overlap ambiguous.

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 aggregate query versus the narrower per-entity siblings. An agent cannot tell from the description whether this is a cheap snapshot to prefer, or a heavier call to avoid when only DRep or committee data is needed.

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

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

Annotations already declare the full safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's main added value is the return format ('List of slots where the pool is elected to produce blocks'), which is useful since no output schema exists. It does not mention that the VRF signing key file is sensitive local material or note any constraints on the computation.

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?

Front-loads the one-sentence purpose before the conventional Args/Returns docstring sections. Well organized and appropriately sized, though the Args block duplicates schema content rather than adding to it.

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 'Returns' line is necessary and it is supplied clearly. For a deterministic computation tool with fully documented params and annotation-covered safety, the description is complete; only edge cases (e.g., invalid key path or malformed nonce) go unmentioned.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters with types, defaults, and descriptions; baseline is 3. The description's Args block largely restates the schema, adding only a scale example for relative_stake ('e.g., 0.001'), which is a small value-add but not enough to exceed the baseline.

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

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

States a specific verb and resource: 'Calculate the leadership schedule for a stake pool operator.' This is unambiguous about what the tool produces. It doesn't explicitly differentiate from siblings, though no sibling tool computes a block production schedule, so the gap is minor.

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 phrase 'for a stake pool operator' implies the audience and use case (an SPO planning block production) but never states when to call this versus other query tools or what prerequisites exist. Usage is only inferable from context, not spelled out.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds only the optional filter and a broad return category ('Pool parameter details'), without permissions, rate limits, or output structure.

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

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

The description is short and front-loaded, giving the core action first and then structured Args/Returns sections. Every sentence earns its place with no redundancy or filler.

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

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

For a simple, single-parameter read-only query with full annotation coverage and a fully described schema, the description provides enough to call the tool correctly. The return value is only vaguely described as 'Pool parameter details,' and sibling differentiation is absent, but no critical invocation detail is missing.

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

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

Schema description coverage is 100% and the single optional parameter is fully documented in the schema. The description repeats the same 'Bech32 or hex stake pool ID' meaning without adding syntax, validation, or behavioral nuance beyond the schema, so the baseline of 3 applies.

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

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

The description states a specific verb and resource: 'Query stake pool parameters.' This is clear and lets an agent know what it retrieves. However, it does not differentiate from sibling query tools such as cardano_query_stake_pools or cardano_query_stake_snapshot, so it falls short of a 5.

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 notes that the stake pool ID filter is optional, which implies usage context but does not say when to use this tool versus the many sibling query tools. There are no explicit when/when-not conditions or named alternatives, leaving routing to inference.

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

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

Annotations declare readOnlyHint=true, but the description states it can 'write to a file', which modifies the filesystem environment. This directly contradicts the read-only annotation. Without this contradiction, the annotations would have covered safety; as written, the mismatch is serious.

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 plus a structured Args/Returns block. The core purpose is front-loaded and every element 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?

No output schema exists, and the description explicitly states the return format ('Protocol parameters as JSON'). Together with the parameter description and annotations, an agent has enough to invoke correctly.

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

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

Schema coverage is 100%, and the description's Args section repeats the schema's description verbatim. It adds no syntax, format, or example beyond what the schema already provides, so baseline 3 applies.

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

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

States a specific verb and resource: 'Query current protocol parameters.' This clearly identifies the tool's function. It does not explicitly differentiate from siblings like cardano_query_pool_params, but the resource name is distinct enough for an agent to distinguish.

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?

Only guidance is the optional file output for fee calculation. There is no explanation of when to use this query versus other query tools (e.g., pool params, treasury) or prerequisites. Usage is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds only the word "current" (implying a point-in-time snapshot) and nothing about what the result contains, freshness, or whether governance actions mid-ratification are included — minimal value beyond the annotations.

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

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

A single well-formed sentence with no filler, and the resource is front-loaded. It is efficient, though its brevity shades into under-specification rather than disciplined concision.

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

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

For a zero-parameter, no-output-schema tool, the description is the only place an agent can learn what "ratification state" comprises (active governance actions, their vote tallies, thresholds, expiry). None of that is provided, and the boundary against cardano_query_gov_state is never drawn, leaving the definition thin for an otherwise simple tool.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The empty schema is self-explanatory and the description does not need to compensate.

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

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

The description contains a verb ("Query") and a resource ("governance ratification state"), so the purpose is decipherable, but it is essentially the title restated with the word "current" inserted. It offers no differentiation from close siblings such as cardano_query_gov_state, cardano_query_drep_state, or cardano_query_committee_state, which an agent must choose among.

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?

There is no guidance on when to use this tool versus the other governance query tools in the sibling list. No prerequisites, no conditions, no alternatives named; the agent is left to infer that "ratification state" is distinct from "gov state" and "drep state" on its own.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered without the description's help. The description adds only the shape of the result (delegation and reward balance); it says nothing about failure modes for invalid/non-registered stake addresses or any rate/network constraints implied by openWorldHint=false.

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 text is short and front-loaded, with purpose first and Args/Returns clearly separated. The Args entry duplicates the schema verbatim, which is mildly wasteful but does not bloat the definition.

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 usefully sketches the return surface (delegation status, reward balance) for a single required parameter, and annotations cover the safety profile. It is adequate for this simple read tool, though the return sketch remains terse.

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

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

Schema description coverage is 100%, and the description merely restates the schema's own text ('Bech32 stake address to query'). Baseline 3 applies since the schema carries the semantics and the description adds no format examples, network scoping, or validation detail.

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

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

The description states a specific verb and resource ('Query information about a stake address') and enumerates the payload ('including delegation and rewards'). It is clear, but it never distinguishes itself from nearby siblings such as cardano_address_info, cardano_query_stake_pools, or cardano_query_stake_distribution.

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?

There is no guidance on when to choose this tool over alternatives — for example, when to use it versus cardano_address_info for a full address or versus cardano_query_stake_pools for pool-level data. The agent must infer usage purely from the name.

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

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

Annotations already declare it as read-only, idempotent, non-destructive, and non-open-world, so the safety profile is covered. The description adds nothing beyond that basic read operation, failing to disclose return format, scope limitations, or any behavioral nuances.

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 clear sentence with no filler. However, it is somewhat under-specified for the number of sibling tools.

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

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

For a no-parameter read tool with full annotation coverage, the missing piece is distinguishing it from siblings and explaining what 'stake distribution' entails (e.g., per-pool stake fractions). Without that, an agent may hesitate between this and similar stake tools.

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

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

The tool has zero parameters, so the baseline is 4. The description correctly implies no inputs are required, and there are no parameter semantics to clarify.

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

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

States a specific verb (Query) and resource (current stake distribution across all stake pools). However, it does not differentiate from sibling tools like cardano_query_stake_snapshot or cardano_query_stake_pools, leaving ambiguity about which one returns distribution data.

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

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

No indication of when to use this tool versus cardano_query_stake_pools, cardano_query_stake_snapshot, or cardano_query_pool_params. The description provides no usage context or exclusions.

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

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

Annotations already cover the safety profile: readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false. The description adds minimal behavioral context beyond confirming it queries data. It does not mention return format, potential size of the result set, or any performance considerations, but with annotations covering the basics, a 3 is appropriate.

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

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

One short sentence that is front-loaded and wastes no words. It communicates the core purpose efficiently.

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

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

For a parameterless read-only query tool with full annotation coverage, the description provides the essential information. An output schema is absent, so the description could have mentioned what is returned (a list of IDs), but the core action is clear. The lack of sibling differentiation is a minor gap.

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

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

The tool takes no parameters, so there are no parameter semantics to describe. Baseline for zero parameters is 4. The description correctly implies no inputs are needed.

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

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

States a clear verb (query) and resource (all registered stake pool IDs). The scope 'all registered' is specified. However, it does not distinguish itself from related sibling tools like cardano_query_stake_distribution or cardano_query_pool_params, which also deal with stake pool data.

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

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

The description implies usage by saying 'all registered stake pool IDs', but it provides no explicit guidance on when to use this tool versus alternatives. With many sibling query tools, some differentiation would be helpful, yet the lack of parameters makes the intended use somewhat self-evident.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and a closed-world scope, so the safety profile is fully covered elsewhere. The description's only behavioral contribution is clarifying that a 'snapshot' means the mark/set/go set, which is modest added context but says nothing about what is returned per snapshot or whether all three are returned together.

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?

Front-loaded with the core action and scope in the first clause, and the args section is short. 'Returns: Stake snapshot data.' is near-tautological filler that could have been omitted or made specific, keeping it short of a 5.

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 one optional parameter and no output schema, the description is adequate but thin: it never explains the distinction between mark/set/go snapshots or what fields a caller should expect, information an agent would need to use the result correctly. The safety profile is covered by annotations, so nothing critical is missing.

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, and the description's 'Bech32 or hex stake pool ID' is verbatim the schema text, so it adds no meaning beyond structured data. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb+resource ('Query stake snapshots') and adds domain-specific scope by naming the three snapshot types (mark, set, go), which an agent can use to understand what data is being read. It does not, however, differentiate this tool from adjacent query siblings like cardano_query_stake_distribution or cardano_query_stake_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?

'Optionally filter by stake pool ID' is parameter guidance, not usage guidance. The description never states when to choose this tool over cardano_query_stake_distribution or cardano_query_stake_address_info, nor when a snapshot is the appropriate data source, leaving selection entirely to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety and idempotency profile is fully covered by structured data. The description adds only that it reports sync progress, which is useful but not deep behavioral context. It does not describe freshness or caching behavior, so a 3 is appropriate.

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

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

A single, front-loaded sentence that names the resource and its returned fields with zero waste.

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

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

For a zero-parameter, annotated, read-only query with no output schema, the description covers what is needed to call it correctly. Ideally it would note the return shape slightly more (since there is no output schema) or mention frequent polling, but it is essentially complete.

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

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

The tool takes zero parameters, so there is nothing to document; the baseline for a no-param tool is 4. The description correctly adds no parameter noise.

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

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

States a specific verb ('Query') and resource ('current tip of the blockchain') and enumerates the returned fields (slot, block number, epoch, sync progress). This clearly distinguishes it from sibling query tools like cardano_query_utxo or cardano_query_leadership_schedule.

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

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

Usage is implied by 'current tip' — the agent can infer this is for chain-head status. However, no explicit when-to-use / when-not-to-use guidance or alternatives are named, so it is only the minimum viable level.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description only adds that the returned content covers treasury plus reserves balances, which is modest added value beyond the structured metadata.

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

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

One front-loaded sentence with no filler or redundancy; every word earns its place.

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

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

For a no-argument, read-only query with no output schema and full annotation coverage, the description conveys enough to invoke correctly. It could briefly note the return shape (single vs per-epoch balances), which is the only small 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 tool takes zero parameters, so there is nothing for the description to disambiguate; the schema is fully covered. Baseline of 4 applies for a parameterless tool.

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

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

Specific verb 'query' plus the exact resources ('treasury and reserves balances'), which clearly separates it from the stake-pool, governance, and transaction query siblings. It does not explicitly name which sibling to prefer, but the resource 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?

No statement of when to use this versus alternatives such as cardano_query_gov_state or cardano_query_utxo, and no prerequisites or conditions. The agent must infer usage purely from the tool name.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds only the subcommand semantics and a thin return note, so it clears the lowered bar but adds little beyond structured fields.

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?

Front-loads the purpose, then lists subcommands and args compactly. The args block duplicates the schema somewhat, but nothing is wasted or buried.

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 should carry the return-value burden, but 'Returns: Mempool information based on subcommand' is too vague to tell an agent what info, next-tx, and has-tx actually yield. Adequate for invocation, incomplete for interpreting results.

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

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

Schema description coverage is 100% and both parameters are documented there, including the enum and the has-tx requirement. The description's arg list largely restates the schema rather than adding format or constraint detail, so the baseline 3 applies.

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

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

States a specific verb and resource (query the transaction mempool) and enumerates the three subcommands with one-line purposes, so an agent can tell it apart from the other cardano_query_* siblings that target different ledgers.

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 subcommand list effectively tells the caller which mode to pick: info for stats, next-tx for the next transaction, has-tx for membership checks. It doesn't state when to prefer this over siblings like cardano_transaction_view, but the internal routing is clear.

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

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

Annotations already declare the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false). The description adds two useful behavioral details beyond annotations: the invocation constraint that at least one filter is required, and the return format ('UTxO set as formatted text'). It does not disclose performance or rate-limit behavior, but given the rich annotations this is sufficient.

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

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

The description is front-loaded with the core action, then uses a clean Args list and a Returns line. It is efficient, though it repeats parameter text already present in the schema, which slightly inflates 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?

For a simple two-parameter read tool with full schema coverage and rich annotations, the description supplies the essential missing pieces: the at-least-one constraint and the return format. It does not need to explain an output schema because none exists, and nothing critical for correct invocation appears absent.

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

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

Schema description coverage is 100% and the description repeats the per-parameter descriptions verbatim, which is redundant. However, it adds a genuine semantic constraint not present in the schema: 'At least one of address or tx_ins must be provided.' That mutual-requirement information materially helps correct invocation.

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

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

The description states a specific verb ('Query') and resource ('UTxO entries'), and clarifies the two filter axes (address and tx_ins). It is clearly more specific than a generic query tool, but it does not explicitly differentiate itself from sibling query tools like cardano_query_tip or cardano_query_tx_mempool.

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

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

The description gives a filtering condition ('Filter by address and/or specific transaction inputs') and a hard requirement ('At least one of address or tx_ins must be provided'). However, it offers no guidance on when to choose this tool over related siblings such as cardano_address_info or cardano_query_tx_mempool, leaving the agent to infer its niche.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true, so the safety profile is largely covered. The description adds the return format (bech32 stake address) but leaves a real ambiguity: it never says what happens when the optional out_file is omitted (returned inline vs written to stdout).

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?

Front-loaded one-line purpose followed by compact Args and Returns sections with no filler. The Args block duplicates schema text, a small redundancy, but overall it is tight and readable.

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 2-parameter tool with no output schema, the description covers the purpose, inputs, and return type adequately. The unresolved out_file-omitted behavior and lack of any workflow context leave a meaningful gap for an agent assembling a Cardano key/address pipeline.

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 both parameters are already documented in the schema, and the Args block merely restates those descriptions verbatim. 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?

States a specific verb ('Build') and resource ('stake address') plus the input it derives from ('a stake verification key'), which distinguishes it from cardano_address_build and cardano_stake_address_key_gen by resource. However it never explicitly names those siblings to reinforce the boundary.

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 versus the many sibling address/key builders (cardano_address_build, cardano_stake_address_key_gen, cardano_key_generate_stake), and no prerequisites or ordering information. The agent must infer 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?

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds only that it produces an output certificate file, without disclosing overwrite behavior, required permissions, or other operational traits beyond the annotations.

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

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

The description is front-loaded with the main purpose and then lists parameters in a compact block. The parameter list is somewhat redundant with the schema, but the overall size is appropriate and no sentence is wasted.

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

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

With a simple three-parameter write tool, no output schema, and annotations covering safety hints, the description provides enough to call the tool correctly. It names all required parameters and the output file, though it omits details like file overwrite behavior and certificate 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 100%, so the schema already documents all three parameters. The description merely repeats the schema descriptions verbatim, adding no extra semantic detail such as file format expectations or key file validity.

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

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

The description states a specific verb ('create') and resource ('stake delegation certificate') and clarifies the purpose ('to delegate to a stake pool'). It implicitly distinguishes from the sibling vote-delegation certificate, but does not explicitly name any alternative tool.

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

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

No when-to-use, when-not-to-use, or alternative guidance is provided. The description only explains what the tool creates and lists parameters, leaving the agent to infer appropriate usage.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds no behavioral context beyond that - it never mentions the deposit refund, that an existing registration is required, or any side effects of deregistering.

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 opening sentence is front-loaded and clear, but the following Args list duplicates the input schema's descriptions word-for-word, adding length without new information.

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

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

For a destructive certificate-creation tool with no output schema, the definition is minimally viable: it names inputs and implies no return value. It omits meaningful context such as the deposit-refund implication and the requirement that a registration exists, which an agent would 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 description coverage is 100%, so the schema already documents all three parameters; the Args block simply restates those same descriptions verbatim. Baseline 3 applies since the description adds no syntax, format, or defaulting details beyond the schema.

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

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

The description gives a precise verb+resource ('Create a stake address deregistration certificate'), which cleanly separates it from the sibling cardano_stake_address_registration_certificate and cardano_stake_address_delegation_certificate 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?

There is no guidance on when to use this versus the registration or delegation certificate siblings, nor any prerequisites (e.g., that the stake key must be currently registered). It only states what the tool does, not when or why.

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

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

Annotations already declare the operation is not read-only, not idempotent, and not destructive, so the safety profile is covered. The description adds nothing beyond that — it does not say whether existing files at the output paths are overwritten, whether the directory must exist, or what is returned on success, which matters for a write-to-disk 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?

The description is short and front-loads the purpose, which is good, but the entire Args section duplicates the input schema word-for-word and therefore earns no place. Structure is clean but the second half is redundant.

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

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

For a simple two-parameter key generator with a 100%-documented schema and no output schema, the description is minimally adequate. It omits file-system side effects (overwrite, directory creation) and does not clarify its relationship to the many sibling key-gen tools, so an agent has enough to call it but not enough to choose it confidently.

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

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

Schema description coverage is 100%, so the schema already fully documents both parameters. The Args block in the description merely restates those same schema descriptions verbatim, adding no new semantic detail (file format, path constraints, overwrite behavior). Baseline 3 applies.

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

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

The description states a specific verb and resource ("Generate a stake address key pair"), so the agent knows exactly what artifact is produced. However, it does nothing to distinguish this from the near-identical sibling cardano_key_generate_stake, nor from cardano_address_key_gen, leaving the selection ambiguous among several key-generation 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?

There is no statement of when to use this tool versus alternatives, and no prerequisites such as a running node or existing key material. With multiple overlapping key-generation siblings, the description offers no routing guidance at all.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no further behavioral context such as file overwrite behavior, required permissions, or effects on existing state; it merely restates the creation purpose and repeats schema parameter descriptions.

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

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

The description is front-loaded with a clear purpose sentence, but the subsequent Args list duplicates information already present in the input schema for all three parameters, making it less concise than it could be.

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

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

The description covers the basic action and all parameters, and annotations supply the safety profile. However, for a certificate creation tool with no output schema, it lacks guidance on when to use it, what the resulting certificate contains, or how it fits into a broader workflow, leaving some contextual gaps.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description repeats these same parameter descriptions in an Args list without adding syntax, format, or usage details 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 states a specific verb and resource: 'Create a stake address registration certificate.' This clearly identifies the tool's function and inherently distinguishes it from siblings like deregistration or delegation certificates, though it does not explicitly name those alternatives.

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

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

The description provides no guidance on when to use this tool versus the deregistration or delegation certificate tools, nor does it mention prerequisites such as needing a stake verification key file. It simply lists arguments.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety/mutation profile is covered by structured data. The description adds only that a certificate file is written to out_file, with no mention of permissions, overwrite behavior, or what the cert is meant to feed into. Adequate but not rich beyond the annotations.

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

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

The lead sentence is well front-loaded and the closing constraint sentence earns its place. But the bulleted Args list just restates the schema's property descriptions verbatim at 100% coverage, adding bulk without information — a waste that keeps this from scoring higher.

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

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

For a certificate-generation tool with no output schema, the definition explains inputs and the exclusivity rule but says nothing about the produced certificate's format, where it plugs in (transaction assembly/signing), or that it is an intermediate artifact rather than a submitted operation. An agent gets enough to call it, but not enough to place it in a 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 description coverage is already 100%, so parameter meanings are fully documented structurally. The description does add value beyond the schema by stating the mutual-exclusivity constraint among the three delegation targets, which the schema's additionalProperties/required fields do not express. It stops short of clarifying interaction between always_abstain and always_no_confidence flags.

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

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

States a specific verb and resource ('Create a vote delegation certificate') and clarifies the three delegation targets (DRep, always-abstain, always-no-confidence). It distinguishes itself from the many query/certificate siblings by the 'vote delegation' qualifier, though it never explicitly contrasts itself with the closely named cardano_stake_address_delegation_certificate (stake vs vote).

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 supplies the key selection rule among the three target modes ('Exactly one of drep_verification_key_file, always_abstain, or always_no_confidence must be provided'), which is genuine usage guidance. However it gives no when-to-use vs. alternatives context, no prerequisites, and no indication of when a vote delegation cert is appropriate versus the sibling certificate tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds useful output context by stating the return value is a bech32 pool ID string, which is valuable because there is no output schema.

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

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

The description is short and front-loads the action. The Args section duplicates the schema, which is mildly redundant, but overall it is efficient and well-structured.

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

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

For a simple one-parameter read-only utility, the description covers the operation, the input, and the return type. It does not describe error behavior or file-format assumptions, but those are minor gaps given the rich annotations and complete schema.

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

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

Schema coverage is 100%, and the sole parameter is already fully documented in the input schema. The description repeats the same file-path meaning without adding format, validation, or sourcing details beyond the schema.

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

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

States a specific verb and resource: get the pool ID from a cold verification key. This is clear and actionable, but it does not distinguish itself from the many sibling stake-pool and key 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 explains what the tool does but gives no explicit guidance on when to use it versus alternatives. It does not mention prerequisites, when-not conditions, or sibling tools such as cardano_stake_pool_key_gen.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered externally. Beyond that, the description only restates the parameters; it never mentions that a file is written to out_file, whether an existing file is overwritten, or that the counter file is consumed/incremented. For a key-material/certificate operation that is a meaningful gap.

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 leading sentence is front-loaded and clear, but the five-line Args list duplicates a schema that is already 100% documented, so a sizable portion of the text does not earn its place. Structure is conventional rather than wasteful, but not lean.

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 5-required-parameter cryptographic issuance tool with no output schema, the description omits the operational context an agent needs: prerequisite artifacts, how kes_period is obtained, and what the tool returns or writes. It is barely more than a restatement of the 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 description coverage is 100% and the Args block merely repeats the schema descriptions verbatim, adding no new semantics. Per the baseline rule for high coverage with no incremental parameter info, a 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?

States a specific verb and resource: 'Issue an operational certificate for a stake pool'. An agent knows exactly what is created. It does not, however, distinguish itself from the very similar sibling cardano_node_issue_op_cert, so the pool-vs-node distinction is left implicit.

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?

There is no when-to-use guidance, no mention of prerequisites (KES keys and counter file must already exist, KES period must correspond to the current epoch), and no routing to the sibling node-level op cert tool. The agent must infer the entire workflow 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?

Annotations already disclose readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false, so the safety profile is partly covered. The description adds that the operation writes key material to two file paths, but it omits the genuinely useful behaviors: whether existing files are overwritten, whether parent directories are created, and what (if anything) is printed on success. For a key-material writer that is a meaningful gap.

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?

Front-loaded single-sentence purpose followed by a compact Args list. Every line is short and readable, though the Args block duplicates the schema descriptions rather than adding anything new.

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?

A simple two-parameter tool with no output schema, so the description need not explain return values. However, it leaves unanswered the practical details an agent needs for a file-writing crypto operation: overwrite behavior, directory assumptions, and failure modes.

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

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

Schema description coverage is 100% and both parameters are fully documented in the schema; the description merely repeats the same text verbatim. Baseline 3 is appropriate – it adds no syntax, format, or constraint information 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?

States a specific verb (Generate) and resource (KES key pair) scoped to 'for a stake pool', which cleanly separates it from cardano_stake_pool_key_gen, cardano_stake_pool_vrf_key_gen and cardano_node_key_gen_kes. It does not explicitly name those siblings, but the resource is distinct enough to select correctly.

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?

There is no statement of when to use this tool versus the many sibling key-generation tools, nor any prerequisite (e.g. whether a pool key must already exist, whether files may already exist). Usage is only implied by the tool name.

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

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

Annotations already declare readOnly=false, destructive=false, idempotent=false, and openWorld=false, so the safety profile is partly covered. The description adds nothing beyond that: it does not say whether existing files at the output paths are overwritten, whether parent directories must exist, or any security consideration for key material.

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 first sentence is well front-loaded and specific. However, the Args block is pure duplication of the input schema's property descriptions, adding no information and inflating length without earning 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 three-parameter key-generation tool with no output schema, the definition covers inputs but omits behavioral essentials such as file-write semantics and where this step fits in the stake pool key sequence. Annotations carry the safety signal, so the definition is minimally viable but not 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%, so the schema already documents all three output-path parameters, and the description merely repeats those descriptions verbatim in an Args block. Baseline 3 applies since no additional meaning (e.g., file format or overwrite behavior) is added.

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

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

The description states a specific verb (generate) and resource (stake pool cold key pair plus operational certificate counter), and the 'cold' qualifier distinguishes it from sibling key-gen tools like cardano_stake_pool_vrf_key_gen and cardano_stake_pool_kes_key_gen. It is clear, though it does not explicitly name those 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?

There is no guidance on when to use this tool versus alternatives, no mention of prerequisites (e.g., part of a larger stake pool setup sequence alongside VRF/KES keys and op cert issuance), and no exclusions. The agent must infer usage from the name alone.

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

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

Annotations declare idempotentHint=true and destructiveHint=false, which tells the agent this is a safe, repeatable write operation. The description adds no behavioral context beyond that – it does not state side effects, overwrite semantics, or whether it requires network access (openWorldHint=false is already in annotations). With annotations covering the safety profile, the description's lack of extra context is acceptable but minimal.

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

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

The first sentence is concise and front-loaded, but the subsequent parameter list is redundant given the schema and makes the description unnecessarily long. The structure is clear but wastes space on information already available in structured form.

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

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

For a complex 13-parameter tool with no output schema, the description is adequate but not rich. It could explain the purpose of the certificate, its role in pool registration, or how it is used in subsequent transactions. Annotations cover idempotency and safety, but the agent still lacks context on when and why to use 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 description coverage is 100%, so the schema already documents all 13 parameters. The description lists them again but adds no new semantic meaning beyond what is in the schema (e.g., it does not clarify the distinction between single_host_pool_relay and multi_host_pool_relay or the implications of setting pledge/cost/margin). 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 states a specific verb (Create) and resource (stake pool registration certificate) and notes it uses 'full pool parameters', which distinguishes it from the sibling retirement certificate. However, it does not explicitly differentiate from related tools like cardano_stake_pool_retirement_certificate or cardano_stake_pool_issue_op_cert beyond the obvious name difference.

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 when-to-use guidance is provided. It does not state prerequisites (e.g., needing a cold key and VRF key), nor does it mention alternatives like the retirement certificate. The agent must infer from the tool name and parameters.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that: it doesn't explain that retirement is effectively irreversible once the epoch passes, that the certificate must still be signed and submitted, or what happens to funds/rewards after the retirement epoch. It simply restates the tool purpose and parameter list.

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 opening sentence is front-loaded and efficient, but the entire Args block duplicates the input schema word-for-word and earns no additional agent value. The description is short, yet a third of it is redundant.

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 destructive, irreversible certificate-generation tool with no output schema and no annotations explaining side effects, the description leaves key context unstated: whether it only writes a file or submits anything, what the output contains, and the constraints on the retirement epoch and cold key. It is not sufficient for an agent to invoke this correctly without trial and error.

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

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

Schema description coverage is 100%, and the description's Args block reproduces the schema's parameter descriptions verbatim, adding no new semantic detail (e.g., whether epoch is absolute or relative, expected key file format, or overwrite behavior for out_file). Baseline 3 applies when the schema carries the parameter documentation.

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

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

The description states a specific verb and resource ("Create a stake pool retirement certificate"), which is unambiguous and clearly distinct from sibling certificate tools like cardano_stake_pool_registration_certificate. It does not, however, name any sibling or scope boundary explicitly, so the differentiation is left to the tool name rather than stated.

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?

There is no guidance on when to use this versus the registration certificate or other certificate generators, and no prerequisites are stated (e.g., that the pool must already be registered, that the cold signing key must correspond to a registered pool, or whether the epoch has validity constraints). The agent must infer all usage 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?

Annotations already state readOnlyHint=false, idempotentHint=false, destructiveHint=false and closed-world scope, so safety is partly covered. The description adds no behavioral context of its own — notably it does not say whether existing files at the given paths are overwritten, which is the main risk for a non-idempotent key-generation tool that writes to disk.

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 purpose sentence is front-loaded and tight. The Args list duplicates the schema's parameter descriptions, which is mild redundancy, but the overall definition is short and readable.

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 two-file-output generation tool with no output schema, the description covers the action and file destinations but omits key context: how it relates to the node VRF key generator, whether target files must not already exist, and what the caller gets back. Adequate but with clear gaps.

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

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

Schema description coverage is 100%, so both parameters are already fully documented in the schema. The description merely restates the same two parameter descriptions verbatim ('Output path for the ... key'), adding no format, path, or overwrite semantics beyond the structured data. Baseline 3 applies.

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

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

States a specific verb and resource ('Generate a VRF key pair') and scopes it to a stake pool, so the core action is unambiguous. However, it does not differentiate itself from the closely related sibling cardano_node_key_gen_vrf, which also generates a VRF key pair, leaving the agent to guess which context applies.

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?

There is no guidance on when to use this stake-pool VRF generator versus cardano_node_key_gen_vrf or the other stake-pool key generators (cardano_stake_pool_key_gen, cardano_stake_pool_kes_key_gen). The description gives no preconditions or workflow context such as when in pool setup this should be run.

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