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

With no annotations, the description fully carries the burden. It explicitly states this tool does not perform the requested action, is a stub, and returns a coming_soon response. It also provides safety advice (no secrets). This is high transparency, though the exact response structure is not detailed.

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

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

The description is two sentences, efficiently front-loading the key message ('Coming soon') and then disclosing behavioral traits and safety. No unnecessary words.

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

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

Given the tool is a stub with 4 optional parameters and no output schema, the description is complete. It explains what the tool does (records demand), what it doesn't do (perform action), and includes a critical safety warning. No gaps for its limited functionality.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds no additional parameter-level details beyond what the schema provides. It offers a general warning but no parameter-specific semantics.

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

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

Description clearly states it is a 'Coming soon' stub that records demand and returns a coming_soon response. It differentiates itself from siblings by explicitly saying it does not perform the action yet, making its purpose unmistakable.

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

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

Description gives context that this is a PMF stub and warns not to send secrets, but does not explicitly state when to use it versus other tools like hostodo_list_payment_methods. Usage is implied but not formally guided.

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

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

With no annotations provided, the description fully carries the burden of transparency. It honestly discloses that the tool is a stub, does not perform the action, and returns a structured response. It also warns against sending secrets, enhancing behavioral clarity.

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

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

The description is very concise with two sentences, no redundant information, and front-loads the key point that it is a stub. Every word earns its place.

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

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

Given that this is a stub tool, the description is complete: it explains the stub nature, what it returns, and that no action is performed. No output schema is needed as the return is a simple structured response.

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% as all four parameters have descriptions in the input schema. The tool description adds a warning about not sending secrets but does not elaborate on parameter meanings or usage. Baseline 3 is appropriate as the schema already documents parameters.

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

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

The description clearly states the tool is a stub that records demand and returns a coming_soon response, not actually adding an SSH key. It also mentions 'access: Add an SSH key', which conveys the intended purpose, and distinguishes from sibling tools like hostodo_list_ssh_keys or hostodo_remove_ssh_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?

The description implies the tool should not be used for actually adding an SSH key because it is a stub, but does not explicitly state when to use it or provide alternatives. The instruction 'Do not send secrets' is a useful guideline.

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

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

With no annotations, the description carries full burden. It transparently discloses the stub nature, that it does not perform the action, returns a structured coming_soon response, and warns not to send secrets. This is sufficient for a non-functional stub.

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

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

The description is extremely concise, three sentences front-loaded with the key information. Every sentence adds value: purpose, stub nature, security warning. No waste.

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

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

Given it is a stub with complex sibling tools and no output schema, the description adequately explains what the tool does (record demand) and its limitations. The lack of return value details is acceptable for a stub.

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 all four optional parameters have descriptions. The tool description adds no additional meaning beyond what the schema already provides, so baseline 3 is appropriate.

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

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

The description clearly states the intended purpose (apply account credit to invoice) but immediately clarifies it is a stub that records demand and does not perform the action. This is specific and distinguishes it from functional 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?

No explicit guidance on when to use this tool versus alternatives like hostodo_pay_invoice. The description implies it should not be used for actual credit application but offers no alternatives or when-not-to-use 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?

Reveals that it returns final status and is safe to call on finished commands. With no annotations provided, this provides useful behavioral context, though could mention if cancellation is synchronous or any side effects.

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

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

Two sentences, front-loaded with action, no superfluous words. Efficient and clear.

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 cancel command with no output schema, the description covers the key behavior (return final status, no effect if finished). Could be more explicit about the response format, but acceptable.

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

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

Schema coverage is 100% with clear descriptions for both parameters. The description adds no additional semantics beyond the schema, so a 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?

Clearly states the action (cancel) and resource (async command), and mentions return value and idempotency. Distinguishes from siblings like hostodo_start_vm_command and hostodo_exec_vm_command.

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

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

Implicitly indicates use case (canceling a running command) and notes when it has no effect. Lacks explicit when-not-to-use or alternatives, but the context is clear enough.

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

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

No annotations are provided, so the description fully conveys that this is a stub that records demand and returns a coming_soon response, with a clear warning not to send secrets. This is transparent about its non-functional nature.

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

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

Three sentences efficiently convey purpose, stub behavior, and security warning. No wasted words, front-loaded with key 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 stub tool, the description is complete: it explains the action, stub behavior, output nature, and security. It lacks details on the exact structure of the response, but this is acceptable for a placeholder.

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% parameter coverage and all parameters are optional with generic descriptions. The description does not add any additional meaning beyond the schema, so baseline 3 applies.

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

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

The description clearly states 'Run a VM health check' and identifies it as a stub for monitoring. It differentiates from siblings by being a placeholder, though the functional intent is clear.

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

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

The description mentions it does not perform the action and warns against sending secrets, but provides no guidance on when to use this tool versus alternatives or when to expect it to be functional.

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

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

With no annotations provided, the description carries the full burden. It transparently states that the tool is a stub, does not perform the action, returns a coming_soon response, and warns not to send secrets. This sufficiently discloses the behavioral traits for a placeholder 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 concise with three sentences. The first sentence introduces the tool, the second explains its stub nature, and the third warns about secrets. It is front-loaded and avoids unnecessary details.

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

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

For a stub tool with no output schema, the description adequately covers its purpose, behavior, and a security note. It provides enough context for an AI agent to understand its limited functionality, though it does not detail the response format.

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

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

Schema description coverage is 100%, with each parameter having a clear description in the input schema. The tool description adds no additional meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states the intended future action ('Close a support ticket') and explicitly clarifies that it is a stub that records demand and does not perform the action. This provides a clear purpose despite the placeholder nature.

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

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

No guidance is provided on when to use this tool versus alternatives like hostodo_create_ticket or hostodo_reply_ticket. The description does not mention prerequisites, scenarios, 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?

Discloses return value (presigned PUT URL), validity period (15 min), and required authorization. Does not mention potential errors or rate limits, but is generally transparent 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?

Three sentences: purpose, return info, and workflow + requirements. No superfluous text, front-loaded with core action.

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

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

Covers purpose, output format, constraints, and next steps. Missing details like URL format or upload method, but sufficient for correct invocation.

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

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

Input schema covers all parameters with detailed descriptions (100% coverage). Description adds no extra parameter information beyond the schema, justifying baseline score.

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

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

Clearly states it creates an upload slot for file transfer to a VPS, using specific verb 'create upload slot' and resource. Distinguishes from siblings like hostodo_install_artifact by describing a preparatory step.

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

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

Explicitly describes the workflow: create slot, upload via returned URL, then install. Also specifies required scopes and prerequisites, leaving no ambiguity about when to use.

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

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

Since no annotations are provided, the description fully carries the behavioral burden. It transparently states that the tool does not perform the requested action and returns a structured coming_soon response. The warning about secrets adds transparency.

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

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

The description is extremely concise, consisting of two short sentences that convey all necessary information without waste. Every word earns its place.

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

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

Given the tool is a PMF stub, the description covers the essential facts: it creates a stub, records demand, does not act, and warns about secrets. The coming soon nature is clear. It could mention the response structure formally, but the description is adequate for a placeholder.

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

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

All 4 parameters have descriptions in the schema (coverage 100%), but these descriptions are generic and do not add meaningful detail beyond the parameter names. The tool description itself offers no parameter-specific guidance, so the baseline score of 3 is appropriate.

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

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

The name and description clearly indicate this tool is for creating a DNS record, and it distinguishes itself by stating it is a 'PMF stub' that does not perform the action. The purpose is clear, though the stub nature adds a caveat.

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

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

The description provides no guidance on when to use this tool versus alternatives like hostodo_create_dns_record (a possible future real tool). It only warns not to send secrets and notes it returns a coming_soon response, but lacks explicit usage context or conditions.

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

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

Despite no annotations, the description fully discloses the tool's stub behavior: it returns a structured 'coming_soon' response and does not execute the snapshot creation. It also warns about not sending secrets, which is critical for safe usage.

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

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

The description is three short sentences that efficiently convey purpose, behavior, and a critical warning. No unnecessary words, and the most important information (stub nature) is front-loaded.

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

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

Given that this is a stub tool with no output schema, the description sufficiently explains the behavior (records demand, returns coming_soon response). It covers the tool's limitations and safety concerns, making it complete for its intended use.

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

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

The input schema already describes all 4 parameters (100% coverage), but the description adds important semantic context: parameters are optional, metadata is for PMF discovery, and secrets should not be included. This aids proper usage 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 starts with 'Create a VM snapshot' which clearly states the intended action, but immediately clarifies that this is a PMF stub that only records demand and does not perform the action. This provides an accurate understanding of the tool's actual purpose, though the initial phrase could be misleading if not read in full.

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

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

The description explicitly states when to use this tool (to record demand for a future snapshot feature) and provides a strong negative guidance: 'Do not send secrets.' It also explains that it does not perform the requested action, helping the agent avoid incorrect expectations.

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

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

No annotations provided, but the description transparently discloses the stub behavior: records demand, returns a structured coming_soon response, and does not execute the action. Warning about secrets adds safety context.

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

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

Two sentences, no waste. Front-loaded with purpose, then explains stub nature. Every sentence earns its place.

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

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

For a stub tool with no output schema, the description sufficiently covers purpose, behavior, and constraints. Missing details about response structure are acceptable given its placeholder nature.

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

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

Schema coverage is 100%, so baseline 3. Description adds no extra meaning to parameters beyond what the schema already provides.

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

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

Description clearly states 'Create a support ticket' upfront, but immediately clarifies it is a stub that does not perform the action. The purpose is specific and honest, though it is not actionable.

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

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

Description explicitly says the stub does not perform the requested action and warns not to send secrets, but does not provide alternatives like using other ticket-related tools for actual ticket 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?

The description honestly discloses that the tool is a stub that returns a coming_soon response and does not perform the action. It also warns about secrets. However, without annotations or an output schema, the response structure remains unspecified, which is acceptable for a stub.

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

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

The description is extremely concise, using two sentences to convey the tool's purpose, current status, and a security warning. No redundant information is present.

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

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

Given that this is a placeholder stub, the description adequately explains the behavioral limitation and security concern. However, it could be more complete by briefly describing what the coming_soon response contains or suggesting alternative tools for actual deletion once implemented.

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

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

Schema coverage is 100%, with each parameter having a basic description. The description does not add extra context or examples for parameters, but the schema already provides adequate information. The 'Do not send secrets' note is a usage guideline, not parameter-specific.

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

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

The description clearly states the action (Delete a DNS record) and resource (DNS record). It immediately identifies the tool as a stub, which is distinct from sibling tools like hostodo_create_dns_record and hostodo_update_dns_record. However, the 'Coming soon' prefix may cause temporary confusion about intended function.

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 includes a warning about not sending secrets but provides no guidance on when to use this tool versus alternatives, such as whether to attempt deletion or wait for implementation. No explicit when-to-use or when-not-to-use criteria 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?

No annotations provided, so description must carry full burden. It mentions 'bounded' (timeout) and 'root' context, but does not disclose whether the command is destructive, whether the VM must be running, or what the output looks like. Lacks important behavioral traits.

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

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

Single sentence containing essential elements. No redundant wording. Every word adds 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?

Given no annotations, no output schema, and three parameters, the description is too minimal. It fails to address return values, error handling, or execution context, leaving the agent with inadequate information for reliable use.

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

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

Schema description coverage is 0% and description does not explain any parameters (vm_id, command, timeout_seconds). The agent must infer meaning from the name alone, which is insufficient for 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?

Description clearly states the action (execute), the resource (bounded root command in an owned VPS), and the mechanism (QEMU guest agent). It distinguishes itself from sibling command tools like hostodo_start_vm_command by specifying 'bounded' and 'root'.

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

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

No guidance on when to use this tool versus alternatives like hostodo_start_vm_command or hostodo_cancel_vm_command. The description does not provide context for when-not-to-use or prerequisite 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?

Fully transparent: clearly states it is a PMF stub that records demand and returns a coming_soon response, does not perform the requested action, and warns not to send secrets. No annotations exist to contradict.

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

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

Three sentences covering purpose, behavior, and security warning. No unnecessary words, front-loaded with key 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 stub tool with no output schema, description adequately explains the response type (structured coming_soon) and billing context. Lacks roadmap or alternative tool recommendations.

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

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

Schema coverage is 100% with parameter descriptions. The description adds no extra meaning beyond the schema for individual parameters, so baseline 3 is appropriate.

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

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

Description states intended purpose (get account balance and credits) and explicitly clarifies it is a 'coming soon' stub that does not perform the action yet. Distinct from sibling tools which are functional.

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 stub versus other billing tools. Only provides a security warning ('Do not send secrets') but no context on alternatives or when it is appropriate to invoke.

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?

Without annotations, the description fully discloses the tool is a stub that does not perform the action and returns a coming_soon response. The warning about secrets adds transparency. However, it could detail the response structure or idempotency.

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

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

The description is two sentences, front-loading the core purpose and immediately clarifying it is a stub. No unnecessary words. Highly efficient.

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

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

For a stub tool with no output schema, the description adequately explains its placeholder status. However, it does not describe the coming_soon response format or any constraints, leaving some ambiguity for agents.

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

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

Schema coverage is 100%, so the schema already documents parameters. The description adds no additional parameter-specific meaning beyond what is in the schema. Baseline score of 3 is appropriate.

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

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

The description clearly states the tool gets VM bandwidth usage and explicitly marks it as a 'coming soon' stub. This distinguishes it from functional tools and avoids misleading agents, though it could be more precise about the stub's output.

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 lacks explicit guidance on when to use this tool versus alternatives. It warns against sending secrets but does not specify that the tool is non-functional or suggest alternative tools like hostodo_get_vm_metrics.

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

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

Despite no annotations, the description clearly states the tool is a stub ('does not perform the requested action yet') and returns a 'coming_soon response'. It also warns not to send secrets. This is transparent about its behavioral limitations.

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 (three sentences) but the first sentence is misleading. Leading with 'Coming soon (deploy): Inspect...' suggests functionality that doesn't exist. A more front-loaded disclosure that it's a stub would improve structure.

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

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

Given the tool is a stub with no output schema, the description adequately conveys that it does nothing and warns about secrets. It is clear enough for an AI agent to recognize it should not be used for real deployments.

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

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

All four parameters have descriptions in the schema (100% coverage), so the description does not need to add more. It adds no additional semantic information, but is adequate given the high schema coverage.

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

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

The description starts with 'Inspect deployment status and logs', suggesting it performs an action, but then immediately contradicts that by stating it's a stub that returns a 'coming_soon response' and does not perform the requested action. This confusion lowers clarity.

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

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

No guidance is provided on when to use this tool versus alternatives. The only advisory is 'Do not send secrets', which is a security warning, not usage context. With many sibling tools, explicit when-to-use instructions are missing.

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

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

With no annotations, the description carries the full burden. It honestly discloses the stub status, that it records demand, returns a structured coming_soon response, and warns against sending secrets. This is transparent and leaves no ambiguity about behavior.

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

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

The description is two sentences, covering purpose, stub status, and a security warning. It is front-loaded and contains no filler, earning full marks for conciseness.

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

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

For a stub tool, the description is sufficiently complete: it explains what the tool intends to do, confirms it's not functional, and warns about secrets. It does not detail the return structure (no output schema), but the mention of a structured coming_soon response suffices given the context.

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

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

Schema coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning beyond what the schema provides, meeting the baseline expectation.

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

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

The description clearly states the tool is for getting service incidents and explicitly identifies it as a stub. This distinguishes it from the many other hostodo tools, none of which are incident-related.

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 warns that the tool does not perform the requested action yet and advises not to send secrets. However, it lacks explicit guidance on when to use it versus alternatives; it implies it should only be used for demand recording but does not state that directly.

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

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

With no annotations, the description carries the full burden. It transparently discloses that the tool is a stub, records demand, and returns a structured response without performing the action. It warns not to send secrets. This is adequate for a stub, though the response structure is not detailed.

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

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

The description is two sentences, clearly stating its purpose and a security warning. No wasted words.

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

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

Given the stub nature and lack of output schema, the description adequately covers the tool's behavior. It explains the stub, records demand, warns about secrets. It could specify the coming_soon response format, but overall it's complete for its limited functionality.

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 parameters are described in the schema. The description does not add additional meaning beyond the schema. Baseline is 3. The description could have clarified that parameters are not actually processed, but it's not required.

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

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

The description clearly states the tool is a stub that records demand and returns a coming_soon response, not actually getting invoice details. It distinguishes itself from sibling tools like hostodo_get_invoice (if it existed) and hostodo_list_invoices by explicitly stating it does not perform the action.

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

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

It provides clear context: 'coming soon' and 'does not perform the requested action yet.' It warns 'Do not send secrets,' which is appropriate. While it doesn't explicitly list alternatives, the stub nature is evident, so the guidance is sufficient.

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

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

No annotations are provided, but the description fully discloses that the tool is a stub, returns a structured coming_soon response, and does nothing else. It also warns about secrets.

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

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

The description is two sentences long, front-loaded with the purpose, and every word adds value. No waste.

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

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

Given that the tool is a stub with no output schema, the description adequately explains its behavior. It could specify the exact structure of the coming_soon response, but it's sufficient for a stub.

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 each parameter. The description adds no additional parameter semantics 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 'Read service logs from a VM' which is a specific verb+resource. It also clarifies it's a stub, distinguishing it from sibling tools that perform actual actions.

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

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

The description explicitly says this is a PMF stub and does not perform the action, and warns not to send secrets. It implies that for actual log reading, another tool should be used, but does not name an alternative.

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

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

With no annotations, the description fully discloses that the tool is non-functional, returns a 'coming_soon' response, and warns against sending secrets. This is comprehensive for behavioral expectations.

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

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

Two concise sentences front-load the key message (stub and non-functional), with no extraneous information. Every sentence earns its place.

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

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

Given the tool is a stub with no output schema, the description covers all necessary context: its purpose, behavior, and security warning. Complete for this minimal functionality.

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

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

Schema description coverage is 100%, so parameters are already described. The description adds no additional parameter semantics, meeting the baseline for high coverage.

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

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

The description clearly states the tool is a stub for getting support ticket details, explicitly noting it does not perform the action yet. This distinguishes it from sibling tools like hostodo_create_ticket or hostodo_close_ticket.

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 informs the agent that the tool is a stub and records demand only, implying not to use it for actual retrieval. However, it lacks explicit 'when to use' vs alternatives, though the stub nature 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?

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only says 'Get detailed metadata' without specifying what metadata includes, potential error states, authentication requirements, or side effects. For a read operation this is minimal but insufficient compared to a 5-point standard.

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

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

Two concise sentences with no wasted words. The first sentence states the core purpose, and the second adds crucial parameter flexibility. Information is front-loaded and easy to parse.

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

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

The description adequately covers the single parameter and core action, but for a tool with no output schema, it lacks any description of what 'detailed metadata' contains (e.g., IP, status, specs). The return value is left entirely implied, which may leave an agent unsure of the output structure.

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

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

The single parameter vm_id is described as accepting 'id, hostname, or unique prefix', which adds significant meaning beyond the schema's bare string type. With 0% schema description coverage, the description compensates well by clarifying acceptable input formats.

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

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

The description clearly states the action ('Get detailed metadata'), the resource ('one owned Hostodo VPS'), and scope (single VM). It distinguishes from sibling tools like hostodo_list_vms (list all VMs) and hostodo_check_vm_health (health check) by focusing on detailed metadata. The mention of flexible references (id, hostname, unique prefix) adds precision.

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 guidance on what to pass as vm_id (id, hostname, unique prefix) but does not explicitly state when to use this tool over alternatives (e.g., list_vms for a list, check_vm_health for health status). No when-not-to-use or exclusion criteria 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?

No annotations are provided, so the description carries the full burden. It explains the output fields and mentions bounded tails (hinting at the tail param limits), but does not disclose possible states (e.g., if command is still running) or any additional behavioral traits like rate limits.

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

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

Two sentences, front-loaded with purpose, and every sentence adds value. No redundant or unnecessary text.

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

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

Despite no output schema, the description explains the return values (status, exit_code, tails, offsets) and references incremental reads. It could mention default tail byte values (schema shows 8192) for completeness, but overall it is adequately comprehensive for a tool with 4 params and async behavior.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds no extra semantics beyond what the schema already provides for the parameters, merely hinting at bounded tails via the word 'bounded'.

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

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

The description clearly states the tool retrieves status and bounded output tails for an async command, naming the specific return fields (status, exit_code, stdout/stderr tails, next offsets). It distinguishes from siblings like hostodo_start_vm_command and hostodo_read_vm_command_logs.

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

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

The description implies usage after starting an async command and references hostodo_read_vm_command_logs for incremental reads, providing helpful context. However, it does not explicitly state when not to use this tool or list alternatives for other scenarios.

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

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

The description fully discloses behavioral traits: it is a stub, does not execute the requested action, returns a 'coming_soon' response, and records demand. It also warns against sending secrets. With no annotations provided, the description carries the full burden and excels in transparency.

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

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

The description is extremely concise, using two sentences to convey purpose, current behavior, and a warning. Every sentence is essential, and the most critical information is front-loaded.

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

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

Given that the tool has no output schema and no annotations, the description adequately covers the tool's current state, its non-functional nature, and security considerations. It is comprehensive for a stub tool with 4 optional parameters.

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

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

Schema coverage is 100% with parameter descriptions already present, so baseline is 3. The description adds no further meaning to parameters beyond the schema, though it includes a general security warning ('Do not send secrets').

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

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

The description clearly states the tool's purpose: 'Get VM resource metrics.' It further clarifies that it is currently a stub that records demand and does not perform the action, distinguishing it from functional sibling tools like hostodo_get_bandwidth_usage and hostodo_check_vm_health.

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

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

The description implies usage for recording demand rather than actual metrics retrieval, but it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions. The 'Coming soon' label hints at future functionality but lacks concrete guidance.

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

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

No annotations provided, so description carries full burden. It discloses the sequence of operations (download, SHA-256 verify, ownership/permissions, atomic move) and the authentication/scope requirement. Does not cover error handling or denied paths in detail, but is fairly transparent.

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

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

Description is concise, front-loaded with the purpose, and uses only three sentences with no redundant information.

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

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

Given the absence of output schema and moderate complexity, the description covers the tool's purpose, steps, and prerequisites. Lacks details on return values or error behavior, but is reasonably complete for an installation 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 baseline is 3. The description adds value by explaining the overall process but adds little parameter-specific detail beyond the schema. The mention of parent directory creation is helpful.

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

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

The description clearly states the verb 'install' and the resource 'artifact to VM filesystem', distinguishing it from sibling tools like hostodo_create_artifact_upload which uploads an artifact.

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 the steps (download, verify, set permissions, atomic move) and the required scope/exec permission, giving clear context for when to use this tool. It lacks explicit when-not-to-use or alternatives, but the context is sufficient.

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

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

The description explicitly discloses that the tool does not perform the requested action, returns a coming_soon response, and warns against sending secrets. This is transparent for a stub, especially without 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 brief and front-loaded with the key point 'Coming soon'. It conveys essential information in three short sentences with no wasted words.

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

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

For a stub without an output schema, the description covers the basic behavior (stub, no action, no secrets). However, it does not clarify what 'records demand' entails or what the response format looks like, leaving some gaps for an agent.

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

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

All 4 parameters have descriptions in the schema (100% coverage), so the baseline is 3. The description does not add any additional semantic meaning beyond what the schema provides.

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

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

The description clearly states that the tool is a stub for recording demand and does not perform the actual listing of DNS zones. This distinguishes it from a functional list tool, though the name may initially imply otherwise.

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

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

No guidance is provided on when to use this tool versus alternatives like hostodo_create_dns_record or other DNS tools. The description does not indicate that this tool should be avoided for actual listing or that it serves only as a placeholder.

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

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

With no annotations, the description discloses that it returns a structured coming_soon response and advises not to send secrets. This openly explains its stub behavior, though it omits the exact response 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?

Extremely concise: two sentences with no fluff. The first sentence names the tool, the second clarifies its stub nature and adds a security warning. Every sentence serves a purpose.

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

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

For a simple stub tool with no output schema and only optional parameters, the description is sufficiently complete. It explains the stub purpose and response type, though it could mention how parameters affect the stub.

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

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

Schema coverage is 100% with each parameter described. The description adds no additional meaning beyond the schema, meeting the baseline for high coverage.

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

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

Description clearly states the tool is a 'Coming soon' stub for listing invoices and explicitly says it does not perform the action yet. The purpose is transparent and well-defined.

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

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

No guidance on when to use this stub vs alternatives like hostodo_get_invoice or hostodo_pay_invoice. The warning 'Do not send secrets' is helpful but does not direct usage context.

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

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

No annotations are provided, so the description carries the full burden. It explicitly states the tool does not perform the requested action, returning a coming_soon response, which is transparent about its stub behavior.

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

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

The description is concise, two sentences, with no unnecessary information. It is front-loaded with the purpose and important caveats.

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 it is a stub with no output schema, the description adequately explains the behavior (returns coming_soon, does not act) and includes a security warning. It is complete for the tool's nature.

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

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

The input schema has 100% coverage for parameter descriptions, so the description does not need to add much. The warning 'Do not send secrets' adds value beyond the schema, but does not explain how parameters affect the stub response.

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

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

The description clearly states it is a stub that records demand and returns a structured coming_soon response, distinguishing it from actual sibling tools that perform real actions.

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

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

The description implies the tool is not ready for actual use and warns against sending secrets, but does not explicitly state when to use alternatives or provide usage context compared to siblings.

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

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

The description transparently discloses it is a PMF stub that does not perform the requested action and returns a coming-soon response, but lacks details on consequences of sending secrets or full safety implications.

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

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

Two sentences efficiently convey purpose and limitation; no superfluous text, but could be slightly more 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 stub, the description covers what it does and doesn't do, but lacks details on the response structure and how parameters are used; adequate but not fully informative.

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

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

Schema coverage is 100% with each parameter described; the tool description adds no additional semantic context beyond the schema, so baseline 3 is appropriate.

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

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

The description states the tool lists reverse DNS records but immediately clarifies it is a stub that does not perform the action; the purpose is clear but potentially misleading if only the title is read.

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

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

No guidance on when to use this tool versus alternatives; the only instruction is 'Do not send secrets,' which is a caution rather than usage direction.

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

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

The description fully discloses that the tool is a stub and does not perform the intended action. This is a high level of transparency, especially with no annotations to fall back on.

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

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

The description is two sentences plus a warning, all essential. It is front-loaded with the key 'Coming soon' nature, then provides critical details. No extraneous information.

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

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

For a stub tool, the description adequately explains what it does and what it doesn't do. It could mention the return format more explicitly, but it is sufficient for its purpose.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add any extra meaning beyond what the schema already provides for the parameters.

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

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

The description explicitly states it is a 'PMF stub' that 'records demand' and does not perform the requested action. It clearly defines what the tool does (list snapshots is aspirational) versus its actual behavior (recording interest).

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 warns 'Do not send secrets' and implies it is for demand recording, but does not explicitly say when to use this tool versus alternatives (e.g., if actual snapshot listing is needed). The context is clear but not complete.

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

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

The description fully discloses its stub behavior: it 'returns a structured coming_soon response' and warns 'Do not send secrets.' This is highly transparent despite the lack of annotations, leaving no ambiguity about side effects or safety.

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

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

The description is three sentences, front-loaded with the key purpose ('Coming soon (access): List SSH keys'), and every sentence serves a clear purpose: stating nature, behavior, and security warning. No unnecessary words.

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

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

Given the tool is a stub with no output schema, the description is fully complete: it explains what it does (records demand), what it returns (coming_soon response), and a critical security note. No additional information is needed for an agent to use 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?

Schema coverage is 100%, and the description adds no further parameter semantics beyond the schema definitions. The 'Do not send secrets' warning is generic and not parameter-specific, so the description meets the baseline but does not enhance parameter understanding.

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

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

The description states it is 'a PMF stub that records demand' and 'does not perform the requested action yet,' clearly indicating it is a placeholder for listing SSH keys. This distinguishes it from sibling tools like hostodo_add_ssh_key and hostodo_remove_ssh_key, but the 'Coming soon' phrasing slightly impairs clarity about its real behavior.

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

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

The description explicitly says it does not perform the action and records demand, implying it should be used only to gauge interest. However, it does not mention alternatives or when to use actual list functionality, leaving unclear guidance for agents expecting real SSH key listing.

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

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

With no annotations, the description indicates it is a read operation requiring vms:read scope. It lacks details on pagination or empty results, but the behavior is straightforward for a listing tool.

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

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

Two concise sentences with no unnecessary words. Front-loaded with key information.

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

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

Given no output schema and zero parameters, the description covers purpose, usage, and required scope. It could mention any limitations, but overall 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?

No parameters exist, so the description provides value by explaining the return value (id as template_id). Baseline is 4.

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

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

The description clearly states it lists enabled OS templates for VM reinstall workflows, specifying the verb (list) and resource (templates) and how the output is used as template_id. This distinguishes it from sibling list tools like list_dns_zones.

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

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

It provides context for when to use (VM reinstall workflows) and required scope. It does not explicitly state when not to use or list alternatives, but the context is sufficient.

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

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

With no annotations, the description fully discloses the stub behavior: it records demand, returns a coming_soon response, and does not execute the action. The warning 'Do not send secrets' adds safety context.

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

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

Three sentences with no wasted words. The purpose is front-loaded, followed by behavioral explanation and a safety note. Each sentence earns its place.

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

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

For a stub tool, the description sufficiently explains its non-functionality and prevents misuse. However, it lacks details about the 'structured coming_soon response' format, which could help agents handle the output.

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 explains all parameters. The description adds no additional parameter-level details but includes a general security note.

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

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

The description clearly states the tool is a 'coming soon' stub that records demand and does not perform the requested action. This distinguishes it from functional siblings by explicitly indicating it is non-functional.

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

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

The description implicitly tells agents not to use this tool for actual ticket listing by stating it does not perform the action yet. However, it does not explicitly mention alternative sibling tools like hostodo_get_ticket or hostodo_create_ticket.

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

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

No annotations provided, so description carries full burden. It implies read-only behavior (listing), but does not disclose authentication needs, rate limits, or return format details. Adequate but not rich.

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

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

Single sentence, front-loaded with the key action and resource. No unnecessary words, perfectly 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 zero-parameter list tool without output schema, the description explains what is returned (VPS instances and capability flags). Could mention that it returns all VMs for the authenticated customer, but overall sufficient.

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

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

No parameters exist, and schema coverage is 100%. The description does not need to add parameter information. Baseline of 4 is appropriate as it adds no confusion.

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

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

Clearly states 'List the authenticated Hostodo customer's VPS instances and capability flags,' using the verb 'list' and specifying the resource. This distinguishes it from sibling tools like hostodo_get_vm (single VM) and other operations.

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

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

No explicit guidance on when to use this tool versus alternatives like hostodo_get_vm for individual details. Implicitly it is for listing all VMs, but lacks 'when not to use' or direct comparison with siblings.

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

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

The description transparently discloses that this is a 'PMF stub' that 'does not perform the requested action yet' and returns a 'structured coming_soon response'. It also warns not to send secrets. With no annotations, the description effectively conveys the tool's non-functional nature and security implications.

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

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

The description is concise with two sentences, no redundant words. It communicates the key information: the action, the stub status, and a security warning. However, the structure could be improved by leading with the fact that it is a stub to avoid misleading the agent.

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

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

Given the tool's stub nature and lack of output schema, the description does not provide guidance on how the agent should proceed if payment is needed. It does not reference alternative tools or next steps, leaving the agent without a clear course of action.

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 for all 4 parameters, so the schema already provides meaning. The description adds no additional semantic value beyond the schema, such as usage hints or parameter relationships. 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 'Pay an invoice' as the primary action, but immediately clarifies it is a stub that does not perform the action. This dual message confuses the tool's actual purpose for an AI agent. It lacks specificity about what the tool does, making it unclear whether it should be used for payment.

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

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

No guidance is provided on when to use this tool versus sibling tools like 'hostodo_get_invoice' or 'hostodo_apply_credit'. The description does not mention alternatives for actual payment or suggest appropriate contexts. The warning 'Do not send secrets' is useful but insufficient for usage decisions.

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

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

With no annotations, the description must fully disclose behavior, but it only lists actions. It fails to mention whether actions are immediate, if confirmation is required, what the impact is on running processes, or error conditions. The description is too terse to inform the agent of behavioral traits.

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

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

The description is minimal and efficiently communicates the core action. However, it could benefit from a structured format (e.g., bullet points) or example values for 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?

Given the tool has two parameters, no output schema, and no annotations, the description is insufficiently complete. It lacks information about return values, error handling, and the effects of each action on the VM state.

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 0% description coverage; the description merely repeats the enum values for 'action' without explaining what each does. The 'vm_id' parameter is not described at all, leaving the agent without context on how to obtain or format it.

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

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

The description clearly identifies the tool's purpose: power-control a VPS. It lists all valid actions (start, shutdown, reboot, stop, reset), which distinguishes it from other VPS management tools that perform different operations (e.g., reinstall, execute commands).

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

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

No guidance on when to use this tool versus alternatives. It does not specify prerequisites, state requirements, or distinguish between similar actions. For example, it does not explain the difference between 'stop' and 'shutdown' or 'reboot' and 'reset'.

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

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

With no annotations, the description bears full burden. It discloses that reads are incremental and offset-based, which implies read-only behavior. However, it does not clarify whether the command must have finished, whether offsets are validated, or if there are rate limits or side effects. More detail would improve transparency.

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

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

Two sentences, front-loaded with purpose ('Read incremental stdout/stderr chunks') followed by a concise usage hint. Every sentence is necessary and no information is redundant. Excellent structure.

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

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

The tool is simple and the description covers the key iterative usage pattern. However, it does not mention potential edge cases like empty chunks when no new output is available, or whether the command must be completed. Given no output schema, a bit more detail on what is returned would improve completeness.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the incremental reading model and offset resumption, but the parameter descriptions in the schema already define the offsets and max_bytes. The description does not introduce new parameter meaning beyond what the schema provides.

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

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

The description clearly states it reads incremental stdout/stderr chunks by offset, distinguishing it from a full output fetch. It uses specific verbs ('read', 'resume') and identifies the resource (async command logs). This differentiates it from sibling tools like hostodo_get_vm_command_output which likely returns full output.

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

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

The description explicitly tells users to use offsets from previous calls to resume reading, providing clear iterative usage guidance. It does not, however, discuss when not to use this tool (e.g., for initial or full output reads) or explicitly mention alternatives like hostodo_get_vm_command_output.

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

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

With no annotations provided, the description fully carries the burden. It discloses the destructive nature ('deletes and rebuilds the guest disk'), the fact that it starts the VM, and that it returns a one-time root password. The behavioral information is clear and non-misleading, though it could mention prerequisites like VM state.

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

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

The description is two sentences: first sentence states purpose and prerequisite, second covers scope and side effects. It is front-loaded with the key verb 'destructively' and contains no redundant information. Every sentence earns its place.

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

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

Given 4 parameters, no output schema, and no annotations, the description covers purpose, prerequisites, side effects, and return value. It lacks details about error handling or exact return format, but overall it is complete enough for an agent to use the tool correctly.

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

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

The schema covers 100% of parameters with descriptions. The tool description does not add new meaning beyond the schema, simply restating the confirmation phrase and ssh_key_id optionality. Per guidelines, baseline 3 is appropriate when schema coverage is high and description adds minimal extra value.

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

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

The description explicitly states 'Destructively reinstall one owned Hostodo VPS to an enabled OS template', using a specific verb and resource. It clearly distinguishes from sibling tools like hostodo_restore_snapshot or hostodo_power_vm by emphasizing the destructive reinstall action.

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

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

The description directs the agent to call hostodo_list_templates first to discover valid template IDs, and specifies the required scope and confirmation phrase. However, it does not explicitly mention when not to use this tool or exclude alternative approaches.

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?

Fully transparent: it admits it's a stub, records demand, returns a coming_soon response, and performs no action. Also warns against sending secrets.

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

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

Three concise sentences, but the first sentence 'Coming soon (access): Remove an SSH key.' is slightly awkward in structure. No waste.

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

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

For a stub tool, the description fully explains what it does and its limitations. No output schema needed; the behavior as a placeholder is adequately described.

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% but description adds no meaning beyond the schema. Parameters are optional and loosely described; the description does not reference them.

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

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

The description clearly states 'Remove an SSH key' but immediately clarifies it's a stub that does not perform the action, making its purpose as a demand-recording placeholder unmistakable.

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

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

No explicit guidance on when to use this tool versus alternatives like hostodo_add_ssh_key or hostodo_list_ssh_keys. It only warns not to send secrets, implying it's not for actual removal.

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

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

No annotations are provided, so the description bears full burden. It discloses the confirmation phrase and scope requirement, but does not mention potential side effects (e.g., whether a reboot is needed) or reversibility. For a rename operation, this is adequate but not comprehensive.

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

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

The description is a single sentence plus a phrase, with no redundancy. Every word provides necessary information (purpose, scope, confirmation format).

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 rename tool without an output schema, the description covers the core aspects: what it does, required scope, and confirmation phrase. It could mention immediate effect or reboot, but overall it is sufficiently complete.

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

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

Schema coverage is 100% with clear descriptions for each parameter (vm_id, hostname, confirmation). The description does not add extra meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the tool renames a Hostodo VPS hostname/display label. The verb 'rename' and resource 'Hostodo VPS' are specific, and no sibling tool performs a rename, so it distinguishes well from alternatives.

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

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

The description specifies the required scope ('vms:power') and the exact confirmation phrase needed, which provides clear usage guidance. While it does not explicitly mention when not to use or alternatives, the lack of sibling rename tools makes this less critical.

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

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

With no annotations provided, the description carries full behavioral disclosure responsibility. It explicitly states the tool does not perform the action, only records demand and returns a coming_soon response. It also warns not to send secrets, which is well-disclosed for a stub 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 extremely concise: two sentences and a warning. It front-loads the key information about being a stub and its purpose, with no redundant text.

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

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

For a stub tool with no output schema and four optional parameters, the description adequately covers its behavior (records demand, returns stub response) and critical warning (no secrets). It could mention that all parameters are optional, but the schema already indicates that.

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 description adds a general security warning but does not provide additional semantic detail for individual parameters beyond what the schema already offers.

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

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

The description clearly states that this tool is a stub ('Coming soon') and that it does not perform the actual reply action. It explains that it records demand and returns a structured coming_soon response, which is specific and distinguishes it from functional 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 mentions it is a stub and warns against sending secrets, but does not provide explicit guidance on when to use it versus alternatives (e.g., actual support ticket systems). It does not mention that users should wait for the real implementation or use other channels.

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

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

With no annotations, the description bears full transparency responsibility. It explicitly states the tool records demand and returns a coming_soon response, does not perform any action, and warns against sending secrets. This is full disclosure of the tool's current behavior and limitations, exceeding typical stub 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?

Two sentences with no extraneous text. First sentence states purpose and stub nature; second adds a critical security warning. Front-loaded with the most important information. Every word earns its place, and the structure is ideal for quick parsing by an AI agent.

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

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

Given the tool's stub status, the description covers what matters: it records demand and doesn't act. The absence of an output schema is acceptable for a stub. One minor gap: it doesn't describe the 'structured coming_soon response' format, though that may be inferred. Overall, it is complete enough for an agent to correctly invoke the tool without false expectations.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add any parameter-specific semantics beyond what the schema already provides. The parameters' purposes are generic ('when relevant') and unchanged. The tool being a stub further reduces the need for parameter details, but no extra value 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 clearly states the tool's intended purpose ('Restart an application or system service on a VM') and immediately clarifies its current stub status ('does not perform the requested action yet'). This distinguishes it from sibling tools like power_vm or exec_vm_command, which handle VM-level power actions. The resource is specific, and the verb-action pairing is unambiguous.

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

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

The description implies usage when the user wants to restart a service but notes it's a stub. It warns 'Do not send secrets,' providing a security guideline. However, it does not explicitly state when to avoid this tool (e.g., if real restart is needed) or suggest alternative tools like hostodo_start_vm_command for power actions. The guidance is partial.

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

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

With no annotations, the description carries full transparency burden. It honestly discloses the tool does not perform the action, only returns a structured stub response. The warning about not sending secrets adds cautionary behavior.

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

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

Two short, front-loaded sentences. Every sentence adds value: one explains the stub nature, the other warns about secrets. No extraneous text.

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

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

For a stub tool, the description conveys it is not functional and records demand. It mentions the structured 'coming_soon' response. Could slightly improve by describing response fields, but overall adequate given tool's limited purpose.

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

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

Schema coverage is 100% with parameter descriptions, so baseline is 3. The description adds no additional parameter meaning beyond 'do not send secrets', which is a general caution rather than parameter-specific semantics.

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

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

The description clearly states the tool is a stub that records demand for restoring a snapshot, not an actual restoration. It distinguishes from siblings like hostodo_create_snapshot which performs a real action. The purpose is specific: logging interest for a future feature.

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 lacks when-to-use guidance. It only warns 'Do not send secrets' and states it returns a 'coming_soon' response. There is no comparison to alternatives or context for when this stub is appropriate versus real 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?

Given no annotations, the description fully discloses the stub nature: it does not perform the action and returns a coming_soon response. It also warns against sending secrets. This adds valuable behavioral context beyond the schema, though it doesn't detail what happens to input 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 description is extremely concise with two front-loaded sentences, no wasted words. It efficiently communicates the key points: purpose, stub status, and a security warning.

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?

As a stub tool with no output schema, the description mentions a 'structured coming_soon response' but does not describe its format or fields, leaving an agent uncertain how to handle the response. Given the tool's simplicity and optional parameters, additional guidance on the response would improve completeness.

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

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

Schema coverage is 100% with each parameter described in the input schema. The description adds no additional parameter information beyond the schema, so the baseline 3 is appropriate.

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

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

The description clearly states the tool is for rolling back a prior deployment, using specific verb and resource. It distinguishes itself from siblings as a stub, but the 'Coming soon' note indicates it's not functional yet, which is clear but may confuse agents expecting a working rollback.

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

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

No explicit guidance on when to use this tool versus alternatives. The description only mentions it's a stub for demand recording and advises not to send secrets, but lacks context on when to prefer it over other deployment-related tools like hostodo_get_deployment.

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

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

With no annotations provided, the description carries the full burden. It honestly discloses that the tool returns a 'coming_soon response' and warns 'Do not send secrets', providing critical behavioral context beyond the schema.

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

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

The description is three sentences, front-loaded with the purpose, and every sentence adds value: purpose, stub nature, and security warning. No redundancy or wasted words.

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

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

Given that this is a stub tool with no output schema and 4 optional parameters, the description fully explains its limited functionality and expected behavior. It is complete for the tool's nature.

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

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

Schema coverage is 100% with complete descriptions. The tool description adds no additional meaning to the parameters beyond 'non-secret metadata', which is already in the schema. Baseline score applies.

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

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

The description clearly states that the tool is intended to 'Set reverse DNS for an IP' but also explicitly reveals it is a stub that does not perform the action. This makes the purpose clear yet distinct from functional siblings.

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

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

The description notes that the tool 'does not perform the requested action yet' and is a 'PMF stub', implying it should not be used for actual operations. However, it does not suggest alternative tools like hostodo_create_dns_record for DNS 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?

No annotations provided, so description carries full burden. Discloses scope requirement and confirmation format, but does not mention side effects, error handling, rate limits, or whether operation is reversible.

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: first gives action and requirements, second adds parameter specifics. No wasted words, information front-loaded.

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

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

Given no output schema and 3 params, description covers purpose, requirements, and parameter details. Could mention what happens on invalid confirmation or whether success is returned, but overall 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 coverage is 67% (2 of 3 params have descriptions). Description adds crucial context: vm_id must be instance id, confirmation must be exact phrases with examples. Does not add semantics for the enabled boolean beyond schema.

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

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

Description clearly states verb 'Enable or disable' and resource 'MCP/QEMU guest-agent root command execution for one owned VPS', distinguishing it from sibling tools like hostodo_exec_vm_command or hostodo_power_vm.

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

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

Explicitly states required scope (vms:exec) and exact confirmation phrases for both enable and disable. Also clarifies to use instance id not hostname. Does not explicitly exclude alternative tools but provides clear 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?

Discloses async behavior, immediate return with command_id, and required permissions. With no annotations, the description carries the burden well, though it doesn't detail side effects like process management.

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

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

Three succinct sentences: purpose, behavior, usage. No waste; front-loaded and easy to parse.

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

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

Covers return value (command_id), polling approach, use cases, and prerequisites. No output schema, but description compensates. Missing details like error handling, but acceptable for the tool's simplicity.

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

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

Schema coverage is 100% and the description restates schema descriptions without adding new meaning. Baseline score of 3 is appropriate.

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

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

The description clearly states it starts an async command on a VPS and returns a command_id for polling. It differentiates from siblings like hostodo_exec_vm_command (sync) and hostodo_get_vm_command_output (polling).

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?

Lists appropriate use cases (builds, package installs, etc.) and prerequisites (vms:exec scope, mcp_exec_enabled=true). Could explicitly compare to alternative tools, but the async nature implies when to use it.

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

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

With no annotations, the description fully discloses the tool's stub behavior: it returns a coming_soon response and does not perform the action. It also warns against sending secrets, adding important behavioral context beyond the schema.

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

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

Two sentences: the first states purpose and stub status, the second warns about secrets. No wasted words, front-loaded with critical info.

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 stub tool, the description is fully complete: it explains what it does (record demand), what it does not do (perform action), and what to avoid (secrets). No further context needed given its placeholder nature.

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

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

Schema coverage is 100% with descriptions for each parameter. The description adds value by warning 'Do not send secrets', which guides parameter usage beyond the schema's generic descriptions.

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

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

The description clearly states it updates a DNS record but immediately clarifies it's a stub that does not perform the action. The purpose is specific: a placeholder to record demand. It distinguishes from actual DNS tools like create/delete.

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 warns 'Do not send secrets' and implies not to use for real operations, but does not explicitly list alternative tools (e.g., use create_dns_record/delete_dns_record). It provides no when-not-to-use context beyond being a stub.

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

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

The description explicitly states that the tool does not perform the requested action, returns a structured coming_soon response, and warns against sending secrets. Given no annotations are present, this provides clear behavioral disclosure.

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

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

The description is short and front-loaded with key context ('Coming soon (helpdesk)'). It efficiently conveys the stub nature and a security warning without unnecessary words.

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

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

For a stub tool, the description is sufficiently complete: it clearly communicates the non-functional state, the return type, and a security caveat. The sibling tools are more complex, but this stub's description fits its limited role.

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 no additional meaning to the parameters beyond what the schema already provides. It could have explained that parameters are used for recording intent or logging.

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 claims the tool 'Upload a ticket attachment' but then states it is a stub that does not perform the action. This creates confusion about the actual purpose, which is to record demand. It does not clearly differentiate from siblings like hostodo_create_ticket or hostodo_reply_ticket.

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

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

No guidance is provided on when to use this tool versus alternatives. The description does not indicate in what scenario a stub should be invoked, nor does it mention any conditions or prerequisites.

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