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

With no annotations, the description carries the behavioral burden and does well: it discloses the doubling policy, the caps via max_cpu/max_memory, and the no-change condition. It does not mention potential side effects such as service restarts or permission requirements, but the core mutation semantics are clear.

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

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

The description is compact and well-structured: a one-sentence summary of the core policy, a one-sentence behavioral detail, then a tight Args list. No redundant elaboration.

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 five-parameter tool with an output schema, the description covers the action, thresholds, caps, and all parameters, making correct invocation possible. The main gap is the lack of routing guidance against scale_service and side-effect caveats, but these are not required for a basic correct call.

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

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

The input schema has 0% description coverage, so the description must supply meaning. It defines all five parameters with units or roles: CPU usage %, memory %, max CPU cores, max memory in MB, and service identifier. This fully compensates for the schema gap.

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

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

The description names a specific action (auto-scale), a resource (service), and the exact behavior: it doubles CPU and/or memory up to caps when thresholds are exceeded, otherwise makes no change. This specificity distinguishes it from the generic sibling scale_service even though no sibling is named.

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

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

It implies use for threshold-based, resource-driven scaling and states the trigger condition ('when usage exceeds the given thresholds'), but it never explicitly says when to prefer this over scale_service or when not to use it. No exclusions or alternative guidance is provided.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only restates that a deployment is created. It does not mention side effects such as image pulling, deployment triggering, reversibility, or required permissions.

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

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

The description is brief and front-loaded with a clear purpose statement. The args block is compact, though somewhat redundant with the input schema.

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

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

For a create operation with no annotations and weak parameter documentation, the description under-specifies important context. It omits preconditions, validation behavior, what a deployment represents, and how this differs from deploy_service.

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

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

Schema description coverage is 0%, so the description must compensate, but most parameter descriptions merely restate the names ('Project ID', 'Service ID'). Only 'image: Docker image to deploy' and 'config: Additional deployment configuration' add marginal meaning; the structure of config and the origin or format of the IDs remain unclear.

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 operation as creating a deployment in EasyPanel, using a specific verb and resource. It is easy to understand what the tool does, though it does not explicitly differentiate itself from the sibling tool deploy_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 like deploy_service or get_deployment. There is no mention of prerequisites, expected workflow, or situations where another tool would be more appropriate.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals that this is a create/mutation operation and that binding is optional, but it says nothing about side effects, idempotency, validation, permissions, or failure 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 compact and well-structured: one purpose sentence followed by an Args list. There is no fluff or repetition, and the core action is front-loaded.

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

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

The tool is simple and has an output schema, so return value details are not necessary. However, with no annotations, the description omits behavioral details and prerequisites for the optional service binding, making it adequate but not fully complete for a mutating tool.

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

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

Schema description coverage is 0%, but the description compensates by explaining that name is a domain name with an example and service_id is the optional service to attach. This adds real semantic meaning beyond the raw schema types, though it stops short of ID format or constraints.

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

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

The description names a specific action ('Create') and resource ('domain') in the first sentence, which distinguishes it from sibling tools like create_service, create_network, or create_project. It also adds the optional service binding, clarifying the exact scope of the operation.

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

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

The tool's purpose implies when to use it, but the description gives no explicit usage conditions, prerequisites, or alternatives. It does not mention how to obtain a valid service_id or whether certain domain names or service bindings are invalid.

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

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

The description goes well beyond the readOnlyHint annotation by explaining the tool's actual non-mutating advisory behavior, why it exists, and what it does not do. It adds valuable context about EasyPanel's automatic network management that the annotation alone does not convey.

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 well-structured and efficiently front-loads the most important fact: it is advisory and does not create anything. The IMPORTANT section and Args list are concise, and every sentence contributes essential information without unnecessary filler.

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

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

Given the tool's simple advisory nature, the description fully covers purpose, non-mutating behavior, parameter semantics, and the correct alternative workflow. The presence of an output schema means the description does not need to explain return values, and nothing critical is missing.

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

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

Schema description coverage is 0%, so the description must compensate for missing parameter documentation. It provides brief but meaningful definitions for all three parameters: name, internal, and driver, including the key semantic detail that internal means isolated from the internet. This is adequate, though not deeply detailed.

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 this is an advisory helper that returns guidance rather than performing creation. It explicitly corrects the misleading tool name by saying 'This tool does NOT create anything', which fully disambiguates it from a typical create operation and from sibling tools like create_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?

The description explicitly explains when not to use this tool: there is no API to create a network directly, and EasyPanel manages networks automatically. It also provides the correct alternative, telling the agent to set internal=true when creating a service instead, which is actionable and specific.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It only states that a project is created, without mentioning side effects, persistence, idempotency, naming constraints, or any other behavioral traits beyond the act of creation.

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

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

The description is efficient and well-structured: one clear purpose sentence followed by a compact Args list. There is no fluff, and every line contributes useful information.

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

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

For a simple two-parameter create operation, the description is minimally viable: it names the resource and the parameters, and the output schema likely covers return values. However, the absence of behavioral context and usage exclusions leaves an agent with limited confidence about side effects and selection criteria.

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

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

Schema description coverage is 0%, so the description must compensate for parameter meaning. It only restates the property names as 'Project name' and 'Project description,' adding minimal value beyond the schema's titles and types. No constraints, formats, uniqueness rules, or optionality details are provided.

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

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

The description states a specific verb and resource: 'Create a new project in EasyPanel.' This clearly differentiates it from sibling tools like create_service, create_network, and create_domain by naming the exact entity being created.

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

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

The description implies usage through the imperative 'Create a new project,' but it does not mention when not to use it, prerequisites, or alternatives. An agent must infer the appropriate selection context from the tool name and sibling list.

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

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

Annotations are absent, so the description must carry the burden of disclosing side effects. It only states that a new service is created and vaguely describes the config parameter; it omits whether the service is started automatically, what happens on name conflicts, 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 purpose statement followed by a compact argument list. It is front-loaded, avoids fluff, and every line provides 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 create tool, the description gives enough to assemble a basic request, especially with the output schema covering return values. However, it lacks usage guidance and behavioral context (e.g., whether the service is immediately available, whether project_id must exist), which would help an agent decide and call it correctly.

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

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

The schema provides only parameter titles with no descriptions, and the description compensates by explaining each parameter: name, project_id, image (with examples), and config (listing ports, env vars, volumes). This adds real meaning, though it omits whether config is required and does not give a precise schema for config.

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 ('Create'), a resource ('service'), and the platform ('EasyPanel'), making the tool's function immediately clear. This clearly distinguishes it from sibling tools that manage or deploy services rather than create them.

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

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

No guidance is given regarding when to use this tool versus alternatives such as create_deployment, update_service, or create_project. The intended use is implied by 'Create a new service,' but there are no explicit conditions, prerequisites, or exclusions.

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

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

The description clearly discloses that the tool does NOT delete anything, returns guidance, and that no direct network deletion API exists. This goes well beyond the readOnlyHint annotation and gives the agent accurate expectations for invoking the 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 short, front-loaded with the critical caveat that nothing is deleted, and followed by a minimal Args section. Every sentence contributes useful information with no filler.

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

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

For a one-parameter advisory tool with readOnlyHint and an output schema, the description covers the surprising behavior, the platform deletion rule, and the argument. The only minor gap is not explaining where the network_id comes from, but this is a small omission given the schema already identifies the required argument.

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%, but the description only restates the parameter as 'network_id: Network ID,' which adds little beyond the schema's title 'Network Id.' It does not explain how to obtain the ID, what format it should be, or any validation behavior, so it fails to compensate for the missing schema descriptions.

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

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

The description states it is an 'Advisory helper for network deletion' and explicitly says 'This tool does NOT delete anything — it returns guidance.' This corrects the potentially misleading delete_network name and clearly distinguishes it from actual deletion tools like delete_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?

The description explains the platform behavior: EasyPanel automatically removes a network once all services in it are deleted, and there is no direct API to delete a network. This makes the helper's purpose clear. It could be stronger by explicitly naming delete_service as the alternative for deleting services first.

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

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

Beyond the destructiveHint=true annotation, the description adds meaningful context: 'This is destructive and cannot be undone' signals irreversibility, and 'including all its services' discloses a cascading blast radius. These traits are not expressed in the annotations, and there is no contradiction with the idempotentHint=true annotation.

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 core content is two front-loaded sentences that each earn their place: the purpose/scope line and the destructive warning. The trailing Args block is slightly redundant with the input schema, adding minor noise but not bloating the description.

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

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

For a simple one-parameter destructive tool with annotations and an output schema already present, the description adequately covers purpose, cascade scope, and irreversibility. Minor gaps remain: it doesn't point to how to obtain the project_id or state the full blast radius beyond services (e.g., networks, domains, deployments attached to the project).

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

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

With schema description coverage at 0%, the description was responsible for compensating on the sole parameter, but it merely restates the schema's own title: 'project_id: Project ID'. It adds no format details, lookup guidance (e.g., via list_projects), or example 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 verb ('Delete') and resource ('a project from EasyPanel'), and clarifies the cascading scope ('including all its services'). This clearly distinguishes it from siblings like delete_service and delete_network, which target different resource types.

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 'including all its services' implies this is the full-project removal tool, but there is no explicit when-to-use vs when-not-to-use guidance and no named alternative (e.g., 'use delete_service if only one service should be removed'). Usage is implied rather than stated.

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

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

Annotations already include destructiveHint and idempotentHint, and the description reinforces this with 'cannot be undone', adding explicit irreversibility context. This goes slightly beyond the structured hint without contradicting it.

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

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

The description is short and front-loads the key destructive warning. The Args block is somewhat redundant with the input schema, but the overall structure is clean and free of fluff.

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

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

For a single-parameter delete operation with output schema present and destructive/idempotent annotations provided, the description covers the critical context: it is destructive, irreversible, and identifies the required service. Minor gaps exist around what happens to associated resources, but these are not essential for a correct call.

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

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

Schema description coverage is 0%, so the description needed to compensate, but the Args section merely restates the parameter name and 'Service ID', which duplicates the schema's own title. It adds no guidance on where to find the ID or any format requirements.

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

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

The description uses a specific verb ('Delete') and resource ('a service from EasyPanel'), clearly distinguishing it from sibling tools like delete_network and delete_project. The destructive nature is also noted.

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

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

The description states the operation and warns that it is destructive and irreversible, implying it should only be used when permanent removal is intended. However, it does not explicitly compare against alternatives such as stop_service or update_service, or state prerequisites.

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

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

With no annotations provided, the description carries the full burden. It discloses the core behavior: pulling the latest source/image and restarting the service. However, it does not mention side effects, permission requirements, downtime, or whether this replaces the running deployment, leaving some behavioral uncertainty.

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

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

The description is short and front-loaded, but the 'Args: service_id: Service ID' line is redundant with the input schema and does not earn its place. Still, it is not verbose or hard to parse.

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

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

For a simple one-parameter tool with an output schema, the description covers the basic operation and parameter. It lacks guidance on when to prefer this over restart_service or update_service, and it does not mention prerequisites. It is minimally viable but not comprehensive.

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

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

Schema description coverage is 0%, so the description should compensate, but it only repeats what the schema already shows: service_id is a Service ID. It adds no extra meaning about where to find the ID, format expectations, or how it is used in the deployment.

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 / redeploy a service', and adds a distinctive mechanism ('pulls the latest source/image and restarts'). This clearly separates it from siblings like restart_service, which would not pull latest source/image.

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

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

The description gives clear context for when to use the tool: when deploying or redeploying a service, including fetching latest source/image and restarting. It does not explicitly name alternatives or state when-not-to-use, but the parenthetical behavior makes the primary use case clear.

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

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

No annotations are provided, so the description carries the behavioral burden. The verb 'Get' makes the read-only retrieval nature clear, but the description does not mention error behavior, preconditions, or side effects. Since an output schema exists, missing return-value details are less critical.

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

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

The description is short and front-loaded with the core purpose. The 'Args' line is somewhat redundant with the schema, but it does not add meaningful bloat or confuse the agent.

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

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

For a simple one-parameter getter, this is minimally viable, especially with an output schema provided. However, it lacks explicit differentiation from related tools and offers no context about when the deployment must exist or how failures are surfaced, leaving clear gaps.

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

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

Schema description coverage is 0%, so the description needed to compensate for parameter meaning. It only restates the schema's own title—'Deployment ID'—adding no format, examples, or additional semantics. The impact is limited because there is only one obvious parameter.

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

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

The description states a specific verb and resource: 'Get detailed information about a specific deployment.' The word 'specific' clearly distinguishes it from sibling list_deployments, and 'information' separates it from logging tools like get_deployment_logs.

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

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

Usage is implied: an agent would use this when it needs details about one known deployment. However, there is no explicit guidance about when to choose this over list_deployments or get_deployment_logs, and no 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 bears the full burden of behavioral disclosure. It does not mention log freshness, pagination/truncation, whether logs are live or historical, or any other behavioral traits beyond the verb 'Get'.

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

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

The description is compact and front-loaded with the core purpose. The 'Args' line is redundant with the schema but brief and not wordy.

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 tool has only one parameter and an output schema, the description leaves operational ambiguity: how to get a valid deployment_id, and how deployment logs differ from service logs, especially because get_service_logs exists as a sibling. This missing distinction is important for correct tool selection.

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

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

Schema description coverage is 0%, and the description only repeats 'deployment_id: Deployment ID', which restates the schema field title. It adds no guidance on id format, where to find a valid deployment_id, or how the id relates to deployments.

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 ('Get') and resource ('logs from a deployment'), clearly indicating a read operation scoped to deployments. It distinguishes itself from get_service_logs by the resource type, though it does not explicitly name the sibling alternative.

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

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

No guidance is given about when to use this tool versus get_service_logs, how to obtain a deployment_id, or what prerequisites exist. The description only states what the tool does, not when it 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?

The annotations already declare readOnlyHint=true, and the description's 'Get detailed information' is consistent with that read-only profile — no contradiction. The description adds the scoping notion of 'specific project' but provides no additional behavioral context such as return shape, error behavior, or existence guarantees. Since annotations cover safety, a 3 is appropriate.

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

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

The description is appropriately sized at two short lines with the purpose front-loaded. The 'Args:' line is redundant with the schema but harmless. There is no wasted prose, though the docstring-style repetition could have been omitted entirely.

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, an output schema exists, and annotations cover the read-only safety profile, so return-value documentation is unnecessary. The main gap is the absence of usage contrast with list_projects and no detail on what 'detailed information' includes. Adequate for making a correct call, but with clear room for improvement.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining the parameter. However, it only restates 'project_id: Project ID,' which is tautological with the schema's property name and title. It adds no format details, examples, or notes on how the ID is obtained. The parameter is self-evident, which softens the impact, but the description still adds zero semantic value.

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

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

The description states a specific verb and resource: 'Get detailed information about a specific project.' The qualifier 'specific' implicitly distinguishes it from the sibling list_projects, and the resource name distinguishes it from get_service and get_deployment. However, it does not explicitly name the sibling it is not, so it misses the top 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?

The description gives no guidance on when to use this tool versus alternatives. It does not mention list_projects for enumerating projects, create_project/delete_project for lifecycle operations, or get_service for the service-level counterpart. The readOnlyHint annotation provides implicit context but no explicit usage direction.

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

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

The description aligns with the readOnlyHint annotation and adds the useful detail that the IP is public rather than internal/private. However, it does not disclose additional behavioral traits such as response format, latency expectations, or potential edge cases. The annotation covers the read-only safety profile, so the description adds a small amount of context beyond it.

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

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

The description is a single, direct sentence with no filler or redundant information. Every word earns its place, and the key subject and object are front-loaded.

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

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

This is a very simple zero-parameter read-only tool with an output schema and a readOnlyHint annotation. The description fully covers the tool's purpose and scope; nothing an agent needs to know to invoke it correctly is missing.

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

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

The tool has zero parameters and the schema confirms an empty properties object, so there is no parameter documentation burden. The baseline of 4 applies because with no parameters, the description does not need to compensate for any parameter coverage gaps.

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

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

The description clearly states the verb 'Get' and the resource 'the server's public IP address,' making the tool's purpose immediately unambiguous. No sibling tool appears to retrieve a server's public IP, so the description effectively distinguishes it from the surrounding operations.

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

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

The description implies this tool is used when the agent needs the server's public IP address, but it does not explicitly state when to use it versus alternatives or provide any exclusionary guidance. Given the tool's simplicity and lack of sibling competition, the implied usage is adequate but not explicit.

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

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

The annotations already declare readOnlyHint=true, so the description does not need to restate that this is a read-only operation. The description adds the phrase 'detailed information' but does not disclose any other behavioral traits such as error handling, authentication requirements, or what happens when a service_id does not exist.

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

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

The main purpose sentence is concise and front-loaded, which is good. However, the 'Args:' line is redundant with the input schema and adds no real value, so not every part of the description 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?

This is a simple one-parameter getter with readOnly annotations and an output schema, so the baseline needs are modest. Still, the description lacks guidance on how to obtain the service_id, what 'specific service' means in relation to siblings, and what constitutes 'detailed information' beyond relying on the output schema.

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

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

The schema description coverage is 0%, and the description's 'service_id: Service ID' adds virtually nothing beyond the schema's existing property title. It does not explain the format, source, or constraints of the service_id, leaving the agent to infer that it is simply the identifier of a service.

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 and resource: 'Get detailed information about a specific service.' It identifies that this tool targets one service by ID rather than listing services, which distinguishes it from list_services. However, it does not explicitly distinguish it from closely related siblings like get_service_logs or get_service_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 for retrieving details about a single, named service, but it provides no explicit guidance on when to use it versus list_services or get_service_logs. There are no alternative tool names or exclusion conditions mentioned.

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 readOnlyHint annotation already signals a safe read operation. The description adds meaningful behavioral context by explaining the tool returns a structured status summary derived from service inspection, including state, deployment status, resources, and errors. It also discloses that the 'lines' parameter is currently unused, preventing an agent from expecting raw-log pagination behavior. No contradiction with annotations.

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

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

The description is compact and front-loaded with the core purpose in the first sentence. The note about raw logs is placed immediately after, and the Args section is minimal. Every sentence contributes useful information, and there is no redundant filler.

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

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

For a read-only diagnostics tool with an output schema present, the description provides enough context: what the tool returns, why it is not raw logs, and which parameter is currently inert. The note resolves the main realistic confusion caused by the tool name. Nothing essential for correct invocation is missing.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining parameters. It adds the critical fact that 'lines' is reserved and currently unused, which goes beyond the schema. However, 'service_id: Service ID' only restates the schema's title and adds no additional semantic detail. The description partially compensates but does not fully enrich both parameters.

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

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

The description states a specific verb and resource: 'Get a status/diagnostics summary for a service.' It also explicitly distinguishes itself from raw container log streaming, which is exactly the ambiguity the tool name creates. This makes it immediately clear what the tool does and how it differs from a naive reading of 'logs.'

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

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

The description clearly says when this tool is appropriate: when a service status/diagnostics summary is needed. It also gives an explicit when-not: raw container log streaming is not exposed by the API, so this tool should not be expected to return raw logs. It does not name a sibling alternative like get_deployment_logs, but the context is still clear enough for an agent to avoid misuse.

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

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

Annotations already declare readOnlyHint=true, and the description's 'Get' verb is consistent with that. The description adds minimal behavioral context beyond what annotations provide, but it does clarify the subject of the statistics. No contradiction exists.

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

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

The description is a single well-structured sentence with no filler. It front-loads the action and target resource, making it immediately scannable and useful.

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

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

Given there are no parameters, an output schema exists to describe return values, and the operation is read-only, the description is complete enough for an agent to select and invoke the tool correctly.

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

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

The tool has zero parameters, so there is nothing to document. A baseline of 4 is appropriate because no parameter information is needed; the description's 'per-service' scope offers mild contextual value.

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

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

The description states a clear verb ('Get') and a specific resource ('per-service runtime statistics'). It distinguishes itself from sibling tools like get_system_stats by explicitly scoping to per-service data rather than system-wide data.

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 'per-service' provides clear context for when to use this tool versus system-level alternatives such as get_system_stats. It does not explicitly name alternatives or provide exclusions, but the intended usage is reasonably evident from the scoped terminology.

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 readOnlyHint annotation already signals that this tool is safe to invoke without side effects. The description adds useful behavioral context by naming exactly what categories of statistics are returned (CPU, memory, disk, uptime), which goes beyond the bare read-only signal.

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

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

The description is a single, front-loaded sentence that names the operation and the data categories it returns. Every word earns its place, and there is no redundant or filler content.

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

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

For a zero-argument, read-only tool with an output schema, this description is complete. It specifies the scope (host system) and the metric domains covered, while the output schema can handle the detailed return structure.

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

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

The input schema has zero parameters, so there is no parameter documentation burden. The description still adds value by indicating the kind of data returned, which partially compensates for the absence of any argument 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 uses a specific verb ('Get') and a precise resource ('host system statistics'), then enumerates the metric categories (CPU, memory, disk, uptime). This clearly distinguishes it from the sibling get_service_stats, which targets service-level metrics rather than host-level ones.

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 'host system statistics' gives clear context that this tool is for host-level metrics, implicitly differentiating it from service-focused siblings like get_service_stats. It does not explicitly state exclusions or alternatives, but for a zero-parameter system stats tool the usage context is evident.

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

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

The readOnlyHint annotation already signals that this operation is safe and non-mutating. The description adds useful behavioral context by specifying that it checks both API reachability and session validity, going beyond the annotation alone.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes to explaining what the tool does.

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

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

For a parameterless health check with a readOnlyHint and an output schema available, the description covers the essential context. An agent can understand what the tool does and when to call it without additional explanation.

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 carries no burden. Per the baseline for parameterless tools, the description does not need to provide additional parameter-level semantics.

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

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

The description uses a specific verb ('Check') and clearly identifies what is being checked: reachability of the EasyPanel API and session validity. It is distinct from the sibling tools, which all target specific resources like services, deployments, or networks.

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

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

The description clearly implies this tool is for verifying connectivity and authentication state, which is a meaningful usage context. It does not explicitly state when not to use it, but there is no overlap with sibling resource-specific tools, so the guidance is adequate.

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 weight; 'List' reasonably conveys a read-only, non-mutating operation and the optional filter describes scoping behavior. However, it does not mention pagination, result ordering, default project scope, or any permissions/rate-limit requirements, leaving some behavioral uncertainty.

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 compact: one sentence states purpose and the optional-filter behavior, and the Args line briefly clarifies the single parameter. No redundant text or filler is present, and the key action is front-loaded.

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

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

For a simple read-only list operation with one optional parameter and an output schema, the description provides enough information to invoke it correctly. It would be more complete with a note on when to use it instead of get_deployment, but that gap is partly covered by the clear purpose statement.

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

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

The schema provides only a title and type for project_id, so the description's 'Optional project ID to filter deployments' adds the crucial semantic that the parameter is a filter. With 0% schema description coverage, this meaningfully compensates, though it does not specify ID format or validation behavior.

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

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

The description uses a specific verb ('List') and resource ('deployments') and specifies the domain ('EasyPanel'), making the tool's purpose immediately clear. It does not explicitly reference sibling tools such as get_deployment or create_deployment, so it stops short of a full 5.

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

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

There is no guidance about when to choose this tool over alternatives like get_deployment or create_deployment, and no exclusions are stated. The only usage hint is the optional project filter, which constrains the parameter but not tool 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?

The readOnlyHint annotation already indicates this is a read operation. The description adds the filtering behavior, but otherwise discloses no additional behavioral traits such as pagination, ordering, or invalid-parameter handling.

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

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

The description is extremely brief and front-loaded with the core purpose. The parameter line adds necessary context without redundancy.

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

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

For a simple list operation with an output schema, the description covers the essential calling context. It could be slightly more explicit about what 'domains' refers to, but the one optional parameter and read-only annotation make the tool usable as documented.

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

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

The schema provides only the parameter name and type with no description, so the description carries the full semantic burden. It clearly explains that service_id is optional and used to filter domains, which is sufficient for the single simple parameter.

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

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

The description states the action 'List domains' with a clear resource and an optional filter. It is immediately distinguishable from sibling tools like list_services or create_domain.

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

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

The description implies the tool is used to retrieve domains and optionally narrow results by service_id. It does not explicitly state when to prefer this over a sibling tool or mention any exclusions.

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

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

Beyond the readOnlyHint annotation, the description reveals a non-obvious behavioral trait: the tool infers per-project topology from service port configuration rather than listing actual Docker networks. This is critical context and prevents a wrong mental model of what the tool returns.

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

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

Two sentences, no filler, with the key behavioral caveat placed immediately after the main purpose. Every sentence contributes essential information.

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

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

With no parameters and an output schema present, the description provides all needed behavioral context: what the tool does, why it exists, and how it derives its results. Nothing critical is missing.

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

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

The tool takes zero parameters, so there is nothing for the description to explain. The baseline of 4 applies because no parameters need semantic elaboration.

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

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

The description clearly identifies the tool as an analyzer of EasyPanel network topology, not a direct Docker network lister. It explicitly distinguishes the tool's behavior from what the name might suggest, making its purpose unambiguous and distinct from create_network and delete_network.

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 establishes the appropriate context: use this tool to analyze network topology, especially since Docker networks are not directly exposed via the tRPC API. It does not explicitly say when not to use it or route to alternatives like create_network/delete_network, but the analytical scope is clearly implied.

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 readOnlyHint annotation already establishes that this is a safe read operation. The description adds the 'all projects' scope, which clarifies the operation's breadth, but it does not disclose any additional behavioral traits such as pagination, ordering, or permission requirements. Given the annotation, the bar is lower, and the description is consistent and 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 description is a single, front-loaded sentence with no wasted words. It conveys the operation and scope efficiently, 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?

Given that there are zero parameters and an output schema exists, the description is nearly complete. The readOnlyHint annotation adds the safety profile. It could mention pagination or sort order, but for a simple list operation, these are not critical 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, so there is nothing for the description to explain about parameter semantics. The baseline of 4 is appropriate because no parameter documentation 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 'List all projects in EasyPanel' states a specific verb and resource, clearly identifying that this tool returns every project. It distinguishes itself from siblings like get_project (single project) and create_project (mutation) because it explicitly targets all projects.

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

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

The usage is implied by the description: call this when you need the full set of projects. However, there is no explicit guidance about when to prefer this over get_project or how it relates to other project-related tools, so it doesn't fully cover 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?

Annotations declare readOnlyHint=true, and the description stays consistent with that by describing a read-only listing operation. It adds the useful context that the result is optionally filtered by project, but it does not disclose pagination, ordering, permission needs, or error behavior. With the annotation covering the safety profile, 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?

The description is compact, with the core purpose front-loaded in the first sentence and a minimal Args block for the parameter. No wasted words or redundant elaboration.

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

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

For a simple list operation with one optional parameter, readOnlyHint=true, and an output schema, the description gives enough to call the tool correctly: what it lists and how to filter. It does not discuss pagination or ordering, but these are not critical for such a straightforward read-only endpoint.

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

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

Schema description coverage is 0%, so the description must compensate. It does: 'project_id: Optional project ID to filter services' clearly explains the parameter's purpose, which is far more informative than the schema's bare title and default value. The description fully covers the only parameter.

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

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

The description clearly states the action ('List') and the resource ('all services in EasyPanel'), and it mentions the optional project filter. This differentiates it from the sibling get_service, which targets a single service, without needing to open the schema.

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

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

The description implies when to use the tool: whenever you need the full list of services, optionally scoped by project. However, it does not explicitly contrast it with get_service or mention when the filter should be used versus when it should be omitted, so usage guidance is only implied, not explicit.

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

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

No annotations are present, so the description must carry the behavioral context. 'Restart a service' merely restates the tool name and gives no details about downtime, state changes, graceful shutdown behavior, or error implications.

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

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

The description is short, but it is under-specified rather than efficiently informative. The 'Args' section repeats schema-level information without adding operational value.

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

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

Given the one-parameter schema and output schema, the description still omits essential behavioral context such as when restart is appropriate, what happens to the service during the restart, and whether the operation is disruptive. A restart tool needs more guidance than this.

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 parameter description 'service_id: Service ID' adds nothing beyond the schema's property name and title. The description fails to explain what the service_id should be or how to obtain 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 the action ('Restart') and the resource ('a service'), so an agent knows what the tool does. However, it does not distinguish itself from the sibling start_service and stop_service tools, which limits the score to 4 rather than 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 gives no guidance on when to use restart_service versus start_service, stop_service, or update_service. No context, 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?

With only idempotentHint annotated, the description carries the burden of behavioral disclosure but adds no side-effect context. It doesn't mention whether scaling causes downtime, a restart, or how changes are applied, leaving an agent to guess operational impact.

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

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

Front-loaded with a clear action sentence followed by a compact Args list. No wasted words, though the Args section lightly duplicates schema property titles without adding much beyond units.

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

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

The description covers the basic operation and parameters, and an output schema exists, so return values aren't needed. However, it omits null-value semantics and fails to differentiate from auto_scale_service, leaving a moderate gap for a mutation tool.

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

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

Schema description coverage is 0%, so the description compensates by explaining cpu and memory with units (cores, MB) and identifying service_id. It adds meaningful semantics beyond the bare schema, though it does not clarify null/default behavior.

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

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

States a specific verb ('vertically scale') and resource ('service's resources'), clearly distinguishing it from siblings like auto_scale_service and restart_service. The purpose is immediately understandable and unambiguous.

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

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

No guidance on when to use this tool versus closely related siblings such as auto_scale_service, update_service, or restart_service. The description provides no context for selection or exclusion.

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

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

Annotations include idempotentHint: true, and the description does not contradict this. The description adds the precondition that the service is stopped, but does not explain behavior on an already-running service, async behavior, or any side effects beyond the annotation.

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 main description is a single clear sentence with no filler. The Args block is somewhat redundant with the input schema, but the overall definition remains compact and front-loaded.

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

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

For a simple one-parameter tool with an output schema and idempotentHint, the core purpose is covered. However, there is no guidance about prerequisites beyond 'stopped', no indication of failure behavior, and no mention of when to choose restart_service instead.

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 Args section says only 'service_id: Service ID', which merely restates the schema property name and title. No additional meaning, format, source, or lifecycle context is provided, so the description does not compensate for the 0% schema description coverage.

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

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

The description 'Start a stopped service' uses a specific verb and resource, and clearly states the target state. It differentiates itself from siblings like stop_service and restart_service by indicating this tool is specifically for starting a stopped 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?

The phrase 'a stopped service' implies the tool should be used when the service is currently stopped. However, no explicit guidance is given about when to prefer start_service over restart_service, or what to do if the service is already 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?

Annotations already provide idempotentHint and destructiveHint. The description adds useful behavioral context by noting the service goes offline until explicitly started again, implying reversibility and distinguishing this from permanent deletion.

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 short and front-loaded with the core action and effect. The Args section is slightly redundant with the schema, but it does not make the description bloated or hard to parse.

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

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

For a simple one-parameter tool with annotations covering idempotency and destructiveness, plus an output schema, the description is mostly sufficient. The main missing piece is guidance on when to choose stop over restart or delete, but the core invocation context is clear.

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

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

The only parameter, service_id, is documented only as 'Service ID', which merely restates the schema title. With 0% schema description coverage, the description should add more meaning, such as where to find the ID, expected format, or behavior when the service is already stopped.

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

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

States the specific action 'Stop a running service' with a clear resource and immediately clarifies the effect ('takes it offline until started again'). This distinguishes it from related siblings like delete_service, restart_service, and start_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 given about when to use stop_service versus its siblings. The description does not mention alternatives such as restart_service or delete_service, nor does it state conditions like 'use this to temporarily take a service offline'.

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?

IdempotentHint=true already conveys repeated-call safety, but the description adds no behavioral context such as whether config replaces or merges, whether changes take effect immediately, or whether a restart is required. It merely restates the operation name.

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

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

The description is short, direct, and front-loaded, with no filler. The Args block is redundant with the schema, but overall it remains easy to scan and does not overexplain.

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 an unconstrained config object and no schema descriptions, critical semantics are missing: merge vs replace behavior, whether an existing service is required, and how config relates to restart or deploy operations. The output schema covers return shape, but not operation 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 0%, so the description carries the burden of explaining parameters. However, 'service_id: Service ID' restates the parameter name, and 'config: New configuration settings' gives no structure, expected keys, or format for the arbitrary nested config object.

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

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

The description states a clear verb ('Update') and resource ('service configuration'), making the tool's core function evident. It is distinguishable from sibling actions like create, delete, restart, or stop, though it does not elaborate on scope or edge cases.

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 create_service, deploy_service, or restart_service. It neither states prerequisites such as the service needing to exist nor exclusions such as deploying code changes.

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