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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds value beyond that by disclosing that returned operations carry a risk level and a blocked-by-server-mode status, which is genuinely useful behavioral context and does not contradict the annotations.

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

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

Two short sentences, zero filler. The what (lists operations with risk level) is front-loaded ahead of the when (discovery and blocked-status check).

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

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

With no output schema, the description has to hint at the return shape, and it does so by naming the two payload fields an agent cares about (risk level, blocked status). It could go slightly further by noting the result is a full catalog rather than a filtered subset, but it is sufficient for a zero-parameter discovery tool.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to clarify about inputs, and it correctly does not invent any.

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

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

States a specific verb+resource: it enumerates every operation the server exposes, annotating each with a risk level. The phrase 'which operations are currently blocked by the server mode' also distinguishes it from every sibling tool, which are concrete panel/site/db operations rather than a discovery meta-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?

Explicitly says when to use it: 'to discover what is possible and which operations are currently blocked by the server mode.' That is a clear context for invocation. It names no exclusions or alternatives, but no sibling offers the same discovery capability, so there is little to disambiguate against.

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

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

Annotations already establish readOnlyHint=true and idempotentHint=true, so safety is partly covered. The description adds genuinely new behavioral context beyond them: it is non-destructive at any time and "reveals no secrets," which matters for a connection/credential-adjacent tool.

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

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

Two compact sentences, front-loaded with the verb and the list of reported fields, followed by the safety reassurance. No redundant or filler 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?

No output schema exists, so the description must carry the return-value burden, and it does by naming the four reported items. For a zero-parameter status tool with annotations covering the safety profile, nothing an agent needs to call 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 takes zero parameters, so the baseline is 4. There is nothing for the description to disambiguate, and schema coverage is 100%.

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 ("Report") and enumerates exactly what is reported: panel address, connection health, panel version, and active modes including read-only and dangerous operations. This distinguishes it from the many panel_* data tools, though it never explicitly names a sibling such as aapanel_capabilities to sharpen the boundary.

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

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

"Safe to call at any time" gives a usable when-to-use signal, implying it is a good first/health check. However, there is no when-not guidance and no routing to aapanel_capabilities or the panel_* status siblings, so the usage context is only 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?

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is known. The description adds concrete blast radius beyond that: existing root logins, cron jobs and monitoring agents break. It still doesn't mention required permissions or whether the change is reversible.

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

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

Two short sentences, zero waste. The action is front-loaded and the consequence follows immediately, 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?

For a single-parameter destructive tool with no output schema and annotations covering the mutation profile, the description covers action plus impact. It stops short of auth/prerequisite context an operator would want before running a root credential change.

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

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

Only one parameter with 100% schema description coverage, so the schema already documents the password field. The description adds no syntax, format, or constraint details beyond it; 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?

States a specific verb+resource: 'Set a new MySQL root password.' The word 'root' distinguishes it from the sibling db_set_password, which handles ordinary database users, so an agent can route correctly without opening the schema.

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

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

The description states what happens but never says when to use this versus db_set_password or danger_mysql_root_password's alternatives, nor what preconditions must hold. There is no explicit when-to-use or when-not-to-use guidance.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false and non-idempotency. The description adds genuinely useful context beyond them: this is the highest-privilege credential on the box and the server refuses to expose it unless an environment flag is set, which is an auth precondition the agent cannot infer from annotations.

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

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

Two sentences, zero waste: the dual behavior leads and the security precondition follows. Front-loaded and appropriately sized for a simple tool.

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

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

No output schema is needed for a credential read, and the auth gate is disclosed. But the description leaves the write path under-specified (no password parameter, no indication of what is overwritten or whether the change is reversible), which is a meaningful gap for a destructive 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 coverage is 100% for id/key/table, so the baseline would be 3. However, the description's only parameter reference is 'when password is supplied', and no password parameter exists in the schema. That mismatch creates real ambiguity about how the write mode is actually triggered and undermines the otherwise self-documenting schema.

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

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

States a specific dual purpose (read the MySQL root password, or set a new one) with the resource named precisely. It does not, however, differentiate itself from the sibling danger_mysql_reset_root_password, which appears to overlap with the 'set a new one' behavior, leaving the agent to guess which to call.

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

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

It gives the condition that switches modes ('when password is supplied') and names a hard prerequisite (AAPANEL_ALLOW_DANGEROUS must be set). But it never says when to prefer this over danger_mysql_reset_root_password, so the agent has no explicit routing guidance between two apparently overlapping 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?

The description adds genuine behavioral context beyond the annotations: the read scope (anything the panel user can read, explicitly including secrets-bearing config and DB files) and the env-var gate that determines success or refusal. It does not explain why such a read is flagged destructive/not read-only, but the gate disclosure is the operationally important part.

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

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

Two sentences, front-loaded with scope and followed by the gating condition; every clause carries information and nothing is padded.

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 tool with no output schema, the description covers scope, representative targets, and the precondition for success. It omits error behavior and any size/permission limits, but the essentials for calling it correctly are present.

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

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

Schema coverage is 100% and the single 'path' parameter is already documented as an absolute host path. The description's example paths illustrate what is targeted but add no syntax or format detail beyond the schema, 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?

States a specific verb and resource ('Read any file readable by the panel user') and immediately scopes the danger with concrete examples (config.json, database files). An agent can distinguish this from danger_write_file, site_get_config, or db_list without opening a schema.

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

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

It gives a real availability condition ('Refused unless AAPANEL_ALLOW_DANGEROUS is set'), which tells the agent when the call will fail. However, it never says when to prefer this tool over narrower siblings like site_get_config or danger_write_file, leaving the choice implicit.

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

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

Annotations already declare destructiveHint=true and non-idempotency, so the safety profile is covered; the description adds genuinely new information by disclosing the environment-variable gate that will cause refusal. It stops short of describing downtime, rollback, or what an update disrupts on the running panel.

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

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

Two short sentences, zero filler, with the action stated first and the blocking precondition second. Nothing to trim.

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

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

For a single-parameter, no-output-schema mutation tool with annotations covering the safety profile, the description supplies both the action and the authorization prerequisite. It could go further on impact/warnings, but 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?

Only one parameter with 100% schema description coverage ("Set true to actually install the update"), so the schema fully documents it. The description adds no semantics beyond the schema, which is the expected baseline here.

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

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

States a specific verb and resource ("Install a panel update") that is clearly distinct from the read-only sibling panel_check_update and consistent with the danger_ prefix convention. It doesn't explicitly name the sibling boundary, but the action is unambiguous.

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

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

The description states a hard precondition (AAPANEL_ALLOW_DANGEROUS must be set), which is useful gating context, but gives no explicit guidance on when to invoke this versus checking first with panel_check_update or how to decide whether a panel update is appropriate.

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

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

Annotations cover safety (destructive=true, readOnly=false). The description adds the critical behavioral fact that all site-tool validation is bypassed and enables a gating env var that can cause the server to refuse the call. That is genuinely beyond what annotations declare.

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

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

Two sentences, front-loaded with the capability and scope, then the safety gate. No wasted words and every clause carries 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?

A destructive file-write tool with no output schema and full schema coverage. The description supplies the risk profile, the bypass behavior, and the env-var gate – everything an agent needs before 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 coverage is 100%, so path, data, and encoding are already documented there. The description adds no syntax, path constraints, or encoding meaning beyond the schema, 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?

States a specific verb (Write) plus resource (any file the panel user can write, including vhost and nginx configs). Explicitly distinguishes itself from the site_* siblings by noting it bypasses their validation. An agent can tell which tool applies without opening any schema.

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

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

Names a concrete precondition (server refuses unless AAPANEL_ALLOW_DANGEROUS is set) and contrasts with the site tools, giving clear when-to-use context. It stops short of naming a specific fallback alternative or spelling out when-not to use it, so it isn't quite a 5.

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

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

Annotations already declare that this is a read-only, idempotent, non-destructive open-world operation. The description adds that the output includes allowed hosts and SSL mode, which is useful return-content context, but it does not go beyond that to describe auth needs, failure modes, or formatting.

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

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

The description is very short and contains no wasted words. However, it is a sentence fragment rather than a fully structured action statement, which slightly limits front-loaded clarity.

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

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

For a simple one-parameter read tool with rich annotations and a fully described schema, the description gives the essential return contents (hosts and SSL mode). It remains incomplete because it does not state the retrieval action explicitly or provide any usage context, leaving gaps an agent must infer from the tool name.

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

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

Schema description coverage is 100%, and the single parameter 'name' is documented in the schema as 'Database name.' The description does not add any parameter meaning beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description names the resource and returned fields (allowed hosts and SSL mode), but it is a noun phrase rather than a clear verb+resource statement. The tool name implies a retrieval action, yet the description itself does not explicitly say what the tool does, and it does not distinguish this from the sibling db_set_access.

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

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

No when-to-use guidance is provided. The description does not mention alternatives such as db_set_access, nor does it state prerequisites or the context in which an agent should call this tool rather than another database-related sibling.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true. The description adds genuinely useful context beyond those flags: the backup artifact's destination directory. It still omits whether the operation is asynchronous, how long it takes, or how to verify completion.

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

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

Two short, front-loaded sentences with no filler; the action leads and the destination follows. It is efficient, though the second sentence could have been spent on more consequential information such as async behavior.

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 non-idempotent mutation with no output schema, the description covers the action and the artifact location but leaves the lifecycle unexplained: no indication of whether the call blocks, how to poll status, or that db_backups lists the results. Adequate but with 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 100%, so the single required 'id' parameter and its 'Database id from db_list.' guidance are fully documented in the schema. The description adds nothing about the parameter, so 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?

States a specific verb and resource ('Start a database backup') and adds where the output goes, which distinguishes it from sibling read tools like db_backups. It does not, however, explicitly contrast itself with db_backups or db_restore.

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

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

There is no statement of when to use this tool versus alternatives, no prerequisites, and no mention of the closely related db_backups (list) or db_restore siblings. The agent must infer the trigger condition entirely.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description only adds ordering ('newest first') and the scoping to a single database, with no note on pagination limits or result shape.

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

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

A single short sentence with no filler, and the ordering cue is front-loaded alongside the resource. It is only slightly penalized for being a fragment that omits an explicit verb.

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 a 100%-covered schema and full annotations, the basics are in place, and no output schema means return values needn't be described. However, for a list tool sitting among db_backup, site_list_backups and db_restore, the absence of any routing or pagination context leaves an agent to infer too much.

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 every parameter (p, type, limit, search) is already documented in the schema, including 'search = Database id from db_list'. The description adds no parameter meaning beyond that, which matches the 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 title supplies the verb ('List'), but the description itself is a noun phrase — 'Backup files recorded for a database, newest first' — that never states what the tool does to them. It also does not distinguish itself from siblings like db_backup (creates a backup) or site_list_backups.

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

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

There is no when-to-use guidance at all: nothing says to call this instead of db_backup when creating one, or that db_restore consumes the results. 'Newest first' is an ordering detail, not usage guidance.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description does add real value by disclosing that a database AND a user account are created (a side effect beyond 'create a database'), but it omits auth requirements and what happens on re-run or name collision.

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

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

Two tight sentences with the core purpose front-loaded and zero filler. The second sentence is spent entirely on one parameter's host semantics, which slightly limits how much ground the short text can cover.

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

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

For an 11-parameter mutation tool with no output schema and no annotations covering semantics, the description is adequate but thin: it says nothing about the created user's privileges, return value, or failure modes. The parameter surface itself is fully described by the schema, which keeps this at a viable 3.

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 11 parameters are documented in the schema; the baseline is 3. The description's host guidance duplicates what the schema already says for 'address' ('Access host, same meaning as dataAccess') and 'dataAccess' ('127.0.0.1, a specific ip, or % for any'), adding no new syntax or constraint.

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

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

States a specific verb and resources ('Create a MySQL database and user'), so an agent immediately knows what the tool does. However, it never references or differentiates itself from siblings like db_set_password, db_set_access, or site_create, which the rubric reserves for 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 second sentence gives conditional guidance ('Pass 127.0.0.1 unless the app connects from another machine...'), but this is parameter-level advice rather than when-to-use-this-tool-vs-alternatives guidance. There are no prerequisites, no exclusions, and no routing to a sibling tool, so it stays at implied usage.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds a genuinely useful nuance beyond them: the panel moves the database to the recycle bin rather than dropping it immediately, yet the agent should still treat the action as destructive. This corrects a naive assumption about recoverability and is not derivable from the annotations alone.

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

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

Two tightly packed sentences: purpose first, then the recycle-bin behavior, then the confirmation prerequisite. No filler, and the destructive warning is front-loaded where an agent will act on it.

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

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

For a destructive mutation tool with rich annotations and a fully described schema, the description covers the essentials an agent needs: it is destructive, it is recoverable via the recycle bin, and db_delete_check should precede it. It does not mention permission requirements or what happens to related users/backups, a minor 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%, with both 'id' (from db_list) and 'name' (for confirmation) documented in the schema itself. The description adds no parameter-level detail, so the 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?

Starts with a specific verb+resource ('Delete a database') and immediately distinguishes its behavior from a hard drop, referencing the sibling db_delete_check. An agent can separate this from db_delete_check or db_recycle_bin without opening a 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?

Explicitly states the prerequisite sequence: confirm with db_delete_check first before calling this tool. That is clear routing guidance, though it frames db_delete_check as a required precondition rather than spelling out when this tool should not be used.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description reinforces the non-mutating intent ('the panel would remove'), which is consistent, but adds nothing about return content, timing, or side effects an agent couldn't already assume.

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 and the preview intent is front-loaded. It is slightly under-specified rather than bloated, and the sentence fragment reads awkwardly, but there is no wasted 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 simple read-only, one-parameter tool with no output schema and full annotation coverage, the description is minimally adequate but never states what it actually returns (record details, blocking dependents, etc.) or how to use the result to confirm the deletion. A preview tool needs that at the margin.

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 a single parameter and 100% schema description coverage, the schema already documents that 'id' is a database id from db_list. The description adds no parameter meaning beyond this, so the baseline 3 applies. No 0-param bump because one parameter exists.

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

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

The description conveys that this is a preview of what a deletion would remove, which is a distinct function from the sibling db_delete. However, the phrasing is a fragment with no clear verb ('The record the panel would remove'), and it never uses the word preview/dry-run or names db_delete as the operation it guards. Purpose is inferable but not stated crisply.

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 clause 'so a deletion can be confirmed against the right database' implies the use case, but there is no explicit when-to-call guidance and no mention of the db_delete sibling it is meant to precede. The agent must infer the workflow.

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

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

Annotations already declare readOnly=false, destructive=false, openWorld=true and idempotent=false, so the safety profile is covered. The description adds the genuinely useful constraint that the file must be host-local rather than uploaded, but says nothing about overwriting existing data, 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?

Two short sentences, front-loaded with the action and immediately followed by the critical host-locality constraint. No filler.

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

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

With no output schema, the description carries the return-value burden but the operation's result is obvious (import success/failure). Annotations cover the safety profile and the schema documents both parameters, so only edge behavior like overwriting an existing database is unaddressed.

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 are already documented in the schema, so the baseline is 3. The description adds no format or syntax detail beyond restating that the file must be on the panel host.

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 (Import) and resource (.sql file into a database) with the scope constraint that the file lives on the panel host. It implicitly distinguishes itself from db_restore and db_backup, though it never names a sibling to make the boundary explicit.

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

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

Gives a clear precondition and an exclusion: the file must already exist on the panel machine and is not uploaded by this server. That tells the agent when this tool applies, but it doesn't point to alternatives such as db_restore or db_sync_from_server.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered by structured data. The description adds value by enumerating the returned fields, but says nothing about pagination behavior, whether the list is scoped to the panel or the whole server, or result ordering.

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

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

A single compact sentence that front-loads the resource and enumerates the returned fields with no filler. It is appropriately sized for a simple list 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?

With no output schema, the description usefully compensates by naming the columns returned, and the annotations plus schema cover safety and parameters. Minor gaps remain around pagination semantics and server scope, but the agent has enough to call it correctly.

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

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

Schema description coverage is 100%, so p, limit, and search are fully documented in the schema itself, including the note that search is often the site id. The description adds nothing beyond this, 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 names the resource (all MySQL databases known to the panel) and the fields returned (user, access host, size), which is enough for an agent to distinguish it from db_tables, db_create, or db_backups. It lacks an explicit verb like 'list', but the name and content make the read-only listing intent 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?

There is no statement of when to use this tool versus its many siblings (db_tables, db_access_get, db_backups, site_list). No prerequisites, no exclusions, and no guidance about pagination or filtering workflow are given.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: it does not mention that OPTIMIZE TABLE rebuilds/reclaims space, may lock or block the table during execution, or that the operation is repeatable but not free. For a mutation on live database tables this is a real gap.

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

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

A single front-loaded sentence with no filler or redundancy; the operation and target are stated immediately. It is appropriately sized, though its brevity reflects under-specification rather than disciplined economy.

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 table-maintenance tool with no output schema, the description should at least say what optimizing accomplishes, whether it locks/affects availability, and how it differs from repair. None of that is present, so the agent lacks the operational context needed to call it safely and correctly.

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

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

Schema description coverage is 100% for both parameters, including the table-name example and the db_tables discovery pointer, so the schema carries the semantic load. The description only echoes the plural scope ('one or more tables'), adding no format, ordering, or multi-database details beyond the schema. Baseline 3 applies.

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

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

The description names a specific operation (OPTIMIZE TABLE) and its resource (one or more tables of a database), so the agent knows exactly what will be executed. However, it does not distinguish itself from the closely related sibling db_repair_table, leaving the choice between table-maintenance tools to inference.

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

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

There is no guidance on when to optimize versus repair (db_repair_table), no prerequisites such as table accessibility or minimum privileges, and no statement of whether the tables should be offline. The only hint about discovery (use db_tables) lives in the schema, not the description.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safe-read profile is covered. The description adds that the panel retains deleted databases so they remain recoverable, which is useful context, but says nothing about retention limits, scope, or how restoration is actually performed.

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

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

Two short sentences with the core meaning front-loaded and no filler. The second sentence's 'first' phrasing is slightly muddled but costs little.

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

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

For a zero-parameter, read-only listing with no output schema, describing the collection is nearly sufficient; an agent knows what it will get. Absent any note on the fields returned or whether retention is bounded, it falls just short of fully self-contained.

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

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

The tool takes no parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The empty schema is consistent with a parameterless listing operation.

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

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

Clearly identifies the resource — databases that were deleted but are still restorable — which is distinct from db_list (live databases) and db_backups. The listing verb is only implied, and it never names the restore counterpart, but the concept is unmistakable.

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

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

'Use db_delete_check first' points at a sibling, but that tool checks whether a delete is safe before deletion, not how to browse the recycle bin, so the routing advice is only tangential. There is no explicit statement of when to consult the recycle bin rather than db_list or db_backups.

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

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

Annotations already declare the important safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=true), so the description does not need to repeat it. The added 'recovering from a crash' context is useful but does not disclose operational details such as locking, duration, or impact on live tables. No annotation contradiction.

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

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

A single front-loaded sentence that states the operation and its purpose with zero waste. Nothing is padded or restated.

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

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

For a simple two-parameter tool with complete schema descriptions and safety annotations, the definition covers purpose and use context adequately. It could be richer about repair risks or the sibling alternative, but no critical calling information is missing.

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

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

Schema coverage is 100%, so both parameters (db_name, tables) are fully documented in the schema. The description adds 'one or more tables' but this is already implied by the array type, so it does not meaningfully extend parameter understanding.

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

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

States a specific verb and resource ('Run REPAIR TABLE on one or more tables of a database'), so the agent knows exactly what operation is performed. However, it does not distinguish this from the sibling db_optimize_table or explain the difference between repair and optimize.

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

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

Gives a clear use condition ('for recovering from a crash'), which tells the agent when this tool is appropriate. It does not name alternatives or state when not to use it, so it stops short of full routing guidance.

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

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

Annotations already declare this is a non-read-only, non-destructive, non-idempotent operation on an open world, so the safety profile is covered. The description adds the useful precondition that the identifier comes from db_recycle_bin, but says nothing about failure behavior, whether the DB is restored under its original name, or what happens to the recycle-bin entry.

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

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

A single sentence with no filler; the verb and required input source are front-loaded and nothing is redundant.

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 mutation with no output schema and annotations that already cover the safety profile, the description is nearly sufficient. It could say more about post-restore state or errors, but an agent has what it needs to call it correctly.

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

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

Schema coverage is 100% and the schema already gives an example rname. The description goes beyond the schema by telling the agent where the value must come from (the recycle bin listing), which is operationally necessary and not encoded in the parameter definition.

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 (restore) and resource (deleted database), and explicitly ties the operation to the recycle bin, which cleanly separates it from sibling db_recycle_bin (list) and db_delete.

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?

Names the source of the required input ('the rname shown by db_recycle_bin'), which implicitly tells the agent to call db_recycle_bin first. No explicit when-not condition or mention of alternatives such as db_import_sql, but the context is clear.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false, so the safety profile is partially covered. The description, however, omits key behavioral facts: whether the supplied host list replaces or appends to existing access, whether changes affect live connections, and whether elevated privileges are required. For a mutation tool this is a meaningful gap.

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

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

A single front-loaded sentence with no filler, appropriately sized for a simple setter. It is concise rather than padded, though the brevity is what leaves the other dimensions thin.

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 output schema and only a one-line description, the definition leaves important ground uncovered: no usage routing against db_access_get, no replacement semantics, no permission requirements. The complete input schema helps, but the description alone is not sufficient to call this tool confidently.

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

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

Schema description coverage is 100%, so the parameters (name, access, dataAccess, ssl) are fully documented in the schema, making 3 the baseline. The description adds essentially nothing beyond the schema — it doesn't clarify the 'ip' vs 'all' dataAccess semantics or how the comma-separated access list interacts with dataAccess.

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 ('Change') and a concrete resource ('which hosts a database user may connect from'), so an agent knows this mutates host-based access. It does not name the sibling db_access_get as the read counterpart, but the verb alone is enough to separate the write from the read.

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

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

No when-to-use guidance, no prerequisites (e.g. privileges needed), and no mention of the read alternative db_access_get for inspecting current access before changing it. The agent has to infer context from the name alone.

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

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

Annotations declare non-read-only, non-idempotent, open-world, non-destructive, so the safety profile is covered there. The description adds genuinely new behavioral context: the credential change cascades to the consuming application, and failing to update config breaks connectivity. It does not contradict destructiveHint=false since no data is destroyed.

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

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

Two short sentences, zero filler. The purpose comes first and the consequence warning follows immediately, both earning their place.

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

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

For a non-idempotent mutation with annotations and no output schema, the description covers the main operational hazard (config drift). It omits other relevant context such as required permissions, whether active connections are dropped, or rollback behavior, which an agent invoking a credential change would benefit from.

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

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

Schema description coverage is 100%, so all three parameters (id, name, password) are already documented, including the 'id from db_list' cross-reference. The description adds no format, length, or validation detail beyond the schema, so 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?

States a specific verb and resource: 'Set a new password for an existing database user.' The 'existing database user' scoping distinguishes it from root-password tools (danger_mysql_root_password) and from access-grant tools (db_set_access), though it doesn't name those siblings explicitly.

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

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

Gives an operational condition ('update the application config in the same change, or the app will lose the database') which implies when this is appropriate, but offers no explicit guidance on when to prefer this over db_set_access or the danger_mysql_root_password siblings.

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

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

Annotations already declare destructiveHint=false and readOnlyHint=false, and 'Safe and non-destructive to existing records' largely restates that safety profile, adding only the nuance that existing panel records are untouched. It does not mention the non-idempotent behavior flagged in annotations or any permission requirements for a write operation, so it adds limited value beyond the structured fields.

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

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

Two short sentences, with the action and scope front-loaded in the first. The second sentence is brief but partially overlaps the safety information already carried by annotations.

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-optional-parameter import tool with no output schema, the description covers the purpose, scope, and safety adequately. It lacks any note on authorization or what the call returns, but nothing essential to invoking 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?

Schema coverage is 100%, so the single 'sid' parameter and its 'website id to bind to, 0 for none' semantics are fully documented in the schema. The description adds nothing about the parameter, 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?

States a specific verb ('Pull ... into the panel inventory') and a precise scope: databases present in MySQL but untracked by the panel. This clearly separates it from siblings like db_list, db_create, and db_import_sql, which either read, create, or load SQL rather than register existing databases.

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 condition for use is explicit and narrow ('exist in MySQL but are not tracked by the panel'), so an agent knows when this tool applies rather than db_create or db_list. It does not name alternative tools explicitly or state when not to use it, which keeps it short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds value beyond them by listing the concrete fields returned (engines, row counts, size), which matters because there is no output schema.

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

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

Two short sentences: the first front-loads what is returned, the second gives the use case. No filler, no redundancy.

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

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

For a one-parameter read-only tool with no output schema, the description supplies the essential missing piece — the returned fields and their rough shape. Minor gaps remain (behavior on a nonexistent database, whether views are included), but nothing critical 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?

Only one parameter (db_name) exists and schema coverage is 100%, so the schema fully documents it. The description implies the scope is "for a database" but adds no format, case-sensitivity, or existence semantics beyond that — the baseline 3 for full schema coverage 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 the resource (a database's tables) and enumerates the specific fields returned — table names, engines, row counts, total size — so the agent knows exactly what this does. It is distinguishable in practice from siblings like db_list (databases) and db_optimize_table (mutations), though it never explicitly names those alternatives.

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

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

"Use this to confirm a schema landed before pointing an app at it" gives a concrete scenario for invocation, which is more than most siblings offer. It stops short of naming alternatives or stating when not to use it (e.g. versus db_list or db_backups).

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is covered without the description. The one added claim, 'Read-only when called without force', implies a conditional non-read-only mode that the annotations do not support and that the schema cannot express, so it muddies rather than clarifies 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?

Two short sentences with no padding, and the core purpose is front-loaded. The second sentence, while brief, is the source of the confusion, but the text is not bloated.

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

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

For a simple read-only status check with no output schema, the description should at minimum explain what is returned (e.g. availability/version signal) and how it relates to danger_update_panel. Instead it omits the return semantics and introduces an undocumented `force` mode, leaving the definition incomplete for reliable invocation.

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

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

Schema coverage is 100% for the single `check` parameter, which normally warrants a baseline of 3. However, the description never mentions `check` and instead references a nonexistent `force` parameter, which could lead an agent to pass an invalid argument; this is worse than adding no parameter information at all.

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 ('Report whether a newer panel release is available'), which is clear on its own. It does not, however, distinguish itself from the sibling danger_update_panel, which performs the actual update, so an agent must infer the routing from the name alone.

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

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

There is no explicit statement of when to use this versus danger_update_panel, nor any prerequisites. The only situational cue is 'when called without force', which refers to a mode that has no counterpart in the input schema, so it is ambiguous rather than helpful.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered by structured data. The description adds the operational framing of checking capacity before writes, but says nothing about output shape, latency, or refresh semantics beyond what the name implies.

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, zero filler, with the scope statement front-loaded and the usage trigger second. Every clause carries 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 no-parameter, read-only diagnostic with no output schema, the description tells the agent what it returns (capacity and inode usage per mounted partition) and when it is useful. Nothing needed 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 takes zero parameters, so per the baseline this is a 4. The description correctly implies the call is unscoped ('every mounted partition') and there is no parameter syntax an agent could get wrong.

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 resource and what it reports: capacity and inode usage for every mounted partition. This is clearly distinguishable from siblings like panel_system_total (system totals), panel_network_status, or panel_mysql_status, so an agent can select it without opening a schema.

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

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

Gives an explicit trigger context ('Use before any operation that writes large files, uploads a certificate, or imports a database dump'), which implicitly points at siblings like ssl_upload and db_import_sql. It stops short of stating when not to call it or naming alternatives directly, but the usage condition is concrete and actionable.

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

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

Annotations already establish readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is fully covered. The description adds polling semantics but says nothing about whether the count includes failed/stalled tasks or what state a zero implies.

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

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

Two tight sentences with the return meaning front-loaded and the usage advice second. Every clause earns its place with no filler.

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

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

For a zero-parameter, read-only polling counter with no output schema, the description tells the agent both what it measures and when to call it. Minor gaps remain around interpretation of the returned value (e.g. zero meaning completion).

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 are no parameter semantics to explain; the baseline for a parameterless tool applies and nothing in the description misleads about inputs.

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 measurable resource: the count of install/compile tasks still running. It is clearly distinguishable from informational siblings like panel_disk_info or panel_system_total, though it does not explicitly name a sibling it differs from.

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

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

It gives concrete when-to-use guidance (poll after requesting a software install) and an explicit anti-pattern (don't guess when a long operation finished). No named alternative tool, but no obvious competing sibling exists for this purpose.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered by structured data. The description adds what data is returned (version and running state), but nothing about freshness, caching, or failure modes.

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 clause of nine words that is front-loaded with the most important fact (MySQL) and contains 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?

With no output schema, the description carries the burden of describing the return payload, and it does name the two fields returned. It could optionally specify the response shape, but for a trivial no-arg status tool this is nearly complete.

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

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

The tool takes zero parameters and the schema is empty, so there are no parameter semantics to convey. Baseline 4 applies; the description correctly implies no input 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 names the specific resource (MySQL) and the two facts it reports (installed version, running state), which cleanly distinguishes it from siblings like aapanel_status or panel_disk_info. It lacks an explicit action verb, but for a no-argument status reader the resource+output framing is clear enough.

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 call this versus alternatives such as aapanel_status or panel_install_task_count, nor any stated prerequisites. The agent must infer the use case from the name alone.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds that network counters are 'cumulative' and values 'realtime', which hints at monotonic counters versus instantaneous gauges — modest value beyond the annotations, but no detail on refresh behavior or output shape.

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 efficient sentence with the resource list front-loaded and zero filler. It is terse to the point of being slightly under-specified rather than padded.

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 no-arg read-only tool with no output schema, the description is adequate but stops short of describing what the returned fields look like (units, percentage vs bytes, counter semantics). An agent can call it correctly but cannot anticipate the response.

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

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

The tool takes zero parameters, so per the calibration baseline a 4 applies and the description has no parameter semantics to compensate for.

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

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

Names the concrete resources returned (CPU, memory, load average, network traffic counters) and the 'realtime' scope, so an agent knows this is a live stats read. However, the verb is only implied, and it does not distinguish itself from the sibling panel_system_total, which plausibly reports overlapping system metrics.

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

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

There is no when-to-use guidance, no conditions, and no mention of the nearest alternative (panel_system_total). Nothing tells an agent when to prefer this tool over its sibling.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is fully covered. The description adds only the diagnostic 'confirm connectivity' framing and nothing about auth needs or rate limits; with rich annotations 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?

Two short sentences with zero filler; the returned-field list comes first and the usage hint second, both earning their place.

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

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

With no output schema, the description compensates by enumerating the fields it returns, which is exactly what an agent needs to decide whether to call it. For a zero-parameter read tool this is nearly complete, though it could state the response shape more precisely.

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

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

The tool takes no parameters, so there is no parameter semantics to explain and the baseline is 4. Nothing in the description misrepresents or omits input behavior because there is no input.

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 the exact resource and enumerates the returned fields (panel version, OS, CPU cores, CPU usage, physical memory), so an agent knows precisely what this tool surfaces. It doesn't name any sibling, but the field list is specific enough to separate it from panel_disk_info and panel_network_status.

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

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

"Use this first to confirm connectivity" gives explicit ordering guidance and a clear context for calling it, and "see what the box looks like" frames it as the overview entry point. There is no statement of when not to use it or which sibling supersedes it for deeper metrics.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true, covering the safety profile. The description usefully adds batch semantics (newline-separated values add several at once) and an external DNS prerequisite, but says nothing about duplicate-domain handling or failure modes for a non-idempotent mutation.

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

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

Three short sentences, front-loaded with the core action, then batching, then the prerequisite. Every sentence carries information an agent can act on.

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

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

With no output schema and a fully described 3-parameter schema, the description covers purpose, batch behavior, and the DNS prerequisite, which is enough to call it correctly. Only minor gaps remain around mutation semantics (duplicates, reversibility) that annotations partly mitigate.

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 id, domain, and webname are fully documented in the schema itself, including the newline/port formatting rule. The description's mention of newline separation merely echoes the schema, so it does not exceed the baseline.

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 (bind) and resource (an extra domain to an existing site), which cleanly distinguishes it from siblings like site_remove_domain and site_create. An agent can identify the operation 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?

It conveys the context (adding an additional domain to an existing site) and states a prerequisite (the site name must also be added to DNS), but never explicitly says when to prefer this over alternatives such as site_create or site_remove_domain, nor 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?

Annotations already declare it is a non-readonly, non-idempotent, non-destructive, open-world operation. The description adds the crucial behavioral fact that this is asynchronous and must be polled, which is not derivable from the annotations. It still omits what the backup produces or whether it can be safely re-run, keeping it below a 5.

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

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

Two short sentences, front-loaded with the action and followed by the completion-check guidance. No filler or restatement of the name or title.

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 async tool with no output schema, the description covers the essential gap: how to detect completion. It does not describe what a backup yields or any size/duration caveats, but the annotations carry the safety profile, so it is nearly 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% and the single parameter (id) is documented as "Website id." The description adds no syntax, format, or constraint information beyond what the schema already provides, so the baseline of 3 applies.

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

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

States a specific verb and resource ("Start a site backup"), which is clear enough to separate it from db_backup and site_list_backups by name. It does not explicitly state scope limitations or call out the sibling it is not, 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?

"Poll panel_install_task_count or site_backups to see when it finishes" is post-invocation guidance, not when-to-use guidance. It names two useful follow-up tools, but gives no condition for choosing this over an alternative or any prerequisite 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 already declare it a non-readOnly, non-destructive, non-idempotent, open-world write. The description adds genuinely new behavioral context: the panel auto-generates passwords, and they are returned exactly once, so the agent must capture and not log them. That is high-value operational detail the annotations cannot 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?

Two sentences, no filler, and the core action plus the optional composite scope are front-loaded before the credential warning. Every clause earns its place.

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

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

For a 17-parameter, no-output-schema mutation tool, the description covers the action, the optional sub-resources, and the critical credential-return behavior. It could say more about what the response contains or that creation requires subsequent site_delete to undo, keeping it from a 5.

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

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

Schema description coverage is 100%, so baseline is 3; the description nonetheless adds meaning by clarifying that FTP/DB credentials are panel-generated rather than supplied, which reframes parameters the schema marks as 'required when ftp/sql is true'. It stops short of explaining the remaining 15 parameters' interplay, so it is not a 5.

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

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

States a specific verb and resource ('Create a PHP site') plus the composite scope (optional FTP account and MySQL database in one call). This clearly separates it from siblings like db_create, site_delete, or site_add_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 phrase 'optionally with an FTP account and a MySQL database in one call' implies the user can consolidate provisioning here rather than chaining db_create and FTP calls, but there is no explicit when-to-use/when-not guidance or named alternative. Usage is implied, not stated.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description adds genuinely new context beyond that: the recycle bin exists for only 'some resources' and must not be relied on, which tells the agent how irreversible this actually is. It stops short of naming auth/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?

Three short sentences, each load-bearing: the action, the mandatory pre-check with its UX obligation, and the recovery caveat. The verb is front-loaded and there is no filler.

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

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

For a destructive two-parameter tool with full schema coverage and annotations carrying the safety hints, nothing an agent needs is missing: the action, the required prior step, and the non-guaranteed recovery are all stated. No output schema is needed since deletion returns no meaningful payload.

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% — 'id' is sourced from site_list and 'webname' is the confirmation domain, both documented in the schema itself. The description adds no syntax, format, or matching semantics beyond that, 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?

States a specific verb and resource ('Delete a site') and immediately names the sibling tool (site_delete_check) that belongs to this operation's workflow, so an agent can distinguish it from site_delete_check, site_stop, or db_delete in the sibling list.

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

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

Gives an explicit prerequisite ordering ('Run site_delete_check first') plus the user-facing condition ('show the user what would be lost'), which is exactly the when-to-use guidance a destructive tool needs. Nothing is left to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds real value by disclosing what the inspection surfaces (associated domains, databases, FTP accounts, root directory), which is the tool's actual payload since no output schema exists. It stops short of noting permission requirements or that a preview does not guarantee the deletion will succeed.

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

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

Two compact sentences with zero filler; the purpose/output enumeration comes first and the mandatory ordering call-out second. The opening nominal fragment is slightly indirect but still front-loads the meaning efficiently.

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

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

With a single required parameter, full schema coverage, and no output schema, the description carries the burden of explaining what is returned and does so by listing the blast-radius components. Adding the pre-condition that the id must reference an existing site would make it fully complete.

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

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

Only one parameter exists at 100% schema coverage, and the schema already documents it as 'Website id to inspect.' The description does not add format, constraints, or lookup guidance beyond this, 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?

States a specific verb+resource (preview what a site deletion would remove) and enumerates the affected resources: domains, databases, FTP accounts, root directory. It is clearly distinguished from the sibling site_delete, which performs the actual removal.

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

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

Explicitly states the condition and ordering: 'Always call this before site_delete so the user can see the blast radius.' The alternative (site_delete) is named and the relationship between the two is unambiguous.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is fully covered. The description contributes the list of values read (anti-cross-site flag, access-log flag, run directory), which is real content-level information not present in annotations or schema, but it adds nothing about permissions or result format.

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 with no filler, though it is phrased as a noun fragment rather than a complete statement of action, which slightly weakens front-loading.

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, enumerating the returned flags is genuinely useful and partially compensates. However, it remains unclear what format the flags take or how the run directory is returned, leaving the description only adequately complete for a two-parameter read tool.

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

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

Schema description coverage is 100% for both required parameters (id, path), so the schema documents them adequately. The description adds no parameter-level meaning, which is the expected baseline when the schema does the heavy lifting.

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

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

The description names the resource (.user.ini flags plus the site run directory) but never states a verb, so the agent must infer that this is the read counterpart of site_set_dir_userini. The sibling setter makes the read/edit split inferable from the name pairing, but the description itself does no differentiating work.

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

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

There is no when-to-use guidance, no prerequisite mention (e.g., needing a path from site_get_root, which the schema does cover), and no explicit routing away from site_set_dir_userini. Usage is only implied by 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds an efficiency/reliability rationale, but says nothing about error behavior, missing ids, or what the record contains.

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

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

Two front-loaded sentences with no wasted words. The primary action is stated first, and the comparative guidance follows immediately.

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

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

For a simple one-parameter read tool with rich annotations and no output schema, the description covers what an agent needs to select and invoke it correctly. It could optionally mention behavior when the id is not found, but the gap is minor.

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

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

Schema description coverage is 100%, and the single 'id' parameter is already documented as 'Website id from site_list.' The description reinforces that the id must be known but adds no syntax or format detail 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?

States a specific verb and resource ('Fetch a single site record by id'), which is clear. It distinguishes itself from site_list by contrasting with 'paging the whole list,' but does not differentiate from other site_get_* siblings like site_get_config or site_get_ssl.

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

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

Explicitly says when to prefer this tool over site_list: when the id is already known, and explains why (cheaper and more reliable than paging). It gives clear context but no exclusions or guidance against other site_get_* alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered. The description adds that output is the 'raw' file (unparsed), which is useful, but says nothing about behavior when the path is invalid or missing, or about output size/format.

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

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

Two short sentences with no padding; the resource statement is front-loaded and the debugging scenario follows it. It could be marginally tighter or fold the scenario into a clearer when-to-use clause, but there is no waste.

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

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

No output schema exists, and the description only implies the return is raw file text — it does not note error behavior for bad paths or whether large configs are truncated. For a one-param read tool with full annotation coverage this is adequate but leaves real gaps.

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

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

Schema description coverage is 100%; the single `path` parameter is already documented with an absolute-path example in the schema. The description does not add format or constraint detail beyond that, so it sits at 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?

States a specific resource — the raw nginx/apache vhost file for a site — which is more concrete than a bare 'get'. It is less clear about how it differs from siblings like site_get, site_get_rewrite, or danger_read_file, so an agent must infer the scope from the 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?

The description gives a usage scenario ('debugging a 502 or a rewrite that is not taking effect'), which is genuinely helpful context for when to reach for it. However it names no alternatives (e.g., site_get_rewrite for parsed rules) and states no exclusions, so routing is only 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is fully covered. The description adds only the review-before-apply framing; it discloses nothing further about failure behavior or template-path constraints.

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

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

One sentence with zero filler, front-loading what is returned before the rationale. Nothing is wasted or buried.

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

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

For a single-parameter read tool with full annotation coverage, the description plus schema is sufficient to call it correctly; no output schema exists, and 'contents of one rewrite template' adequately indicates the return. It could still note behavior on a missing path, hence not a 5.

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

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

There is a single parameter with 100% schema description coverage, including an example absolute path, so the schema carries the parameter burden. The description adds no additional meaning about path format or validity, matching the 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?

States a specific resource (one rewrite template) and what it returns (its contents), and the title's 'Read' verb is unambiguous. The distinction from site_rewrite_templates (list all) and site_set_rewrite (apply) is inferable but not stated, so it stops short of a clear 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?

The phrase 'so a rule can be reviewed before it is applied to a live site' implies the use case (preview prior to applying). However, it names no alternative tool and gives no when-not guidance, leaving routing to the agent's inference.

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

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

The annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds that the return value is an absolute root directory and that it avoids listing every site, but it does not disclose authentication needs, error behavior, or output format. 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 a single short sentence with no wasted words. The scope constraint is front-loaded and the sentence 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?

For a simple read-only getter with 100% schema coverage and full annotation coverage, the description is nearly complete. It states the returned value and scope, though it stops short of explicit usage routing among the many sibling tools.

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

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

Schema description coverage is 100%, so the schema already documents id, key, and table adequately. The description adds no parameter-level meaning, such as explaining the key or table defaults, 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 states the specific resource: the absolute root directory of a site. It distinguishes itself from site_list by saying 'without listing every site', though the verb 'get' is only implied by the tool name rather than stated outright.

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

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

There is no explicit when-to-use guidance, no when-not-to-use guidance, and no named alternative such as site_get or site_list. The phrase 'without listing every site' hints at a scope distinction, but it does not tell the agent when this tool is the right 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that certificate subject and expiry are returned 'when present', hinting at conditional/possibly empty results, but says nothing about auth needs, error cases, or response shape.

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 that states the resource and the return content with zero redundancy. Nothing to trim.

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

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

With no output schema, the description takes on return-value explanation and does so adequately at a high level (deployment status, cert subject, expiry). It is complete enough for a trivial one-parameter read, though it does not characterize the shape of the 'not present' case.

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 there is only one parameter, so the schema fully documents siteName as the primary domain. The description adds no syntax or format detail beyond what the schema already provides; baseline 3 applies.

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

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

The description names a specific resource (SSL status of a site) and specifies the returned content: deployment status plus certificate subject and expiry. It is unambiguous against siblings like ssl_deploy or ssl_disable, though it does not explicitly contrast with site_get or ssl_list.

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

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

There is no guidance on when to call this versus alternatives such as ssl_list or site_get, and no stated prerequisites. The agent must infer usage purely 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds the returned field set, which is useful, but says nothing about pagination behavior or result volume despite page/limit parameters existing.

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, zero filler, and the payload contents are front-loaded before the usage hint. Every clause earns its place.

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

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

With no output schema, the description usefully enumerates the returned fields, and annotations cover the safety profile. Pagination/filtering behavior is left entirely to the schema, which is acceptable but slightly under-described for a list tool.

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

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

Schema description coverage is 100%, so all four parameters (p, limit, type, search) are already documented with defaults and semantics. The description adds no parameter-level detail beyond the hint that most operations need a numeric site id, so baseline 3 applies.

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

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

The description names a specific resource (PHP sites) and enumerates the returned fields (id, domain, root path, remark, expiry, backup count), so an agent knows exactly what this call yields. It doesn't explicitly contrast with near siblings like site_list_domains or ssl_list, 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?

"This is the entry point for any site operation, since most actions need a numeric site id" gives a clear condition for reaching for this tool first. It stops short of naming alternatives or exclusions (e.g., when to prefer site_get for a known id).

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true. The description adds useful ordering information ('newest first'), but does not mention pagination, response shape, or other behavioral details beyond the safety profile.

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 phrase with zero waste. It front-loads the resource and includes the ordering cue, making it appropriately sized for a simple list tool.

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

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

For a simple list operation with rich annotations and full schema descriptions, the description covers the resource, scope, and ordering. It omits pagination details, but those are fully specified in the schema, so the omission is minor.

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

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

Schema description coverage is 100%, so all four parameters are already documented. The description only implies that 'search' maps to a site, adding no syntax or format detail beyond the schema.

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

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

The description names the resource (backup records) and scope (for a site), and the title supplies the verb 'List'. It also adds the ordering ('newest first'), but it does not explicitly differentiate itself from sibling tools like db_backups or site_backup.

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

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

The description gives no when-to-use guidance, no prerequisites, and no alternatives. It relies entirely on the tool name and title for context, leaving the agent to infer usage from siblings.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is fully covered externally. The description adds one genuinely useful behavioral detail — that each domain is returned with the port it answers on — but says nothing about ordering, count limits, or 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?

One short sentence, front-loaded with the resource and closing with the most useful extra fact (the port). No filler at all.

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

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

For a one-parameter read tool with rich annotations and no output schema, the description is nearly sufficient — it even previews the returned fields. Only the absence of any routing toward sibling tools keeps it from a 5.

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

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

Schema coverage is 100% and the single 'id' parameter is described as 'Website id.' in the schema, so the description need not restate it. Baseline 3 applies since the description adds no parameter detail beyond the schema.

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

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

Names a specific resource (domains bound to a site) and the tool name supplies the list verb. It is clearly distinguishable from site_add_domain and site_remove_domain, though the description itself never names those siblings.

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

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

Usage is implied by the resource name rather than stated: an agent can infer this is the read path when it needs a site's domains. There is no explicit when-to-use, no exclusion, and no pointer to alternatives such as site_get or site_add_domain.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description's 'currently runs' adds a small hint that this is live runtime state rather than configured state, but it discloses nothing beyond that – no auth requirements, caching, or return format.

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

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

A single short sentence with no filler and the key scope term ('specific site') front-loaded. It loses a point only for being a verbless fragment rather than a complete, self-contained statement.

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 trivial one-parameter read tool with full schema coverage and no output schema, the description tells the agent what question it answers. It is nearly complete, with only minor ambiguity about the exact shape of the returned version value.

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

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

Schema coverage is 100% and siteName is documented as the primary domain, so the schema carries the parameter burden. The description adds no further meaning about the parameter. 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 attribute (PHP version) and scope (a specific site), which distinguishes it from a setter like site_set_php_version. However, it is a sentence fragment without a verb, and it does not explicitly differentiate itself from the sibling site_php_versions (plural), which likely lists available versions rather than the currently active one.

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

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

There is no guidance on when to use this tool versus site_php_versions or site_set_php_version. The agent must infer from naming alone whether this returns the active version or the available set.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds genuine domain context with the '00' pseudo-version semantics, which annotations cannot express, but says nothing about return shape or ordering for a listing tool.

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

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

Two tight sentences with the core enumeration front-loaded and the edge-case explanation second. Every clause carries information; nothing is padding.

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

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

For a zero-parameter, read-only enumeration with strong annotations and no output schema, the description covers what the agent needs: what comes back and what the special version value means. Only minor gaps remain around output ordering/format.

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 and the schema is empty at 100% coverage, so the baseline is 4. Nothing about parameters needs explaining.

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 precisely what the tool enumerates: every PHP version installed on the panel, plus the special '00' pseudo-version for pure static. It is unambiguous about the resource, though it never distinguishes itself explicitly from the sibling site_php_version tool, leaving the agent to infer the difference.

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?

'Pass one of these versions when creating a site' gives a clear consumption context, telling the agent this is a lookup feed for site_create. It stops short of naming sibling alternatives or stating when not to use it, but the use case is easy to infer.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false, so the safety profile is covered. The description adds real value beyond that by defining the blast radius: only the domain binding is removed and the site survives, which is exactly the context an agent needs before invoking a destructive 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 tight sentence with zero waste, and the scope-limiting clause is front-loaded where the agent will read it.

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 4-parameter mutation with no output schema, the annotations and full schema coverage carry most of the load and the description covers purpose and scope. It stops short of noting side effects the agent might care about, such as impact on SSL, DNS, or redirects attached to the removed domain.

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 id, webname, domain and port are all documented in the schema itself. The description adds no syntax, format, or defaulting detail beyond that, 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?

States a specific verb+resource ("Unbind one domain from a site") and adds the disambiguating scope clause "leaving the site itself intact," which separates it from site_delete. It does not name the counterpart sibling site_add_domain, so it is clear but not explicitly differentiated by 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?

There is no explicit when-to-use or when-not-to-use guidance. The phrase "leaving the site itself intact" implicitly contrasts with site_delete, so the usage context is implied rather than stated, and no alternative tool is 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds only that these are templates 'shipped with the panel', implying a static server-provided catalog, but says nothing about ordering, count, or whether entries vary per site.

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 with the resource stated first and illustrative examples last. It is well sized for a trivial list tool, though it is a fragment rather than a full statement of 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 read-only list tool with full annotation coverage and a fully documented single param, the description is minimally sufficient. It stops short of connecting the returned templates to the sibling that consumes them (site_set_rewrite), leaving the workflow implicit.

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?

There is a single parameter with 100% schema description coverage ('Primary domain of the site'), so the schema already carries parameter meaning. The description adds nothing about siteName or why a site is required to list global templates. Baseline 3 is appropriate.

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

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

The description names the specific resource (named rewrite rule templates) and gives concrete examples (wordpress, laravel5, thinkphp), so an agent knows this returns a catalog of available templates. However it uses no verb and does not differentiate itself from adjacent siblings like site_get_rewrite or site_set_rewrite.

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

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

There is no when-to-use or when-not-to-use guidance, and no mention of the obvious workflow (call this to discover valid template names before invoking site_set_rewrite). The agent must infer the purpose from the noun phrase alone.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that — notably it never says which direction the toggle moves, what state results, whether it is idempotent in practice, or whether a reload is required.

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

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

A single tight sentence with no filler, and the operation is front-loaded. It is terse to the point of under-specification, but nothing in it is wasteful.

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

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

This is a mutating tool with no output schema and no description of the resulting state or how a caller controls the toggle direction (there is no boolean parameter). For a state-changing operation that flips an unknown current value, the description leaves the agent unable to predict the outcome.

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

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

Schema coverage is 100% for both parameters (id, path), so the schema carries the parameter documentation and the baseline is 3. The description adds no meaning about how 'path' relates to the site root the tool modifies.

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 ('toggle') and a specific resource ('.user.ini cross-site protection for a site'), so an agent knows the operation domain. It stops short of explicitly distinguishing itself from the read-side sibling 'site_dir_userini', which is left to the name pattern to convey.

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

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

No guidance on when to use this versus 'site_dir_userini' or 'site_get_config', and no mention of prerequisites (e.g. whether the site must be running). The agent must infer everything from the name.

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

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

Annotations already declare the write profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the safety picture is covered. The description adds useful domain context that this affects how nginx resolves directory index requests, but omits whether the change is immediately live or requires a reload, and what happens to the previous index list.

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

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

A single tight sentence with the action front-loaded, no filler. The trailing 'comma separated' is slightly redundant with the schema but costs little.

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 annotations covering the write profile and a fully described schema, the definition is minimally viable, but for a config-mutating tool it should at least indicate that the site id must reference an existing site and whether a reload/restart is implied.

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

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

Schema coverage is 100% with both parameters fully described, so the schema already carries the semantics. The description only restates the comma-separated format already present in the Index parameter description, adding no new format or validation detail.

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 ('Change') and resource (nginx directory index filenames), which tells an agent exactly what the tool mutates. It is distinguishable from read-only siblings like site_get_config or site_get_rewrite, though it never names a specific alternative it could be confused with.

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

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

There is no guidance on when to use this versus siblings such as site_set_rewrite or site_set_run_path, nor any prerequisite (e.g. that the site must already exist, or that nginx may need a reload). The agent must infer usage entirely.

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 flag this as a non-read-only, non-idempotent mutation, and the description adds a real behavioral caveat beyond them: extensions may differ between versions, so the agent should verify after switching. It still omits whether the site is restarted or when the change takes effect.

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

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

Two short sentences, front-loaded with the action and followed by the one caveat that matters. 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 two-parameter mutation with no output schema and annotations covering the safety profile, the description gives an agent enough to act correctly, including the post-change verification step. Only minor gaps remain, such as restart/rollback behavior.

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

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

Schema coverage is 100%, so both parameters are documented in the schema, including that version should come from site_php_versions. The description's 'installed PHP version' is consistent but adds no syntax or format detail beyond the schema, 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?

States a specific verb and resource: switching a site to another installed PHP version. This clearly distinguishes it from read-only siblings like site_php_versions and site_php_version, though it does not name those siblings explicitly.

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

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

Usage context is implied by 'switch a site to another installed PHP version' and the 'verify afterwards' caveat, but there is no explicit when-to-use statement and no routing to alternatives such as site_php_versions for discovering valid targets.

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

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

Goes beyond the annotations by disclosing that the current rule is overwritten and that nginx is reloaded (an open-world side effect consistent with openWorldHint=true). It adds real value the annotations do not carry. Note the overwrite behavior sits somewhat uneasily with destructiveHint=false, but overwriting a config with new content is not a straight contradiction.

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

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

Two tight sentences with the action and its side effect front-loaded, followed by the safety caveat. Nothing is wasted and nothing is buried.

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 output schema, the description covers the key behaviors: overwrite semantics and the nginx reload. It omits rollback/failure behavior and any permission requirements, which would matter for a live-config write, but the essentials for calling it correctly are present.

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

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

Schema description coverage is 100%, so all three parameters (path, data, encoding) are already documented in the schema. The description adds no syntax or format detail beyond that, 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?

States a specific verb and resource ('Write the rewrite config for a site') plus the operational side effect ('reload nginx'). It implicitly distinguishes itself from the read-side siblings (site_get_rewrite, site_rewrite_templates) by telling the agent to read the existing rule first.

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

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

Gives clear operational context: use this when changing a live rule, and read the existing one first. It does not name the alternative tool (site_get_rewrite) explicitly, but the workflow guidance is strong and actionable.

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

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

Annotations already declare it as a non-read-only, non-destructive, non-idempotent, open-world mutation, so the safety profile is covered. The description adds one useful behavioral constraint – the directory must already exist inside the site root, i.e. it will not create it – but says nothing about whether nginx is reloaded, permissions required, 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?

Two sentences, front-loaded with the effect and followed by the precondition. Every clause earns its place with no filler.

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

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

For a simple two-parameter setter with full schema coverage and no output schema, the description supplies the purpose plus the key precondition. It is nearly complete; only operational details such as restart/reload implications or error handling are absent, which is acceptable at this complexity.

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

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

Schema description coverage is 100%, so both id and runPath are already documented in the schema. The description reinforces that runPath is relative to the site root and must exist, adding modest value but no format or syntax detail beyond the schema's own '/public' example. 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?

States a specific verb and resource (change the directory nginx resolves requests against) and the scenario it serves (entry point in a subdirectory like /public). Sibling tools such as site_set_index and site_set_rewrite are clearly distinct in subject matter, though no sibling is named explicitly.

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

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

Gives a concrete condition for use: apps whose entry point lives in a subdirectory such as /public. It does not state when to avoid this tool or point to alternatives (e.g., site_set_index for default index files), but the triggering context is clear.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds the state precondition ('stopped') and the outcome ('back online'), but says nothing about idempotency behavior (starting an already-running site) or failure/reversal conditions.

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

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

A single short sentence with the state precondition and resulting outcome front-loaded; no filler whatsoever.

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 low-complexity two-parameter lifecycle toggle with full schema coverage and annotations carrying the safety profile, the description is essentially sufficient. Only minor gaps remain around re-starting a running site and the absence of an explicit pointer to site_stop.

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% for both required params (id, name), so the schema already carries the parameter semantics. The description adds no format or usage detail about the domain-name or id arguments, matching the baseline 3 when the schema does the heavy lifting.

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

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

States a specific verb+resource: bringing a stopped site back online. It is clearly the inverse of the sibling site_stop and distinct from site_create/site_delete, though it never names those siblings explicitly.

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

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

Usage is only implied by the precondition 'stopped site' — an agent can infer it applies to a halted site, but there is no explicit when-to-use/when-not statement, no mention of what happens if the site is already running, and no named alternative.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description usefully confirms the site is retained rather than removed, but says nothing about whether the operation is reversible, what happens if the site is already stopped (relevant given idempotentHint=false), or what is returned.

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 eight-word sentence with zero filler, and the key constraint is front-loaded. It is arguably terse for a state-changing tool, but nothing is wasted.

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

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

For a simple two-parameter state toggle with annotations covering safety, this is minimally adequate. It omits reversibility (site_start), what happens on repeat invocation, and any response behavior, which leaves modest gaps 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 coverage is 100% with both 'id' and 'name' fully documented in the schema, so the baseline is 3. The description adds no format or syntax meaning beyond what the schema already provides.

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

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

States a specific verb+resource ('take a site offline') and adds a scoping clause ('without deleting it') that distinguishes it from site_delete. It does not explicitly name site_start as the inverse, but the purpose is unmistakable.

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

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

No when-to-use guidance, no prerequisites, and no mention of the obvious alternative site_start for bringing the site back up. The 'without deleting it' clause only implicitly signals usage.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuine semantic value by defining id 0 as the default group, but says nothing about whether the set is static, how many entries exist, or what the entries contain beyond ids.

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

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

A single front-loaded sentence with no filler; the most decision-relevant fact (id 0 = default) is included rather than padded with boilerplate.

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-param enumeration with no output schema, the description is adequate but thin: it never says what a returned entry looks like (id plus name?) or whether the list is stable, which is the missing piece when no output schema exists to carry that load.

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

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

The tool takes zero parameters, so the baseline is 4. The description's note about id 0 applies to returned values rather than inputs, but for a no-argument lookup there is nothing further the description could document about parameters.

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

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

The description names the resource precisely: available site groups/classification ids, and usefully flags that id 0 is the default. It is clearly a read-only enumeration tool, distinguishable from siblings like site_list or site_get, though the verb ('list'/'retrieve') is implied rather than stated.

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

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

There is no when-to-use guidance and no mention of alternatives. The natural use case — calling this to resolve valid group ids before site_create or similar — is left entirely to inference.

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

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

Annotations already disclose readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is largely covered. The description nonetheless adds a genuinely useful behavioral fact not derivable from the annotations: the deployment overwrites the sites' existing SSL configuration, which tempers the 'non-destructive' hint. It does not cover failure behavior, rollback, or auth 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?

A single, front-loaded sentence with the action first and the side effect second. No filler, no restatement of the title, nothing wasted.

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

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

For a two-parameter mutation tool with full schema coverage and annotations but no output schema, the description covers what it does and its main side effect. It stops short of naming the upstream prerequisite (an uploaded certificate) and what happens if binding fails for one of several domains, which would be helpful for a multi-target operation.

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

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

Schema description coverage is 100%, with both required parameters documented (hash sourced from ssl_list/ssl_upload; domains as an array of domain strings). The description adds only the loose confirmation that domains can be multiple sites, so the baseline of 3 applies since the schema does the heavy lifting.

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

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

The description states a specific verb and resource ('Bind a stored certificate') plus the target scope ('to one or more sites') and the effect ('replacing their current SSL configuration'). The phrase 'stored certificate' implicitly separates it from ssl_upload (which stores) and ssl_disable (which removes), so an agent can pick it 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?

Usage is only implied: the word 'stored' hints that a certificate must already exist (via ssl_upload or ssl_list) before deploying. There is no explicit when-to-use, no statement of when NOT to use it (e.g., vs ssl_disable), and no mention of prerequisites or required panel permissions.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the barrier is lower. The description usefully adds what is destroyed (SSL config) and the resulting state (plain HTTP), but says nothing about irreversibility, whether the certificate is deleted, or side effects like HTTPS downtime.

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

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

A single front-loaded sentence with no filler; the effect is stated before the consequence. Every clause earns its place.

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

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

For a destructive mutation with no output schema, the description covers the high-level effect and the annotations cover the safety profile, but it omits prerequisites, reversibility, and error/edge behavior. Adequate but with 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 100%, with both siteName and updateOf documented in the schema, so the baseline is 3. The description adds no parameter-level meaning, such as what siteName expects or why updateOf must be set.

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

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

The description gives a specific verb+resource ('Remove the SSL configuration from a site') plus the resulting state ('returning it to plain HTTP'). It is easy to distinguish from ssl_upload/ssl_deploy by the 'remove' verb, though it does not explicitly name those siblings.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as ssl_deploy or ssl_list. The agent must infer the 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?

Annotations already declare readOnly, idempotent, non-destructive, and open-world behavior, so the safety profile is covered. The description adds useful content about what the results contain (the deploy hash), but says nothing about pagination behavior, result ordering, or size limits.

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 with the resource and the key payload detail front-loaded; nothing is wasted. It reads as a fragment without an explicit verb, which costs it the top score.

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 paginated list tool with no output schema and fully documented parameters, the description covers what is returned and why it matters (the deploy hash). Only pagination/ordering behavior is unaddressed, which is a minor omission.

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 (p, limit) are fully documented in the schema with defaults, bounds, and semantics. The description adds no parameter meaning beyond that, 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?

Identifies the resource (SSL certificates uploaded to the panel) and adds a distinctive detail — that each entry carries the deploy hash. That distinguishes it from ssl_upload/ssl_deploy/ssl_disable, though the verb is only implied by the name rather than stated.

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

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

No explicit when-to-use or when-not statement. The phrase 'the hash needed to deploy one to a site' implicitly routes the agent here before calling ssl_deploy, but that workflow dependency must be inferred rather than being spelled out.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description usefully adds that it accepts sensitive private-key material and returns a hash, but says nothing about overwrite behavior (relevant given idempotentHint=false) or validation failures.

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

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

Two short sentences with zero padding, and the storage action is front-loaded ahead of the return-value contract. Every clause carries 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 output schema, the description correctly compensates by naming the return value (the hash) and its purpose. For a two-parameter tool with full schema coverage this is nearly sufficient; only error/overwrite behavior is unaddressed.

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% — both 'cert' and 'key' are documented in the schema with PEM formatting requirements. The description only restates the two inputs at a high level, adding no syntax, encoding, or ordering detail beyond the schema. 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 verb and resource ('Store a PEM certificate and private key in the panel') and names the concrete artifact produced (the hash consumed by ssl_deploy). This clearly separates it from siblings like ssl_list, ssl_deploy, and ssl_disable, which operate on already-stored certificates.

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 establishes the workflow context by saying the returned hash is used by ssl_deploy, which tells the agent this is the prerequisite step for deployment. However, it never states when NOT to use it (e.g., to replace an existing certificate) or whether an alternative sibling exists for that case.

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