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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds the mount path and read_only behavior, but does not disclose what happens if the volume is already attached elsewhere, whether the mount path must be empty, or if the operation can override existing mounts. These details would be valuable beyond the annotations.

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

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

Two sentences with no filler. The core action is front-loaded, and the read_only option is presented succinctly. Every word earns its place.

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

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

For a simple mount operation with full schema coverage and no output schema, the description covers the essential prerequisites (running sandbox, absolute path) and the read_only option. It omits edge-case behavior but remains sufficient for an agent to invoke the tool correctly.

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

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

Schema coverage is 100% with descriptions for every parameter. The tool description adds meaning by stating the mount path must be absolute and that read_only controls write access, which complements the schema's generic descriptions. This exceeds 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 uses a specific verb ('Mount') and identifies the resource (volume) and target (running sandbox) with an absolute path, clearly distinguishing it from siblings like tenki_detach_volume and tenki_create_volume. The intent is 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?

The description clearly states the action (mount a volume into a running sandbox) and the key option (read_only). It does not explicitly name alternatives or exclusion conditions, but the context is unambiguous enough for an agent to know when to call this tool versus its siblings.

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

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

Annotations already mark it read-only and non-destructive; the description goes further by revealing a live identity probe, clarifying that it does not log in, and explicitly stating it never returns the token. This is valuable safety-relevant behavior beyond the structured hints.

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

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

Three sentences each add necessary information: what it reports, when to call it, and what it deliberately avoids doing. The most important information is front-loaded, with no filler or repetition.

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

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

Given zero parameters, an output schema, and read-only/idempotent annotations, the description covers the essentials: what is checked, how the check happens, when to invoke it, and explicit safety boundaries. Nothing needed for correct invocation is missing.

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

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

The tool has zero parameters and the schema documents that fully, so there is nothing for the description to explain. With no parameters, the baseline of 4 applies.

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

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

The description names a specific verb ('Report'), a clear resource ('Tenki credential'), and the exact facts it returns (presence, kind, endpoint). It also implicitly distinguishes this from the sibling tenki_whoami by focusing on credential state rather than identity.

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 gives explicit trigger conditions: call it first after auth errors, or when it is the only available tool because no credential is configured. It does not mention a when-not-to-use case or an alternative tool, but this tool is a diagnostic entry point rather than one option among competing 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 discloses that the tool performs a binding/routing mutation, which aligns with annotations (readOnlyHint=false, idempotentHint=false). However, it adds little beyond the annotations: it doesn't state whether existing bindings are replaced, whether the preview URL must already exist, or what happens to traffic during rebinding. With annotations present, the bar is lower, but the description still provides minimal added behavioral context.

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

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

A single 12-word sentence that front-loads the verb, object, and destination. The parenthetical 'advanced routing' adds useful context without bulk. There is no filler, repetition, or unnecessary detail.

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

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

For an advanced routing tool with no output schema and only minimal annotations, the description omits important context: the lifecycle relationship (e.g., whether the preview URL must be created first via tenki_create_preview_url), what happens when rebinding an already-bound URL, and error conditions. An agent navigating 70+ siblings needs more context to invoke this safely.

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 covers 100% of parameters with clear descriptions, and session_id even names source tools (tenki_create_sandbox/tenki_list_sandboxes). The description adds no parameter-specific meaning beyond the schema, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Bind'), names the resource ('a named preview URL'), and the destination ('a sandbox session and port'). The parenthetical '(advanced routing)' helpfully distinguishes it from simpler preview tools like tenki_open_preview or tenki_create_preview_url, making the tool's role 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 phrase 'advanced routing' implies this is for advanced binding scenarios, but there is no explicit when-to-use/when-not-to-use guidance or reference to sibling alternatives such as tenki_unbind_preview_url, tenki_open_preview, or tenki_create_preview_url. Usage context is only implied, not stated.

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

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

Annotations already convey mutability (readOnlyHint=false) and non-idempotence (idempotentHint=false). The description adds the asynchronous build lifecycle (polling until READY) and how the result feeds into sandbox creation. It could mention resource implications or cancellation, but the annotation coverage lowers the bar and the added context is valuable.

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

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

The description is two sentences with zero fluff. It front-loads the core action and then provides the essential follow-up workflow. 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 absence of an output schema, the description sufficiently explains what to do with the returned build (poll and extract imageDigestRef). Combined with thorough schema descriptions for parameters, an agent can invoke the tool and integrate it into the sandbox-creation flow. Minor omissions like failure handling are not critical.

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 covers 100% of parameters with descriptions, so the baseline is 3. The description does not add new parameter-level meaning; it focuses on the workflow. The schema already explains build_env, image_name, build_secrets, and publish_raw_image, so this is acceptable.

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

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

The description states a specific verb and resource ('Trigger a build for a template'), the outcome ('producing a bootable image'), and the relationship to sibling tools (poll with tenki_get_template_build, use digest with tenki_create_sandbox). This clearly distinguishes it from other template-related tools.

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

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

The description gives a clear usage context: trigger a build, then poll the resulting build until READY and feed its imageDigestRef to tenki_create_sandbox. It does not explicitly state when not to use this tool (e.g., when just inspecting a template), but the workflow is concrete enough to route an agent correctly.

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

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

Annotations already convey that this is not read-only, not idempotent, and not destructive-hinted. The description adds the useful 'in-progress' precondition but does not disclose side effects such as whether cancellation is reversible or how completed builds are handled. This is acceptable given annotation coverage, but it leaves some behavioral detail implicit.

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

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

A single sentence with no wasted words: the verb is front-loaded, the object is specific, and the precondition is included. Every part earns its place.

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

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

For a one-parameter cancellation tool with annotations present, the description gives enough to select and invoke it correctly: what to cancel and how to identify it. It does not describe post-cancel behavior or error cases, but those are not essential for calling it.

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 the only parameter with a description ('The template build ID to cancel.'), so baseline 3 applies. The tool description merely restates that the cancellation happens 'by its build ID' without adding format, source, or validity guidance beyond what the schema already provides.

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

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

The description uses a specific verb ('Cancel') with a clear resource ('template build') and the required identifier ('build ID'). The qualifier 'in-progress' distinguishes this from get/list/build template operations in the sibling list, so an agent can tell what it does at a glance.

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

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

The description clearly scopes usage to 'in-progress' template builds, which tells the agent when the tool applies. It does not explicitly route to alternatives like tenki_get_template_build or tenki_list_active_template_builds, but the context is clear enough for a simple cancellation operation.

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

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

Annotations indicate a mutation (readOnlyHint=false) and non-idempotent behavior. The description adds that the URL is 'shareable' and 'public', which conveys the side effect of exposure. It also states the networking requirement, which is behavioral context not present in annotations. No contradictions.

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, compact sentence that front-loads the action and includes the key prerequisite. Every word earns its place; there is no filler.

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

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

Given the tool's complexity (4 params, all documented) and no output schema, the description adequately covers the main purpose and a critical prerequisite. However, it doesn't mention what the tool returns (presumably the preview URL) or explicitly distinguish it from the closely related tenki_bind_preview_url / tenki_get_preview_url, leaving minor gaps.

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

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

Schema description coverage is 100%, so all four parameters are already well-documented in the schema. The description adds no additional parameter-level meaning beyond mentioning 'for a port', which is already in the schema. The baseline of 3 applies because the schema does the heavy lifting.

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

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

Description states a specific verb ('Create') and resource ('shareable public preview URL for a port in a sandbox'), which clearly distinguishes it from siblings like tenki_get_preview_url (retrieve) and tenki_open_preview (open). It also notes a key prerequisite (inbound networking). The purpose is unambiguous.

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

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

The description explicitly states when to use this tool (to create a shareable public preview URL) and includes a critical precondition (sandbox must have inbound networking enabled). It doesn't explicitly list alternatives or exclusions, but the context is clear enough that an agent can infer when this tool is appropriate versus related tools like tenki_bind_preview_url or tenki_open_preview.

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

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

Annotations only provide generic readOnly/destructive/idempotent hints (all false), so the description carries most of the behavioral disclosure burden. It adds materially useful behavior: the sandbox is persistent, boots in ~2 seconds, optionally polls until RUNNING (tie to wait_ready), and exposes a data-plane endpoint plus session_id for follow-up. It does not fully document cost/implications of persistent resources or failure behavior, but it does disclose key runtime behavior beyond what annotations 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 compact: three sentences, with the core action and persistence front-loaded, followed by a concrete downstream usage pointer. Every sentence adds value: what it is, what is returned, and how to use the result. No filler or repetition of schema 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 15-parameter, 0-required tool with no output schema, the description compensates well by naming the returned fields (session id, state, endpoint), the boot behavior, and the next-step functions. It could be slightly stronger by noting higher-level lifecycle implications (e.g., persistent resources run until terminated or idle-reaped) or how idle_timeout and max_duration_seconds govern lifetime. Given the schema covers all parameters and sibling tools cover lifecycle/cleanup, the description is functionally complete for selecting and invoking the tool.

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

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

The schema covers 100% of the parameters, so the baseline is high, and the description's pointers to tenki_exec / tenki_read_file / tenki_write_file reinforce the central return-value semantics. The description adds the notion of persistence, boot time, and the returned session/endpoint, which helps interpret parameters like wait_ready, image, snapshot_id, and idle_timeout. It does not rehash every parameter, but with complete schema coverage that is not necessary.

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

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

The description states a specific action ('Create a persistent sandbox microVM'), the optional source ('from a snapshot or template image'), and the primary outputs (session id/state, data-plane endpoint). It also clearly differentiates this from the many sibling tools by naming the session-based interaction tools (tenki_exec, tenki_read_file, tenki_write_file) that operate on the returned session_id. This distinguishes it from other create/update/terminate operations while covering the main resource and verb.

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

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

The description gives concrete usage context: persistence, ~2s boot, and how to interact with the returned session_id using named sibling tools. It implicitly explains when to use this tool (when a persistent sandbox is needed) versus alternatives like snapshots, templates, volumes, or one-off code execution, though it does not explicitly enumerate exclusions or provide conditional routing to alternatives beyond the exec/read/write trio. The guidance is strong but could be clearer about when tenki_run_code or tenki_create_snapshot would be more appropriate.

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

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

Annotations indicate readOnlyHint=false (mutation), idempotentHint=false, and destructiveHint=false. The description adds valuable context: it captures disk and memory, excludes attached volumes, and the snapshot is reusable. It does not contradict annotations and discloses a key limitation (volumes not captured). However, it does not mention potential side effects like cost, timing, or whether the sandbox continues running, though these are not critical given the annotations.

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

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

The description is a single, well-structured sentence that front-loads the core action, includes a critical caveat (volumes not captured) in parentheses, and ends with a direct pointer to the consuming tool. Every word earns its place with no redundancy.

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

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

For a create operation with four parameters (all documented in the schema) and no output schema, the description covers the essential behavior, the volume limitation, and the reuse path. It is sufficient for an agent to correctly invoke the tool, though it could mention prerequisites like the sandbox must be running (implied by 'running sandbox') or that the snapshot creation is asynchronous. These are minor gaps.

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

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

The input schema has 100% parameter description coverage, so the schema fully documents name, expires_at, session_id, and store_raw_image. The tool description adds no additional parameter details beyond what the schema provides, so it meets the baseline of 3 but does not enhance understanding of parameter semantics.

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

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

The description clearly states the action (capture a running sandbox's disk and memory as a reusable snapshot) and the resource (a sandbox session). It explicitly notes attached volumes are NOT captured, distinguishing it from volume-related operations, and points to the consuming tool (tenki_create_sandbox) for reuse. This is a specific verb+resource that separates it from the many snapshot-management 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 gives a workflow hint (boot a new sandbox later with tenki_create_sandbox + snapshot_id) and notes the volume limitation, but it does not explicitly contrast with other snapshot tools (e.g., list, get, update, delete) or state when not to use this tool. The context is implied rather than explicit, so an agent must infer that this is the only creation operation among snapshot siblings.

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

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

Annotations carry the safety profile (readOnlyHint=false, openWorldHint=true), and the description adds meaningful behavior beyond that: the template is just a spec, not yet bootable, and the typed-vs-legacy distinction is a real behavioral constraint on downstream image naming and sandbox booting. This is exactly the kind of context that helps an agent anticipate 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 with no filler: the core definition is front-loaded, and the NOTE delivers the key distinction. The second sentence is dense with nested parentheticals, but every clause earns its place given the tool's complexity.

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 create tool with 13 parameters, nested objects, and no output schema, the description covers the most decision-critical context: what is being created, the build step that follows, and the typed-template requirement for publishable images. Parameter-level details are left to the schema, which is acceptable given 100% coverage. It could mention the return value, but that gap is minor.

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

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

Schema description coverage is 100%, so the schema already documents all 13 parameters, including constraints, mutual exclusivity, and defaults. The description reinforces the importance of builder_spec for named images, but that is largely restating what the builder_spec parameter description already says. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource: 'Create a custom-image template' and clarifies what that is ('a reusable sandbox-image spec: base image + setup script + default resources'). It also distinguishes itself from the sibling tenki_build_template by positioning creation as the prerequisite to building a bootable image.

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

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

The description gives clear workflow guidance: create the template now, and 'Build it into a bootable image later with tenki_build_template.' It also provides a decisive usage condition by explaining that only a typed template (builder_spec, no legacy fields) can produce a named, publishable image usable by tenki_create_sandbox. It stops short of explicit when-not-to-use guidance or alternatives for simple template creation, so not a 5.

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

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

Annotations already indicate this is a non-read-only, non-idempotent, non-destructive action. The description adds useful behavioral context: the volume persists across sandbox teardown and is workspace-scoped, with workspace defaulting to the API key's first workspace. This clarifies the side effect without contradicting annotations.

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

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

Two sentences with no fluff. The core action and persistence property are front-loaded, and the workspace default behavior is stated clearly in the second sentence.

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 three-parameter create tool with strong annotations, the description covers purpose, persistence behavior, and workspace selection. There is no output schema, so mentioning the return value would be helpful, but the description is otherwise sufficient for an agent to select and invoke the tool correctly.

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

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

All parameters have full schema descriptions (100% coverage), so the baseline is 3. The description's mention of workspace_id defaulting overlaps with the schema's own workspace_id description, adding little new semantic value beyond reinforcing workspace scoping.

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

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

The description states a specific verb and resource: 'Create a workspace-scoped persistent volume.' It also defines the key differentiator—durable block storage that survives sandbox teardown—so an agent can distinguish this from sandbox, snapshot, and template creation 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 gives clear context for when the tool is appropriate: when persistent block storage that outlives sandbox teardown is needed. It does not explicitly name sibling alternatives or state when not to use it, so it does not earn a full 5.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false. The description adds value by stating the result is 'permanently offline', which conveys irreversibility. This aligns with and reinforces the annotations without contradicting them.

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

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

A single concise sentence with no wasted words. The action verb leads, and the permanently-offline consequence is included without padding.

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

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

For a simple, single-parameter delete operation, the description plus annotations and schema provide everything an agent needs: what is deleted, how it is identified, and that the action is destructive and permanent. No output schema is needed for this tool.

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

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

The input schema has 100% parameter coverage, with preview_url_id already described as 'The preview URL id to delete.' The description's 'by id' adds no new meaning beyond the schema, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Delete'), a specific resource ('preview URL'), and an explicit scope ('by id'), making it immediately clear what the tool does. It also distinguishes itself from siblings like tenki_get_preview_url and tenki_unbind_preview_url by emphasizing permanent deletion.

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 makes the purpose and consequence clear enough that an agent can infer when to use it: when a preview URL should be permanently removed. It does not explicitly contrast with related tools like tenki_unbind_preview_url or tenki_touch_preview, so it misses the top score for explicit alternatives and exclusions.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, which covers the safety profile. The description adds 'permanently' to emphasize irreversibility and 'by ID' to specify the targeting mechanism, but it doesn't disclose additional behaviors like whether the snapshot must be unattached or what happens if the ID is invalid. Given the annotations carry the main burden, a 3 is appropriate.

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

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

The description is a single, front-loaded sentence: 'Permanently delete a snapshot by ID.' It contains no filler and immediately conveys the action, the object, and the key modifier (permanently) and targeting mechanism (by ID). Every word earns its place.

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

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

For a simple delete operation with one parameter and no output schema, the description is sufficiently complete. It covers what the tool does and the essential detail of deletion by ID. While it doesn't discuss error conditions or prerequisites, the annotations handle the destructive nature, and the tool's simplicity means an agent has enough information to call it correctly.

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

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

The schema has a single required parameter snapshot_id with no description (0% coverage). The description's 'by ID' confirms that this parameter is the snapshot identifier, but it doesn't provide extra detail on format or provenance. While the parameter name is self-explanatory, the description adds only marginal value beyond the schema field name.

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 specific action (permanently delete) and resource (snapshot) and includes the key detail that deletion is by ID. It clearly distinguishes from sibling tools like tenki_get_snapshot, tenki_list_snapshots, tenki_create_snapshot, and tenki_update_snapshot, making the tool's purpose unambiguous.

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

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

The description makes it obvious when to use this tool: when a snapshot needs to be permanently removed. It doesn't explicitly mention alternatives or exclusions, but the sibling list shows no other snapshot deletion tool, so the context is clear enough for an agent to select it appropriately.

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

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

Annotations already mark destructiveHint=true, so the description doesn't need to restate that deletion is destructive. It adds useful behavioral context beyond annotations by explaining that builds or dependents block deletion unless force is passed. No contradiction with annotations.

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

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

Two short sentences with no wasted words. The core action comes first and the conditional force instruction follows immediately, making the key usage nuance easy to scan.

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

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

For a two-parameter destructive delete with annotations and no output schema, the description covers the core behavior and the non-obvious force path. It doesn't describe success/failure responses or cascading side effects, but those are minor given the simple operation and destructiveHint annotation.

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 both parameters fully. The description adds only a slight expansion of the force semantics ('builds or dependents') over the schema's 'dependents', but does not carry the parameter documentation burden.

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

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

States a specific verb ('Delete') and resource ('a template by ID'), clearly distinguishing this from sibling delete tools that target other resources (snapshots, volumes, preview URLs). The 'force' qualifier adds a precise condition that sharpens the purpose.

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

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

The description tells the agent when to pass force ('even when builds or dependents exist'), which is the key conditional for successful deletion. It does not explicitly name alternatives, but for a delete operation the target resource is self-evident.

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

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

The annotations already mark this as destructive and non-idempotent, and the description adds meaningful context by stating that data is destroyed and that the operation fails with VolumeInUse if attached. It also gives a remedy ('detach it first'), which goes beyond the structured hints.

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

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

One front-loaded sentence conveys the core action and irreversibility, followed by the key failure condition and remedy. Every clause earns its place and 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?

For a one-parameter deletion tool, the description fully covers the action, the destructive consequence, the failure mode, and the required prerequisite. No output schema is needed to convey return value, and the annotations cover the safety profile.

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

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

Schema description coverage is 100%, and the single parameter volume_id is already fully documented in the schema. The tool description adds no additional parameter-level meaning, so it meets the baseline but does not exceed 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 states a specific verb and resource: 'Permanently delete a volume and destroy its data.' It clearly distinguishes this from volume-related siblings like update, attach, detach, and resize by emphasizing permanent deletion and data destruction.

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

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

The description gives a clear usage condition: it will fail if the volume is attached, and the agent should detach it first. It does not explicitly name the detach alternative or provide explicit when-not-to-use guidance, but the prerequisite is clear and actionable.

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

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

Annotations already disclose that the operation is destructive (destructiveHint: true), not read-only, and not idempotent. The description adds no behavioral context beyond the basic action, but it also does not contradict any annotations, so a neutral score is appropriate.

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

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

A single, front-loaded sentence with no wasted words. It could arguably be enriched, but for a simple tool it is appropriately 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?

The description is functional for a simple 2-parameter operation, and annotations cover the destructive aspect. However, it omits any context about side effects, prerequisites, or what happens after unmounting, leaving some ambiguity for an agent deciding among volume-related operations.

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 session_id and volume_id. The description adds no additional parameter meaning, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Unmount') with a clear resource ('a volume') and location ('from a sandbox session'). It plainly distinguishes the operation from sibling tools like tenki_attach_volume and tenki_delete_volume.

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

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

There is no guidance on when to use this tool versus alternatives, no mention of prerequisites (e.g., volume must currently be attached), and no exclusion of cases where delete_volume or attach_volume would be more appropriate. The usage is implied only by the name and terse description.

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

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

The description adds strong behavioral context beyond the annotations by explaining output truncation, the head+tail preview, and where full output is retained at stdoutPath/stderrPath. It does not contradict the annotations, though it could have more explicitly noted the side-effect potential of running arbitrary commands.

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 front-loaded sentences deliver the core purpose and the most important edge-case behavior without wasted words. The structure is efficient and every clause contributes useful 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 7-parameter tool with an output schema and annotations, the description covers the essential return behavior and output-size handling. It does not explicitly describe timeout behavior or distinguish itself from tenki_run_code, but these are minor gaps given existing schema and annotation coverage.

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

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

Schema description coverage is high (86%), so the baseline is 3. The description's max_output_bytes explanation largely repeats what the schema already provides, and it adds little new semantic meaning for params like timeout_seconds, cwd, or env.

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

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

The description clearly states the tool's action and resource: 'Run a command in an existing sandbox' and explicitly lists the return values: stdout, stderr, and exit code. It is clear and specific, though it does not explicitly differentiate itself from tenki_run_code or other command/code execution 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 phrase 'existing sandbox' implies a prerequisite and suggests use after sandbox creation, but the description gives no explicit when-to-use/when-not-to-use guidance or alternative tool names. The usage context is implied rather than clearly stated.

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

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

Annotations already indicate this is a mutating, non-idempotent, open-world operation, so the description need not restate those. It adds the concrete consequence of a 'public preview URL,' which is useful context, but it does not disclose lifecycle details such as whether the exposed port persists, how cleanup happens, or what happens if the server is not reachable.

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 filler. The first sentence states the operation and outcome, and the second gives a concrete use case. Every word earns its place.

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

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

For a simple three-parameter tool, the description covers the core action, the result ('public preview URL'), and the motivating scenario ('web server it wants to show'). Without an output schema, return-format detail is not specified, but the description is adequate for an agent to understand what the tool accomplishes.

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%: port, slug, and session_id all have descriptive schema text. The description itself adds no parameter-level detail beyond the schema, so the baseline score of 3 applies.

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

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

The description uses a specific verb-resource pair ('Expose a port from a sandbox') and a concrete outcome ('get a public preview URL'). It clearly distinguishes this from sibling tools like tenki_unexpose_port and tenki_create_preview_url by tying the action to a sandbox port.

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

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

The description gives a clear usage context: 'Useful when an agent starts a web server it wants to show.' It does not explicitly state when not to use it or name alternative tools, but the intended scenario is readily inferable.

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

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

Annotations already signal readOnlyHint=false and idempotentHint=false. The description adds useful behavioral context: it affects wall-clock lifetime, applies only to running sandboxes, and prevents auto-termination at the max-duration cap. This goes beyond the bare annotations without contradicting them.

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

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

A single sentence that front-loads the core action and the motivating outcome. Every word contributes meaning; there is no fluff or repetition.

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

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

For a simple two-parameter operation with no output schema, the description provides the operation, the precondition (running sandbox), and the purpose (avoid auto-termination). It could mention return behavior or limits on extensions, but nothing critical is missing.

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

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

Schema description coverage is 100%, so the baseline of 3 applies. The tool description itself doesn't add parameter-level detail, but the schema already defines both session_id and additional_duration_seconds adequately. The 'Duration string' wording in the schema is slightly ambiguous, but that's a schema concern, not a description gap.

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

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

The description uses a specific verb ('Extend'), a specific resource ('a running sandbox's wall-clock lifetime'), and a clear intended outcome ('so it isn't auto-terminated at its max-duration cap'). This clearly differentiates it from related operations like pause, resume, terminate, or generic update.

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

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

The phrase 'running sandbox' and 'max-duration cap' gives clear context for when this tool should be used. It does not explicitly name alternatives or exclusions, but the use case is specific enough that an agent can infer when to invoke it.

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

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

Annotations already communicate read-only, idempotent, non-destructive behavior. The description adds meaningful context beyond annotations: the URL is short-lived, the retrieval uses HTTP GET, and only artifact-id-based download is supported. It does not specify exact expiration or response format, but those are not essential for correct invocation.

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

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

The description is compact and front-loaded: the core operation is stated first, followed by a single critical limitation. Every sentence earns its place, 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 two-parameter, read-only, idempotent tool with no output schema, the description is sufficient. It names the return kind ('short-lived signed URL'), the HTTP method, the resource scope, and the key API limitation, giving an agent everything needed to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, and both session_id and artifact_id are already documented in the schema. The description reinforces the artifact_id concept with an example, but it does not add substantive per-parameter meaning beyond what the schema already provides.

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

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

The description uses a specific verb and resource: 'Get a short-lived signed URL to download (HTTP GET) a command artifact from a sandbox by its artifact id.' It clearly distinguishes the tool from path-based or snapshot-related siblings by scoping it to command artifacts and explicitly stating 'download-by-artifact-id only, not download-by-path.'

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 context is clear: use this tool when you need a signed URL for a command artifact and you have an artifact_id. The note 'not download-by-path' provides an explicit boundary, though it does not name alternative sibling tools such as tenki_read_file or tenki_get_snapshot_download_url.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the read-only safety profile is established. The description's 'Fetch' is consistent with those annotations, but it adds little behavioral context beyond them, such as error behavior or what exactly 'details' includes.

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

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

The description is one short sentence with no filler. It front-loads the action, resource, and the parameter used to identify the resource, making it immediately scannable for an 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?

For a simple get-by-id tool with one fully documented parameter and annotations covering safety, the description is largely sufficient. It does not describe the return fields or not-found behavior, but an agent can invoke the tool correctly with the information provided.

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

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

The input schema fully documents preview_url_id as 'The preview URL id.' The description reinforces that the operation is by id but does not add extra meaning such as where the id comes from or expected format. With 100% schema coverage, the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Fetch'), names the resource ('preview URL's details'), and identifies the scope ('specific ... by id'). This clearly distinguishes it from sibling tools like tenki_list_preview_urls (all preview URLs) and tenki_create_preview_url or tenki_delete_preview_url.

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

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

The phrase 'specific preview URL's details by id' implies the tool is for retrieving one known preview URL rather than listing all of them. However, the description does not explicitly state when to use this tool versus alternatives such as tenki_list_preview_urls, nor does it mention any exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the scope of what is fetched (state and metadata) but no deeper behavioral context, such as what 'state' entails or how it relates to list_sandboxes output. No contradiction with annotations.

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

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

A single, front-loaded sentence with zero filler. Every word contributes meaning for a simple getter tool; nothing is redundant with the name or schema.

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

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

For a simple read-only getter with one well-documented parameter and rich annotations, the description adequately covers purpose and return scope. It could add a note about what fields 'state' includes, but nothing critical is missing for an agent to invoke it correctly.

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

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

Schema coverage is 100%: the single session_id parameter is documented with type, format (UUID), and provenance (from tenki_create_sandbox or tenki_list_sandboxes). The description adds no parameter-level meaning, so the baseline 3 applies.

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

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

The description uses a specific verb ('Fetch') and resource ('a sandbox') and names the return scope ('current state and metadata'). This distinguishes it from get-resource siblings like tenki_get_snapshot or tenki_get_volume, though it does not explicitly differentiate from tenki_list_sandboxes.

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 when-to-use guidance, no alternative tools, and no exclusions. The intended usage is only weakly implied by the session_id parameter provenance in the schema, not stated in the description itself.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the tool returns status and metadata, but does not describe error behavior, authorization needs, or return structure beyond that.

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

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

One short sentence with no filler. The subject, object, and selection criterion are all front-loaded, making the description immediately scannable.

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

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

For a simple read-only get-by-ID tool with only one required parameter and strong annotations, the description covers the essential invocation context. It names the return content (status and metadata), though it omits details like not-found behavior or whether the result is wrapped in a response object.

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 0%, but the single parameter snapshot_id is semantically self-explanatory and the description reinforces that this ID selects the snapshot. It does not add format guidance or explain how to obtain a valid snapshot_id, though the minimal schema makes this a modest gap.

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

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

The description uses a specific verb ('Fetch') and resource ('one snapshot's status and metadata') with an explicit identifier criterion ('by ID'). This clearly distinguishes it from list-style tools like tenki_list_snapshots and from tenki_get_snapshot_download_url.

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 use case is reasonably implied: call this when you have a specific snapshot_id and need that snapshot's status/metadata. However, it does not explicitly state when not to use it or mention alternatives such as list_snapshots or get_snapshot_download_url.

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

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

Annotations already establish that this is read-only, idempotent, and non-destructive. The description adds meaningful behavior beyond that: it returns a short-lived pre-signed URL, targets the raw disk image, and depends on a snapshot creation option. It does not disclose what happens if the precondition is unmet, but the annotation coverage lowers that burden.

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

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

The description is a single sentence that leads with the action and outcome, then tacks on the essential prerequisite. There is no filler or redundancy.

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

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

For a one-parameter read-only tool with rich annotations, the description covers the purpose, output type, and a key prerequisite. It omits details like URL expiration duration or error behavior, but nothing essential is missing for an agent to invoke it correctly.

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

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

The schema only defines snapshot_id as a required string with no description. The description indirectly clarifies that this ID refers to a snapshot and adds the store_raw_image requirement, but it does not explain the ID format or how to obtain a valid snapshot_id. With 0% schema coverage, this is partial but not full compensation.

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 (get), the resource (a snapshot's raw disk image), and the output (short-lived pre-signed URL). It also adds the distinctive prerequisite store_raw_image, which separates it from generic download tools like tenki_get_download_url and preview tools like tenki_get_preview_url.

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

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

The description gives a clear precondition for use: the snapshot must have been created with store_raw_image. This frames when the tool is applicable, though it does not explicitly name alternatives like tenki_get_download_url or state a direct 'do not use when' exclusion.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable behavior beyond that: the deprecation status and the critical empty-response semantics ('no retention override, i.e. kept indefinitely'), which affects how an agent interprets results.

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

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

Two sentences deliver the purpose, the deprecation warning, and the key empty-response meaning. There is no filler, and the most important behavioral caveat is front-loaded in the second sentence.

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 optional-parameter getter, the description covers purpose, deprecation, and the empty-response case. With no output schema, it could have been slightly more explicit about the shape of a non-empty response, but the retention fields are clearly implied by the tool name and description.

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

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

Schema coverage is 100%, and the only parameter, workspace_id, is already documented with 'Workspace (defaults to the key's first workspace).' The description adds no further parameter detail, so the 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 uses a specific verb and resource: 'Get the workspace's pause- and snapshot-retention periods.' It also distinguishes this tool from its sibling, tenki_get_workspace_settings, by explicitly noting the deprecation and the alternative that returns the same fields.

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

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

The description clearly identifies when not to use this tool by marking it 'DEPRECATED upstream' and states that tenki_get_workspace_settings 'returns the same retention fields alongside the quotas.' This gives the agent an explicit routing decision between the two tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered. The description adds no further behavioral context, such as return format or error behavior, but it does not contradict the annotations.

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

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

One short, front-loaded sentence with zero filler. Every word contributes to identifying the tool's purpose.

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

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

For a single-parameter, read-only lookup with comprehensive annotations, the description and schema are sufficient. No output schema exists, but 'Retrieve one template' adequately implies that the result is the template object.

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 template_id is already documented as 'The template ID.' The description's 'by ID' adds no new semantic meaning beyond confirming the lookup key, 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?

States a specific verb ('Retrieve'), a precise resource ('one template'), and the discriminator ('by ID'), which distinguishes it from tenki_list_templates and the template mutation tools. An agent can tell exactly what this tool does without opening the schema.

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

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

The phrase 'one template by ID' implies it should be used when a specific template_id is already known, rather than for enumeration. However, it does not explicitly state when not to use it or name alternatives such as tenki_list_templates.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description adds value by explaining the result includes state, progress, and result image, plus how imageDigestRef is consumed by tenki_create_sandbox. This goes beyond what annotations and schema provide.

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

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

Two concise, front-loaded sentences with no filler. The main action and return contents come first, and the downstream integration detail earns its place in the second sentence.

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

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

For a one-parameter, read-only, idempotent lookup tool, the description is complete: it names the key result fields and connects the result to a concrete downstream use in tenki_create_sandbox. No output schema exists, but the description covers the essential return semantics.

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

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

Schema description coverage is 100% and the only parameter, build_id, is documented as 'The template build ID.' The description reinforces 'by its build ID' but adds no extra format or semantic detail 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 uses a specific verb 'Retrieve' with a precise resource, 'one template build by its build ID', and names the returned aspects: state, progress, and result image. This clearly distinguishes it from sibling tools like tenki_get_template and tenki_list_active_template_builds.

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?

Gives strong usage context: use this to retrieve a build and, when READY, its imageDigestRef is what tenki_create_sandbox's image argument expects. It does not explicitly name alternatives or say when not to use it, but the downstream purpose is clear.

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

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

Annotations already signal readOnlyHint=false, idempotentHint=false, destructiveHint=false, and the description is consistent with them. It adds value beyond annotations by disclosing that the URL is short-lived (expires, so use promptly) and that the upload mechanism is HTTP PUT with a signed URL, which is effectively the auth model. It does not quantify the expiry or describe the response, but no contradiction exists and the added context exceeds the annotation baseline.

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 filler. The first sentence front-loads the core action and key traits (short-lived, signed, HTTP PUT, binary, sandbox path), and the second delivers the routing rule vs. tenki_write_file. Every clause 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 3-parameter tool with a fully documented schema, safety annotations, and a clear sibling-routing rule, the description is nearly complete. Small gaps: the agent must infer that after obtaining the URL it must perform the PUT itself, the 'short-lived' duration is unquantified, and there is no output schema describing the returned URL structure. These are minor and do not block 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?

Schema coverage is 100%: each parameter (path, session_id, content_type) already has descriptive text with examples and provenance hints (e.g., session_id 'from tenki_create_sandbox or tenki_list_sandboxes'). The tool description itself does not add parameter-level meaning, so the baseline 3 applies.

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

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

The description names a specific verb+resource: getting a short-lived signed URL for HTTP PUT upload of a binary file into a sandbox path. It also distinguishes itself from the closest sibling (tenki_write_file) by explicitly scoping itself to non-text/binary/large payloads, and the upload direction contrasts with tenki_get_download_url.

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 the selection condition: use when payloads are non-text, too large, or binary, instead of tenki_write_file. This names the alternative and the precise triggering criteria, leaving nothing for the agent to infer.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, which fully cover the safety profile. The description adds 'metadata and current state' but that is essentially the purpose, not additional behavioral context. It is consistent with the annotations and does not contradict them, but it does not disclose anything beyond what the annotations already provide (e.g., no rate limits, auth requirements, or side effects).

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

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

The description is a single, efficient sentence with the key action ('Fetch') front-loaded and no redundant information. Every word earns its place, and it is appropriately sized for a simple get operation.

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

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

Given the tool's simplicity, the annotations cover safety, and the schema covers the parameter, the description is sufficient. It states the resource ('volume') and the targeted aspect ('metadata and current state'), which is a reasonable specification for a read-only fetch. There is no output schema to clarify return format, but that is not necessary here. It lacks explicit mention of possible error scenarios or volume states, but these are not essential for a basic fetch operation.

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

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

Schema description coverage is 100%; the parameter volume_id is already described with an example ('vol_…'). The description's phrase 'by its id' aligns with the schema but does not add new meaning. With full schema coverage, the baseline is 3, and the description does not compensate with extra details like format validation or related constraints.

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

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

The description precisely states a verb ('Fetch'), a resource ('a single volume's metadata and current state'), and the required identifier ('by its id'). It clearly distinguishes from sibling tenki_list_volumes (plural vs. singular) and other volume mutation tools like tenki_delete_volume or tenki_resize_volume, leaving no ambiguity about what this tool does.

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

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

The description implies usage (when you need a single volume's details), but it does not explicitly state when to choose this over alternatives like tenki_list_volumes or when not to use it (e.g., if you need to modify the volume). No explicit exclusions or alternative routing are provided, so it relies on the agent's inference from the tool name and sibling list.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive. The description adds valuable behavioral context by listing exactly what fields are returned and clarifying that idle timeout and max duration are not included here (set per sandbox). This goes beyond the annotations without contradicting them.

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 paragraph that front-loads the core purpose, then lists specifics. It is efficient and free of fluff, though a bulleted list could improve readability. The trailing clarification about per-session defaults is concise and useful.

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

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

For a read-only tool with no output schema, the description lists all returned fields and explains scope. It does not mention error cases or authentication, but given the simple input and read-only annotations, it provides sufficient context for an agent to call it correctly.

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

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

The schema describes workspace_id fully ('Workspace to read. Omit to use the API key's first workspace.'). The description adds no additional parameter information, so it relies entirely on the schema. With 100% coverage, 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?

The description begins with a clear verb ('Read') and specific resource ('a workspace's sandbox quotas and retention policy'), then enumerates exact fields. This unambiguously distinguishes it from related tools like tenki_get_workspace_usage or tenki_update_workspace_settings.

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

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

The description provides clear context: it is for workspace-level limits and explicitly notes there are no per-session defaults, which implies it is not for retrieving per-session settings. However, it does not name specific alternative tools or give explicit when-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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral nuance by specifying the 'per-second' granularity and the aggregation across all sandboxes, which are helpful details not present in the annotations.

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

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

The description is a single, front-loaded sentence that leads with the action and resource, followed by a brief purpose clause. There is no redundant or filler content.

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

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

For a simple read-only tool with one optional parameter and no output schema, the description combined with annotations and full parameter schema coverage gives an agent sufficient information to decide when and how to call it. A minor gap is the lack of any hint about the response format, but that is not essential for this tool.

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

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

Schema description coverage is 100%, and the workspace_id parameter is already documented with 'Workspace to report on. Omit to use the API key's first workspace.' The description only reinforces the workspace context without adding new parameter-level meaning beyond the schema.

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

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

The description states a specific verb and resource: 'Get per-second sandbox billing and usage figures for a workspace'. It also defines scope ('across all of the workspace's sandboxes'), distinguishing it from siblings like tenki_get_workspace_settings or tenki_get_sandbox.

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

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

The phrase 'use this for cost visibility across all of the workspace's sandboxes' provides clear context for when to call it. However, it does not explicitly name alternatives or when-not-to-use conditions, so it stops short of full exclusion guidance.

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

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

Beyond the annotations, the description reveals important runtime behavior: checkout/diff/log execute in /home/tenki, which is not a git repository, so they fail on repos in subdirectories. It also states the API rejects unsupported operations and notes that only certain operations are supported. This is substantial, operationally relevant context that the annotations alone do not provide.

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

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

The description is long but information-dense, with the core purpose and supported operations front-loaded. The caveat, workaround, and per-operation argument summaries all earn their place. It loses a point because the 'For reference' section substantially repeats the args description already present in the input schema, making the text slightly more verbose than necessary.

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

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

Given the tool's complexity, the description is highly complete: it covers supported operations, required and optional arguments, a proven failure mode, and a recommended fallback. It does not describe the return value shape (e.g., what stdout/stderr or exit codes look like), and there is no output schema to fill that gap, but the essential calling information is present.

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

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

The schema already documents the operation enum and a brief args shape, so the baseline is 3. The description adds meaning by marking `repo` and `ref` as required, clarifying value coercion, explaining `create: 'true'` as `-b`, and describing alternative diff argument forms (`base?+head?`). This is a clear improvement over the schema, though it partially repeats the schema's args description.

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 a specific verb and resource: 'Run a git operation in a sandbox.' It then clearly enumerates the supported operations (clone, checkout, diff, log) and explicitly distinguishes this tool from tenki_exec, which is the named fallback for other git commands. This makes it easy for an agent to know exactly when this tool is the right one.

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

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

Usage guidance is explicit and actionable. It names the sibling tenki_exec as the alternative for unsupported git commands, and it even provides a live-verified caveat with a concrete workaround (`git -C <directory> ...`). This goes well beyond implied usage and leaves little to inference.

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

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

Annotations already establish that this is a non-read-only, non-idempotent, non-destructive operation. The description adds useful behavioral context by noting the certificate is short-lived and access flows through the SSH gateway, but it does not disclose details such as certificate lifetime, return value, or side effects beyond issuing the certificate.

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

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

The description is a single, well-structured sentence that front-loads the core action and outcome. There is no redundant or filler content.

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

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

For a two-parameter tool with annotations and full schema coverage, the description conveys enough about purpose and mechanism for correct invocation. The lack of an output schema means the return value is not explicitly described, but this is a minor gap given the otherwise clear action and inputs.

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

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

The input schema already covers both parameters fully at 100% coverage, describing public_key as the SSH public key and session_id as the sandbox session UUID. The description restates the connection to SSH access but adds no parameter-specific 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 uses a specific verb ('Issue') with a specific resource ('short-lived SSH certificate') and states the intended outcome ('authorizing SSH access to a sandbox via the SSH gateway'). This clearly differentiates it from nearby siblings like tenki_update_ssh_keys and tenki_list_ssh_gateways.

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

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

The description gives clear context: this tool is for authorizing SSH access to a sandbox through the SSH gateway, and the 'short-lived' qualifier implies it is for temporary access rather than persistent key management. It does not explicitly name alternatives or exclusion cases, so it is one step below explicit routing guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it is a safe read operation. The description adds the 'in-progress' qualifier, which clarifies scope, but does not disclose other behaviors like return format or pagination. With strong annotation coverage, the description adds modest value beyond the structured metadata.

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

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

The description is a single, front-loaded sentence with no redundant words. It clearly conveys the action and scope without unnecessary detail, making it appropriately concise for a simple tool.

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

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

For a read-only list tool with one well-documented parameter and no output schema, the description is sufficient. It could optionally hint at the return structure (e.g., list of builds with details), but this is not essential given the tool's simplicity and annotation coverage.

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

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

Schema coverage is 100% and the parameter description already explains template_id. The tool description does not add any additional meaning beyond the schema, so it remains at the baseline for well-covered 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 states a specific action (list) on a specific resource (active builds) scoped by template_id. It is distinct from siblings like get_template_build but does not explicitly differentiate itself; however, the resource type is unique enough that an agent can infer the purpose.

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

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

The description gives clear context that the tool lists in-progress builds for a template, but it provides no explicit guidance on when to use it versus alternatives such as get_template_build or build_template. Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the behavioral trait that it filters snapshots by the non-existence of the source session, which is not captured by annotations. It also states the workspace scope. This is useful extra context beyond the structured hints.

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

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

The description is a single, efficient sentence that front-loads the verb and resource, defines 'dangling' inline, scopes to the workspace, and adds a purpose. There is no wasted wording or repetition of schema or annotation data.

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

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

For a simple list tool with two optional params and no output schema, the description captures the core behavior and purpose. Missing details include pagination behavior and explicit alternative routing, but given the safety annotations and simple schema, the description is largely sufficient. A short note on page_token/page_size and a pointer to other snapshot list tools would make it fully complete.

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

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

Schema description coverage is 0%: neither page_size nor page_token has any schema documentation. The description does not compensate by explaining these parameters or their purpose. While the names are self-explanatory for pagination, there is no detail on defaults, limits, or formatting. In a low-coverage case, the description should provide at least a mention, which it fails to do.

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

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

The description clearly states the verb 'List', the resource 'dangling snapshots', and provides an inline definition ('those whose source session no longer exists'). It also scopes to the workspace and mentions the cleanup use case, which distinguishes it from other snapshot listing tools like tenki_list_snapshots or tenki_list_session_snapshots.

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

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

The description gives a usage hint ('useful for cleanup') but does not explicitly compare with sibling snapshot-list tools or state when NOT to use this tool. An agent may still infer it from the name, but explicit guidance about alternatives like tenki_list_snapshots would improve selection.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, fully covering the safety and idempotency profile. The description adds no further behavioral context beyond restating the action—it does not mention response format, prerequisites like an active sandbox, or any edge behavior. Since annotations carry the safety burden, a score of 3 is appropriate.

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

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

The description is a single sentence of seven words, with no filler. The purpose is front-loaded and immediately clear, making it highly efficient for an agent to parse.

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

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

For a simple read-only listing tool, the description states the action, and the required parameter is fully documented in the schema. While there is no output schema, the description 'List the ports' implies the return type. The only minor gap is the lack of explicit return format, but this is not critical for a list operation.

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

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

The input schema provides a descriptive comment for session_id, including its purpose and origin. The tool description itself adds no parameter-specific details. With 100% schema coverage, the baseline of 3 is correct because the schema does the heavy lifting.

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

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

The description uses the specific verb 'List' and the resource 'ports currently exposed from a sandbox', clearly distinguishing this tool from siblings like tenki_expose_port and tenki_unexpose_port. An agent can immediately understand what is being listed and for which entity.

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

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

The description does not provide explicit guidance on when to use this tool or mention any alternative tools. The usage is implied by the verb and resource, but there is no 'use this when...' or 'instead of...' statement, leaving the agent to infer the appropriate context on its own.

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

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

Annotations already declare the operation is read-only and non-destructive. The description adds meaningful behavioral detail by disclosing that dotfiles are included by default and that include_hidden=false changes that behavior, which is not captured by the annotations alone.

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

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

The description is a single focused sentence that front-loads the core action and then clarifies the key behavioral option. No filler or 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?

For a simple read-only directory listing tool, the description covers the essential context: what is listed, where, and the hidden-file behavior. It does not describe output format or recursion, but those are not critical for correct invocation given the read-only annotations and simple scope.

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 documents all parameters. The description adds value by explaining the default behavior of include_hidden with concrete examples (.git, .env, .gitignore), going beyond the schema's basic property definitions.

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

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

The description uses a specific verb and resource: 'List a directory in a sandbox'. It further clarifies scope by mentioning dotfiles and the include_hidden flag, which distinguishes it from sibling tools like tenki_list_sandboxes and tenki_read_file.

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

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

The description clearly states the operation's context: listing a sandbox directory. It does not explicitly name alternatives or exclusion conditions, but the context is specific enough that an agent can infer when this tool is appropriate.

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

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

Annotations already cover readOnly/openWorld/idempotent, and the description adds valuable non-obvious behavior: client-side filtering that applies only to the fetched page, newest-first ordering, and pagination semantics via nextPageToken. The client-side filter caveat is especially important to prevent incorrect assumptions about server-side filtering.

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

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

Two sentences, front-loaded with the main purpose, then the session_id caveat, then pagination. Each sentence carries distinct, necessary information with no filler or repetition.

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

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

For a read-only paginated list with four optional parameters and no output schema, the description covers ordering, filtering scope, pagination tokens, and how to widen result sets. Combined with the annotations, an agent has everything needed to invoke the tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description enriches session_id by explaining the client-side scope, and it provides actionable pagination guidance for page_size and page_token. Workspace_id and bounds are already well-covered by the schema, so the description does not need to repeat 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 states a specific verb ('List'), a clear resource ('the workspace's preview URLs'), and an ordering ('newest page first'). This cleanly separates it from sibling preview URL tools like tenki_get_preview_url, tenki_create_preview_url, and tenki_delete_preview_url, making the operation 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?

Clear usage context is given: list preview URLs, optionally filter by session_id, paginate via nextPageToken, and raise page_size to widen results. It does not explicitly name alternatives or exclusion conditions, but the context is strong enough that an agent can infer when this tool is appropriate.

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

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

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds minimal behavioral context, such as workspace scope, but does not disclose pagination behavior or the effect of include_terminated beyond what the parameter schema already states. With annotations present, the score is moderate but not higher.

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

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

The description is a single, front-loaded sentence with no fluff or repetition. It is concise and easy to parse, though it could include a second sentence about pagination or sibling differentiation without becoming bloated.

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

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

Given the existence of a near-identical sibling tool and multiple parameters, the description is incomplete. It does not mention pagination, termination filtering, or return shape, and no output schema is provided. An agent selecting or invoking this tool would need to consult other sources or guess important calling conventions.

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

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

The description adds no parameter-level meaning. Schema coverage is only 33% (only include_terminated has a description), and page_size/page_token lack descriptions. The tool description does not compensate by explaining pagination, default page size, token format, or how include_terminated changes results, leaving agents to guess from parameter names.

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

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

The description states a specific verb and resource: 'List sandboxes for the workspace.' It clearly identifies the action and scope. However, it does not distinguish itself from the sibling tool tenki_list_workspace_sandboxes, which appears to describe the same operation, so it stops short of a 5.

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

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

The description provides no guidance on when to use this tool versus alternatives such as tenki_list_workspace_sandboxes or other list tools. It does not mention pagination usage, default behavior for include_terminated, or any context indicating when this list should be preferred. An agent is left to infer usage from the name alone.

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

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

Annotations already establish that this is a read-only, idempotent, non-destructive operation. The description adds no extra behavioral context such as pagination semantics, ordering, or authorization requirements beyond the obvious 'list' 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?

A single sentence communicates action, resource, and scope with no filler. The description is front-loaded and every word contributes to meaning.

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

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

The tool is simple and annotations cover the behavioral safety profile, but the description omits guidance on response shape and pagination parameters. With no output schema provided, an agent must infer these details.

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

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

Schema description coverage is only 33%, so the description must compensate for undocumented parameters. It restates the session scope, but does nothing to explain page_size or page_token, leaving those parameters semantically incomplete.

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?

Names a concrete resource ('snapshots') with an action ('List') and a clear scope ('from a specific sandbox session'). This distinguishes it from sibling tools like tenki_list_workspace_snapshots and tenki_list_dangling_snapshots.

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

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

The phrase 'from a specific sandbox session' clearly establishes the selection context: use this tool when snapshots tied to one session are needed. It does not explicitly name alternatives or when-not-to-use conditions, so it does not reach a 5.

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

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

Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), and the description adds a meaningful behavioral trait beyond them: the workspace owner is inferred from the API key, meaning no explicit owner parameter is needed. The description is consistent with the annotations and adds useful scoping context, though pagination behavior is left undisclosed.

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

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

A single 13-word sentence that is front-loaded with the action and resource, with no wasted words. The parenthetical about API-key owner inference earns its place by clarifying scoping.

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

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

For a simple read-only list operation with rich annotations, the description conveys the core purpose and scoping adequately. However, it omits any mention of pagination despite the pagination parameters, and it fails to disambiguate against the sibling snapshot-listing tools, which is a significant completeness gap in this tool-dense context.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining the two parameters, but it never mentions page_size or page_token or the pagination mechanism they imply. The parameter names are conventional enough to hint at their purpose, but the description does nothing to compensate for the missing schema documentation.

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

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

The description states a specific verb ('List') and resource ('saved snapshots') with clear workspace scoping, and adds a useful detail about owner inference from the API key. However, it does not differentiate this tool from the four snapshot-listing siblings (tenki_list_workspace_snapshots, tenki_list_session_snapshots, tenki_list_dangling_snapshots), so an agent cannot tell them apart from the description alone.

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

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

No guidance is given on when to use this tool versus the sibling alternatives. Given that tenki_list_workspace_snapshots, tenki_list_session_snapshots, and tenki_list_dangling_snapshots all exist, the description's phrase 'for the workspace' creates ambiguity rather than resolving it, and no conditions or exclusions are provided.

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

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

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds the 'currently active' scoping but does not describe return format, pagination, or gateway object fields. This is acceptable given the low-risk read-only nature, but it adds only moderate behavioral context.

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

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

The description is a single focused sentence with no filler. The verb, resource, and scope are front-loaded, making the tool's purpose immediately 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, read-only list operation with one optional parameter fully documented in the schema and safety annotations present, this description is complete. The output is self-evident from the verb 'list', and nothing essential for invoking the tool correctly is missing.

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

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

The input schema fully documents the only parameter, workspace_id, including the default behavior. The description adds no new parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('List'), a concrete resource ('SSH gateways'), a status qualifier ('currently active'), and a scope ('workspace'). This clearly differentiates it from the many sibling list tools such as tenki_list_sandboxes, tenki_list_exposed_ports, and tenki_list_volumes.

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

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

The description gives clear context: use this tool to enumerate active SSH gateways for a workspace. It does not explicitly name alternatives or exclusion conditions, but the resource is specific enough that an agent can infer when this is the appropriate tool among the sibling list operations.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds the tag-filtering semantics but does not disclose any pagination behavior or output details beyond what the schema provides.

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

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

A single concise sentence that states the primary action and the main optional modifier. Every word earns its place and the key filtering capability 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?

For a simple read-only list operation with no output schema and four optional parameters, the description is mostly complete. The main gap is page_size/page_token semantics, but the annotation set already establishes the read-only, idempotent, non-destructive safety profile, so the missing information is minor.

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

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

Schema description coverage is 50%: tags and workspace_id are documented in the schema, while page_size and page_token have no descriptions. The tool description adds 'optionally filtered by tags' which reinforces the tags meaning. However, page_size and page_token semantics remain undocumented, so the description partially compensates but not fully.

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

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

The description clearly states the verb (List), the resource (templates), and the scope (for the workspace, optionally filtered by tags). It distinguishes itself from sibling list tools like tenki_list_sandboxes or tenki_list_volumes by naming the resource explicitly.

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

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

The description implies when to use this tool: when you need to list templates, possibly filtered by tags. However, it does not explicitly state when to prefer alternatives like tenki_list_workspace_snapshots, and there is no guidance about pagination or the default workspace behavior, which the schema only partially hints at.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior, so the bar for extra disclosure is lower. The description adds useful behavioral context beyond annotations by noting the default workspace behavior and pagination support.

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

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

The description is a single, front-loaded sentence with no filler. It communicates the core action, the scope, a default behavior, and pagination in minimal words.

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

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

For a simple read-only listing tool with fully documented parameters and supporting annotations, the description is complete enough for an agent to call it correctly. No output schema is present, but the return type is strongly implied by 'list volumes.'

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

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

All three parameters are described in the schema (100% coverage), so the description does not need to compensate. The description's mention of the default first workspace and pagination adds no meaning beyond the schema descriptions already present.

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 a specific verb ('List') and identifies the resource ('persistent volumes in a workspace'), which clearly distinguishes it from sibling tools like tenki_list_sandboxes or tenki_get_volume. The parenthetical about the default workspace adds further 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 makes clear it is for listing volumes in a workspace and mentions the default workspace and pagination, giving an agent enough context to select it over volume mutation tools. It does not explicitly mention when not to use it or name alternatives, but the resource scoping is strong.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, so the safety profile is covered. The description adds the workspace default and 'every sandbox' completeness context, but does not disclose pagination behavior or result format; not a serious gap for a list 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?

One sentence front-loads the action and scope and appends a concise use case. No filler or repetition of schema 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 simple read-only list operation, the description plus rich annotations and parameter schema are sufficient to call the tool correctly. No output schema exists, so a bit more detail on the response/pagination would be welcome, but it is not essential for invoking the tool.

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

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

Schema covers workspace_id and include_terminated with descriptions; description reinforces the workspace default but adds little meaning. page_size and page_token lack descriptions, but their standard pagination semantics and the description's 'every sandbox' claim make them reasonably interpretable.

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

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

States a specific verb and resource: 'List every sandbox belonging to a specific workspace.' The workspace scope and default behavior distinguish it from the sibling tenki_list_sandboxes, so an agent can tell which listing tool to use.

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?

Provides a clear use case ('useful for spotting leaked, still-billing sandboxes across the workspace') that signals when this workspace-scoped listing is appropriate. It does not name alternatives or state exclusions, but the workspace-context is strong enough for selection.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is well covered. The description adds useful non-obvious behavior: the default workspace behavior and pagination support. This exceeds what the annotations alone communicate, though it does not detail pagination iteration mechanics.

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

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

Two short sentences with no filler. The main action is front-loaded, immediately followed by the default-workspace behavior and pagination support. Every word earns its place.

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

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

For a read-only, idempotent list operation with no required parameters and no output schema, the description covers the key usage context: workspace scope, default workspace, and pagination. It omits details like sorting or result shape, but these are not necessary for an agent to invoke the tool correctly. Slight gaps in pagination parameter semantics prevent a 5.

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 only 33%, with page_size and page_token lacking any schema description. The description merely says 'Supports pagination' without explaining how page_token works, what page_size controls, or how the two interact. With low schema coverage, the description needed to compensate but does not.

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

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

The description states a specific verb and resource: 'List all snapshots in a workspace', which clearly differentiates it from session or dangling snapshot tools. The added default-workspace behavior ('defaults to the key's first workspace') makes the scope even more concrete. It does not name sibling tools explicitly, but the workspace-scoped phrasing is enough to disambiguate.

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

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

The description gives clear context: this is for listing snapshots scoped to a workspace, and it explains that the workspace defaults to the key's first workspace. This helps an agent decide when to use this tool. It does not explicitly state when not to use it versus other snapshot-listing tools, but the workspace framing provides solid guidance.

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

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

Annotations already indicate this is a mutating, non-destructive operation. The description adds a useful mkdir -p analogy and explains recursive behavior, but it does not clarify what happens if the directory already exists, whether partial failures occur, or any permission-related behavior. It is adequate for a simple mkdir 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 short sentences with no filler. The core operation is front-loaded, and the recursive behavior is explained in one clear clause. Every word earns its place.

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

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

For a simple 3-parameter tool with no output schema, the description provides enough context: what it does, where it applies, and the one edge case that matters. Minor details like behavior on existing directories or failure modes are not covered, but the schema and annotations fill most practical gaps.

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

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

Schema coverage is 100%, and the schema already describes all three parameters, including the recursive behavior and the path under /home/tenki. The description only restates the recursive concept with the mkdir -p analogy, adding little semantic value beyond the schema.

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

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

The description states a specific action ('Create a directory') and a clear target ('in a sandbox'), which immediately distinguishes it from file manipulation siblings like read, write, remove, and move. It also mentions the recursive flag, so an agent can tell exactly what the tool does without opening the schema.

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

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

The description clearly establishes the use case: creating a directory in a sandbox, with the recursive option covering missing parent directories. It does not explicitly list alternatives or exclusions, but the tool's purpose is narrow and unambiguous given the sibling set.

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

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

Annotations already indicate a mutating, non-idempotent operation, so the description carries a lower burden. Even so, it adds no behavioral details beyond the path scope that is already present in the schema. It does not mention overwrite behavior, failure modes, whether the operation is atomic, or what happens if the destination exists.

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 only two short sentences, with the primary action front-loaded and no filler. Every word contributes either to stating the operation or essential path constraints.

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 move/rename operation the description is mostly sufficient given the schema coverage. However, it omits details about destination conflicts, whether existing files are overwritten, and what result the agent should expect, leaving some ambiguity for correct invocation in edge cases.

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

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

Schema description coverage is 100%, so all three parameters are already well documented in the input schema. The description restates the '/home/tenki' constraint but adds no new parameter-level meaning, making the baseline 3 appropriate.

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

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

The description clearly states the action ('Move or rename') and the resource ('a file or directory within a sandbox'), with the path scope '/home/tenki' adding precision. It does not explicitly differentiate from sibling file operations, but the verb+resource is specific enough for basic disambiguation.

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 usage is implied by the verb 'Move or rename' and the stated sandbox scope Mendatory. However, there is no explicit guidance about when to use this tool instead of alternatives like tenki_write_file, tenki_remove_path, or a copy operation, and no exclusions are provided.

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

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

Goes beyond annotations by disclosing the live-verified URL failure for ports other than 7681 and clarifying that the viewerToken still resolves via tenki_resolve_preview_token. Also notes the require allow_inbound prerequisite. This adds significant behavioral context not in the annotations.

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

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

Three sentences with no filler. The main purpose is front-loaded, and the warning is placed immediately after, making it easy to scan. Every sentence provides necessary information.

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

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

For a tool with a specific failure mode and token behavior, the description covers the essential caveats, the prerequisite, and the token resolution. Given the schema documents parameters and no output schema is present, the description is sufficiently complete 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?

Schema description coverage is 100%, so the parameters are fully documented in the schema. The description adds little beyond the schema, except for the allow_inbound prerequisite which is not a parameter. 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?

States a specific action (open a viewer-token-gated preview) and distinguishes itself from sibling tools (tenki_expose_port, tenki_create_preview_url) by explaining it is for AUTHENTICATED-mode previews. The verb 'open' and resource 'preview' are 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?

Explicitly instructs when NOT to use this tool and provides alternatives: 'USE tenki_expose_port OR tenki_create_preview_url INSTEAD for an ordinary web server.' Also gives a concrete reason (non-7681 ports return a fallback host that 404s), so an agent can decide correctly.

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

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

Annotations already indicate this is a non-read-only, non-destructive operation. The description adds specific behavioral detail by stating that it snapshots and suspends the sandbox, making the state change understandable. It does not mention side effects like billing or process behavior, but the disclosed snapshot+suspend behavior is meaningful and not contradicted by the annotations.

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

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

A single, compact sentence that front-loads the action and resource, then explains the mechanism and lifecycle intent. There is no wasted wording or redundancy.

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

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

For a simple one-parameter lifecycle tool, the description plus schema and annotations cover what the agent needs: what the tool does, that it is non-destructive, and where to obtain the session_id. No output schema exists, and the description adequately conveys the relevant state change.

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 session_id parameter is already well documented in the schema, including its source from tenki_create_sandbox or tenki_list_sandboxes. The tool description itself does not add parameter-level guidance, but it does not need to because the schema already carries that weight.

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

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

The description names a specific verb ('Pause'), a specific resource ('sandbox'), and the concrete mechanism ('snapshot + suspend'). It also conveys the lifecycle intent ('so it can be resumed later'), which clearly distinguishes it from terminate, resume, or standalone snapshot 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 gives clear context: use this when you want to temporarily suspend a sandbox while preserving its state for later resumption. It does not explicitly name alternatives or exclusions, but the intent is clear enough that an agent can select this over terminate_sandbox or create_snapshot.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds useful constraints: only UTF-8 text files and only paths under /home/tenki, which imply that binary files or other paths may fail.

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

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

One short, front-loaded sentence with no filler. The key verb, object, and path constraint are immediately 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 2-parameter read operation, the description plus schema covers what an agent needs: session-derived sandbox context, path restriction, and file type. No output schema exists, but 'read a file' adequately implies returning content.

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

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

Schema description coverage is 100%, so both params are already documented. The description restates the sandbox path restriction but does not add new semantic detail beyond the schema.

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

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

States a specific action (read), a resource (UTF-8 text file), and an explicit scope (sandbox under /home/tenki). It clearly distinguishes itself from sibling tools like tenki_list_files and tenki_stat_path.

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?

Provides clear context: this reads files only within the sandbox path. It does not explicitly mention alternatives or when not to use it, but the action and path constraint make the usage context clear.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, and the description builds on this by specifying recursive removal of non-empty directory contents, matching rm -r behavior. It clarifies what gets destroyed without contradicting annotations, though it doesn't mention error cases or irreversibility beyond the existing destructive hint.

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

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

Two short, focused sentences: the first states the primary action, the second clarifies recursive behavior. No filler, no repetition of schema details, and the key 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?

For a three-parameter delete tool with full schema coverage and destructive annotations, the description is sufficient. It covers the operation, sandbox scope, and recursive semantics; no output schema exists, so return values are not expected. It could mention behavior on missing paths, but that is not essential 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?

Schema coverage is 100%, providing baseline 3. The description adds the 'non-empty directory' qualifier and the rm -r analogy, which clarifies when recursive is required beyond the schema's 'Remove a directory and its contents (default false)'.

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 a specific verb 'Delete' and resource 'file or directory in a sandbox', distinguishing it from sibling tools like tenki_read_file, tenki_write_file, tenki_move_path. The 'rm -r' analogy further reinforces the deletion semantics.

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

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

The description implies usage as the deletion tool for sandbox filesystem paths but does not explicitly state when to use it versus alternatives such as tenki_move_path or executing rm via tenki_exec. It lacks when-not guidance or exclusion conditions, leaving usage inference to the agent.

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

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

Annotations already signal non-readonly, non-idempotent behavior. The description adds valuable context beyond that by explaining the keep-alive heartbeat mechanism and the consequence of preventing idle reaping. There is no contradiction with the annotations.

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

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

A single front-loaded sentence with no filler: action, resource, purpose, and consequence are all present. Every clause 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 one-parameter heartbeat tool with no output schema and annotations covering the side-effect profile, the description gives the agent enough to call it correctly. No critical information is missing.

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

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

Schema description coverage is 100% and already explains session_id as 'The sandbox/session ID to mark as active.' The tool description does not add extra parameter semantics, so the baseline 3 applies.

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

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

The description names a specific verb and resource ('Report client-side activity on a sandbox') and states the operational effect ('reset its idle timer and keep it from being reaped as idle'). This clearly differentiates it from lifecycle/read/list 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?

It gives a clear context for use: report client-side activity to reset the idle timer and prevent idle reaping. It does not explicitly name alternatives like tenki_extend_sandbox or state when not to use it, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, covering the write and non-destructive nature. The description adds the critical behavioral constraint that volumes can only grow, not shrink, which is not in the annotations. It also gives the exact size range, providing useful context beyond the structured metadata.

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

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

The description is two sentences with zero fluff. The action and primary constraint are front-loaded in the first sentence, and the size range is stated efficiently. It is an exemplary model of conciseness for a simple tool.

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

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

For a two-parameter mutation tool with annotations covering safety, the description provides the essential behavioral constraint (grow-only) and the size range. It does not explain prerequisites like volume state or synchronous behavior, but these are not critical for basic usage. It is largely complete for the tool's simplicity.

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

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

The schema has 100% description coverage, with both volume_id and size_bytes fully described including the size range. The description repeats the range in prose but adds no new semantic information. Since the schema carries the full parameter documentation, 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 action: 'Grow a volume to a new size in bytes' – a specific verb and resource. It also includes the size range and the explicit constraint 'Volumes can grow but not shrink,' which precisely defines the operation and distinguishes it from any shrink behavior. This leaves no ambiguity about what the tool does.

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

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

The description implies when to use it: when you need to increase a volume's size. It also gives a clear when-not condition with 'can grow but not shrink,' indicating it should not be used for shrinking. However, it does not explicitly mention alternative tools like tenki_update_volume for other volume property changes, so it lacks routing 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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description does not need to restate safety. It adds the conceptual output, sandbox/port, but provides no additional behavioral details such as token validation behavior, error cases, or response format. No contradiction exists.

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

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

The description is one sentence with no filler; it front-loads the verb and object and adds only a brief 'advanced' caution. This is appropriately sized for a single-parameter resolver tool.

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

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

For a one-parameter, read-only, idempotent tool, the description is largely sufficient: the input is unambiguousainer, side effects are covered by annotations, and the result type is described at a conceptual level. It falls short of full completeness because there is no output schema and the exact structure of the resolved sandbox/port is unspecified.

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 token parameter is already clearly described as 'The preview token to resolve'. The prose description adds no extra details about token format, constraints, or interpretation.

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

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

The description states a specific action, 'Resolve', and a specific resource, 'preview token', and clarifies the result as 'the sandbox/port it points at'. It is not tautological and clearly identifies a distinct read-only lookup, though it does not explicitly name or differentiate sibling preview 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 intended use is implied: an agent would call this when it has a preview token and wants to know where it points. However, there is no explicit guidance on when to prefer this tool over related preview tools such as tenki_get_preview_url or tenki_open_preview, and the parenthetical 'advanced' is only a weak contextual hint.

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

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

The annotations already signal that this is a non-read-only, non-destructive, non-idempotent operation, so the description does not need to restate that. The only additional behavioral context is the state precondition 'previously paused'; side effects such as billing, resource allocation, or failure modes are not disclosed.

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

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

The description is a single, short sentence with no filler or redundant information. The key precondition, 'previously paused,' is stated directly and early, making it appropriately sized for a one-parameter state-transition tool.

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

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

For a simple tool with one fully documented parameter and annotations covering safety and mutation traits, the description provides the essential invocation condition. It does not describe return values or error behavior, but the operation can be selected and invoked correctly from the given text.

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

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

The input schema already provides 100% parameter description coverage, including that session_id is a UUID from tenki_create_sandbox or tenki_list_sandboxes. The description adds no parameter-level detail, but the schema carries the burden sufficiently.

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

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

The description uses a specific verb, 'resume,' and identifies the resource, 'sandbox,' while adding the scope 'previously paused,' which separates it from create, pause, terminate, and list operations. It is unambiguous, though it does not explicitly name a sibling alternative.

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

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

The phrase 'previously paused' implies that this tool is appropriate only for sandboxes currently in the paused state, which gives some usage direction. It does not explicitly state when not to use it or mention alternative tools like tenki_get_sandbox or tenki_pause_sandbox.

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

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

Annotations only declare non-read-only, non-idempotent, non-destructive, open-world. The description adds genuinely new behavioral context: cost-guard, self-termination, sandbox teardown, per-stream head+tail truncation over ~64KB, and the fact that the sandbox is unrecoverable afterward. No contradiction with annotations.

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

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

Four sentences, each earning its place: core lifecycle, cost/safety note, usage guidance with alternative, and the truncation caveat. The most important action verb is front-loaded, and there is no filler or repetition of schema content.

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

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

With no output schema, the description covers the return values (stdout/stderr/exit code), the key behavioral limits (truncation, self-termination), and the routing to a persistent alternative for large outputs. For a one-shot execution tool with a 100%-covered schema, nothing an agent needs to call and interpret it is missing.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the schema. The description merely echoes the allowed languages ('shell/python/javascript') and the default timeout without adding meaning beyond what the schema's property descriptions already provide. 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 names a specific verb+resource: boot a throwaway microVM, run a snippet, return stdout/stderr/exit code, and tear it down. It also explicitly distinguishes itself from the persistent sandbox flow (tenki_create_sandbox + tenki_exec), so an agent can tell it apart from siblings without opening schemas.

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 states exactly when to use this tool ('one-shot execution when you don't need a persistent sandbox') and when not to ('for large output use tenki_create_sandbox + tenki_exec and page through the retained file'). The alternative is named explicitly with the condition that selects it.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds useful behavioral context by specifying exactly which metadata fields are returned and positioning the tool as an existence/inspection helper before mutation operations. It does not describe behavior for missing paths, but the annotations lower the burden here.

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 compact two-sentence structure with no filler. The first sentence front-loads the purpose and return type, and the second sentence gives actionable usage guidance. Every word earns its place.

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

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

For a simple stat operation with only two fully documented parameters and strong safety annotations, the description is nearly complete: it names the metadata fields, the sandbox scope, and the intended use case. Minor gaps remain, such as how a nonexistent path is reported, but nothing critical prevents 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?

Schema description coverage is 100%, so both parameters are fully documented in the input schema: path is an absolute path under /home/tenki and session_id is a sandbox UUID. The description adds no parameter-level detail beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description states a specific verb ('Get metadata') and a precise resource ('a file or directory in a sandbox'), naming the data returned: size, mode, type, timestamps. This clearly distinguishes it from siblings like tenki_read_file, tenki_list_files, or tenki_remove_path by focusing on metadata and existence checks rather than content operations.

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

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

The description explicitly tells an agent when to use this tool: 'Use to check whether a path exists or inspect it before reading/removing.' This provides clear context, though it does not name alternative sibling tools or state explicit exclusion cases such as 'use read_file if you need file contents.'

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