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 explicitly warns that the clone runs in the background and that the tool returns when the clone starts, not when it finishes, and advises checking ecp_apps_directory_tree afterward. This is important, non-obvious behavior that an agent needs to know.

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 earning its place: purpose, authentication options, and the critical async behavior. The most important caveat is placed at the end but is clearly highlighted, and there is no filler or repetition of schema property names.

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

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

The description covers the key authentication modes and the background-clone behavior, but given the tool's complexity—9 parameters, no output schema, and no annotations—it still omits explanations for app_name, app_dir, branch, and deploy_type. It is adequate for a basic call but not fully complete for all valid use 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 0%, so the description must compensate for the schema's silence. It explains provider, repo_full_name, repo_url, repo_username, and repo_password, but leaves required parameters like app_name and app_dir, plus branch and deploy_type, unexplained. The added meaning is useful but incomplete for a 9-parameter tool.

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

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

The description opens with a specific verb and resource: 'Create an app by cloning a git repo.' This clearly distinguishes the tool from siblings like ecp_apps_create_from_upload and the broader ecp_apps_* family, so an agent can identify its purpose 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 gives clear guidance on the two authentication modes: use provider+repo_full_name with a connected git account, or repo_url with optional credentials for private repos. It does not explicitly state when to prefer this tool over ecp_apps_create_from_upload, but the git-cloning framing makes the primary use case 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?

With no annotations, the description carries the full burden of behavioral disclosure. It does not state whether this operation mutates state, whether it triggers deployment, what side effects occur, or what the response contains. 'Register' suggests a write operation, but the consequences are 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?

The description is a single short sentence, which is concise, but it is under-specified rather than efficiently informative. It front-loads the key prerequisite but omits essential context that would justify its length.

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

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

For a 4-parameter tool with no annotations and no output schema, this description is incomplete. It does not explain the registration workflow, the meaning of deploy_type, or what happens after registration, leaving an agent to guess at critical invocation 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 0%, so the description must compensate, but it only mentions app_dir. It does not explain app_name, domain, or deploy_type, nor how they relate to the registration process. The required parameters are not all described.

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 'Register an app whose files were already uploaded to app_dir.' states a verb and resource, but it is vague about what 'register' means in this system and how it differs from ecp_apps_create_from_git or ecp_apps_deploy_step. It does not clearly distinguish this tool from the many app-related siblings.

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

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

The description implies a prerequisite (files already uploaded to app_dir) but gives no explicit guidance on when to choose this tool over ecp_apps_create_from_git, ecp_apps_deploy_step, or ecp_apps_update_domain. No exclusions or alternative routing 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?

Without any annotations, the description takes on the full burden. It discloses important side effects: the supervisor process is stopped and the app's files are removed, plus the 'Irreversible' warning. This transparently conveys the destructive nature of the operation. It does not, however, mention any potential cascade effects or failures (e.g., if the app doesn't exist or files are in use), but for the given granularity this is sufficient.

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

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

The description is very concise and front-loaded. The main action ('Delete an app') appears first, followed by a single clause detailing what happens and a clear warning. It's appropriately sized for the operation and adds 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 simple operation, the description covers the essential behavior (stopping the process and removing files, irreversibility). However, it lacks explicit clarification on the parameters and any expectations about return values or errors. There is no output schema, so a brief note about what the tool returns (e.g., success confirmation) would improve completeness. The description satisfies the core need but leaves 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 description does not explain the 'id' parameter or explicitly state that 'confirm' must be true to proceed. Although the schema shows a required 'confirm' boolean with const:true, the description provides no contextual meaning (e.g., 'You must pass confirm: true to authorize deletion'). The destructive nature of the operation makes this gap more impactful, as the agent may not understand why the confirm field is needed.

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

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

The description clearly states the action ('Delete an app'), the specific resource affected ('an app'), and the scope of destruction ('stops its supervisor process (if any) and removes its files'). It directly tells the agent what this tool does without ambiguity, and the sibling list shows distinct operations like ecp_apps_tail_logs and ecp_supervisor_stop_process, so there's no confusion about purpose.

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

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

The description does not provide any usage guidance about when to use this tool versus alternative tools, nor does it mention prerequisites or warnings beyond the bare statement 'Irreversible.' There is no reference to related operations such as ecp_apps_deploy or ecp_supervisor_* tools, leaving the agent to infer appropriate usage from the operation 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?

With no annotations, the description carries the full burden. It explicitly discloses that install/build run in the background and cannot show output, that configure returns no output, and that start/stop/restart/remove return a real result. This is meaningful behavioral context beyond the schema, though it omits details like side effects or error handling.

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 organized by action groups and front-loads the critical distinction between synchronous supervisor actions and background commands. Each sentence adds information, with no fluff. It's slightly long but structured effectively.

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 0% schema coverage, no output schema, and 10 parameters, the description is incomplete. It neither explains all parameters nor describes expected return values for start/stop/restart/remove (only 'real result'), nor error behavior. The guidance to check tail logs is useful but insufficient for a tool with this complexity.

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

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

Schema coverage is 0%, so the description must compensate. It explains the meaning of action, app_root_directory, install_command, build_command, and stack_version, but leaves app_id, app_name, deploy_type, env_file_path, and start_command undocumented. The partial coverage is helpful but does not fully resolve the 10-parameter tool's semantics.

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

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

The description clearly states the tool runs one step of an app's deploy lifecycle and enumerates the action values with their specific behavior (start/stop/restart/remove manage supervisor process; install/build run background commands; configure pins asdf version). This distinguishes it from sibling tools like ecp_supervisor_* by framing them as lifecycle steps, though it never explicitly names alternatives.

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

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

The description gives some contextual guidance for install/build (cannot see output, use tail logs) and notes configure returns no output, but it does not explicitly state when to use this tool versus alternatives like ecp_supervisor_start_process for start/stop/restart/remove. No condition or exclusion logic is provided to guide tool selection, so the agent is left 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?

With no annotations, the description carries the burden of behavioral disclosure. 'Browse' safely implies a read-only operation, and the parenthetical clarifies intent, but it does not explain what happens with the optional 'directory' argument, what is returned, or any special behavior. It is adequate but not rich.

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

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

The entire description is a single, efficient sentence. It front-loads the action and immediately reinforces it with two practical use cases, with no redundant 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 tool with one undocumented, optional' and no output schema, the description needed to at least explain the shape of the 'directory' parameter and the tree output. It walks away, leaving the agent to guess how to call it correctly. The use cases are helpful, but the core semantics are incomplete.

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 provides only the name and type for 'directory' (string, optional) with no description. The description never explicitly says what to pass for 'directory' or how it affects the tree, leaving the agent to infer based on the parameter name. It offers some context but does not compensate for the 0% schema description 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 states a clear verb ('Browse') and resource ('the account's directory tree') and gives two concrete use cases. It does not explicitly differentiate itself from the sibling ecp_files_directory_tree, but the purpose is not vague.

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 indicates when to use the tool: to pick a location for a new app or to check where a git clone landed. It does not mention exclusions or alternatives, but the provided context is enough to orient usage.

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

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

With no annotations, the description must carry the behavioral burden. 'Clear' communicates that the operation is destructive, but it does not disclose whether the log is truncated or deleted, whether the action is reversible, what impact it has on the running process, or whether special permissions are needed.

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 efficiently conveys the verb, target, and scope without 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 destructive action, the description names the target and the effect, which is minimally sufficient for invocation. However, the absence of annotations and any mention of consequences, return behavior, or process impact leaves meaningful gaps for a destructive 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 schema only declares app_name as a string with 0% description coverage, and the description does not explicitly document the parameter. However, the phrase 'an app's ... log' implies that app_name identifies the target app, providing minimal semantic context beyond 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?

The description states a specific verb ('Clear') and a specific resource ('an app's supervisor-managed process log'), which clearly distinguishes this from siblings like ecp_apps_tail_logs or file-based log tools. It also scopes the action to supervisor-managed logs, removing 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 gives no guidance on when to use this tool versus alternatives such as ecp_apps_tail_logs or ecp_supervisor_restart_process. It does not mention exclusions, prerequisites, or which situations call for flushing logs.

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 present, so the description carries the full burden. It implies a read-only lookup via 'get', but it does not describe what 'details' include, what happens if the id is invalid, whether authentication is required, or that this operation has no 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?

One short, front-loaded sentence with no filler. Every word contributes to meaning and it is far more economical than the schema alone.

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 getter, the description is minimally sufficient, but with no annotations and no output schema it leaves the response shape, error behavior, and return content completely 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?

With 0% schema description coverage, the description must compensate for the single 'id' parameter. The phrase 'by id' clarifies that the parameter is the app's identifier, but it does not specify the id format, its source, or how it relates to results from ecp_apps_list.

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'), a specific resource ('one app'), and the lookup key ('by id'). It clearly distinguishes this from ecp_apps_list, which targets multiple apps, and from the create/delete/update 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 clearly implies the tool is for fetching a single app's details, but it does not explicitly say when to prefer it over ecp_apps_list or mention any conditions or exclusions. The usage context is clear but not fully specified.

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

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

No annotations are provided, and the description only says 'List all apps,' giving no detail about what fields are returned, whether the response includes metadata, or any other behavioral traits. The description carries the full disclosure burden and does not meet it.

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

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

A single clear sentence with no filler. It front-loads the action and resource effectively for a zero-parameter tool.

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

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

Given the tool's simplicity and zero parameters, the description is sufficient for an agent to know how to invoke it. The lack of output-format detail is a minor gap, and the absence of sibling differentiation is somewhat compensated by the clear scope of 'all apps.'

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

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

The tool has zero parameters, so the schema leaves no ambiguity. The description does not need to add parameter details; 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 uses a specific verb and resource: 'List all apps on this hosting account.' It clearly communicates the tool's scope, though it does not explicitly contrast itself with app-related siblings like ecp_apps_get or ecp_oneclick_blueprint_apps.

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

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

There is no guidance on when to use this tool versus alternatives such as ecp_apps_get, ecp_apps_directory_tree, or ecp_oneclick_blueprint_apps. The agent is left to infer selection from the name and one-line 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?

With no annotations, the description carries the burden of behavioral disclosure. It clearly states the tool does not run the command, which is a key behavioral trait. However, it doesn't disclose whether saving overwrites existing commands, whether commands are validated, or what the response contains. The 'does not run it' clarification is valuable but incomplete.

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 front-loads the primary action and includes a parenthetical clarification about execution. It is concise and every word earns its place, though the parenthetical could be seen as slightly verbose.

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

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

For a simple save operation with two parameters and no output schema, the description covers the core purpose and the critical non-execution behavior. However, it lacks details about overwrite semantics, validation, or response format, which an agent might need to call it correctly. It is adequate but not complete.

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

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

Schema description coverage is 0%, so the description must compensate for the two parameters. It mentions 'named custom command' and 'for an app', which loosely maps to 'commands' and 'app_id', but it doesn't explain the structure of the commands array, the meaning of 'title' vs 'command', or any constraints. The description adds minimal semantic value beyond the schema's property 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 ('Save') and resource ('named custom command for an app'), and clarifies that it does not run the command. It distinguishes itself from a hypothetical 'run' operation, though it doesn't explicitly name a sibling tool. The purpose is clear and actionable.

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

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

The description implies when to use this tool: when you want to persist a custom command without executing it. It references a 'blocked command-execution phase' in the plan, which provides context but no explicit alternatives or exclusions. It doesn't say when not to use it or point to a sibling for running commands, so guidance is partial.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It states the action ('tail') and a precondition, but does not explain output format (e.g., streaming vs. last N lines), whether it blocks, pagination, or potential failure modes. For a log-tailing tool, this is a significant 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, concise sentence with no filler. The core action is front-loaded, and the contextual qualifier ('only meaningful after...') is appended naturally. It is appropriately sized for the tool's simplicity, though slightly under-specified.

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

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

Given no output schema, no annotations, and minimal parameter explanation, the description leaves the agent without key details needed for correct invocation: what byte_count does, what the output will be, and any error conditions. For a tool that might stream logs, this is notably incomplete.

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 two parameters (app_name, byte_count) with 0% coverage in the description. The description does not explain what byte_count means or how it affects the tail operation, and even app_name's semantics are implied only by the name. Since schema lacks descriptions, the description should compensate, but it doesn't.

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 'tail' with a clear resource ('app's supervisor-managed process log'), which distinguishes it from generic listing tools. It also adds a key precondition ('only meaningful after a 'start' deploy step'), which helps clarify an important timing aspect. However, it doesn't explicitly differentiate from sibling tools like ecp_apps_flush_logs or ecp_supervisor_list_processes, so it's not a full 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 a usage condition ('only meaningful after a 'start' deploy step'), which gives some context on when to call it. But it does not mention alternatives or scenarios where another tool (e.g., ecp_apps_flush_logs or ecp_supervisor_start_process) would be more appropriate, so the guidance is incomplete.

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 present, so the description carries the behavioral disclosure burden. It does name a concrete side effect (creating the nginx server block), but it does not say whether an existing block is overwritten, whether this is reversible, or what permissions are implied.

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 front-loaded sentence with no filler, repetition, or boilerplate. It names the action and the main side effect 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 two-parameter tool, the description covers the core goal and one key side effect, making it minimally usable. However, it lacks context about overwrite behavior, domain format expectations, and the sibling static-domain tool, which weakens its completeness.

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

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

Schema coverage is 0%, and the description only indirectly maps id to an app and domain to the target domain. No format, constraints, or interaction between id and domain is given, so the agent has to infer the parameter details.

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 concrete action and resource: point an app at a domain, create the nginx server block, and update the app's domain record. It does not explicitly distinguish itself from the sibling ecp_apps_update_static_domain, so it is not a perfect 5.

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

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

No when-to-use or when-not-to-use guidance is provided. There is no mention of prerequisites, such as the app existing, or how this relates to alternatives like ecp_apps_update_static_domain.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the operation creates an nginx block and updates a domain record, but does not mention side effects (e.g., whether existing nginx config is overwritten), reversibility, permission requirements, or failure behavior. For a mutation tool, this is insufficient transparency.

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

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

The description is a single, efficient sentence with no filler. It front-loads the primary action ('Point a static-site app at a domain') and immediately follows with the concrete implementation steps. Every word earns its place, and the structure is ideal for quick parsing.

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

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

The tool has moderate complexity, no output schema, and no annotations. The description omits essential context: return value, error scenarios, prerequisites (e.g., app must exist and be static-site), and the format of 'id'. An agent cannot confidently invoke this tool correctly without additional information, making it incomplete for its 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%, and the description does not explain the 'id' parameter at all. It mentions 'domain' in the text, which hints at its meaning, but 'id' remains ambiguous (e.g., is it the app ID?). The description adds minimal value beyond the schema, which already lists 'id' and 'domain' but provides no descriptions. The agent is left guessing about parameter formats and 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 clearly states the verb ('Point a static-site app at a domain') and the resource ('static-site app'), and specifies the two concrete actions performed ('creates the nginx static block' and 'updates the app's domain record'). This distinguishes it from sibling tools like ecp_apps_update_domain, which is likely for non-static apps, and ecp_nginx_set_conf, which handles nginx config generically.

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

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

The description implies usage for static-site apps, but does not explicitly state when to choose this over the sibling ecp_apps_update_domain or other domain-related tools. There is no mention of exclusions or prerequisites (e.g., app must be static-site type). The guidance is implicit but not actionable for an agent deciding between this and 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. It discloses that the operation takes time, cannot show install output, and requires external verification via a sibling tool. It does not mention side effects, failure modes, or the confirm parameter's role. This is useful but not comprehensive for a mutation tool.

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

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

Two sentences, front-loaded with the purpose and immediately followed by the critical behavioral caveat. No wasted words; every sentence provides essential information for correct invocation.

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 install command, the description covers the main workflow but omits parameter semantics and doesn't explain how to discover valid versions (e.g., via ecp_asdf_list_all_versions). Without annotations or output schema, this is incomplete for an agent to call correctly with confidence.

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 says nothing about the parameters (name, version, confirm). The agent must infer that 'name' refers to the plugin, 'version' to the specific version, and 'confirm' is a safety flag (since it is const true). No guidance is given on how to obtain these values or formats, leaving significant ambiguity.

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

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

Clearly states the action ('Install a plugin version') and the resource. Distinguishes from sibling asdf tools like list and uninstall by specifying the install action and the follow-up verification step. The phrase 'takes time' adds practical context.

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 explicit guidance on the post-install workflow ('check ecp_asdf_list_installed_versions afterward'), which implies when to use this tool versus alternatives. However, it doesn't explicitly mention when not to use it (e.g., if the version is already installed) or alternative tools for checking availability, so not 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?

No annotations are provided, so the description carries the full burden. It discloses the read-only nature implicitly ('List') but doesn't clarify whether 'available' means remote registry versions, whether it requires network access, whether the plugin must already be installed/added, or what the response format looks like. For a list operation this is a moderate 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?

One short sentence with an example. It is front-loaded with the verb and resource, and the example adds clarity without bloat. It could be slightly more informative, but it 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 one-parameter list tool, the description is close to adequate, but with no annotations, no output schema, and 0% parameter coverage, it leaves ambiguity about what 'name' means and what 'available versions' includes. An agent could confuse this with listing installed versions or plugin names, so more context is needed.

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 says 'for a plugin (e.g. nodejs)'. It gives an example value but doesn't explain what 'name' refers to (plugin name vs version name), whether it must match an already-added plugin, or any format constraints. The example helps but doesn't fully compensate for the undocumented 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 description states a specific verb ('List') and resource ('all available versions for a plugin'), with an example ('nodejs'). It clearly distinguishes from siblings like ecp_asdf_list_installed_versions (installed vs available) and ecp_asdf_plugin_list (plugins vs versions), though it doesn't explicitly name those siblings.

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

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

The description implies usage context: it lists available versions for a plugin, which is useful before installing. However, it doesn't explicitly state when to use this vs ecp_asdf_list_installed_versions or ecp_asdf_install, nor does it mention prerequisites like whether the plugin must already be added.

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 verb 'List' clearly implies a read-only operation, so the basic behavior is transparent. However, with no annotations, the description doesn't state what happens on invalid or unknown names, and it doesn't explicitly rule out side effects, leaving the burden on the tool name.

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

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

The description is extremely concise, a single three-word phrase that is immediately scannable. It contains no fluff or repetition, but the brevity comes at the cost of semantic completeness, which is penalized elsewhere.

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

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

With one required parameter and no explanation of what it refers to, plus no mention of output or relation to sibling tools, the description is not self-sufficient. An agent would need to rely on the tool name and sibling context to use this correctly.

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

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

The parameter schema provides no description, and the tool description does not compensate. 'name' is left undefined — there is no statement that it is a plugin/language name or an example of valid values, so an agent cannot reliably infer how to fill 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 names a clear action (List) and an object (installed versions), but 'installed versions' is ambiguous without specifying of what. The tool name implies asdf, but the description doesn't state that `name` identifies a language/plugin, nor does it distinguish this from the sibling ecp_asdf_list_all_versions.

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 choose this tool over siblings like ecp_asdf_list_all_versions or ecp_asdf_plugin_list. The description does not mention the required `name` parameter, prerequisites, or typical usage context.

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

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

With no annotations, the description carries the full burden. It does convey that the operation is scoped to 'this account's container' and implies a read-only list operation, but it does not explicitly state that it is non-destructive, nor does it describe any output format or potential limitations. Basic transparency is present, but richer behavioral context (e.g., return structure, pagination) is missing.

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

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

A single, front-loaded sentence with no redundant words. It begins with the verb and clearly communicates the action and scope, achieving maximum efficiency.

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

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

There is no output schema, so the description should at least hint at the return value. It says 'List ... plugins' but does not specify whether the output is a list of plugin names, versions, or additional metadata. It also does not mention that the operation is read-only, though that is implied. For a simple listing tool, this is adequate but not fully complete.

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

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

The tool has zero parameters, so the description does not need to elaborate on parameter meanings. The baseline for zero parameters is 4, and the description does not introduce any confusion; it simply lists what the tool returns, which is sufficient.

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

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

The description clearly states the action ('List') and the resource ('asdf plugins currently installed on this account's container'), including a scope qualifier that distinguishes it from potential siblings like ecp_asdf_plugin_list_all. It is specific and unambiguous.

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

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

No guidance is provided on when to use this tool versus alternatives such as ecp_asdf_plugin_list_all or ecp_asdf_list_installed_versions. The description does not mention any conditions, exclusions, or alternative tools, leaving the agent 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?

With no annotations provided, the description carries the full burden. It states a read-like action (list) but does not disclose whether it requires any setup, the scope of the list (e.g., all sources), or potential errors. It adds minimal behavioral context beyond the verb 'list', though the read-only nature is implied.

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

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

One concise sentence with useful examples (nodejs, python, ruby) that clarify what asdf plugins look like. No wasted words, and the purpose 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 zero-parameter list tool, it is reasonably complete. The examples aid understanding. However, it doesn't clarify that the list is only of available (not installed) plugins, which might be inferred but not explicit enough for full contextual completeness with no annotations or output schema.

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

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

The tool has zero parameters and schema coverage is 100%, so there is nothing for the description to add. Given no parameters, a baseline of 4 is appropriate; the description correctly focuses on the tool's purpose.

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

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

The description clearly states the action (list) and the resource (asdf plugins available to install), with examples. It is distinct enough from sibling tools like ecp_asdf_plugin_list and ecp_asdf_list_all_versions due to the explicit mention of 'available to install'.

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 explicit guidance on when to use this tool versus alternatives like ecp_asdf_plugin_list (which likely lists installed plugins) or ecp_asdf_list_all_versions. The phrase 'available to install' implies a use case, but no clear when-to-use/when-not-to-use context is provided.

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

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

With no annotations at all, the description carries the full burden of behavioral disclosure, but it only states the basic effect. It does not say whether the plugin/version must already be installed, what system state changes, whether the operation is reversible, or what the tool returns.

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. Every word adds meaning, and it is readily 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 mutation tool with no annotations and no output schema, the description is too thin to be complete: it omits preconditions, side effects, and result behavior. The low parameter count keeps it from being lower, but an agent still lacks enough context to invoke it safely and correctly.

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

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

The input schema provides no descriptions for 'name' or 'version', so the description must compensate. It does clarify that 'name' refers to a plugin and 'version' is the version to make globally default, but it leaves unspecified what version values are valid or whether the version must be installed.

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, 'Set', and a specific resource, 'global default version for a plugin', making the operation identifiable without opening the schema. It is clearly distinct from sibling asdf operations like install, uninstall, or listing versions, though it does not explicitly name or contrast them.

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

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

The description gives no guidance about when to call this tool, what to do first (e.g., list installed versions or install a version), or when to prefer a sibling asdf tool instead. Usage must be inferred from the tool name and domain.

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 burden of behavioral disclosure. It explicitly reveals the destructive impact ('Breaks anything still configured to use it') and the lack of output, which is important for a mutation tool without an output schema.

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

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

Three short sentences deliver purpose, warnings, and the post-check workflow with no waste. The most important behavioral caveats are front-loaded.

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

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

The description is situationally sufficient for a destructive action and even routes the agent to a verification sibling, but it lacks parameter guidance and does not explain the required confirm flag. Since there are no annotations and no output schema, the remaining gaps are material.

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, but it only says 'a plugin version' and never explains the meaning of name, version, or confirm. The confirm parameter in particular is entirely undocumented, which is a gap for a destructive tool that requires explicit confirmation.

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 and resource: 'Uninstall a plugin version.' This makes the tool distinct from related siblings like ecp_asdf_install and ecp_asdf_set_global, though it does not explicitly contrast itself with those alternatives.

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

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

The description gives useful operational context by warning that the operation breaks anything still configured to use that version and tells the agent to verify with ecp_asdf_list_installed_versions afterward. However, it does not state explicit when-to-use or when-not-to-use conditions versus similar uninstall/removal 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?

There are no annotations, so the description carries the full burden. 'List' communicates a read-only operation, and the description clarifies exactly which snapshots are included and which are not. It does not specify output format, but for a zero-parameter list tool that is a minor gap.

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

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

The description is a single, front-loaded sentence. It states the action and object first, then adds the key scoping distinction in a parenthetical. 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?

This is a simple zero-parameter list operation with no output schema or annotations. The description adequately explains what will be listed and explicitly disambiguates it from storage.bd backups. Nothing necessary 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 100% schema coverage, so there is no parameter burden for the description to carry. Baseline 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 uses a specific verb and resource: 'List local restic snapshots of this account's host paths.' It also distinguishes itself from storage.bd's own backups, which prevents confusion with the many storage_bd backup 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 parenthetical 'separate from storage.bd's own backups' gives clear contextual guidance about scope. It does not explicitly name an alternative tool or list exclusions, but the boundary is clear enough for an agent to route between this and the storage_bd backup family.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states that the command runs 'unattended, repeatedly, as this account's own system user' and warns to 'review carefully before confirming.' This reveals the security and persistence implications of scheduling a job, which is valuable context beyond the schema. It does not cover all possible behaviors (e.g., error handling, output), but the core safety-relevant behavior is 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 two sentences, front-loaded with the purpose and then providing a concise behavioral caution. Every word earns its place; there is no filler or redundancy. The structure efficiently conveys the essential information.

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

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

Given the tool's simplicity (3 parameters, no output schema, no annotations), the description covers the core purpose, the cron expression format, the execution context (unattended, as user), and a safety warning. It does not explain return values or error scenarios, but for a scheduling tool these are less critical. The description is sufficiently complete for an agent to correctly invoke it, though it could add a note on what the response contains.

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 for parameter documentation. It explains the cron_expression format with an example ('0 3 * * *'), which adds value. It does not describe the 'command' parameter (though its purpose is obvious) or the 'confirm' parameter, though the caution 'review carefully before confirming' implicitly references it. The description partially covers parameters 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 states a clear verb and resource: 'Schedule a cron job.' It directly addresses the tool's function and is easily distinguishable from sibling tools like ecp_crontab_list and ecp_crontab_remove by naming the action explicitly. There is 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 does not explicitly state when to use this tool versus alternatives or provide exclusions. However, the purpose is self-evident from the name and the context of sibling tools (crontab list/remove). The caution 'review carefully before confirming' implies a decision-making step but does not guide on alternative selection. This is adequate but not explicit.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool lists scheduled cron jobs, but it doesn't mention whether the list is sorted, whether it includes disabled jobs, what fields are returned, or whether any side effects occur. For a read-only listing tool, this is a moderate 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, concise sentence that front-loads the action and resource. Every word earns its place, and 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 zero-parameter listing tool, the description is minimally adequate. However, it lacks context about the output format, whether the list is limited to the current account, and how it relates to cron management siblings. Given the absence of annotations and output schema, a bit more detail would improve completeness.

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

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

The tool has zero parameters, so there is no schema burden to compensate for. The description accurately indicates the scope ('this account's scheduled cron jobs'), which is sufficient for an agent to invoke the tool without needing parameter details.

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 ('this account's scheduled cron jobs'), which clearly identifies the tool's function. It doesn't explicitly differentiate from sibling tools like ecp_crontab_add or ecp_crontab_remove, but the read-only listing intent is unambiguous.

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

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

No guidance is provided about when to use this tool versus alternatives. The description implies a simple listing use case, but there is no mention of exclusions, prerequisites, or related tools such as ecp_crontab_add/ecp_crontab_remove for managing jobs.

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

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

With no annotations, the description must carry the behavioral burden. It does disclose exact-match semantics and implies no wildcarding, but it does not explicitly state irreversibility, what happens on no match, or the role of the confirm flag.

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 with no filler. The exact-match constraint and the list reference are front-loaded and directly support correct use.

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 removal tool, the description gives the missing operational essentials: match an existing entry exactly and use ecp_crontab_list to get the values. It is adequate for selecting and invoking the tool, though error/no-match behavior is not covered.

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 meaning to cron_expression and command by defining them as an exact-match pair against an existing entry, which is genuinely useful beyond the schema. But it gives no additional meaning to confirm, and schema coverage is 0%, so compensation is partial.

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 ("Remove") and resource ("scheduled cron job"), and it points to ecp_crontab_list as the companion lookup tool, making it clearly distinct from ecp_crontab_add and ecp_crontab_list.

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

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

It explicitly instructs the caller to match an existing entry's cron_expression and command exactly and references ecp_crontab_list, giving clear preconditions. It does not explicitly contrast with ecp_crontab_add or state when not to use the tool, so it stops short of a full when/when-not map.

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

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

With no annotations provided, the description carries the full burden. 'Get' and 'static' clearly signal a non-mutating, read-only operation with no side effects. It does not detail return formatting or whether credentials are included, but for a zero-parameter info retrieval tool, the safety profile is sufficiently 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, well-structured sentence that front-loads the verb and resource, then adds the crucial scope qualifier. Every word earns its place with no redundancy or filler.

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

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

For a zero-parameter read-only tool, the description is complete: it states what is returned (static host/port connection info), for what scope (each database engine, this account's own container), and the absence of parameters means no invocation ambiguity. No output schema is needed for an agent to correctly select and call 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 defines zero parameters, so the baseline is 4. There are no parameter semantics to explain, and the description appropriately says nothing about 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 names a specific verb ('Get'), resource ('static host/port connection info'), and scope ('for each database engine, for apps running in this account's own container'). This clearly differentiates it from the many sibling DB tools by focusing on connection metadata rather than database operations or service status.

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 scope qualifier 'for apps running in this account's own container' provides some contextual guidance, implying it is for retrieving connection details in this environment. However, it does not explicitly name alternatives (e.g., ecp_db_services_status or network port map tools), nor does it state when not to use 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 burden, and it does convey that this is a non-mutating status check across specific DB engines plus the MySQL caveat. It doesn't specify the return format or error behavior, but for a zero-parameter status probe that is a minor gap.

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

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

A single sentence covers the action, target engines, scope, and the MySQL exception without redundancies. It is compact, front-loaded, and every clause adds relevant 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 parameterless status check with no output schema, the description is complete enough to select and invoke correctly. It identifies the engines, the status dimensions, account scope, and why MySQL is excluded, leaving no critical ambiguity.

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 schema coverage is 100%, so no parameter documentation is needed. The description adds useful contextual meaning by explaining which engines are relevant and which is always available, which is more than the empty schema supplies.

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 checks whether Postgres, MSSQL, and Mongo are enabled/configured/status for the account, so the agent knows exactly what resource is being checked. The MySQL parenthetical distinguishes this tool from MySQL-related DB tools by explaining MySQL is always available and not part of the optional DB check.

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

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

It gives clear context for when to call this tool: when the status of optional database engines is needed. It also provides an exclusion by noting MySQL is always available and not an optional engine, though it does not name a specific alternative 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?

Annotations are absent, so the description must carry the behavioral burden. It says 'add' and thereby implies a write, but it discloses nothing about conflicts, overwrite behavior, propagation, required permissions, idempotency, or what happens when a record already exists – a significant gap for a mutation tool.

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

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

The description is a single sentence with no filler, exactly no wasted words. It is suitably front-loaded, stating the operation and target immediately, and in concise terms earns its place in the definition.

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

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

With 9 parameters, 3 required ones, no output schema, and no annotations, the one-line description is materially incomplete. It does not explain how values map to DNS concepts, the permitted values for `type`, the meaning of `content` versus `value`, whether `proxied` is supported, or what success/error responses look like – so an agent cannot reliably make valid calls.

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 all 9 parameters, and the description contributes no parameter meaning beyond the existence of 'DNS record.' It leaves required parameters (`domain`, `name`, `type`), optional fields (`ttl`, `value`, `content`, `proxied`, etc.), and their mutual relationships completely undocumented; this fails the low-coverage requirement that the description compensate.

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

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

The description says 'Add a DNS record to a domain's zone,' which gives a specific verb ('add'), a concrete resource ('DNS record'), and a target location. This distinguishes it from DNS siblings like ecp_dns_list_records and ecp_dns_delete_record, though it stops short of explicitly contrasting with them.

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

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

No guidance is given on when to use this tool instead of ecp_dns_list_records, ecp_dns_delete_record, or domain-management verbs like ecp_domains_add_subdomain. There is no mention of preconditions, typical workflows, or cases where an alternative should be preferred.

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 clearly discloses that the operation is destructive and adds a key nuance: the record match is fuzzy — 'closely enough for the DNS provider to identify it — which is not inferable from the schema alone. It could also mention permanence or confirmation expectations, but the core behavioral trait is conveyed.

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 compact sentences with no filler. The action is stated first, and the crucial matching constraint is added in the second sentence without 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 DNS delete with a nested record object and required confirmation, the description covers the central matching behavior that could trip up an agent. There is no output schema and no explicit return-value information, but the action is simple enough that the missing details are unlikely to 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 description coverage is 0%, so the description must compensate for parameter understanding. It adds meaningful guidance by highlighting that name, type, and content are the matching fields on the record object. However, it does not explain the domain parameter or the confirm flag beyond what their names imply, leaving some semantic burden on the schema.

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

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

The description names a specific verb and resource: "Delete a DNS record from a domain's zone. It is immediately distinguishable from sibling tools like ecp_dns_list_records and ecp_dns_add_record because the action and target are explicit. No ambiguity remains 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 gives a useful prerequisite: the record must match an already-existing record closely enough for the provider to identify it. However, it never explicitly directs the agent to ecp_dns_list_records to fetch that record, nor does it state when not to use this tool. Usage context is implied by the tool name rather than explicitly routed.

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 of behavioral disclosure. It only says 'List DNS records,' which implies a read operation, but it doesn't disclose whether the list is paginated, sorted, filtered, or what happens if the domain doesn't exist. For a read tool, this is a moderate gap but not a contradiction.

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

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

The description is a single short sentence that is front-loaded with the action and resource. It is concise and easy to parse, though it could add a bit more useful context without becoming verbose.

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

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

Given the tool has one required parameter, no output schema, and no annotations, the description is too thin. It doesn't explain the return format, error behavior, or any domain validation rules. An agent would need to guess or call the tool to learn basic behavior.

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

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

Schema description coverage is 0%, and the description only mentions 'a domain's zone' without explaining the format or semantics of the 'domain' parameter. It doesn't clarify whether the domain should include 'www', a trailing dot, or a subdomain. The description adds minimal value beyond the schema's bare 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 and resource: 'List DNS records for a domain's zone.' This clearly identifies the operation. However, it doesn't explicitly distinguish itself from sibling tools like ecp_dns_add_record or ecp_dns_delete_record, though the verb 'list' makes the distinction fairly obvious.

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

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

No guidance is provided about when to use this tool versus alternatives. There is no mention of prerequisites, such as whether the domain must exist or be managed by the system, nor any exclusions. The context signals show many DNS-related siblings, but the description doesn't help an agent choose among them.

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 mutation (adding a domain) but doesn't mention potential side effects, DNS implications, ownership requirements, or whether the operation is reversible. The description is too thin to inform an agent about behavioral consequences.

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 core action. It is appropriately sized for a simple tool, though it could add a bit more context 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?

For a mutation tool with no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't explain the role of dns_server, what happens after adding a domain, or how to verify success. An agent would need to guess at important 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 0%, so the description must compensate. It only explains the 'domain' parameter implicitly ('additional domain') but says nothing about 'dns_server', which is a nullable string with unclear purpose. The description adds minimal meaning beyond the schema's bare 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 ('Add') and resource ('additional (addon) domain to this account'), which clearly identifies the operation. It distinguishes from siblings like ecp_domains_add_subdomain and ecp_domains_list_additional, though it doesn't explicitly name them.

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

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

No guidance on when to use this tool versus alternatives like ecp_domains_add_subdomain or ecp_domains_list_all. The description implies usage for adding an addon domain but provides no context about prerequisites, validation, or when not to use it.

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

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

With zero annotations, the description carries full responsibility for behavioral disclosure, but 'Add' reveals only that this is a mutation. It does not state whether re-adding an existing subdomain fails or overwrites, what side effects occur (auto DNS, web config, TLS), or any error/reversibility details, so the agent is left guessing about consequences.

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?

Eleven words, action front-loaded, and no filler or repetition. To ensure score faithfulness, every word earns its place and the same meaning-points cannot be further compacted without losing the ownership constraint.

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-string-parameter tool with no output schema or annotations, the description covers the essential intent and the key precondition. However it leaves post-conditions unexplained (whether the subdomain is immediately served, needs DNS records, or needs a certificate) and provides no error/failure context, so the agent must probe to be confident.

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 does map both parameters by naming 'domain' as the owned parent and 'subdomain' as the child being created. But it omits the required subdomain format (e.g., bare label 'www' vs. full 'www.example.com') and the exact relationship the schema expects, so compensation is partial.

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 provides a specific verb 'add' and a clear resource: a subdomain of an already-owned domain. The phrase 'a domain this account already owns' meaningfully distinguishes it from siblings like ecp_domains_add_domain and ecp_domains_delete, though it never names those siblings 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 ownership precondition is implied by 'a domain this account already owns,' suggesting the parent domain must exist first (via ecp_domains_add_domain). However, there is no explicit when/when-not guidance, no naming of alternatives, and no direction about whether to reach for ecp_dns_add_record instead when only a DNS name is needed.

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

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

With no annotations, the description carries the behavioral burden and explicitly states 'Irreversible,' which is critical for a destructive tool. It also discloses the primary-domain restriction. It does not describe downstream effects on subdomains or DNS records, but the core safety-relevant behaviors are covered.

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 convey the action, a key restriction, and irreversibility with no wasted words. The most important operational facts are front-loaded.

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

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

The tool is simple, and the description covers the action, a major constraint, and durability of the operation. However, it lacks guidance on what happens if the primary domain is attempted, what confirm must be set to, and whether related DNS or subdomain records are affected, leaving some context gaps given no annotations or output schema.

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

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

Schema description coverage is 0%, so the description must compensate for parameter meaning, but it only implicitly references 'domain' and says nothing about the required 'confirm' parameter or the domain format. The 'confirm: true' constraint is left entirely to 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: 'Delete a domain from this account.' It also adds a key differentiating constraint, 'Cannot delete the primary domain,' and the verb 'delete' clearly separates it from sibling tools like ecp_domains_add_domain and ecp_domains_set_redirect.

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 context is implied by the verb and resource—use this when you need to remove a domain. It provides one when-not condition ('Cannot delete the primary domain') but does not mention alternatives or any prerequisite step such as listing domains first.

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

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

With no annotations, the description carries the burden, and it clearly conveys a read-only listing operation scoped to addon domains. It does not mention response format or error behavior, but for a zero-parameter list operation these are less critical.

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 filler. The key distinction ('additional (addon) domains only') is front-loaded, and 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 zero-parameter list tool with no output schema, the description is sufficient to select and invoke it correctly. It could add a note about the return shape, but the core 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 tool has no parameters, and the schema documents this completely with empty properties and 100% coverage. There is nothing for the description to add about parameters; baseline 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?

States a specific verb ('List'), the resource ('additional (addon) domains'), and an explicit exclusion ('excluding the primary domain'). This clearly differentiates it from ecp_domains_list_all and other domain-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 words 'only' and 'excluding the primary domain' tell the agent when this tool is appropriate: when addon domains are needed and the primary domain is not. It does not explicitly name ecp_domains_list_all as the alternative for full domain lists, but the context 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?

With no annotations, the description carries the transparency burden. The verb 'List' clearly indicates a read-only, non-destructive operation. It states the exact data returned (every domain), which is sufficient for a simple list tool. No side effects or special behaviors are implied, and the description doesn't omit anything relevant for a tool with zero parameters.

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 zero waste. It immediately states the action and scope, and the qualification '(primary + additional)' is essential and placed right where it matters. Everything present 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 parameter-less list tool with no output schema, the description provides all necessary context: it lists every domain, specifies that both primary and additional are included, and ties to the account. There are no missing details that would prevent an agent from calling it correctly, given the simple nature of the 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 tool has zero parameters, so the baseline is 4. The description adds no parameter-specific information because none exists; the schema already covers the empty parameter set completely. The description correctly focuses on what the tool returns rather than on 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 verb 'List' and resource 'every domain (primary + additional) on this account' clearly define the tool's function. It explicitly distinguishes from the sibling ecp_domains_list_additional by covering both primary and additional domains, leaving no ambiguity about scope.

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

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

The description implies this is the comprehensive domain list, contrasting with the sibling that only lists additional domains. While it doesn't explicitly name the alternative, the phrase '(primary + additional)' signals that this is the full-list tool, and no exclusions are needed. This provides clear context without explicit when-not guidance.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only says 'Remove a domain's redirect.' It does not disclose whether this is destructive to the redirect configuration, whether it affects the domain itself, whether it requires the domain to currently have a redirect, or what the response/return value looks like. For a mutation operation with zero annotation coverage, this is a significant 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, concise sentence with no wasted words. It is front-loaded with the verb 'Remove' and the resource. It could arguably include more context, but for what it says, it is efficient and clear.

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

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

Given the tool's simplicity (1 parameter, no output schema, no annotations), the description is minimal but leaves out important context: what happens to the domain after redirect removal, whether the operation is idempotent, and what the expected result is. The sibling ecp_domains_set_redirect exists, so an agent would benefit from knowing the relationship. The description is not complete enough for an agent to confidently invoke this tool without additional assumptions.

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 for the undocumented 'domain' parameter. The description mentions 'a domain's redirect', which implies the 'domain' parameter identifies the domain whose redirect should be removed. However, it does not specify the expected format (e.g., domain name with or without protocol, subdomain handling, etc.). The description adds minimal meaning beyond the schema's bare 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 'Remove a domain's redirect.' clearly states the verb (remove) and resource (a domain's redirect). It distinguishes itself from the sibling ecp_domains_set_redirect, which is the inverse operation, and from ecp_domains_delete, which removes a domain entirely. However, it does not explicitly name these siblings or elaborate on what 'redirect' means in this context.

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: call this when you want to remove a redirect that was previously set on a domain. It does not explicitly state when to use this versus ecp_domains_set_redirect or ecp_domains_delete, nor does it mention any prerequisites (e.g., domain must exist, redirect must exist). The context is clear enough for a simple operation, but no explicit guidance is provided.

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

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does not mention what happens to existing redirects, whether the operation overwrites, side effects, or success/failure behavior. For a mutation tool with zero annotation coverage, this is a significant 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 concise sentence, which is appropriately short. However, its brevity comes at the cost of missing important details. It is not bloated, but it is also not fully developed to explain key aspects like parameter meanings or side effects.

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

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

Given the tool is a mutation with zero annotations and no output schema, the description is incomplete. An agent needs to know what a successful redirect entails, whether it replaces existing redirects, and any constraints (e.g., domain format). The current one-liner is insufficient for safe and 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 0%, so the description must explain the parameters. It only implies that 'redirect_target' is 'another URL' and mentions the example, but it does not clarify the meaning of 'permanent' vs 'temporary' for redirect_type, nor specify the format expected for the domain. The description adds minimal semantic value beyond the schema's raw 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 clearly states the action ('Redirect') and the resource ('a domain to another URL'), with a clarifying example ('www -> apex'). It is specific enough to understand the tool's function, but it does not explicitly contrast with sibling tools like ecp_domains_remove_redirect, so it misses the chance to fully differentiate.

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

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

The description provides no guidance on when to use this tool versus alternatives (e.g., when to remove a redirect or when to use a subdomain tool). It simply states what it does, leaving the agent to infer appropriate contexts without 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 burden. It states the tool creates an empty file, which implies a write operation, but doesn't disclose whether it overwrites existing files, what happens if the destination doesn't exist, whether parent directories are created, or what the response looks like. For a mutation tool with zero annotation coverage, this is a significant 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, efficient sentence with no waste. It's front-loaded with the core action. However, it's so brief that it sacrifices valuable context that could be added without much length.

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

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

For a 2-parameter mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain path semantics, overwrite behavior, or return values. The sibling list shows many file operations, but this description doesn't help the agent understand how this tool fits into the file management workflow.

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

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

Schema description coverage is 0%, so the description must compensate. It doesn't explain what 'destination' means (full path? directory?) or what 'file_name' should look like (extension? format?). The description adds no meaning beyond the parameter names themselves, leaving the agent to guess the semantics of both required 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 'Create a new empty file.' clearly states the verb (create) and resource (a new empty file). It distinguishes from siblings like ecp_files_add_folder (folder vs file) and ecp_files_write (which writes content vs creating empty). However, it doesn't explicitly mention the destination path or file_name parameters, which are the core of the operation.

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

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

No guidance on when to use this tool vs alternatives. It doesn't mention that ecp_files_write might be better for creating a file with content, or that ecp_files_add_folder is for directories. The context of 'empty file' is implied but no explicit when/when-not guidance is given.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the core creation action and omits important behaviors such as whether an existing folder causes an error, whether parent directories are created, and what permissions are involved.

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

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

The description is extremely short and contains no filler words, with the core action front-loaded. However, the brevity is achieved by omitting useful guidance, so it is not a fully appropriate size.

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 parameter descriptions, the description is too thin. An agent cannot determine expected path semantics, failure behavior, or return behavior.

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

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

Schema description coverage is 0%, and the description does not mention destination or folder_name. The parameter names are somewhat self-explanatory, but the description adds no meaning beyond the schema, and destination in particular is ambiguous without further 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?

The description clearly states a specific verb and resource: 'Create a new folder.' It is distinguishable from sibling tools like ecp_files_add_file and ecp_files_directory_tree, though it does not add any contextual detail about where or how the folder is created.

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 about when to use this tool versus alternatives such as ecp_files_add_file, ecp_files_write, or ecp_files_rename. No prerequisites, conditions, or exclusions are mentioned, leaving the agent 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state whether the operation is reversible, what errors might occur (e.g., file not found, invalid permission), whether it affects directories or symlinks, or what the response looks like. The 'chmod' verb implies mutation, but no impact details are 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 an inline example, which is efficient. The example is front-loaded. However, it omits critical details that could be added concisely, such as path resolution or format constraints, slightly reducing efficiency.

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 low schema coverage (0%), no output schema, and three required parameters with no enums, the description is incomplete. It fails to explain the relationship between the three parameters, the expected permission format beyond a single example, or the operational context (e.g., whether the file is in a remote system). An agent would be uncertain about how to handle 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 0%, so the description must compensate. The example 'new_permission: '644'' adds context for the permission format, which is helpful. However, 'current_directory' and 'file_name' are not explained beyond their names; the description does not clarify whether paths are absolute, if current_directory prefixes file_name, or how permissions should be formatted (e.g., leading zeros, symbolic).

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 ('chmod') and resource ('a file'), with an example of the format ('new_permission: '644''). It distinguishes itself from sibling file operations (e.g., write, delete, rename) by specifying it changes permissions specifically. However, it does not explicitly contrast with other permission-related operations, though none exist among siblings.

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

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

The description gives no guidance on when to use this tool versus alternatives. It does not mention that this is the only tool for permissions, nor does it clarify scenarios like user/group ownership, recursive changes, or symbolic vs. octal modes. It only implies usage for changing permissions without any explicit context or exclusions.

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

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

With no annotations, the description bears the full burden of behavioral disclosure, but it only states the action. It does not reveal important behavior such as the archive format (zip/tar/gz), what current_directory is used for, whether existing output files are overwritten, or how paths are resolved. The description confirms the tool creates an archive but leaves significant side effects and constraints 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?

The description is a single efficient sentence with no filler words. It front-loads the action and resource, which is appropriate for a straightforward tool. It is concise, though arguably too sparse, which is a completeness issue rather than a structure issue.

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 that creates an archive, has no annotations, no output schema, and 0% schema coverage, the description is under-specified. It omits archive format, path resolution semantics, overwrite behavior, return values, and the role of current_directory. An agent would not have enough information to safely invoke this tool with confidence.

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%, so the description must compensate for parameter meaning. 'Files/folders' loosely maps to file_paths and 'archive' maps to output_filename, giving some hint, but current_directory is entirely unexplained. The description does not clarify whether paths are relative to current_directory, whether it must be absolute, or how the parameters relate to each other.

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 ('Compress') and resource ('files/folders into an archive'), making the tool's core purpose clear. It does not explicitly distinguish this from the sibling ecp_files_extract, but the action is unambiguous enough that an agent can tell it is the compression counterpart.

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

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

The description gives no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. While it implies 'use when you need to create an archive,' it does not mention the sibling extract tool or any conditions that would make compression inappropriate.

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 present, the description carries the full burden of behavioral disclosure. It conveys that the operation is a copy (source preserved, destination created) but omits critical behavior such as overwrite semantics, whether the destination is a directory path or a full file path, handling of existing destinations, and whether intermediate directories are created. For a file-operation tool this is a significant 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 short sentence that conveys the core action immediately. It is concise and front-loaded, though it achieves this by omitting behavioral details. For conciseness itself, it scores well.

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

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

There is no output schema and no annotations, so the description is the only context. It fails to mention overwrite behavior, directory creation, destination interpretation, error handling, or how this differs from move/copy_multiple. The description is too minimal to support correct invocation in edge cases, though the basic copy operation is understandable.

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 only parameter names (file_path, destination) with no descriptions or formats interested. The description names the parameters implicitly ('Copy one file/folder to a destination') but adds no detail about path syntax, directory-vs-file semantics, or naming behavior. Some meaning can be inferred from parameter names, but the description does not clarify critical details such as whether destination is a directory or a full target path.

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 ('Copy') and a clear object ('one file/folder to a destination'), so an agent can tell this is a copy operation. However, it does not distinguish itself from closely related siblings like ecp_files_copy_multiple, ecp_files_move, or ecp_files_rename beyond the word 'one'. The purpose is minimally clear but lacks any differentiation from alternative 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 no guidance on when to use this tool versus ecp_files_copy_multiple, ecp_files_move, or ecp_files_add_file. There are no conditions, prerequisites, or examples indicating appropriate use. An agent must infer usage entirely from the tool name and sibling names.

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

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

With no annotations, the description must convey behavioral context. It hints at a copy operation but doesn't confirm non-destructiveness, error handling, or whether the source can be a folder. The term 'copy' implies non-destructive, but this is not explicit, and no additional context is provided.

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

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

The description is a single, concise sentence that is easy to read and front-loads the action. It is not overly verbose, but its brevity contributes to the lack of 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?

Given the tool's complexity (copying multiple files/folders) and lack of annotations or output schema, the description is insufficient. It doesn't explain crucial aspects like whether copying a folder is recursive, how conflicts are handled, or what the return value is. More detail is needed for an agent to use it correctly.

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

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

Schema description coverage is 0%, so the description must explain the parameters. It mentions 'file_paths' and 'destination' in the name context but doesn't clarify formats (e.g., absolute paths, handling of multiple items, whether destination can be a directory). The description is too brief to compensate for the missing schema details.

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 action ('Copy multiple files/folders') and the target ('to a destination') clearly. However, it doesn't distinguish from sibling tools like ecp_files_copy, ecp_files_move_multiple, or ecp_files_move, which could be ambiguous to an agent.

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

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

The description provides no guidance on when to use this tool versus alternatives like ecp_files_copy for single items or ecp_files_move_multiple for moving. It doesn't mention that 'copy' is non-destructive, nor does it specify any constraints on source/destination paths.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It does state the critical fact that deletion is 'Irreversible,' which is essential for a destructive operation. However, it does not mention the required confirmation flag, whether folder deletion is recursive, or any permissions needed.

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 action is front-loaded, and the critical warning 'Irreversible' is placed immediately after. 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?

The tool is simple and the schema is minimal, but with no annotations and no output schema, the description could do more. It omits the confirmation requirement and expected outcomes or errors, leaving some important context for an agent deciding whether 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%, and the description adds almost no parameter-level meaning. It implies file_path by saying 'file or folder' but does not explain the confirm parameter or its true-required semantics, which is a meaningful gap for a destructive operation.

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: 'Delete a single file or folder.' It clearly scopes the operation to a single item, which differentiates it from the sibling ecp_files_delete_multiple and related file operations like rename or move. The purpose is immediately understandable.

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 'single file or folder' provides clear context for when this tool applies, but it does not explicitly name alternatives such as ecp_files_delete_multiple for batch deletions. It implies the boundary without stating when-not-to-use or exclusions explicitly.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It warns of deletion but doesn't state that the operation is irreversible, whether confirmation is required beyond the confirm parameter, whether it's recursive for folders, or whether there are any safeguards, error behaviors, or implications for the filesystem. This is a destructive operation with a `confirm` parameter, so those details are critical.

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, front-loaded with the action and object. It earns its place with no padding. Extremely concise.

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

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

For a destructive batch operation with two parameters (confirm constraint, string array) and zero schema descriptions, this is thin. It doesn't state that confirm must be exactly true, whether the array accepts full paths vs relative paths, whether items are deleted recursively, or what the confirmation pattern is. The high-consequence nature of the operation demands more.

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 description adds minimal parameter meaning. It clarifies that file_paths refers to 'multiple files/folders', which is some value, but it doesn't explain the confirm-requires-true contract, path format expectations, or deletion semantics. The description partially compensates for the schema gap but not enough to achieve a 3.

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

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

The description states 'Delete multiple files/folders' with a specific verb (delete) and resource (files/folders), which clearly conveys the tool's core action. It distinguishes reasonably from the sibling ecp_files_delete (singular) by implying batch operation, though it doesn't explicitly contrast them.

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

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

No guidance on when to use this tool versus alternatives like ecp_files_delete, ecp_files_move, or ecp_files_rename. There's no context about batching use cases, prerequisites, or when the singular delete is preferable. The agent gets no selection help beyond 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?

With zero annotations, the description carries the full burden, but it only reveals that it includes files. It does not say whether it is read-only, whether it recurses, what the output shape is, or what `hidden_files` does. Even a read tool should state it is non-mutating and whether the tree is recursive.

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 tight sentence with the core purpose upfront and the sibling distinction in a parenthetical. Every word earns its place; 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?

With no output schema, no annotations, and undocumented parameters, the description provides only a high-level purpose and a sibling comparison. It leaves an agent guessing about path format, recursion, output contents, and the meaning of `hidden_files`.

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 for the two undocumented parameters (`directory`, `hidden_files`). It says absolutely nothing about what these parameters mean, what format directory takes, or what the default behavior is for hidden files. This is a critical 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 states a specific verb and resource ('Get the directory tree including files') and explicitly distinguishes itself from the sibling ecp_apps_directory_tree ('which is folders only'). An agent can tell this apart from the main alternative without looking at 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?

The description explicitly names the alternative tool (ecp_apps_directory_tree) and states the condition that selects this one: when you need files included, unlike that sibling which is folders only. 'Mobile' is not needed but it gives clear context for the correct situation.

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 mentions the core extraction action but does not disclose whether the destination directory must already exist, whether files are overwritten, what archive formats are supported, 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?

A single, front-loaded sentence with no filler. Every word contributes to understanding 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?

Given the lack of annotations, output schema, and parameter descriptions, this definition is too sparse. An agent cannot determine preconditions like whether the destination must exist, or postconditions like what files are written, making correct invocation and sequencing uncertain.

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%, so the description must compensate. It adds some meaning by labeling file_path as an archive and destination as a directory, but it omits useful constraints such as supported archive formats, path conventions, or directory creation 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 ('Extract') and resource ('archive into a destination directory'), making the tool's function immediately clear. It also distinguishes itself from sibling operations like ecp_files_compress or ecp_files_copy.

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

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

Usage is implied by the description: it should be used when an archive needs to be extracted to a directory. However, there is no explicit guidance on when to choose this tool over alternatives or when not to use it.

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

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

The description conveys the core behavior—checking existence—and implies a read-only operation, but it does not explicitly state whether it returns a boolean, raises errors for missing paths, or requires permissions. With no annotations to fill this gap, the behavioral picture is adequate but minimal.

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

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

The description is a single front-loaded sentence that states the operation with no wasted words. It is appropriately sized for a simple predicate 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 existence check, the description is minimally viable. However, with no output schema and no annotations, it leaves the return format and path semantics unstated, so the agent must rely on inference and naming 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 only parameter, 'directory', is self-describing by name, but the description adds no guidance on expected format (absolute vs. relative path), symlink behavior, or whether the directory must be accessible. At 0% schema description coverage, the description needed to compensate and did 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 uses a specific verb ('Check') and a specific resource ('a directory'), and the tool name narrows it to existence testing. This clearly sets it apart from sibling file tools like ecp_files_list, ecp_files_directory_tree, and ecp_files_read.

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

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

The description provides no guidance on when to use this tool versus alternatives, such as before creating or accessing a directory. It names no exclusions, preconditions, or sibling tools that might be more appropriate for related tasks.

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

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

With no annotations provided, the description must carry the behavioral disclosure burden. It conveys that this is a non-mutating list operation, but it does not disclose whether hidden files are included by default, whether it recurses into subdirectories, or what shape the returned list takes.

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 or redundant wording. It loses a point only because its extreme brevity leaves important parameter and behavioral context unaddressed, though the concision itself is effective.

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

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

Given no annotations, no output schema, and no parameter descriptions, the description is not complete enough for confident invocation. Missing details include the optional/required nature of directory, hidden_files semantics, default behavior, and the format of the returned listing.

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 either 'directory' or 'hidden_files.' The agent is left to guess whether directory is a path or identifier, whether it has a default, and exactly what the hidden_files boolean controls.

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: 'List files/folders in a directory.' This is clear enough for an agent to understand the basic operation, but it does not distinguish this tool from closely related siblings such as ecp_files_directory_tree, ecp_files_read, or ecp_files_is_directory_exists.

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

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

The description provides no guidance on when to use this tool versus alternatives like ecp_files_directory_tree or when a different file-listing approach would be preferable. There is no mention of context, exclusions, or sibling selection 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 does not mention whether the move overwrites existing files, whether it works across filesystems, whether the destination must be a directory, or what happens on failure. The description only states the action without any 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 short sentence with no wasted words. It is front-loaded with the verb and resource. However, it is so terse that it sacrifices useful detail, though conciseness itself is appropriate.

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 file operation with no annotations, no output schema, and 0% parameter coverage, the description is incomplete. An agent needs to know whether destination is a directory or full path, whether overwrite is allowed, and what the return value indicates. The sibling set includes move_multiple, copy, and rename, so more context is needed to select and invoke this 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 0%, so the description must compensate for the two parameters. It does not explain what file_path and destination mean beyond their names, nor does it clarify whether destination is a directory or a new full path. The description adds no parameter-level meaning.

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

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

The description states a clear verb ('Move') and resource ('one file/folder') with a destination. It distinguishes itself from siblings like ecp_files_copy and ecp_files_move_multiple by specifying 'one' file/folder, though it doesn't explicitly name those alternatives.

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

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

No guidance is given on when to use this tool versus ecp_files_move_multiple or ecp_files_copy. The description implies a single-item move but doesn't state exclusions or alternatives, leaving the agent to infer the distinction from sibling names.

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

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

No annotations are provided, so the description carries the full burden. It states 'move' which implies a destructive operation on the source files, but doesn't disclose what happens on partial failure, whether the destination must already exist, or whether overwrites are allowed. The schema is similarly bare, so the agent gets no behavioral guidance at all.

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

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

One short sentence that communicates the core action. It doesn't waste words, but it also doesn't add any detail beyond the name and schema. As a descriptive sentence it is minimal but functional.

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 multi-file move operation, the description lacks critical context: destination semantics (directory vs exact path), behavior on collisions, whether overwriting occurs, permission/authorization requirements, and any limitations on the number of files. The sibling set includes ecp_files_copy_multiple and ecp_files_move (single), but nothing distinguishes this from ecp_files_move other than pluralization. The description doesn't mention return values or errors either.

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 two parameters (file_paths and destination) are completely undocumented in the description. Schema coverage of semantics is near zero: we only know types and that both are required. The description's phrase 'move files to a destination' strongly implies the parameters but adds no detail about acceptable path formats, whether source file paths must exist, overwrite behavior, or handling of folders. With minimal schema infoفق, the description should compensate but doesn't.

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, 'Move files', clearly states the verb (move) and resource (files), and the name 'ecp_files_move_multiple' implies batch semantics. However, it does not explicitly distinguish itself from sibling `ecp_files_copy_multiple` or `ecp_files_move` (which doesn't exist in the sibling list but 'ecp_files_copy_multiple' does), so there's minor ambiguity about whether multiple means batch versus single.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives like ecp_files_copy_multiple or ecp_files_move (if it exists). The context is fuzzy – it says 'move multiple files' but doesn't clarify when an agent should choose this over single-file move or copy operations.

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

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

No annotations are provided, so the description must carry the burden of behavioral disclosure. It only says 'read... content' but does not mention side-effect-free behavior, file size or encoding limitations, permission requirements, or what happens if the file is missing or not a text file. The disclosure is minimal and lacks the behavioral detail needed when annotations are absent.

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

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

The description is a single sentence with no fluff and is front-loaded with the action and object. It is appropriately compact for such a simple tool, though it is terse enough that it approaches under-specification rather than true 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?

With no annotations and no output schema, the description should fill in what an agent needs to know. It doesn't explain the return value format or path constraints, and while the operation is simple, the lack of any behavioral or output details leaves important gaps for confident 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?

The schema has 0% description coverage, and the description adds no detail about the file_path parameter. It doesn't explain whether paths are absolute or relative, what path scope is allowed, or what format the parameter should take. This leaves the agent to guess the path semantics, a significant 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 clearly states a specific action ('read') and a specific resource ('a text file's content'). It distinguishes itself from sibling file tools such as ecp_files_write, ecp_files_list, and ecp_files_directory_tree by saying exactly what is returned. An agent can immediately tell this tool is for retrieving file contents.

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

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

The description gives no guidance on when to use this tool over alternatives. There are no references to companion tools like ecp_files_list or ecp_files_directory_tree, no exclusions, and no prerequisites. The agent must infer usage from the tool name and one-sentence purpose.

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

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

No annotations exist, so the description carries the full burden of behavioral disclosure. It states the mutation but omits important details such as overwrite behavior, path restrictions, error conditions, or whether new_name may include a different directory.

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 core operation is front-loaded and every word earns its place. It is a model of concise description, even though it sacrifices depth.

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 underexplained parameters, the description is too thin. It leaves meaningful ambiguity around overwrite behavior, path semantics, and how it relates to move/copy sibling tools.

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

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

Schema description coverage is 0%, and the description adds no parameter-level details. The parameter names and the phrase 'within a directory' hint at basic meaning, but path format and whether new_name can move the item are left unexplained.

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 ('rename') and resource ('file or folder within a directory'), so the operation is clear. It does not explicitly contrast it against sibling tools like ecp_files_move or ecp_files_copy, but the rename action is reasonably distinguishable.

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

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

No guidance is provided about when to use this tool instead of alternatives. There is no mention of prerequisites, exclusions, or when a move/copy operation 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?

With no annotations present, the description carries the full behavioral disclosure burden and does disclose the overwrite/create semantics and the risky effect on a running app. However, it fails to mention the mandatory `confirm` gate, whether the overwrite is irreversible, or what happens on errors or path issues.

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 worded, front-loaded sentences. The core action is stated first and the risk/recommendation follows immediately, with no distracting detail 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 three-parameter mutation tool with 0% schema description coverage and no annotations or output schema, the description is underdeveloped. It leaves the `confirm` flag, error behavior, file-path semantics, and safety details unspecified, so an agent cannot confidently invoke the tool correctly from this definition alone.

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

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

The input schema has 0% description coverage and the description does not effectively compensate. It only hints that file_content is text, but does not clarify file_path format, that confirm must be true, or the relationship between parameters and the described 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 opening line states a specific operation (overwrite) on a specific resource (a text file's content) and adds that creates file if it doesn't exist, distinguishing it from read, list, and most delete/rename tools. The description does not name a specific sibling alternative, but the action semantics are clear enough to separate it from the many other file 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 supplies context relevant to choosing this tool: it's for replacing file content, with a caution about breaking running apps when the file is a config/env/source file and a suggestion to review it first. It does not name sibling tools or state when to prefer this over alternatives, leaving 'when to use' mostly implicit.

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 a key limitation: the tool only returns a URL and cannot complete OAuth itself, which is valuable. However, it does not mention any side effects, prerequisites (e.g., whether the provider must already be configured), or error conditions. The description gives the essential behavior but not a comprehensive picture.

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

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

The description is two concise sentences with no redundancy. It front-loads the primary action ('Get the OAuth authorize URL') and then adds the essential caveat about opening it in a browser. 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 tool with a single parameter and no output schema, the description covers the core purpose and the critical caveat about browser completion. It does not mention whether the URL is one-time or whether the user should first check existing connections (via ecp_git_list_connections), but given the tool's simplicity, this is not a significant gap. The description is adequate for an agent to use the tool correctly.

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

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

The description does not elaborate on the 'provider' parameter, but the enum in the schema (github, gitlab, bitbucket) makes the valid values clear. Since the tool is specifically for git providers and the parameter is self-explanatory, the description adds no extra meaning. With 0% schema description coverage, it would benefit from a note like 'Specify the provider you want to connect,' but the enum suffices for correct invocation.

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

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

The description clearly states the tool's function: retrieving an OAuth authorize URL for connecting a git provider. It uses a specific verb ('Get') and a precise resource ('OAuth authorize URL'), and distinguishes itself from sibling tools like ecp_git_list_providers or ecp_git_list_connections by focusing on the authorization step. No 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 explicitly instructs to open the URL in a browser and notes that the tool cannot complete OAuth itself, giving clear guidance on the immediate next step. It implies this is the initial step in connecting a provider, but does not explicitly mention alternatives or when not to use it. The context is sufficient for an agent to know 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?

No annotations are provided, so the description carries the full burden, but it only states the disconnect action without disclosing consequences such as whether connected repositories, webhooks, or OAuth tokens are affected. The confirm:true parameter hints at destructiveness, but the description does not explain it.

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

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

The description is a single, front-loaded sentence with no filler. It is appropriately short, though it slightly repeats the connect root in 'disconnect/connected'.

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 potentially destructive action with no annotations and no output schema, the description should explain preconditions, side effects, and success behavior. It only offers a terse statement of the action, leaving important context unanswered.

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 adds no parameter-level meaning. The provider enum and the confirm const:true are only visible in the schema, with no explanation of what they mean or why confirmation is required.

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

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

The description uses a clear action verb ('Disconnect') and a specific resource ('connected git provider'). It distinguishes the tool from related git management siblings like ecp_git_list_connections and ecp_git_authorize_url, though it does not explicitly name them.

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

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

There is no guidance about when to use this tool versus alternatives, nor any mention of prerequisites such as requiring an existing connection. The intended use is only implied by the tool name and brief 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?

No annotations are provided, so the description must carry behavioral disclosure. It merely says 'List', which implies a read-only operation, but does not explicitly state that it has no side effects, nor does it mention authentication, rate limits, or any other behavioral traits. The description adds no insight beyond the tool name.

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

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

The description is a single, clear sentence with no fluff. It is front-loaded with the action and object, making it immediately understandable. 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 list operation with no parameters and no output schema, the description is complete enough. It clearly states what it lists. It does not explain the return format, but that is largely self-evident for a list operation. No critical information is missing 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 the schema trivially covers 100% of them. The description adds no parameter information because there are none. Per the baseline rule for zero-parameter tools, a score of 4 is appropriate since there is nothing to document beyond the schema.

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

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

The description clearly states a specific verb ('List') and resource ('this account's connected git accounts'), which unambiguously distinguishes it from siblings like ecp_git_list_providers (available providers) and ecp_git_list_repos (repositories). No ambiguity in 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 provides no explicit guidance on when to use this tool versus alternatives. While the name implies it is for listing connections, it does not mention sibling tools or conditions for selection, leaving the agent to infer the appropriate context.

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

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

With no annotations, the description must carry the load. It does reveal a read-only, scope-limited behavior ('enabled for this install'), but it does not mention permissions, return format, or any edge cases like unknown providers.

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. The parenthetical list of provider names is compact and adds meaning without bloating the text.

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

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

For a zero-parameter, no-output-schema list operation, the description adequately conveys the operation, scope, and result subject. It is enough for an agent to invoke the tool correctly, though a bit more detail about the return shape would fully close the 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 has zero parameters and 100% schema coverage, so there is nothing to document. The description adds useful domain context by enumerating the provider types (GitHub/GitLab/Bitbucket), making the baseline of 4 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 verb ('List'), the resource ('git providers'), and narrows it to GitHub/GitLab/Bitbucket enabled for the install. This is distinguishable from siblings like ecp_git_list_connections and ecp_git_list_repos.

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

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

No explicit guidance is given about when to use this tool versus related git tools such as ecp_git_list_connections or ecp_git_authorize_url. The intended use case must be inferred from the name and 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?

With no annotations, the description carries the transparency burden, and it does signal that this is a read-oriented browsing operation that depends on an existing provider connection. It doesn't disclose behavior like pagination, result ordering, or the absence of filtering, but for a simple browse tool this is adequate.

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

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

A single sentence with no filler; the key scoping information and purpose are front-loaded. Every word contributes meaning, making it an efficiently structured description.

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 list/browse tool with three parameters and no output schema, the description is minimally sufficient but leaves gaps: it doesn't explain that provider must correspond to an already-connected provider or how page/search affect results. An agent can call the tool correctly using the schema, but not with full confidence about behavior.

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

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

Schema description coverage is 0%, so the description needed to compensate by explaining provider, page, and search, but it does not address any of them. The only indirect hint is 'connected git provider', which loosely relates to the provider parameter; page and search are left entirely to inference from their names.

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

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

The description names a specific verb ('Browse') and resource ('repos available via a connected git provider'), and adds the purpose 'for picking one to deploy from'. It is clearly distinct from sibling git tools like list_providers and list_connections, though it does not explicitly call them out.

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

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

The parenthetical 'for picking one to deploy from' provides a clear use case for when this tool should be selected. It does not, however, explicitly exclude alternatives or explain when list_connections/list_providers 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?

With no annotations, the description must carry the full behavioral disclosure burden. 'Get' implies a read-only operation, but it does not explicitly state that it makes no modifications, nor does it mention potential failure conditions (e.g., app has no git provider) or permission requirements.

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

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

The description is a single concise sentence with no filler, but it is too terse to convey necessary context. It is front-loaded with the verb, but omits essential details that could be included without much bloat.

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

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

Given no output schema, no annotations, and a single parameter, the description is incomplete. It does not explain what the response will contain (e.g., a list of supported events, boolean flags), nor how it relates to the other git webhook tools. An agent cannot confidently infer the tool's full behavior from this 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?

The only parameter, app_id, is completely undocumented. The schema has 0% description coverage and the tool description does not explain what app_id refers to or how it is used. The agent is left to infer from the name alone.

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

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

The description states a specific verb 'Get' and a resource: 'webhook features the app's git provider supports.' This distinguishes it from siblings that create/update/delete webhooks or list providers/repos. However, 'webhook features' is vague – it doesn't specify what kinds of features (e.g., events, secret rotation) are queried.

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

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

No guidance is provided on when to use this tool versus alternatives like ecp_git_webhook_create or ecp_git_webhook_get. The natural use case (checking capabilities before creating a webhook) 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?

With no annotations, the description carries the full burden. It does disclose the primary behavioral effect: 'runs `commands` automatically whenever a matching push arrives' and includes a safety warning to review commands before confirming. However, it does not mention potential side effects such as overwriting existing webhooks, required permissions, or irreversibility, leaving gaps in transparency.

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

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

The description is extremely concise: two sentences with no fluff. The primary purpose is front-loaded, and the warning about reviewing commands is relevant and placed after the core action. Every sentence contributes meaning, and nothing is repetitive.

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 creation tool with 5 parameters, no output schema, and no annotations. The description is sparse and does not explain key parameters or the interaction between them (e.g., how provider and branch_filter affect the webhook). It also omits any mention of what the response will contain or any side effects beyond running commands. An agent would struggle to construct a correct request without additional information.

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 for parameter documentation. It only hints at two parameters: `commands` (runs commands) and `confirm` (review before confirming). It does not explain `app_id`, `provider`, or `branch_filter`, which are critical for correct invocation. The description adds minimal value beyond the schema and fails to cover all 5 parameters.

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

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

The description clearly states the action: 'Create a deploy webhook for an app.' It specifies the resource (webhook) and the verb (create), and distinguishes itself from sibling tools like get/update/delete by the explicit creation intent. It also elaborates on the purpose by explaining the webhook runs commands on matching pushes.

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 want to create a new deploy webhook) but does not explicitly differentiate it from alternatives like ecp_git_webhook_update or delete. No exclusions or conditions are provided, so the guidance is only implied rather than explicit.

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 operation is 'Irreversible', a key behavioral trait. However, with no annotations provided, it carries the full burden of behavioral disclosure but does not mention other aspects like required confirmation (though the schema implies it) or any side effects beyond permanence.

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

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

The description is extremely concise, using two short sentences to convey purpose and a critical caveat. It is front-loaded with the action and resource, and 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 only two parameters and no output schema, the description is fairly complete. It states the action and irreversibility, but it could have mentioned the confirmation requirement or the impact on the app's deployment workflow. Given the simplicity, it is adequate but not rich.

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 provides no explanation of the parameters app_id and confirm. Schema coverage is 0%, so the description should compensate but does not. The confirm parameter's const true requirement is only visible in the schema, and the description does not clarify that confirmation is mandatory.

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 'Delete' and the resource 'an app's deploy webhook', making the operation unambiguous. It also distinguishes from sibling webhook tools like get, create, update, and rotate_secret by specifying the destructive action.

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

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

There is no guidance on when to use this tool versus alternatives. It does not mention conditions, prerequisites, or any exclusions. The agent is left to infer that deletion is appropriate only when a webhook should be removed permanently.

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?

There are no annotations, so the description carries the behavioral burden. The verb 'List' clearly signals a read-only operation, and the debugging purpose implies the response includes delivery attempt details. However, it does not mention any other behavioral traits (pagination, sorting, failure details, or if it's merely a summary). For a list operation this is acceptable but not fully 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 sentence with no unnecessary words. The primary action and resource are front-loaded, and the scope of purpose is added in a short parenthetical. No filler or repetition exists.

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

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

For a simple one-parameter read operation, the description covers the essential points: what it lists, whose history, and why. There is no output schema, so the description should ideally hint at what fields are returned, but the debugging purpose implies the relevant data will be present. This is complete enough for an agent to call and interpret: use it, inspect the returned delivery records.

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's phrase 'app's webhook delivery history' directly ties the sole parameter app_id to the app whose deliveries should be listed. Since the schema provides no description for app_id, the tool description compensates well by giving the parameter clear purpose.

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

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

The description uses a specific verb ('List') and a specific resource ('app's webhook delivery history'). It also states the intended use case ('for debugging why a push didn't deploy'), which distinguishes it from the sibling webhook management tools that configure webhooks rather than inspect their delivery attempts.

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

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

The parenthetical provides clear diagnostic context: use this when investigating a failed deployment. It does not explicitly name alternatives or state when not to use it, but the use case is specific enough that only a minor echo of 'when not' would bring it to 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get' conveys a read-only, non-mutating operation, which is the key behavioral trait, but the description adds no further context such as side-effect absence, response behavior, or error conditions. This is minimal but not misleading.

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 words. Every part contributes meaning, and 'Get' immediately signals the operation type. This is appropriately concise for a simple getter 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?

The tool is simple: one parameter, no output schema, no annotations. The description identifies the resource and the return concept ('config and status), which is adequate for a minimal getter. However, the lack of parameter semantics and absence of any return format or usage-against-siblings guidance leaves some gaps for an agent trying 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?

The schema has 0% description coverage and the description does not mention the `app_id` parameter at all. The parameter name is self-explanatory as an app identifier, and the schema gives its type, but the description adds no additional meaning such as where the app_id comes from or how it should be formatted. With no compensation for the low coverage, this is a clear 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 ('Get') and names a specific resource ('an app's git deploy-webhook config and status'), which makes the core purpose clear. It is readily distinguishable from the webhook create/update/delete siblings, though 'status' could be more clearly separated from related tools like ecp_git_webhook_deliveries or ecp_git_webhook_capabilities.

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 context is implied: the agent should call this when it needs the current git deploy-webhook configuration/status and not when it wants to create, update, or delete a webhook. However, the description does not explicitly state when not to use it or name alternative tools, so an agent must infer the boundary from the verb and sibling names.

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 burden of behavioral disclosure. It does state a key side effect ('invalidates the old value'), which is helpful. However, it does not mention the need for an explicit confirmation, the fact that a new secret will be generated (and how that new secret is surfaced to the agent/user), or any other possible operational consequences.

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 front-loads the main action and the primary behavioral effect. It does not waste words, though it could be expanded slightly to hint at the confirm requirement without hurting 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?

Given the lack of annotations, no output schema, and a bare parameter schema, the description leaves important gaps: the purpose of 'confirm', what the tool returns (e.g., the new secret), and what happens if the app has no webhook. An agent cannot fully understand the tool's contract from the provided description and schema alone.

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 only hints at 'app_id' by referring to 'an app', but does not clarify its nature or format. The 'confirm' parameter — a boolean const true — is completely unexplained, leaving unstated that the user must explicitly confirm this destructive operation. Since schema coverage is 0%, the description partially compensates for app_id but fails on confirm.

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 ('Rotate') and names a precise resource ('app's deploy-webhook secret') with a clear effect ('invalidates the old one'). This distinguishes it from sibling tools like ecp_git_webhook_create, ecp_git_webhook_update, and ecp_git_webhook_delete, although it does not explicitly contrast with them.

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

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

The description tells what the tool does but provides no guidance on when to choose rotation over updating or deleting a webhook, or any situational triggers. There are no explicit use-case conditions or exclusions, so the agent must infer the selection from the name and prior knowledge.

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