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

With no annotations, the description carries the full burden of disclosing behavior. It does clearly indicate that unused Docker images will be removed, but it leaves 'unused' undefined and does not explicitly warn that the cleanup is destructive/irreversible. This is a moderate transparency gap for a cleanup operation.

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

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

The description is five words long, immediately front-loads the action and target resource, and contains no filler. It earns its place without being 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?

The tool has no parameters, no output schema, and no annotations, so this sentence is the main source of context. It conveys the core action but omits safety/irreversibility information and does not route the agent away from the potentially overlapping system_prune sibling. Adequate for invocation, but not fully complete 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 tool has zero parameters, so the 0-param baseline applies and there is no parameter meaning for the description to clarify. The phrase 'Docker images' helps orient the agent to the target resource, but no parameter-level detail 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 states a specific verb ('clean up') and resource ('unused Docker images'), making the tool's basic function clear. It does not explicitly distinguish itself from the sibling system_prune, which could plausibly overlap in scope, so it falls just short of 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?

There is no guidance on when to use this tool versus alternatives such as system_prune, nor any statement of prerequisites, exclusions, or safety considerations. The intended usage is only implied by the verb phrase.

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 behavioral disclosure burden on its own. It only says an app service is created, without describing side effects, prerequisites, required permissions, failure modes, or what happens to related resources.

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

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

The description is a single short sentence with no filler, making it easy to parse. However, the brevity mostly reflects a lack of substantive guidance rather than efficient packing of useful information.

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

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

For a simple tool with two fully documented string parameters, the basic invocation is understandable from the description and schema. Still, with no annotations and no output schema, it does not explain return behavior, whether the project must already exist, or how this step fits into the app lifecycle.

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?

Both parameters are already described in the input schema with 100% coverage, giving basic meaning to projectName and serviceName. The description adds no additional semantics about their relationship, accepted formats, or constraints, so the schema remains the primary source of parameter meaning.

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

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

The description states a concrete action and resource: create an app service. It is clearly distinct from siblings like create_project and create_database, though it does not explicitly differentiate from deploy_app or other app lifecycle tools.

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

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

No guidance is provided about when to use create_app versus deploy_app, inspect_app, start_app, or destroy_app. There are no exclusions, prerequisites, or alternative conditions stated, so the agent must infer usage from the tool name.

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

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

With no annotations provided, the description carries the full burden of explaining side effects and behavior. It only says 'Create a Docker Compose service,' which implies mutation but does not disclose whether the service is persisted, whether it deploys immediately, what prerequisites exist, or how it interacts with the project. This is insufficient for a create operation with no safety annotations.

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

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

The description is a single, front-loaded sentence with no wasted words, which is structurally clean. However, it essentially restates the tool name and provides no added detail, so the brevity is under-specification rather than helpful conciseness. It is adequate but not exemplary.

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

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

For a two-parameter creation tool with no output schema and no annotations, a description should at least clarify lifecycle context: does this create a service definition in an existing project, and is deploy_compose needed afterward? The current description leaves those critical workflow details unspecified, making it incomplete for reliable agent use.

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

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

Schema description coverage is 100%, so the schema already documents both parameters at a basic level. The description adds no extra meaning about the relationship between projectName and serviceName, such as whether projectName must refer to an existing project or whether serviceName is a new definition. Baseline 3 applies because the schema handles the parameter names and the description does not undermine that.

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 action ('Create') and a specific resource ('a Docker Compose service'), and the resource name distinguishes it from siblings like create_app and create_database. However, it does not explicitly differentiate itself from create_app or say how a Compose service relates to a project, so it is clear but lacks sibling differentiation.

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

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

There is no guidance about when to use this tool versus alternatives. Nothing indicates whether it should be used before deploy_compose, whether it requires an existing project, or how it differs from create_app or create_project. The agent must infer usage entirely from the tool name and parameters.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Create a database service' – no mention of side effects, required permissions, whether creation is asynchronous, whether it can fail due to resource limits, or what resources are provisioned. This is a significant gap for a mutating tool.

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

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

The description is extremely short and free of fluff, but it is also under-specified. It essentially restates the tool name with 'database service' and does not add valuable context. While concise, it does not earn its place because it provides little beyond the name.

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

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

For a 4-parameter creation tool with no output schema and no annotations, the description is incomplete. It lacks prerequisites, post-conditions, return value information, and any caveats about engine selection or password handling. The schema fills some gaps, but the description alone is not sufficient for correct invocation.

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

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

Schema description coverage is 75% (projectName, serviceName, and password have descriptions; engine has an enum). The description adds no parameter meaning beyond the schema. It does not clarify the engine enum choices or confirm that password auto-generation behavior is relevant. The high schema coverage keeps this at baseline 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 a clear verb and resource: 'Create a database service'. It is distinct enough from siblings like create_app or create_project, though it does not explicitly distinguish itself from other create_* tools. The object 'database service' is specific and aligns with sibling tools inspect_database and destroy_database.

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. There is no mention of prerequisites (e.g., an existing project), no indication that inspect_database should be used to verify creation, and no mention of when other create_* tools would be more appropriate. The agent gets only a bare action statement.

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

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

With no annotations, the description carries full behavioral burden, but it only says 'Add a domain to a service.' It does not disclose side effects, whether HTTPS/certificate provisioning happens, validation rules, or whether the operation is reversible. This is a mutation tool and should reveal more.

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 or repetition. Every word contributes to identifying the action and resource, which is ideal for this simple tool.

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

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

The schema fully documents parameters and required fields, making basic invocation possible. However, with no annotations and no output schema, the description should state prerequisites and consequences more explicitly, such as whether the service must already exist and what happens when the domain is added.

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

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

Schema description coverage is 100%, so all five parameters are documented in the schema. The description itself adds no semantic detail beyond 'domain' and 'service', so the baseline 3 applies.

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

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

The description states a clear action (add) and target resource (a domain to a service), which is enough to distinguish create_domain from sibling tools like list_domains and delete_domain. The verb and object are specific rather than tautological.

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 choose this tool over alternatives, no prerequisites, and no mention of list_domains/delete_domain for other domain operations. The only usage signal is implied by the word 'add'.

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 only states that a mount is created; it says nothing about side effects, reversibility, permissions, or whether this modifies the service configuration. This is 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?

A single, front-loaded sentence with no filler or redundancy. It communicates the core action and target resource efficiently, which is exactly what conciseness requires.

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 5 parameters, no output schema, and no annotations, the tool needs more contextual guidance. The description fails to explain bind mount vs named volume semantics, prerequisites, or what successful invocation returns. An agent is left guessing about 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?

The input schema already provides 100% description coverage for all five parameters, so the baseline is 3. The description adds no extra meaning about how parameters relate, such as the difference between 'name' and 'hostPath' or how required parameters interact.

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 ('Create') and a specific resource ('a volume mount for a service'). This clearly distinguishes it from siblings like list_mounts, create_database, and create_domain without requiring the schema to be opened.

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 about when to use this tool versus alternatives. There is no mention of prerequisites, such as needing an existing service, or any exclusions or alternative tools like list_mounts for inspecting existing mounts.

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. 'Expose a port' implies a mutation but does not state whether this creates an immediate mapping, whether it is reversible, whether it requires the service to be running, or what side effects it may have. Almost no behavioral context is given.

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

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

The description is a single short sentence with no filler or repetition. It is concise and front-loaded, though it is so brief that it provides little operational value beyond the tool name.

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

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

Given no annotations, no output schema, and five parameters, the description is far too sparse. It does not explain behavior, return values, prerequisites, conflicts, or default behavior. An agent has insufficient context to confidently invoke this tool beyond what the schema already provides.

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

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

Schema description coverage is high (80%), so the schema already explains most parameters, including 'External port' and 'Container port'. The description adds no meaningful parameter-level information, which is acceptable at this coverage level, though the protocol parameter remains undocumented in the description.

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

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

The description uses a specific verb ('Expose') and a clear resource ('port for a service'), so an agent can tell this is about creating external access to a service port. It does not explicitly contrast with sibling tools like list_ports or create_mount, but the resource is distinct enough for basic identification.

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 list_ports or create_mount. The phrase 'for a service' implies some context, but no conditions, prerequisites, or exclusions are provided.

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

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

No annotations are provided, so the description bears the full burden of disclosing behavioral traits. It only states 'Create a new project' and does not mention side effects, required permissions, reversibility, duplicate-name handling, or what happens after creation. For a mutation 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 efficient sentence with no wasted words or fluff. It is concise and front-loaded, though it carries little substantive information beyond the tool name itself.

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, an agent receives no information about return values, error behavior, side effects, or post-creation steps. The schema documents the sole parameter, but the overall definition is too minimal to be considered complete for a tool that mutates state.

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

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

Schema description coverage is 100%: the only parameter, 'name', is documented as 'Project name (lowercase, no spaces)'. The description itself adds no parameter-level information, so the baseline score of 3 applies.

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

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

The description clearly states a specific verb and resource: 'Create a new project.' This distinguishes it from sibling tools like create_app and create_database. However, it adds no differentiating details beyond the resource name and essentially restates the tool name, so it falls short of a 5.

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

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

The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The only usage signal is implied by the verb and resource: use it when you want to create a project. This is insufficient for an agent choosing among many create_* sibling tools.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether the domain is permanently deleted or merely detached, nor does it mention irreversibility, permissions, or side effects. For a destructive operation, 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, front-loaded sentence with no filler. Every word contributes meaning, making it highly readable and easy to parse.

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

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

Although the operation is simple, the description lacks essential context: no guidance on obtaining domainId, no mention of side effects or irreversibility, and no pointer to list_domains for discovering valid domains. With no annotations and no output schema, the agent is left with too much to guess.

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 only 67%, and the key domainId parameter has no description in the schema. The tool description adds no information about how to find or format domainId, and the other parameter descriptions are minimal tautologies like 'Project name' and 'Service 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 uses a specific action, 'Remove', with a clear resource, 'domain from a service', which goes beyond the tool name by adding the service scope. It is clearly distinct from sibling tools like create_domain and list_domains.

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 the tool: when you need to remove a domain from a service. However, it gives no explicit exclusions, prerequisites, or alternatives, so the agent must 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 provided, the description carries the full burden of behavioral disclosure, but it only says 'Trigger deployment.' It does not state whether deployment is asynchronous or blocking, whether it rebuilds the service, whether it causes downtime, or how the result is reported.

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 front-loaded with the primary action. Every word contributes, but the brevity comes at the cost of useful context, making it concise rather than substantively efficient.

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

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

For a deployment action with no annotations, no output schema, and a sibling set full of lifecycle tools, the description is incomplete. It does not mention result format, error cases, async behavior, or how to monitor the deployment, leaving important operational questions 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 100%, so the schema already documents both parameters. The description adds no meaning beyond the schema's minimal 'Project name' and 'Service name,' so the baseline 3 applies.

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

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

The description names a clear verb-resource pair ('Trigger deployment' for 'an app'), and the tool name confirms it targets a single app. It is differentiated from deploy_compose and deploy_template by naming 'app' as the resource, though it does not explicitly define what counts as an app deployment.

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 start_app, restart_app, deploy_compose, or deploy_template. The description is a one-line action statement with no conditions, prerequisites, or exclusions, leaving the agent to infer deployment semantics from the tool 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 of explaining side effects. 'Deploy' implies mutation, but the description does not disclose whether this creates a new service, updates an existing one, restarts containers, or is destructive. It also says nothing about authentication, rate limits, or output behavior.

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

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

The description is a single clear sentence with no wasted words. However, it is so brief that it sacrifices useful context; it is concise but not richly informative.

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 and no output schema, the description is incomplete. It does not explain the deployment behavior, how it differs from related compose/app tools, or what the agent should expect after invoking 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 100%, and both parameters have minimal but understandable descriptions ('Project name', 'Service name'). The tool description adds no further meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource ('Deploy a compose service'), but it is vague about what 'deploy' actually does in this context. It does not distinguish this tool from siblings like create_compose or deploy_app, leaving the agent to infer the boundary between creating and deploying a compose service.

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 does not mention prerequisites, exclusions, or conditions that would route an agent to deploy_compose instead of create_compose, deploy_app, or deploy_template.

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 'Deploy' without explaining side effects, whether it creates a project or app, required permissions, idempotency, or failure modes. This is a significant transparency gap for a mutation-like operation.

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

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

The description is a single sentence with no wasted words and front-loads the main action. It is concise, though it sacrifices useful detail that could have been added without significant bloat.

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

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

For a deploy tool with no output schema, no annotations, and a nested schema object, this description leaves the agent without knowledge of what the deployment produces, what preconditions exist, or what the template schema should contain. Sibling tool names alone are insufficient to convey complete usage 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?

The input schema only documents 'schema' as 'Template schema object' and leaves 'projectName' undocumented, giving 50% coverage. The description adds the phrase 'one-click template' but does not clarify how projectName and schema are used or what structure the template schema should have.

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 ('Deploy') and identifies the resource as an EasyPanel one-click template, which matches the tool name and broadly distinguishes it from deploy_app and deploy_compose. It does not explicitly contrast with sibling deployment tools, but the resource type is clear.

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

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

The template reference implies this tool is for deploying from one-click templates, but there is no explicit guidance about when to use it instead of deploy_app, deploy_compose, or create_app. Usage context is implied rather than stated, and no exclusions or alternatives are named.

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

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

No annotations are provided, so the description must carry the burden of behavioral disclosure. It only states the deletion action and gives no information about irreversibility, side effects on child resources, permissions required, or cleanup behavior.

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

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

The description is a single, focused sentence with no wasted words. It is concise and front-loaded, though it sacrifices behavioral detail for brevity.

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 tool with no annotations and no output schema, the description is too sparse. An agent cannot determine consequences, reversibility, or how this relates to other destructive tools like destroy_project or destroy_database.

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

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

Schema description coverage is 100%, with 'Project name' and 'Service name' already documented in the schema. The description adds no extra meaning beyond what the input schema provides, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: 'Delete an app service.' It clearly communicates the operation, though it does not explicitly differentiate itself from destroy_project or other lifecycle tools beyond the resource name.

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 resource type: use this when you need to delete an app service. However, there is no explicit guidance about when to choose destroy_app over destroy_project or what prerequisites or precautions apply.

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, but it only restates the destructive action. It does not disclose whether data is permanently lost, whether deletion is reversible, or whether there are safety guards such as confirmation or cascade behavior.

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

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

The description is a single front-loaded sentence with no filler. It is appropriately concise for stating the core action, though it sacrifices behavioral detail that would make it more complete.

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 tool with no annotations and no output schema, this description is incomplete. It does not explain consequences, return value, or any conditions that should be verified before invoking it, which an agent needs for a high-stakes operation.

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

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

Schema description coverage is 67%: projectName and serviceName are already described in the schema, and engine has a self-explanatory enum. The description adds no parameter-level meaning but does not need to compensate heavily; the remaining engine parameter is covered by its allowed values.

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

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

The description states a specific action ('Delete') and a specific resource ('a database service'), which clearly separates it from destroy_app and destroy_project. It does not explicitly name sibling tools, but the resource scoping makes the purpose unambiguous.

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

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

The description gives no guidance on when to use this tool versus create_database, inspect_database, or destroy_project. It also fails to state prerequisites or conditions that should be checked before deletion.

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

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

Without annotations, the description must carry the full burden of disclosure. It states the core destructive behavior and the cascade to all services, but does not mention irreversibility, permissions, or side effects on linked resources like domains, mounts, or databases.

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 action and scope are 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 one-parameter destructive tool, the description covers what action is taken and the affected scope. However, with no annotations or output schema, it does not state whether deletion is reversible, what response to expect, or whether resources beyond services are affected.

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 detail. An agent only knows projectName is a string; it is not told whether it needs an exact name from list_projects or any format/validation rules.

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

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

Description uses specific verb 'Delete' and resource 'project', and clarifies scope with 'all its services'. This differentiates it from destroy_app and destroy_database, whose scope is narrower.

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 when-to-use or alternative routing is provided. The intended use (deleting a project) is implied by the verb and resource, but the description does not state when to prefer destroy_app or other cleanup 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?

With no annotations, the description carries the behavioral disclosure burden. The verb 'Get' and 'details/log' clearly indicate a read operation and describe the returned content. However, it does not mention potential size of logs, authorization requirements, or any edge-case behavior such as truncated output.

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 leads with the action and resource, and includes only the most relevant distinguishing detail: the full build/deploy log. 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?

The tool is simple: one required parameter, no nested objects, and no output schema. The description sufficiently conveys what the tool returns and the key detail that the log is included. More structural detail about the return shape would help but is a minor gap given the low 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?

The schema already documents the only parameter well, including its origin ('Action ID from list_actions'), so schema description coverage is 100%. The tool description adds no additional parameter-level meaning, which matches the baseline of 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 a specific verb ('Get') and resource ('deploy action details'), and adds clarifying scope with 'full build/deploy log'. It is clearly distinguishable from list_actions in intent, though it does not explicitly name its sibling for contrast.

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 in the description. The only contextual hint is the parameter description 'Action ID from list_actions', which implies a sequencing relationship but does not explain when to prefer this tool over list_actions or other inspection 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?

With no annotations, the description must carry behavioral information itself. 'Get' clearly signals a read-only inspection and the parenthetical indicates what categories of details are returned. However, it does not disclose the response format, whether all four categories are always returned, or any authentication prerequisites; for a simple getter this 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?

A single compact sentence that leads with the action and immediately scopes the result via the parenthetical. Every word contributes, with no filler or redundancy.

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

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

For a two-parameter read-only inspection tool, the description gives the essential return categories and the schema fully documents the parameters. It is missing only minor details such as the structure of the response and behavior when the app does not exist, so it is nearly complete for straightforward use.

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

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

Schema description coverage is 100%, with both projectName and serviceName documented as plain name strings. The description adds no additional meaning about how these parameters relate to the returned details, so it meets the baseline without going 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 uses a clear verb-resource pair ('Get app service details') and a parenthetical enumerating the relevant detail categories (env, domains, build, source). This distinguishes it from project/database/compose inspection tools by naming the app service resource, though it does not explicitly contrast any sibling.

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 tool is for retrieving app-level service details rather than project, database, or compose details, but it provides no explicit when-to-use guidance or exclusion such as 'use list_domains for domain-only queries.' An agent can infer the target context from the name and listed fields, but not with high confidence.

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. 'Get' implies a read-only operation, but there is no explicit disclosure about side effects, authentication needs, rate limits, or what happens on failure. This is minimal transparency for a non-annotated 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 terse sentence, front-loaded and free of filler. It is appropriately sized for a simple read tool, though it is more of a short label than an explanatory 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?

With no output schema, no annotations, and only a minimal description, an agent gets no sense of what 'details' are returned or what preconditions apply. The two parameter names are self-explanatory, but the description leaves too much context to inference for confident tool selection among many siblings.

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 descriptions for both parameters ('Project name' and 'Service name') with 100% coverage, so the baseline is 3. The description adds no additional parameter-level meaning beyond what the schema already offers.

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

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

The description names a specific verb ('Get') and resource ('compose service details'), which distinguishes it from sibling inspect tools like inspect_app and inspect_database. However, 'details' is vague and the exact scope of what is returned is left unspecified.

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 inspect_compose versus other inspect tools, nor any mention of exclusions or alternatives. The description simply states the operation without any context for selection.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. 'Get' and 'info' indicate a read-only operation, and the mention of connection string/status names the expected return content. However, it does not disclose sensitive-data handling, auth requirements, failure behavior, or whether any state is affected.

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

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

The description is a single sentence that is front-loaded with the action and resource, and the parenthetical adds concrete output details without waste. Every word earns its place.

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

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

The description is complete enough for a simple read-style tool with three self-explanatory required parameters, but it lacks guidance on alternatives, output shape, or behavioral caveats. The absence of an output schema and annotations increases the burden on the description, which is only partially met.

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

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

The schema already provides basic descriptions for projectName and serviceName, and the engine enum lists valid values. The description adds no parameter-level meaning beyond that, but the parameters are straightforward and adequately inferable from the tool's purpose. Given the partial schema coverage, this is acceptable but not exceptional.

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 action ('Get') and a specific resource ('database service info'), and it names the expected outputs: connection string and status. This distinguishes it from sibling tools like inspect_app, inspect_project, and inspect_compose because it is explicitly scoped to database services.

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

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

The description implies the tool should be used when a caller needs a database's service info, connection string, or status. However, it does not explicitly state when to prefer this over sibling inspect tools or when not to use it, leaving some inference to the agent.

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

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

With no annotations, the description carries the burden of behavioral disclosure; the verb 'Get' indicates a read/no-side-effect operation. It does not disclose output structure, error conditions, or whether container information requires a running Docker daemon, but for a getter this is minimally 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?

The entire description is a single, front-loaded phrase with no filler or repetition. Every word adds meaning and the description is easy to scan.

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

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

The tool is a simple one-parameter getter, and the description states the main return contents. However, with no output schema or annotation context, it leaves the exact shape of 'project details' and the container list unspecified, and it does not clarify how this relates to sibling inspect 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%, so the description must compensate. The word 'project' in 'project details' hints that projectName identifies the target project, but the description adds no format, constraints, or examples beyond the property name.

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

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

The description uses a specific verb ('Get') and resource ('project details and Docker containers'), clearly identifying what the tool returns and distinguishing it from list/create/destroy project siblings. It does not explicitly name alternatives like inspect_app, but the project scope is clear enough for an agent to separate it from those 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 phrasing implies use when a caller needs project-level details and associated Docker containers, but it provides no explicit when-to-use/when-not-to-use guidance or comparison with inspect_app or list_projects. The context is inferable rather than stated.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It communicates that the tool lists recent items and supports filtering, which implies a non-destructive read operation. However, it does not disclose default ordering, pagination, how filters combine, or any rate or access considerations.

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

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

The description is two short sentences with no filler. The main purpose is front-loaded, and the filtering capability is presented immediately after the core action.

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

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

For a simple optional-parameter list tool, the description is adequate but not complete. It lacks information about the output shape, since there is no output schema, and does not explain what 'recent' means or how to retrieve more than the default number of actions.

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 only 33% because limit has a description but projectName and serviceName do not. The description adds meaning by identifying projectName and serviceName as filters, but it does not clarify whether they can be combined, whether matching is exact or partial, or how limit interacts with filtering.

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: list recent deploy actions/builds. It also mentions filtering by project or service, which gives concrete scope. However, it does not explicitly differentiate itself from the sibling get_action_log, leaving some ambiguity about whether this is the right list-style tool.

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

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

The description clearly indicates when to use the tool: to view recent deploy actions/builds, with optional filtering by project or service. It provides clear context but does not mention exclusions or alternative tools for related cases, such as retrieving detailed logs via get_action_log.

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

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

No annotations are provided, so the description carries the burden. "List" implies a read-only, non-destructive operation, but the description does not disclose details such as whether authentication is required, whether results are paginated, or whether it returns all certificates system-wide. The behavior is predictable enough for a basic list tool.

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

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

The description is a single, front-loaded sentence with no unnecessary words. It fully earns its place and contains no filler or redundant phrasing.

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 no parameters, no annotations, and no output schema, the description is nearly complete for invocation purposes. It could optionally state what the return value contains, but "List SSL certificates" is sufficient for an agent to understand the intended 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 and schema coverage is 100%, so the schema already fully documents the input surface. With no parameters, the baseline is 4; the description adds no parameter-specific details because none are needed.

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

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

The description uses a specific verb and resource: "List SSL certificates". It clearly states what the tool does and is immediately distinguishable from sibling list_* tools such as list_projects or list_domains by the resource type.

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 tool name and simple verb, but there is no explicit guidance on when to use this tool over alternatives or any exclusions. For a straightforward no-parameter list operation, this is adequate but not exemplary.

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 disclosure burden. The verb 'list' and scope 'for a service' communicate a read-only, service-scoped operation, but the description does not mention result contents, pagination, prerequisites, or empty/error behavior.

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

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

The definition is a single, front-loaded sentence with no filler. Every word contributes to the core purpose, making it easy for an agent to parse quickly.

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 annotation coverage, so the description should explain what a successful call returns; it only says 'List domains'. For a list operation, the return shape—such as whether domain names, statuses, or records are included—is important for downstream use, and that information is missing.

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

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

The input schema documents both required parameters with 100% coverage, so the description adds little parameter meaning beyond 'for a service', which aligns serviceName with the domain query scope. This is the baseline case where the schema carries the parameter documentation burden.

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

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

The description uses a specific verb and resource: 'List domains for a service'. It clearly distinguishes itself from sibling tools like create_domain and delete_domain, as well as unrelated list_* tools, so an agent can tell what it does without opening the schema.

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

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

No explicit when-to-use or alternative guidance is provided. However, the phrasing implies it is the read-only counterpart to create_domain/delete_domain and should be used when current domain information for a service is needed, but this is inferred rather than stated.

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

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

With no annotations available, the description carries the burden of conveying behavior. The verb 'List' signals a non-destructive read operation, which is helpful. However, it does not disclose what the response contains, whether empty results are possible, or any service state requirements, leaving some behavior unexplained.

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 succinct sentence that states the action and target without redundant detail, filler, or repetition of schema information. It is concise and effectively structured.

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

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

The tool is simple and both required parameters are well documented in the schema, but there is no output schema and the description does not specify what the listing returns (e.g., mount paths, mount names, or empty behavior). This leaves a minor gap for an agent that needs to interpret the result after 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 input schema already provides full descriptions for both parameters ('Project name' and 'Service name'), achieving 100% schema description coverage. The tool description adds no parameter-level meaning beyond indicating the service context, so the baseline score of 3 is appropriate.

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

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

The description clearly identifies the action ('List') and the resource ('volume mounts for a service'), so an agent understands what the tool does. However, it does not explicitly distinguish itself from sibling tools such as create_mount or list_ports, which prevents a perfect score.

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 like create_mount or inspect tools. The only implicit context is that it operates on a service, but no conditions, exclusions, or alternative tool recommendations 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?

With no annotations provided, the description carries the full behavioral disclosure burden. It states only the list action and resource, adding no information about return format, pagination, permissions, or whether the operation is globally scoped or cluster-scoped. The verb 'List' does imply read-only behavior, so there is no contradiction, but the transparency is otherwise 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 sentence with the key verb and resource front-loaded. Every word earns its place; there is no filler or repetition.

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

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

For a zero-parameter, no-output-schema tool, 'List cluster nodes' is nearly complete. The only slight gap is that it doesn't specify whether it returns all nodes in the current cluster or across clusters, and no return structure is mentioned; however, the low complexity keeps this from being a major deficiency.

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 description coverage (vacuously), so there is nothing for the description to add. The baseline of 4 for parameterless tools 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 'List cluster nodes' uses a specific verb ('List') and a clear resource ('cluster nodes'), which unambiguously identifies a read-only enumeration operation. It also distinguishes from sibling tools such as list_projects and list_domains by the resource type.

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

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

The intended use is implied by the resource name — use this tool when you need to see cluster nodes — but the description gives no explicit guidance about when to prefer it over related list tools, nor any exclusions or conditions. There are no sibling tools operating on nodes, so confusion is unlikely.

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 behavioral burden. It only says 'List' and does not disclose what happens for nonexistent services, whether results include both host and container ports, whether sorting or formatting is applied, or whether the operation requires a running service.

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 information. Every word contributes to identifying the action and the target resource.

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 list operation, the description is minimally sufficient to make a correct call. However, with no output schema or annotations, it leaves gaps around return value structure, error behavior, and scope nuances, so 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 100%, so both parameters are already documented with 'Project name' and 'Service name'. The tool description adds no additional parameter meaning beyond what the schema provides, which meets the baseline but doesn't exceed it.

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

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

The description clearly states a specific verb ('List') and resource ('exposed ports') scoped to a service, which makes the core purpose easy to understand. It is distinguishable from sibling list tools like list_projects and list_domains, though it doesn't explicitly differentiate itself from create_port or other port-related actions.

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

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

No usage context is provided. The description does not say when to use this tool versus alternatives, when not to use it, or any prerequisites such as an existing service or deployed app.

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' implies a read-only, non-destructive operation, and the phrase 'all projects and their services' clarifies the scope. However, no annotations are provided, and the description does not disclose return format, pagination, ordering, authentication requirements, or any potential side effects, leaving the description to carry the behavioral burden with limited information.

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

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

The description is a single, well-formed sentence that front-loads the action and resource. Every word contributes meaning: 'List' specifies the operation, 'all projects' defines scope, and 'their services' clarifies the output content. There is no wasted or redundant text.

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

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

The tool is simple with no parameters and no output schema, and the description gives the core purpose. Still, it does not specify the shape of the returned data, whether services are nested under each project, or any behavioral limits. For an agent needing to act on the response, this is adequate but leaves some 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 tool has zero parameters and an empty input schema, so parameter semantics are essentially moot. The description adds no param-level detail, but none is needed because there is nothing to configure; the baseline for a zero-parameter tool is appropriate.

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

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

The description uses a specific verb ('List') and a clear resource ('projects') while adding scope ('all') and content ('their services'). This clearly distinguishes it from sibling tools like create_project, destroy_project, and inspect_project, which perform different actions on the same resource.

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?

For a simple list operation, the intended use is reasonably implied: use this tool when you need an overview of all projects and their services. However, the description does not explicitly mention when not to use it or point to alternatives such as inspect_project for details of a single project.

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 full responsibility. It only says 'List panel users' with no information about output format, pagination, permissions, or side effects. For a read-only listing tool, the lack of return behavior is a notable 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 extremely concise: a short three-word phrase. It earns its place by being direct, though it is arguably under-specified rather than efficiently complete.

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 parameters, no output schema, no annotations, and no usage guidance, the description is minimal. An agent can infer it lists users, but has no idea what data is returned or how to interpret results. Given the tool's simplicity, a brief but richer description would be expected.

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 zero parameters, so there are no parameter semantics to explain. The baseline of 4 applies because there is nothing for the description to add beyond the schema, and the description does not mislead.

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 panel users'. This is clear enough to convey the basic action, but it does not differentiate from sibling tools like list_projects, list_domains, or list_ports. The name and description are nearly identical, providing little added distinction.

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 alternatives. There is no mention of context, prerequisites, or exclusions. The description is a bare statement with no usage direction.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and does not mention that rebooting is disruptive, may terminate running services, or may require elevated permissions, leaving consequences 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, compact sentence with no filler words. It front-loads the action and resource immediately, and every word contributes meaning, making it an appropriately sized description 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?

For a zero-parameter tool, the description covers the minimal mechanics of invocation, but it omits important operational context such as expected downtime, impact on running applications, or post-reboot behavior. An agent can call it correctly but cannot anticipate the consequences, so completeness is only partially adequate.

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

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

The tool has zero parameters, so the schema fully covers the input surface with 100% coverage. The description appropriately does not need to document parameters, and the baseline for no-parameter tools is 4.

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

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

The description uses a specific verb and resource ('Reboot the server'), making the core action immediately clear. However, it largely restates the tool name and does not distinguish itself from sibling tools such as restart_app or restart_panel, which are close 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?

There is no guidance on when to use this tool versus alternatives like restart_app or restart_panel, nor any mention of prerequisites, warnings, or appropriate timing. The description provides only the action itself with no 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 needs to disclose side effects and operational behavior on its own. 'Restart' implies a stop/start cycle and potential downtime, but the description does not mention whether the restart is graceful, whether it fails when the service is stopped, or any 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, clear sentence with zero redundant words. The core action is front-loaded and instantly parseable.

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 and output schema, the description should provide usage and side-effect context, but it does not. An agent learns what the tool does but not when to use it or what consequences to expect, leaving a notable 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?

Schema description coverage is 100%, so the schema already documents both parameters (projectName and serviceName) adequately. The description adds no further meaning about parameter usage or formats, so the baseline of 3 applies.

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

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

The phrase 'Restart an app service' uses a specific verb and a clear resource, leaving no ambiguity about the core operation. The action is naturally distinct from sibling tools such as start_app, stop_app, and deploy_app.

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 restart_app versus alternatives like start_app, stop_app, or deploy_app. It also omits prerequisites such as whether the service must already be running.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure, yet 'Restart EasyPanel' reveals nothing about the consequences of the operation. It does not state that the panel interface becomes temporarily unavailable, whether running apps are affected, or whether server reboot is the alternative when the panel is unreachable. The only behavioral signal is the inherent meaning of the verb 'restart.'

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?

At two words, the description contains zero wasted prose and matches the trivial zero-parameter interface. However, the brevity reads more like under-specification than disciplined concision, since no usage, behavioral, or alternative context is included.

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 disruptive lifecycle operation with no annotations and no output schema, a two-word description is incomplete. The agent cannot determine whether restarting the panel interrupts managed apps or how this differs from reboot_server, and no conditions or caveats are given. Given the size of the sibling tool family, this is a meaningful 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 an empty input schema, so the baseline of 4 applies per the rubric. There are no arguments for the description to clarify, and no parameter semantics are missing.

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

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

The description states a specific verb ('Restart') and a named resource ('EasyPanel'), making clear that this tool restarts the panel platform itself rather than an app or the server. It is only minimally differentiated from siblings like restart_app or reboot_server, but the core purpose is unambiguous and it adds the product name beyond what the tool name implies.

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 closely related siblings such as restart_app, reboot_server, system_prune, or cleanup_docker. There is no mention of the conditions that warrant a panel restart, no exclusions, and no alternatives. The agent must infer usage context entirely from the tool name.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It only says 'Get resource stats,' without explaining whether the operation is read-only, what specific stats are returned, whether the service must be running, or any other behavioral traits.

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

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

The description is a single, focused sentence with no filler or redundant wording. It communicates the core purpose immediately and is appropriately sized for a simple stats retrieval 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 description is too sparse for a tool with no output schema and no annotations. It does not clarify what 'resource stats' includes, how the service is scoped beyond the parameters, or how this tool relates to the many sibling tools. An agent would need additional context to invoke it correctly in ambiguous situations.

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

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

Schema description coverage is 100%, with both projectName and serviceName described as simple names. The description adds no additional semantic detail beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description states a clear action ('Get') and object ('resource stats for a service'), so an agent can understand the basic purpose. However, it does not differentiate 'service' from sibling tools like system_stats or storage_stats, leaving some ambiguity about the exact resource type.

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 about when to use this tool versus alternatives such as system_stats, storage_stats, or inspect_app. The agent is left to infer the appropriate context from the tool name alone, which is not reliable.

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 indicates mutation ('Update') but does not disclose whether existing environment variables are replaced or merged, whether a restart or redeploy is needed, or whether changes are persistent. This is 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 concise sentence with no filler and the action is front-loaded. It could have included additional behavioral context without becoming bloated, so it earns a 4 rather than a 5.

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

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

While the input schema covers parameter semantics well, this is a mutation tool with no annotations and no output schema. The description omits important contextual details such as whether the app must be restarted, whether all existing env vars are overwritten, and how the update affects the running service. An agent lacks the behavioral context needed for safe invocation.

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

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

Schema description coverage is 100%, with the env parameter already documented as 'KEY=VALUE lines'. The description adds no extra meaning beyond the schema, so the baseline of 3 applies.

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

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

The description states a specific action ('Update') and a clear resource ('environment variables for an app'), which distinguishes it from sibling tools like set_app_resources or set_app_source_image. It does not specify whether the update replaces or merges existing variables, so it stops short of 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?

There is no guidance on when to use this tool instead of alternatives, no prerequisites, and no mention of sequencing relative to related app operations. While the purpose is inferable from the name and description, explicit when-to-use guidance is absent.

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 indicates a mutation ('set') but doesn't explain whether changes apply immediately, require a restart, replace existing limits, or affect running services. The existence of reservation parameters also raises unaddressed semantics around CPU/memory allocation.

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 fluff; the core action is front-loaded. It loses a point because it omits reservations, which are part of the tool's actual scope and could be mentioned without sacrificing brevity.

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, this description is too thin. It doesn't cover behavioral effects, reservation handling, or what happens after the call, leaving an agent uncertain about side effects and expected outcomes.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters. The description adds minimal value beyond grouping them under 'CPU/memory limits'; it does not clarify the distinction between limits and reservations, but the schema's basic descriptions suffice for individual parameter meaning.

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

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

Description states a specific verb and resource ('Set CPU/memory limits for an app'), making the primary function clear and distinguishing it from siblings like set_app_env or set_app_source_image. However, it omits that the tool also handles reservations (cpuReservation, memoryReservation), so it's not fully complete.

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

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

The context of 'CPU/memory limits' implies this tool is for resource configuration on an app, which suggests when it should be used relative to other set_app_* tools. But there is no explicit guidance about when not to use it or how it differs from similar resource-related 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?

With no annotations, the description must carry behavioral disclosure. It only says 'Set app source' and doesn't state whether the operation replaces an existing source, triggers a redeploy, requires permissions, or what side effects occur.

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 fluff and the main action front-loaded. However, it is so terse that it withholds useful context that could be added 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 mutation tool with six parameters, four required, no annotations, and no output schema, the description is too thin. It doesn't explain what 'set app source' means operationally, what defaults apply (e.g., branch), or what the caller should expect after success.

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 50%, and the description adds no parameter detail beyond the word 'GitHub repo,' which hints at owner/repo but doesn't clarify branch, path, or the role of projectName/serviceName. The schema's brief descriptions for only three parameters leave the other three 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 and resource: 'Set app source to a GitHub repo,' which clearly indicates the action. It implicitly distinguishes from the sibling set_app_source_image by specifying GitHub repo as the source type, though it doesn't explicitly name the alternative.

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

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

There is no guidance about when to use this tool versus alternatives such as set_app_source_image, nor prerequisites like the app existing or a GitHub token. The only usage signal is the verb 'Set,' 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 provided, the description must carry the full behavioral disclosure burden. It states the action but does not explain side effects, whether the change requires redeployment, whether existing credentials/configurations are affected, or what the result of a successful call looks like.

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

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

The description is one short sentence with no filler or repetition. It is front-loaded with the action and resource, making it easy to scan.

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

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

For a mutating tool with no annotations and no output schema, this description is too thin to be fully actionable. It omits practical context such as whether the image is used directly by deploy_app, whether the app must be restarted, and what a successful response conveys.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters, including an example for image. The description adds no new parameter-level detail beyond what the schema provides, so the baseline 3 applies.

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

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

The description states a specific action ('Set') on a specific resource ('app source') with a specific target type ('Docker image'). This is enough to distinguish it from the sibling tool set_app_source_github, though it does not explicitly name the alternative.

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

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

The description provides no guidance on when to use this tool versus set_app_source_github or any other deployment-related sibling. It does not mention prerequisites, expected context, or scenarios where a different source type should be chosen.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It at least conveys the primary effect of starting a service, but it does not mention idempotency, failure behavior if already running, prerequisites, permissions, or any side effects.

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

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

The description is a single, short sentence that is easy to parse and front-loads the action. It is concise with no filler, though it achieves brevity at the expense of contextual detail.

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

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

For a state-changing tool with no annotations and no output schema, this description is too sparse. It does not explain the lifecycle context, what happens after invocation, or how it relates to deploy_app and restart_app, leaving an agent to guess important semantics.

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

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

Schema description coverage is 100%, so the two parameters are already documented. The phrase 'app service' weakly implies that serviceName refers to a service within a project, but the description adds little meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description states a specific action ('Start') and resource ('an app service'), so an agent can infer the tool's basic function. It is distinct at a surface level from siblings like stop_app and restart_app, though it does not explicitly separate starting from deploying.

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 start_app versus deploy_app, restart_app, or stop_app. The description does not state whether the service must already exist, whether it should be used after a failed deploy, or what conditions make this tool the correct choice.

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 disclosing behavior, but it only says 'Stop an app service.' It does not explain whether stopping is reversible, what happens to running containers or deployments, whether it requires a currently running app, or what the response indicates.

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 filler or repetition. It is exactly as short as it can be while naming the action and target, though it sacrifices substance 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?

For a simple operation with two fully documented parameters, this is minimally viable. However, the absence of annotations and an output schema means the description should ideally note the effect of stopping and whether the app can be restarted later; those details are missing.

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

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

The input schema already documents both parameters with 100% coverage, so the baseline applies. The description adds no param-specific meaning, but it also does not need to compensate for 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 a clear verb ('Stop') and a resource ('an app service'), so an agent can identify the core action. It does not explicitly contrast with sibling tools like start_app or destroy_app, but the meaning is unambiguous enough on its own.

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 about when to use stop_app versus start_app, restart_app, or destroy_app. The agent must infer the appropriate usage purely from the tool name and sibling context.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get storage usage breakdown,' which suggests a read operation but does not describe aggregation, scope, units, or what the breakdown includes.

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

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

A single six-word sentence with zero filler. The core action and resource are front-loaded, making it maximally concise.

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

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

The tool is simple and parameterless, but with no output schema and no annotations, the return format and exact scope are left unspecified. The description is minimally adequate but lacks detail that would help an agent understand what 'breakdown' actually 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?

The tool has zero parameters, so the schema fully covers invocation. Per the rubric, a parameterless tool gets a baseline of 4 because there is nothing for the description to clarify.

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

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

The description uses a specific verb and resource: 'Get storage usage breakdown.' It clearly identifies the tool's function and naturally distinguishes it from siblings like system_stats and service_stats because it is the only tool concerned with storage.

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 about when to use this tool versus system_stats or service_stats, and no alternatives are mentioned. The agent must infer usage from the tool 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 responsibility for behavioral disclosure. It does clearly state the destructive nature ('remove all unused data'), which is important context. But it omits specifics such as which Docker objects are affected, whether the operation is irreversible, and whether it could cause unintended data loss.

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 phrase with no redundant filler. It does, however, largely restate the tool name with only the vague parenthetical adding substance, so it is efficient but somewhat under-developed.

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, zero-argument tool with no annotations and no output schema, this description is too thin. An agent is not told what 'unused data' includes, what the blast radius is, whether the operation is reversible, or how it compares to the sibling cleanup_docker.

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 nothing for the description to document. Baseline of 4 applies because parameter semantics are not applicable.

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 ('prune') and resource ('Docker system'), and the parenthetical 'remove all unused data' clarifies the action. However, it does not explicitly distinguish this from the sibling cleanup_docker, so it is clear but not fully differentiated.

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 about when to use this tool instead of alternatives such as cleanup_docker. The description implies a Docker cleanup use case but provides no explicit context, exclusions, or preferred conditions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says 'Get system stats.' It does not state whether the call is read-only, what format the returned statistics take, whether any permissions are required, or whether the command has side effects. The minimal wording leaves most behavioral expectations implicit.

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

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

The description is one short sentence that wastes no words and places the core action and object first. The parenthetical detail adds useful specificity without bloat.

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

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

For a zero-parameter system statistics read operation, the description is largely sufficient: an agent knows what to call and roughly what it will receive. It could be more complete by stating the output shape or distinguishing it from service_stats, but the low complexity of the tool reduces the need for extensive 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?

The tool has zero parameters, so the schema already exhaustively covers the input surface. The description adds useful context by listing the categories of returned data, though this is not strictly parameter-related. The baseline of 4 is appropriate for a parameterless tool.

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

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

The description states the exact action ('Get') and resource ('system stats') and enumerates the covered metrics: CPU, memory, disk, network. It is clear and self-contained, though it does not explicitly differentiate itself from the similarly named sibling tools service_stats and storage_stats.

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 that this tool is used when system-wide statistics are needed, but it gives no explicit guidance about when to prefer it over service_stats or storage_stats. It provides a general context without exclusions or alternative routing.

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

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

With no annotations, the description carries the full burden and does disclose that this is a direct, unmediated passthrough to any of 347 procedures across 43 namespaces, including mutations. However, it does not warn about the risks of calling arbitrary write procedures, unexpected raw response shapes, or lack of validation, which would be valuable for a raw fallback 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 two sentences long and front-loads the core purpose and usage rule. The examples are useful and not excessive, and every sentence earns its place.

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

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

The fallback purpose and example procedure names provide good orientation, but the description omits guidance on how to structure the 'input' object, what the response format will be, or what happens on invalid procedures. For a raw passthrough tool with no output schema and no annotations, this leaves meaningful gaps for an agent trying to invoke it correctly.

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

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

The description adds useful naming convention context through examples for the 'procedure' parameter. However, with schema coverage at 67%, it does not compensate for the undocumented 'input' object parameter, and it does not explain how 'isMutation' should be chosen beyond the schema's brief description.

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

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

The description uses a specific verb and resource: 'Call any EasyPanel tRPC procedure directly.' It clearly distinguishes itself from the sibling tools by positioning itself as the fallback for anything not covered above, and the examples (wordpress.getPlugins, box.createService) concretely illustrate its 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 phrase 'Use for anything not covered above' explicitly tells an agent when to select this tool over the dedicated siblings. This is a direct usage rule with an implicit when-not condition: prefer the listed tools when available.

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