CitadelHosts

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

With no annotations provided, the description carries the full burden and does so well: it enumerates the complete state machine with semantic meaning for each state, marks which states are terminal, and prescribes the recovery action per state. This is behavioral context an agent could not get from the schema or 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?

Front-loaded with the core purpose and the return token, then the state glossary, then the polling instruction. Dense but every clause is informative; the only mild redundancy is restating return values that an output schema already declares, though the semantic annotations on each state still earn their place.

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

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

For a simple one-parameter status tool with an output schema, the description supplies everything needed to interpret and act on the result, including the state transitions and next-step routing. Nothing required for correct invocation or interpretation 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 0% and the description never mentions managed_app_id — not its expected format, nor where to obtain it (e.g. list_apps). The single required integer parameter is largely self-describing by name, which keeps this from being a severe gap, but the description adds no meaning beyond the schema.

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

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

States a specific verb (check) and resource (managed status of an application) and distinguishes itself from siblings like get_app_details, get_app_logs and get_app by returning only a status token rather than config or logs. An agent can route to it without opening any 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?

Gives concrete when-to-use guidance for edge states: restart with start_app when Stopped, check get_app_logs then restart when Unknown, and poll Queued/Created until Running or terminal. It stops short of an explicit when-not-to-use statement (e.g. use get_app_details for full config), so it is strong but not exhaustive.

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

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

No annotations are provided, so the description carries the full disclosure burden. It says nothing about required permissions, whether deployment is asynchronous, what happens on duplicate deploys, or whether the app is started automatically. The only behavioral hint is that the array arguments are optional-in-practice, which overlaps with parameter semantics rather than tool 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?

Three short sentences, each doing distinct work: the action, the id-source routing, and the optionality guidance. Front-loaded with the core verb and resource, 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?

This is a mutating, multi-argument deployment tool with no annotations and no output schema, so the description should say more than it does. It omits return/result expectations, async or timing behavior, failure modes, and the meaning of the three array parameters, leaving real gaps for an agent deciding how to invoke 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?

Schema description coverage is 0%, so the description must supply all parameter meaning. It explains application_id's dual source well, but territory_id is never described, and mount_points, deploy_settings and configurable_env_vars are lumped together as "advanced arrays" with no indication of what each configures. Only one of five parameters is genuinely clarified.

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

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

The first sentence gives a specific verb and resource ("Deploy a managed application onto a territory"), which is clearer than most siblings. It also disambiguates the application_id argument by naming the two id sources (catalog via list_available_apps vs. custom via create_custom_app). It does not, however, distinguish deployment from adjacent lifecycle siblings like start_app or get_app_definition.

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

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

Two useful triggers are implied through sibling references: use list_available_apps to obtain a catalog id and create_custom_app to obtain a custom definition id. The closing sentence also advises omitting the advanced arrays unless needed. There is no statement of when to choose this over start_app/check_app_status or what prerequisites must hold before deploying.

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

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

No annotations are provided, so the description must carry the behavioral burden. It says it schedules automatic backups, but does not disclose permissions, timing, what happens on creation, or how retention works via keep_last.

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

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

The description is a single front-loaded sentence with no wasted words. It is appropriately concise, though its brevity contributes to gaps covered in other dimensions.

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

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

For a three-required-parameter mutation tool with no annotations and no output schema, the description is too thin. It does not explain required inputs such as keep_last, nor does it describe scheduling behavior or return expectations.

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

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

Schema description coverage is 0%, and the description only vaguely maps app_id and frequency by mentioning an app and scheduling. It does not explain keep_last, retention semantics, or the frequency options beyond the enum values in the schema.

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

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

The description states a clear verb+resource: "Schedule automatic backups for an app." An agent can understand the core action, though it does not explicitly distinguish this from siblings like list_backup_tasks or restore_backup.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 no explicit when-to-use guidance, prerequisites, or alternatives. The only implied usage is that it creates a backup task for an app, with no mention of when other backup-related tools should be selected instead.

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

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

With no annotations, the description carries the full burden and does disclose non-obvious behavior: is_custom defaults to true (registry image), the image reference format differs per mode, exactly one port must serve traffic, volumes persist data at container_path, and env_vars function defaults to TEXT. It stops short of stating permissions, idempotency, or what happens on a name collision, so it is strong but not complete.

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

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

Purpose is correctly front-loaded, but the body is a dense run-on paragraph that jumbles prerequisites and per-field semantics together. It also near-verbatim repeats the schema's own image description ('repo:tag' vs fully-qualified public image), which spends words without adding new value.

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

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

For a moderately complex nested tool with no annotations and no output schema, the description covers the registration workflow, image sourcing modes, port/volume/env_vars semantics well enough to call it correctly. Missing only the return value and collision/permission behavior.

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

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

Top-level schema descriptions are absent (reported coverage 0%), but the description compensates well by explaining the image reference format for both is_custom modes, the single-traffic-port constraint, container_path volume semantics, and the env_vars TEXT default. It does not explain the top-level 'name' or 'description' fields, but those are largely self-evident.

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

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

States a specific verb+resource: 'Register a custom application definition from the user's own Docker images', and explicitly positions it upstream of the sibling create_app ('so it can be deployed with create_app'). An agent can distinguish this registration step from deployment without opening either 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?

Gives an explicit ordered workflow and prerequisite chain: push images first via get_registry_credentials, tag/push as <registry>/<app-name>:<tag>, then verify with list_custom_images. It names the downstream alternative (create_app) and the verification sibling (list_custom_images), leaving nothing 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?

No annotations are provided, so the description carries the full behavioral burden for a mutation tool. It notes the size_limit unit, but does not disclose permissions, side effects, billing implications, persistence, or constraints on volume creation.

Agents need to know what a tool does to the 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 short sentences and front-loads the core action. There is no wasted language, though its brevity leaves important gaps rather than creating clutter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 mutating tool with no annotations, no output schema, and no schema parameter descriptions, the definition is not complete enough. It omits crucial information about permissions, creation behavior, return values, and parameter constraints.

Complex tools with many parameters or behaviors need more documentation. 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 should compensate for three required parameters. It only clarifies that size_limit uses GB; it adds no meaning for name or ssd_or_hdd beyond the enum values already in the schema.

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

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

The description states a specific verb and resource: "Create a standalone storage volume." The word "standalone" hints at differentiation from managed volumes, but the description does not explicitly name a sibling or spell out when this is preferable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 says what the tool creates but gives no guidance on when to use it versus alternatives such as list_managed_volumes or create_app. There are no exclusions, prerequisites, or usage conditions.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose one important side effect: 'Starts billing.' That is genuinely useful beyond structured data. However, it says nothing about required permissions, cost magnitude or billing cadence, whether the action is reversible (delete_territory exists but that link is unstated), or what happens on failure.

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

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

Three short sentences with no filler. The core action is front-loaded, and the enum mapping and billing side effect follow in priority order. Every clause carries information the agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 creation call it covers the parameter fully and flags billing, but with no annotations and no output schema the description still omits auth requirements, cost expectations, and whether a territory identifier or status is returned. Adequate but with clear gaps for a billed mutation.

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

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

Schema description coverage is 0% and the single parameter 'index' is opaque from the schema alone, yet the description fully maps both enum values to names and CPU sizes ('1 = Watchtower (1 CPU), 2 = Stronghold (6 CPU)'). This completely compensates for the missing schema documentation for the only parameter.

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

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

The first sentence gives a specific verb plus resource ('Create a new territory'), which is unambiguous and clearly distinct from delete_territory, rename_territory, and list_territories in the sibling set. It does not explicitly name a sibling to differentiate against, but the create verb alone separates it from the read/modify territory tools.

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

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

The description implies the usage context by defining the two territory tiers, so an agent can decide which variant to request, but it never states when creating a territory is appropriate versus other tools, nor any prerequisites such as billing state or quota limits. Guidance is implied through the enum explanation rather than stated as workflow advice.

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

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

With no annotations, the description carries the full burden. It usefully discloses two behavioral traits: the destructive nature and the billing side effect. However it omits irreversibility, required permissions, and whether dependent resources (e.g. apps tied to the territory) are affected.

Agents need to know what a tool does to the 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, action front-loaded with the consequence and the destructive marker trailing. Every word earns its place with zero 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 one-parameter delete tool with no output schema and no annotations, the essentials (what it deletes, billing impact, destructive flag) are present. It still leaves irreversibility and dependent-resource behavior unstated, which matters for an irreversible mutation.

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

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

Schema description coverage is 0% and the sole parameter territory_id is undocumented in both schema and description. The parameter is only inferable from the tool name, so the description adds no real semantic meaning beyond what the identifier implies.

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

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

States a specific verb+resource ('Delete a territory') and adds the billing consequence. It is clearly distinguishable from siblings like create_territory, rename_territory, and list_territories without opening a schema, though it does not name them 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?

No when-to-use guidance, no preconditions, and no mention of alternatives. The agent is not told when deletion is appropriate versus, say, rename_territory or get_territory_status, nor whether confirmation is required.

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

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

No annotations are provided, so the description carries the full burden. It discloses the return payload shape and maps 'status' to the PascalCase enum shared with check_app_status, which is genuine behavioral context, but it says nothing about error behavior (e.g. unknown id), permissions, or whether the read is side-effect free.

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

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

Front-loaded with the core action and return scope, then a routing note. The parenthetical field list is dense but earns its place as a preview of the payload; nothing is wasted.

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

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

With no output schema and no annotations, the description steps in to describe the returned record and the status enum, which is exactly what an agent needs to interpret results. It stops short of covering failure modes, but the essential gaps are filled.

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

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

Schema description coverage is 0% and there is a single required integer, managed_app_id. The description only says 'by id', which restates the parameter name without adding format, source, or lookup guidance, so it does not compensate for the documentation 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?

States a specific verb and resource ('Get the full application record by id') and enumerates the returned sub-fields (container instances, mount points). It also explicitly distinguishes itself from check_app_status and get_app_details, so an agent can pick it apart from siblings without reading any 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?

Gives a clear routing rule: use get_app_details for resource usage instead. It also implicitly separates itself from check_app_status by scoping this tool to the full record. No explicit 'when not to use', but the alternative is named with its selecting condition.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the 404 outcome for non-owned custom definitions, which is real behavioral context. It does not state whether the call is read-only, what auth is required, or anything about caching/rate limits, leaving meaningful gaps for a tool with zero annotation coverage.

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

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

Two tightly packed sentences, front-loaded with purpose and then the access constraint. No filler or redundancy; 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?

No output schema and no annotations, so the description must stand in for them, and it does reasonably well by naming the returned fields and the visibility/404 behavior. It is not fully complete for a resource-fetch tool (no note on auth, id provenance, or error cases beyond 404), 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 coverage is 0% and the sole 'id' parameter is an untyped-by-description integer. The phrase 'by id' only weakly maps the parameter to the application-definition identity; it adds no format, range, or source guidance (e.g., where the id comes from). Minimal value over the bare schema.

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

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

States a specific verb ('Get') and resource ('an application definition') and even enumerates the returned content (containers, ports, volumes, env vars), which is genuinely informative. It does not, however, distinguish itself from near-neighbor siblings such as get_app, get_app_details, or get_app_link, so an agent must infer the boundary.

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

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

The visibility rule ('catalog definitions are shared; custom definitions are visible only to the user who created them (404 otherwise)') is a useful precondition for when this call will succeed versus fail. There is no explicit guidance on when to prefer this over get_app/get_app_details, so 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?

No annotations are provided, so the description bears the full burden. 'Get' and 'usage summary' imply a safe read, and the returned fields are disclosed, but it says nothing about permissions, aggregation windows, freshness of the CPU/memory figures, or cost of the call.

Agents need to know what a tool does to the 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 tight sentences: the scoping summary first, the disambiguation to get_app second. Every clause earns its place and the most decision-relevant 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?

With no output schema, the description usefully enumerates what comes back, covering the main completeness gap for a read tool. Only the input identifier and permission/refresh semantics remain unexplained.

Complex tools with many parameters or behaviors need more documentation. 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% and the single parameter (managed_app_id) has no schema description. The description never mentions the identifier, its format, or how to obtain it, so it adds no semantic value over the bare integer property.

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

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

States a specific verb ('Get') and resource (usage summary for a managed application) and enumerates the returned fields (app name, auth flag, CPU/memory usage, per-container and per-volume storage), which clearly separates it from the fuller get_app record.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 names the alternative sibling ('For the full record ... use get_app') and gives the condition that selects it, so an agent can route between the summary and full-record tools without opening either schema.

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

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

With no annotations, the description carries the full burden, and it does disclose one genuine behavior: app_link is null when the app publishes no port, which tells the agent not to treat null as an error. It omits other relevant traits such as whether the app must be running, permission requirements, or what happens for a not-yet-deployed app.

Agents need to know what a tool does to the 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 tight sentences: the purpose and audience are front-loaded, and the null/edge-case note follows. Every clause 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 one-parameter getter with no output schema, the description covers the essential return contract (public URL, or null when no port is published). What is missing is the precondition context — deployment/running state and whether unauthorized callers get an error — but the core is sufficient to call the tool.

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

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

Schema description coverage is 0% and the single required parameter managed_app_id is never explained in the description — no format, no source of the id, no relation to sibling tools that also take an app id. The schema name is self-evident, but the description provides no compensation for the documentation gap as required at low 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?

Specific verb+resource (get the public URL of a deployed managed application) plus the returned field name, so the agent knows exactly what comes back. It is distinguishable from list_apps or get_app_logs by its output, but it never explicitly contrasts itself with the close siblings get_app / get_app_details / get_app_definition, which all target the same app id.

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

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

Usage is only implied by the clause 'so it can be shared with the user', which hints this is for surfacing a link to an end user. There is no explicit statement of when to call this instead of get_app_details or get_app, and no stated prerequisites (e.g., app must be deployed/running).

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

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

With no annotations, the description carries the full burden. It does disclose a meaningful behavioral trait—that it samples only ~4 seconds of logs—and the default container behavior. But it says nothing about auth/permissions, output volume limits, or whether lines are truncated, leaving mutation/read safety and result-shape context 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?

Three short sentences, front-loaded with the core capability, then the sampling behavior, then the parameter guidance. 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 two-parameter read tool with no annotations and no output schema, the description covers purpose, sampling semantics, and the one ambiguous parameter. The main remaining gap is any indication of what the returned log lines look like or their volume, but overall it is sufficient to invoke correctly.

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

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

Schema description coverage is 0%, so the description must compensate, and it does for the non-obvious parameter: container_select is explained as a managed_container_id with a cross-reference to get_app_details and a documented default. Only managed_app_id is left to inference, which is reasonable given the name and sibling naming conventions.

Input schemas describe structure but not intent. Descriptions should explain 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: 'Capture recent container log lines for an app.' No sibling tool in the provided list retrieves logs, so the agent can immediately distinguish this from the get_app_*/list_* family.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 implicit context (log retrieval for a given app) and one useful operating instruction—omit container_select to target the app's first container. However, it offers no explicit when-to-use/when-not guidance or named alternatives among the sibling tools.

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

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

No annotations are provided, so the description carries the burden. It discloses the unit (cents USD) and that the balance is user-scoped, which is genuinely useful, but it says nothing about permissions needed, currency edge cases, or whether a zero/negative balance is possible.

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

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

A single short sentence with the resource front-loaded and the unit appended; no filler, nothing to trim.

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

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

With no output schema and no annotations, the description is the only source of return-value information, and it only reveals the unit, not the shape (e.g., whether it returns a bare number or an object). Adequate for a trivial read but leaves a real gap.

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

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

The tool takes no parameters, which is the baseline-4 case; the description correctly implies nothing needs to be supplied beyond the implicit user context.

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

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

Specific verb (get) plus a precise resource (credit wallet balance) with the unit disclosed as cents USD. It is clearly distinct from the sibling get_payment_status, though it never explicitly contrasts with it.

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

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

Usage is only implied by the name: retrieve the wallet balance. There is no statement of when to use this versus get_payment_status, no prerequisites (e.g., auth/account context), and no exclusions, but for a zero-parameter read the ambiguity is low.

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

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

With no annotations provided, the description carries the full behavioral burden and does not meet it. It does not say whether this is a read-only lookup (implied but unstated), what authentication or scope is required, what the result looks like, or how it behaves when no payment method 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?

A single ten-word sentence that front-loads the verb and the exact condition, with no filler or redundant restatement of the tool name.

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

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

For a zero-parameter lookup this is nearly sufficient, but with no output schema the description should state what is returned — a boolean, or the possible status values the name implies. As written, an agent cannot tell whether the response is a bare true/false or an enumerated status.

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

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

The tool takes zero parameters, so there is nothing for the description to explain; the baseline of 4 applies. Schema coverage is reported at 100% with an empty properties object.

Input schemas describe structure but not intent. Descriptions should explain 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 pairs a specific verb ("Check") with a specific condition ("whether the user has a payment method on file"), so an agent knows exactly what is being answered. It does not, however, distinguish this from the adjacent get_billing_balance sibling, and the narrowing from the name "get_payment_status" to just "payment method on file" leaves mild scope ambiguity.

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

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

The description states what is checked but gives no when-to-use guidance, no prerequisites, and no exclusions relative to get_billing_balance or the other status-checking siblings. Usage is only inferable from the wording.

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

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

With no annotations, the description carries the full behavioral burden. It discloses key traits: the password is the caller's own API token, restricted to read_write keys, compatible with docker/podman/skopeo login and CI, and image paths are automatically scoped to the account. Missing details like token expiry or rate limits keep it from a 5.

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

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

Three sentences, front-loaded with the primary action, then authentication constraints, then downstream usage. Every clause adds actionable value 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 zero-parameter tool with no output schema and no annotations, the description supplies credential nature, compatibility, scoping behavior, and the create_custom_app handoff. It omits the exact shape of returned instructions and token expiry details, but is largely complete 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 tool takes 0 parameters, so there is no parameter semantics to document; baseline 4 is appropriate. The description adds no meaningful parameter information because none exists.

Input schemas describe structure but not intent. Descriptions should explain 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 Docker registry login credentials and step-by-step instructions for pushing custom images') and clearly distinguishes itself from siblings like list_custom_images or create_custom_app. An agent can identify the tool's output without opening any 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?

It explains the authentication caveat ('read_write keys only'), compatibility targets ('docker/podman/skopeo login and in CI'), and the downstream workflow with create_custom_app ('reference them in create_custom_app as <app-name>:<tag> with is_custom true'). It lacks an explicit when-not-to-use statement but provides strong contextual routing.

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

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

With no annotations at all, the description carries the full behavioral burden, and it does disclose the meaningful state semantics: Queued means provisioning and cannot host apps, Active means ready to host, Deleted is terminal with billing stopped. It does not cover failure behavior (unknown/invalid territory_id), permission requirements, or that this is a non-mutating read, leaving some gaps.

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

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

Two tight sentences, front-loaded with the action and followed immediately by the return-value breakdown. Every clause earns its place with no filler.

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

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

An output schema exists, so return values were already covered, yet the description helpfully augments them with lifecycle meaning. For a low-complexity single-parameter lookup this is nearly sufficient; only the origin of territory_id and error/edge-case behavior are 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 0% for the single required territory_id, so the description must compensate, and it does not. It never explains what a territory_id is, its format, or that it can be obtained from list_territories; 'one territory' adds essentially nothing beyond the parameter 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 a specific verb+resource ('Get the status of one territory') and the singular scope implicitly separates it from the list_territories sibling. It is clear and unambiguous, but it never explicitly names the contrasting sibling or the bulk alternative, so it stops just short of the top mark.

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

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

Usage is only implied by the verb 'Get' — the agent can infer this is the lookup for a single territory's lifecycle state. There is no statement of when to prefer it over list_territories, no prerequisites (e.g., where territory_id comes from), and no exclusions.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Forcefully kill' implies abrupt termination with no graceful shutdown, but the description does not state whether this causes data loss, what happens to attached volumes/backups, whether it is reversible, or what permissions are needed for a destructive operation.

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

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

A single short sentence with the destructive action front-loaded and zero filler. It is efficient, though the brevity is partly under-specification rather than disciplined conciseness.

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

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

For a destructive one-parameter tool with no annotations and no output schema, the description omits nearly everything an agent needs: how to obtain the managed_app_id, when this beats stop_app, and what side effects to expect. The minimal schema is not enough to compensate.

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

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

Schema description coverage is 0% and the single parameter is fully undocumented. The description only implies the ID refers to a 'managed application', which is marginal help in distinguishing it from custom apps in the sibling set; no format, source, or validity constraints are given.

Input schemas describe structure but not intent. Descriptions should explain 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 ('kill') and resource ('running managed application'), which is clearly distinguishable from read-oriented siblings like get_app or list_apps. However, it never names or contrasts with the closest sibling stop_app, leaving the kill-vs-stop distinction to inference.

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

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

There is no when-to-use guidance, no alternatives named, and no preconditions given. With stop_app in the sibling set, an agent would reasonably wonder which termination tool applies; the single word 'forcefully' is the only hint that this is an escalation path.

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

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

With no annotations provided, the description carries the full behavioral burden. It usefully discloses that the 'status' field uses PascalCase values sourced from check_app_status, but says nothing about read-only semantics, permissions, pagination, or result size.

Agents need to know what a tool does to the 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 tight sentences, purpose front-loaded, and the second sentence earns its place by clarifying the encoding of the status field an agent will encounter in results.

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

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

For a zero-parameter list tool with no output schema and no annotations, the description covers the core purpose and one output nuance, but omits return structure beyond 'status' and any pagination or auth context an agent might need.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly adds no parameter semantics because there are none to explain.

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

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

The description gives a specific verb and resource ('List all managed applications') plus scope ('across the user's territories'), which implies a distinction from the sibling list_available_apps. It stops short of explicitly contrasting the two, so the differentiation is inferred rather than stated.

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

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

There is no when-to-use guidance, no prerequisites, and no explicit routing to alternatives such as list_available_apps or get_app. The reference to check_app_status explains status values, not when to call this tool.

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

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

With no annotations, the description carries the full behavioral burden and discloses very little. It does not say whether the catalog is filtered by account, territory, or subscription, whether results are paginated, or whether any permission is required to enumerate deployable apps.

Agents need to know what a tool does to the 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. It is sized appropriately for a zero-parameter list tool, though it is arguably too terse to be maximally 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, parameterless tool with no output schema, the description is minimally adequate but omits what the catalog contains (app definitions, versions, availability scope) and whether the result set is bounded. These gaps matter less here than for a mutation tool.

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

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

The tool takes no parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter-related gaps exist.

Input schemas describe structure but not intent. Descriptions should explain 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 specific verb ("List") and resource ("application catalog") and adds the scoping qualifier "available to deploy". This hints at how it differs from the sibling list_apps, but the distinction is left implicit rather than stated.

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

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

There is no when-to-use guidance and no mention of the closely related siblings list_apps, get_app, or get_app_definition. The phrase "available to deploy" implies a catalog view but the agent must infer when this tool is preferred over the alternatives.

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

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

No annotations are provided, so the description carries the full burden. "List" implies a read-only operation, but it does not disclose pagination, authorization requirements, whether all backups are returned when app_id is omitted, or the shape of returned data.

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

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

A single, front-loaded sentence with zero filler. Every word contributes to the described operation and optional filter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 listing tool, the description is minimally adequate. However, with no annotations or output schema, it should at least distinguish this tool from list_backup_tasks and mention what is returned or how results are bounded.

Complex tools with many parameters or behaviors need more documentation. 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 adds value by clarifying that app_id is an optional filter. It still does not explain the integer format, default behavior when omitted, or whether invalid app ids produce errors.

Input schemas describe structure but not intent. Descriptions should explain 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 (List) and resource (backups), making the basic operation clear. However, it does not differentiate from the sibling list_backup_tasks, so an agent cannot tell from the description alone 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?

The phrase "optionally filtered by app id" gives one usage condition, but there is no guidance on when to use this versus list_backup_tasks or other list_* siblings, and no exclusions are stated.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not disclose pagination, return fields, auth requirements, or whether disabled tasks are included; for a read-only list tool this is a moderate but real gap.

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

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

The description is a single front-loaded sentence with no wasted words. It communicates the core purpose and optional filter efficiently.

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

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

For a simple one-parameter list tool, the description is minimally adequate. However, with no output schema and no annotations, it should say more about what is returned or how results are ordered.

Complex tools with many parameters or behaviors need more documentation. 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 must compensate. It clarifies that app_id is an optional filter, which adds meaning beyond the bare integer schema, but it does not specify format or filtering behavior.

Input schemas describe structure but not intent. Descriptions should explain 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 scheduled backup tasks.' It is clear what the tool does, but it does not explicitly distinguish itself from sibling tools such as list_backups or list_jobs.

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

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

The description mentions an optional app_id filter but gives no guidance on when to use this tool versus alternatives like list_backups. There are no exclusions or contextual usage rules.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that this is a list operation and names the returned fields, but it does not state permission requirements, whether all images are returned, pagination behavior, or ordering. The addition of return fields is useful context beyond the schema.

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

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

The description is two tight sentences with no wasted words. The core purpose and return fields are front-loaded, followed immediately by the recommended usage condition.

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

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

For a zero-parameter list tool with no output schema, the description gives enough context: what is listed, which fields are returned, and when to call it. No additional detail is strictly required for an agent to use it correctly.

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

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

The tool has zero parameters, so there is no parameter semantics to document. The description appropriately avoids irrelevant parameter detail, though it does not need to compensate for any missing schema coverage.

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

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

The description uses a specific verb-resource pair: 'List the Docker images pushed to the user's CitadelHosts registry.' It also names the returned fields (name, tag, size bytes), making the scope unambiguous and distinguishable from the app, job, backup, and territory 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 explicitly states the key usage condition: 'Verify pushes here before referencing images in create_custom_app.' That tells the agent when to use the tool, but it does not name alternatives or exclusions for cases where verification is unnecessary.

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

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

No annotations are provided, so the description carries the full disclosure burden. It hints at the states returned (queued/active/failed), which is useful, but says nothing about ordering, pagination, result limits, or whether it's a safe read-only operation.

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

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

A single tight sentence with the verb, resource, scope, and covered states front-loaded. 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 zero-parameter read tool with no output schema and no annotations, the description is minimal but nearly sufficient. It could still state the return ordering or that results are not filterable, which an agent would otherwise have to discover empirically.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. The schema is empty and consistent with the description's implication that no filtering input is accepted.

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

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

Specific verb (list) plus resource (background jobs) with an explicit scope: the user's jobs in queued, active, or failed states. It's immediately distinguishable from app-oriented siblings like list_apps or list_backups, though it doesn't explicitly name a sibling it is not.

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

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

There is no guidance on when to use this versus other list/status tools (e.g. check_app_status), no prerequisites, and no mention of whether it can be filtered or scoped. The reader must infer usage entirely from the name.

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

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

No annotations are provided, so the description carries the full burden: it does not confirm read-only behavior, describe scoping/authorization requirements, or mention pagination or filtering. 'List' implies a safe read, but nothing is explicitly disclosed beyond the target resource.

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

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

One front-loaded sentence with zero filler. It is efficient, though the sparseness borders on under-specification for a tool with an undocumented parameter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 list tool with no output schema and no annotations, the description is minimally adequate but leaves open how managed_app_id is obtained and how this differs from list_storage_volumes. An agent could call it, but with avoidable uncertainty.

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

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

Schema description coverage is 0% and the single required parameter managed_app_id has no description anywhere. The phrase 'managed application' hints at what the ID refers to, but the description adds no format, source, or syntax information to compensate for the coverage 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 gives a specific verb+resource: 'List volumes attached to a managed application.' An agent can tell this is a per-app volume listing, but it never distinguishes itself from the sibling list_storage_volumes (or list_apps). Clear purpose, no sibling differentiation.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as list_storage_volumes. The agent must infer usage entirely from the one-line purpose statement.

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

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

With no annotations, the description carries the full burden; it does reveal that results include size limits and usage, which is useful behavioral context for a list call. However, it never states the operation is read-only, nor does it mention pagination, ordering, or auth requirements for a listing that could be large.

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

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

A single well-formed sentence with the resource and returned fields front-loaded and no filler. Nothing redundant or wasted.

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

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

For a zero-parameter read tool with no output schema, the description does indicate what comes back (size limits and usage). It is a bit thin on how this differs from managed volumes and lacks any pagination/return-shape detail, but the essentials are 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 tool takes zero parameters, so there is no parameter semantics to explain and the baseline is 4. The description correctly implies the listing is unfiltered and covers the caller's own volumes.

Input schemas describe structure but not intent. Descriptions should explain 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 (List) and resource (the user's standalone storage volumes) plus the data returned (size limits and usage). The word 'standalone' implicitly distinguishes it from the sibling list_managed_volumes, but the contrast is never made explicit.

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

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

No guidance on when to use this versus list_managed_volumes or the other list_* siblings, and no prerequisites or exclusions stated. The agent must infer usage entirely from the name and the adjective 'standalone'.

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

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

With no annotations, the description carries the behavioral burden, and it does disclose the returned fields (limits, status, pricing), which hints at a read-only listing. However, it says nothing about permissions, result size, or pagination, so it is only partially transparent.

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

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

A single, front-loaded sentence with no filler; the scope and returned fields are stated immediately.

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

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

With no output schema, the description should convey what comes back, and it names the three field groups (limits, status, pricing). For a parameterless list tool, that is sufficient, though slightly more detail on the shape of results would help.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to compensate for.

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

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

The description states a specific verb (List) and resource (territories) and clarifies what a territory is ("resource containers that hold apps"), which an agent would not otherwise know. It does not explicitly distinguish itself from the closest sibling get_territory_status, 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?

There is no when-to-use or when-not-to-use guidance; the description only says what the tool returns. An agent gets no help deciding between this and get_territory_status or list_apps.

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

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

No annotations are provided, so the description carries the full behavioral burden. It only implies a mutation and does not disclose permissions, reversibility, validation rules, side effects, or what happens if the territory does not exist.

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

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

The description is a single front-loaded sentence with no wasted words. It is concise, though it lacks any additional structure or clarifying 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 a simple mutation tool, the basics are obvious, but with no annotations, no output schema, and no schema descriptions, the definition should say more about parameter meaning and mutation behavior. It is not complete enough for reliable invocation beyond the tool name.

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

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

Schema description coverage is 0%, and the description does not explain that territory_id identifies the target territory or that name is the new name. It only allows the agent to infer meaning from the parameter names themselves.

Input schemas describe structure but not intent. Descriptions should explain 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: "Rename a territory." It is clearly distinguishable from create/delete/get/list territory siblings by operation, but it does not explicitly name or compare those siblings.

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

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

It gives only the implied usage of renaming an existing territory. It does not state when to use this instead of create_territory, delete_territory, get_territory_status, or list_territories, nor does it mention prerequisites.

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

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

With no annotations, the description carries the full burden, and it does deliver the single most important trait: the operation overwrites current volume data and is destructive. It omits other relevant behavior such as required permissions, whether the app must be offline, and whether the operation is reversible.

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

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

Two short sentences, front-loaded with the action and the risk, with no padding or redundancy. Every word earns its place.

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

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

For a destructive mutation tool with no annotations and no output schema, the description is too thin: it omits prerequisites, sourcing of the backup_id, and post-restore behavior. It names the risk but does not give an agent enough to invoke the tool confidently.

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

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

Schema coverage is 0% and the single parameter backup_id has no description in either the schema or the description text. The description never explains what a valid backup_id is or where to obtain one (e.g., from list_backups), so it fails to compensate for the coverage 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?

States a specific verb and resource ('Restore a backup') plus the target scope ('over the app's current volume data'), so the action is unambiguous. It does not differentiate itself from backup-related siblings like list_backups or create_backup_task, but the read/write distinction is intuitively clear from the verb.

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

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

No guidance on when to use this versus alternatives, no mention that a backup_id must first be obtained via list_backups, and no preconditions (e.g., whether the app must be stopped). The word 'Destructive' signals caution but conveys no usage criteria.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only implies a state mutation; it does not disclose required state, idempotency, permission/auth needs, whether startup is async/long-running, or failure modes if the app is not stopped.

Agents need to know what a tool does to the 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 waste or filler. It is efficient, though the brevity comes at the cost of the missing context scored elsewhere rather than through 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 mutation tool with no annotations, no output schema, and an undocumented required parameter, the description is too thin. An agent lacks the precondition, side-effect, and parameter guidance needed to invoke it confidently.

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

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

Schema description coverage is 0% for the single required parameter, and the description says nothing about managed_app_id's format, source, or expected values. It only vaguely implies 'managed application', adding almost no meaning beyond the schema property 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?

States a specific verb (start) and resource (a stopped managed application), which is clearly distinguishable from the sibling stop_app/kill_app. However, it does not explicitly reference siblings or scope beyond the verb, so it does not reach the 5-level differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 'stopped managed application' implies a precondition but never states when to use this versus stop_app, kill_app, or get_app, nor what happens if the app is already running. No exclusions, no alternatives, no context for the agent to route 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?

No annotations are provided, so the description carries the full burden. 'Gracefully' is a useful behavioral signal, but the description does not say what stopping entails (drain, shutdown delay, reversibility), whether it requires permissions, or how it differs operationally from the forced kill_app.

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

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

One front-loaded sentence with no filler. The key distinguishing qualifier 'gracefully' appears immediately and nothing is wasted.

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

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

For a mutation tool with no annotations, no output schema, and an undocumented required parameter, the description omits the operationally important details: whether the stop is reversible, what a subsequent action should be, and how it relates to kill_app.

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

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

The single required parameter managed_app_id has 0% schema description coverage, and the description only indirectly characterizes the target as a 'running managed application'. The parameter's identity is self-evident from its name, so this is adequate but adds little 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 ('stop a running managed application'), and the qualifier 'gracefully' hints at how it differs from the destructive sibling kill_app. However, it never names that sibling, so differentiation is left to inference.

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

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

There is no statement of when to use this versus kill_app, start_app, or check_app_status, nor any precondition such as the app needing to be running. The agent must infer that 'gracefully' is the selection criterion.

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

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

No annotations are provided, so the description carries the full behavioral burden. It says the tool toggles the proxy login requirement but does not explain whether it flips the current state, what permissions are needed, whether the app must be running, or how active sessions are affected.

Agents need to know what a tool does to the 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 or filler content. Its brevity is appropriate for the dimension, even though other dimensions need more 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?

This is a mutation tool with no annotations and no output schema, and the sole parameter is undocumented in both the schema and description. The definition should do more to explain state semantics, prerequisites, and what confirmation or result the agent should expect.

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

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

Schema description coverage is 0%, and the description does not mention the sole parameter, managed_app_id. The parameter name is suggestive, but the description adds no meaning about identifier format, source, or 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 uses a specific verb, "Toggle," and a specific resource, "whether the proxy requires login to reach the app." This makes the operation clear, though it does not differentiate the tool from sibling app-management tools or mention how the app is identified.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 state when to use this tool versus alternatives such as start_app, stop_app, or get_app_definition. Usage is only implied by the tool's purpose, with no prerequisites or exclusions given.

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