turbopress

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

Annotations only declare write/non-destructive; the description goes far beyond by disclosing first-run account creation, idempotency (existing account unchanged), the created/exists response signal, the 60-minute welcome-email password link that fires only in the created branch, and the automatic scans that follow. This is exactly the behavioral context an agent needs and cannot get from 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?

Front-loads the core action and keeps detail proportional to the tool's real complexity (idempotency, email timing). The parenthetical source-code confirmation and timestamp are slightly verbose but they substantiate a behavior an agent must not misreport, so nearly 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?

With no output schema, the description compensates by explaining the created/exists response and the downstream scan tools, which is enough to call and interpret it. It omits auth/permission requirements and error cases, leaving only 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?

Only one parameter ('domain') with 100% schema description coverage, so the schema already documents it fully. The description adds no format or syntax detail beyond 'für eine Domain', 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 ('Aktiviert') and resource ('turbometrics'), plus its scope ('für eine Domain') and what the product is (kostenlose Performance-Überwachung für turbopress-Kunden). This clearly separates it from sibling monitoring tools like start_performance_scan and get_performance_score.

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

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

It explains the activation workflow and names the follow-up tools (get_performance_score, get_performance_findings), which implies the usage context. However it never states explicitly when to choose this tool over alternatives (e.g. start_performance_scan) or any preconditions, so guidance is implied rather than explicit.

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

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

Annotations declare destructiveHint=true and readOnlyHint=false. The description adds concrete impact beyond the annotations: a faulty record can break mail delivery or website reachability, and Plesk rejects MX records without a priority. It does not state auth requirements or reversibility, but adds meaningful operational context.

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

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

Front-loads the purpose, then covers MX and TXT edge cases and ends with a check-before-confirm warning. Five sentences with no obvious repetition, though some schema details are 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?

Given the rich schema descriptions and destructive annotation, the description is complete enough for safe invocation. It omits authentication/prerequisites and return details, but no output schema exists and the host pitfalls are covered in the schema.

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

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

Schema coverage is 100%, so parameters are already documented in detail. The description still adds semantic weight by tightening priority from 'usually required' to mandatory for MX and confirming TXT/DKIM usage and the 2048-character limit.

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 ('Legt... an') and resource ('DNS-Record auf einer Domain') plus the supported record types. It implicitly distinguishes creation from sibling delete_dns_record and get_dns_records by the action, but 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?

No explicit when-to-use or when-not-to-use guidance. It gives a conditional for MX priority and a caution to check details, but does not route the agent between this and alternatives like get_dns_records or delete_dns_record.

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 destructiveHint=true, but the description goes far beyond that: it enumerates concrete side effects (securityKeys ends all sessions, adminUsername replaces the login name, dbPrefix alters the database, secureContent/disableUnusedScripting can break wp-content plugins) and flags that five measures cannot be undone. This is exactly the behavioral context an agent needs before a destructive call.

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

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

Front-loaded with the core action and the single-measure constraint, then the discovery pointer, then the critical side-effect list. Every sentence carries decision-relevant information; nothing is padding despite the density.

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 write tool with no output schema and three fully documented parameters, the description supplies scope, discovery path, side effects, and reversibility limits. Nothing an agent needs to call it safely is missing.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds a real semantic constraint beyond the schema: EXACTLY ONE measure per call, and it names the sibling (get_wordpress_hardening) that supplies valid measure values. That meaningfully lifts it over the schema-only 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 and resource ("Wendet GENAU EINE WP-Toolkit-Härtungsmaßnahme auf eine WordPress-Installation an") and immediately scopes it as a single measure, which is critical for a destructive operation. It also routes to get_wordpress_hardening for the valid identifiers, so the agent can distinguish this from the discovery sibling without opening either schema.

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

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

Explicitly points the agent to get_wordpress_hardening as the prerequisite for obtaining valid measure identifiers, and warns that five of nineteen measures are irreversible. It does not name revert_wordpress_security_measure as the undo path for the reversible fourteen, so the guidance is clear but not fully complete on 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=true and destructiveHint=false, so the safety profile is covered. The description adds a genuine behavioral trait beyond that: only an unambiguous WHOIS status is reported as available/registered, and an inconclusive lookup is surfaced as such rather than being guessed. That uncertainty-handling behavior is not derivable from the schema or annotations.

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

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

Two front-loaded sentences with no filler; the mechanism and the scope constraint come first, followed by the reporting behavior. Slightly dense but 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 one-parameter, read-only lookup with no output schema, the description covers what the tool does, what it accepts, and how ambiguous results are reported. Only the absence of any explicit routing against sibling domain tools keeps it from being 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?

Schema description coverage is 100% and the single 'domain' parameter is already documented with a format example ('z. B. example.de'). The description adds no syntax or validation 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 ('Prüft, ob eine beliebige Domain zur Registrierung verfügbar ist') and pins down the mechanism (WHOIS-Lookup). The parenthetical clarifying that it is 'nicht auf eigene Domains beschränkt' implicitly distinguishes it from sibling get_domains, 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?

The scope note tells the agent this works for arbitrary domains, which is useful context, but there is no explicit statement of when to prefer this over prepare_domain_order or suggest_domain_alternatives. Usage is implied rather than directed.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description goes further by describing the result structure (three separate categories, affected files named per category) and by warning that legitimate manual edits also trigger findings. That interpretative framing is real added value beyond the annotations, though return format/pagination details are absent.

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

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

Front-loaded with the core comparison and the three finding types, with the scope limit and the caveat following. Four sentences, each carrying distinct information, though the first sentence is long and packs mechanism plus enumeration together.

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 explaining returns and does so by naming the three finding types and stating that files are listed per type. Combined with the explicit scope boundary and the false-positive caveat, an agent has enough to call and interpret the tool correctly, though exact output shape remains unspecified.

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

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

Schema description coverage is 100% – both 'domain' and 'site_url' are documented in the schema, including when site_url is needed. The description adds no parameter-level information 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?

The description states a concrete verb and resource (compares a WordPress installation against official checksums) and enumerates the exact three finding categories it produces. The scope constraint 'only the WordPress core, not plugins, themes or uploads' implicitly separates it from neighbors like scan_wordpress_vulnerabilities, get_outdated_plugins and get_wordpress_hardening.

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 – checking core integrity is a post-compromise or hygiene action – but the description never states when to reach for this tool versus scan_wordpress_vulnerabilities or get_wordpress_hardening, nor any prerequisites. The interpretation caveat ('a finding is not automatically a break-in') is helpful context rather than 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?

Adds substantial context beyond the annotations: it discloses that it reads plugin state first, enumerates three distinct outcomes, warns that the "not determinable" outcome is not an all-clear, and states that content is preserved but the next requests are briefly slower. This is exactly the behavioral disclosure a non-destructive mutation tool needs.

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

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

Front-loads the core action and mechanism, then layers the outcome semantics. Slightly dense and the "live gemessen, wirkt nachweislich" phrasing is mildly promotional, but every sentence carries functional 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 compensates by describing the three possible outcomes and the misleading one, plus the side effect on subsequent requests. An agent has enough to call it and interpret the result 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 both parameters are already documented in the schema, including the site_url multi-installation caveat. The description mentions the domain context but adds no parameter syntax or format detail beyond the schema, so the baseline 3 holds.

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 (clears the WordPress cache of a domain) and even names the exact mechanism ("wp litespeed-purge"). An agent can immediately distinguish this from cache-adjacent siblings like get_performance_score or update_wordpress_core.

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 frames the trigger condition: "Erster Schritt, wenn Änderungen an der Website nicht sichtbar werden." That is clear when-to-use guidance. It stops short of naming a specific alternative tool or when-not-to-use, so it doesn't reach 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=false and destructiveHint=false, so the safety profile is partly covered. The description adds only that the ticket is one's 'own' and already exists; it says nothing about whether closing is reversible, whether the ticket can be reopened, whether confirmation or special permissions are required, or what happens to the ticket afterwards.

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 action verb is front-loaded. It is efficient, though the extreme brevity leaves substance to the other dimensions rather than adding structure or scoping detail.

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

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

For a one-parameter mutation tool with no output schema and full schema coverage, the description is minimally sufficient to call the tool. It still omits what an agent would want to know before acting: whether closing is final, what state the ticket ends in, and any authorization scope beyond 'eigenes'.

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 ticket_id is documented in the schema as the internal ID shown by get_support_tickets, so the baseline is 3. The description adds no additional parameter meaning beyond that.

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

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

States a specific verb and resource ('Schließt ein bestehendes ... Support-Ticket'), which clearly separates it from create_support_ticket, get_support_tickets and reply_to_ticket in the sibling list. It does not, however, explicitly name those siblings or contrast behavior with them.

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

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

'bestehendes eigenes' implies a precondition (the ticket must already exist and belong to the caller), which is useful usage context. But there is no explicit when-to-use guidance and no routing to alternatives such as reply_to_ticket when the user actually wants to respond rather than close.

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 only declare readOnlyHint=false and destructiveHint=false. The description adds substantial behavior: server-side validation with rule-specific rejection, file-existence checks for exec/php, warnings returned when files are missing, and explicit instructions about uncertain results. This goes well beyond 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?

The description is front-loaded with the purpose, then adds only decision-relevant constraints about validation and response warnings. Each sentence contributes to correct invocation, and the length is justified by the tool's validation complexity.

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 validation behavior, the file-check edge case, warning propagation, and uncertainty handling. An agent has enough context to call this correctly and to relay results accurately.

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 detailed per-parameter semantics for type, command, schedule, and domain. The description mainly points back to the command schema rather than adding new parameter meaning, so 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?

States a specific verb and resource ('Richtet einen wiederkehrenden Cronjob für eine Domain ein') and scopes it to Plesk scheduled tasks, so it is distinguishable from get_cronjobs and delete_cronjob 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?

Provides clear usage context: read the command rules before suggesting a command, and notes that a missing file still creates the cronjob with a warning. It does not explicitly name alternative tools or when not to use this one, so it stops short of the top score.

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 and destructiveHint=false, so the safety profile (a write that is not destructive) is covered. The description usefully adds that this is a MySQL database scoped to a domain, but says nothing about irreversibility, whether duplicates are rejected, or naming failures beyond what the schema documents.

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

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

One tight sentence with the verb and resource front-loaded and zero filler. Nothing redundant, though it is brief enough that the missing usage context is conspicuous.

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 whose annotations cover the safety profile and whose schema fully documents both inputs, plus no output schema to explain, the description is minimally adequate. It leaves the key workflow question (relationship to create_database_user) unanswered.

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

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

Schema description coverage is 100% with both parameters (name, domain) fully documented in the schema, including the character constraints on name. The description adds no parameter syntax or format detail 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?

States a specific verb (legt an / creates), resource (MySQL-Datenbank) and scope (auf einer Domain), so the agent can tell it apart from read tools like get_databases or delete_database. However it does not distinguish itself from the closely related sibling create_database_user, which is the most likely confusion point.

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 instead of alternatives, no prerequisites (e.g. whether the domain must already exist, whether a database user must be created separately), and no mention of the create_database_user sibling. Usage must be inferred entirely from the name.

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

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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false), so the bar is lower, and the description still adds genuine value: the password is generated randomly for the agent and surfaced in the response. This tells the agent both that it should not supply a password and where to find it. Missing are permission requirements and any failure-mode 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?

A single tight sentence that front-loads the create action and then the two key facts (linking, generated password). No filler, nothing 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?

With no output schema, the description should explain the return, and it does state the password appears in the response — the most important output fact for this tool. It is largely complete for a 3-param creation tool, though it could say more about what else the response returns.

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 login parameter is documented in exceptional depth in the schema itself (character rules, length caveat, Plesk failure mode). The description adds no parameter-level detail beyond restating that the database is pre-existing. Baseline 3 applies 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 states a specific verb+resource ('Legt einen neuen Datenbank-User an') with an added scope detail: it links the user to an existing database. This makes the outcome clear. It does not, however, explicitly distinguish itself from close siblings like create_database or delete_database_user, so it stops short of a 5.

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

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

There is an implicit prerequisite — the target database must already exist ('bestehende Datenbank') — but no explicit when-to-use/when-not or alternative routing. An agent gets no guidance on how this differs from create_database or when another tool is preferable.

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 only declare write and non-destructive; the description adds the behavior an agent actually needs: the password is randomly generated, returned once, and must be relayed to the customer because it will not be shown again. It further discloses that duplicate addresses are not pre-checked, that creation is rejected if the address exists, and that the existing mailbox is left untouched and this is not a failure.

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

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

Three sentences, action first, then credential handling, then the duplicate-address caveat, then the inventory alternative — every sentence carries information and is front-loaded. Slightly verbose with the reassurance clause ('das ist keine Störung') but still efficient.

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

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

For a mutation tool with no output schema, the description supplies the crucial output context (password is returned in the response, once) and the failure semantics (existing address causes rejection, not corruption). An agent has everything needed to call it correctly and to advise the customer.

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

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

Schema description coverage is 100%, so both parameters are fully documented in the schema, including local_part character rules and examples. The description adds no parameter-level 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?

The first sentence states a specific verb and resource ('Legt ein neues E-Mail-Postfach auf einer Domain an'), which an agent can distinguish from siblings like reset_email_password or set_email_alias without opening the schema. It also names get_email_accounts as the related read tool, sharpening 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?

It routes the agent to get_email_accounts for checking the existing inventory and explains that no pre-check happens on create, which is clear context for when this tool is the right choice. It stops short of explicitly contrasting creation with adjacent siblings such as setup_email_provider or set_email_forwarding, so it is not a full when/when-not treatment.

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?

Adds important context beyond annotations: password is server-generated, the default home directory behavior, the warning about '/' granting full hosting access, and critically that the actual directory set must be taken from the response (not assumed). This is valuable behavioral disclosure for a mutation tool with annotations covering safety.

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?

Four sentences, front-loaded with purpose, then key default/warning, ending with a critical instruction. No significant waste, though it could be slightly tighter. Every sentence adds value.

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

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

For a mutation tool with no output schema, the description covers the main behavioral aspects: password generation, directory defaults, security implications of '/', and reliance on the response for actual directory. Missing: permissions required, whether the account is immediately active, or what the response contains beyond the directory.

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 fully documents parameters including validation examples for 'home'. The description adds no new parameter syntax, but does provide context on default behavior and the '/' special case. 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?

Clear verb+resource: 'Legt einen zusätzlichen FTP-Zugang für eine Domain an' (Creates an additional FTP account for a domain). The 'zusätzlich' (additional) differentiates from other creation tools, though it doesn't explicitly name the delete sibling. Purpose is specific and distinguishable.

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

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

No explicit when-to-use or when-not-to-use guidance. The implicit context (creating an FTP account) is clear from the name and the note about default directory behavior hints at usage, but it lacks routing to alternatives like reset_ftp_password or delete_ftp_account.

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 only say readOnlyHint=false / destructiveHint=false, so the description carries the real burden and does: HTTP-Basic prompt, directory becomes unreachable without login, blocked from search engines, password is generated server-side (agent supplies none), and all values are validated server-side. These are non-obvious operational facts an agent needs before calling.

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?

Four short sentences, front-loaded with the operation and its effect, then the password-generation and validation notes. No filler, though the closing sentence partially duplicates details already in the schema.

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

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

No output schema exists, so the description must cover behavior, and it covers effect, auth model, and server-side generation well. It does not address what happens if the directory is already protected or how to undo the change, which is the main remaining 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% and the per-parameter docs already include exhaustive valid/invalid examples, so the schema does the heavy lifting. The description adds only a cross-cutting reminder that umlauts are permitted in 'title' but not in 'directory'/'username', which is useful but marginal, 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 verb and resource (protect a domain directory with HTTP-Basic auth) plus the observable effect (area unreachable, including for search engines). This is unmistakably distinct from the inverse sibling remove_protected_directory and from the other create_* tools.

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

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

The description implies when the tool is relevant and gives one process instruction ('lies die Regeln, bevor du dem Kunden Werte vorschlägst'), but it never states when to use this versus alternatives (e.g. hotlink protection or other security measures) or what prerequisites/ordering apply. Usage is implied rather than explicit.

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

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

Far exceeds the annotations (readOnlyHint=false, destructiveHint=true): it discloses that the existing certificate is replaced, the Let's Encrypt 5-per-week limit, two distinct guards with their explicit limitations, that force bypasses both, that guard failure is reported rather than silently skipped, and what the response contains. This is exactly the destructive/mutating context an agent needs.

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?

It is long, but it is front-loaded with the action and replacement semantics, and the remaining sentences carry genuine behavioral facts (rate limit, guard logic, failure reporting). Minor redundancy with the schema's parameter descriptions is the only wasted space.

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 explicitly explains the return shape ('live bestätigtes Ergebnis... oder ausdrücklich als unbestätigt'), and covers the mutation's side effects, prerequisites, and safeguards. Nothing needed to invoke it safely 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 schema already documents all five parameters including defaults and the mail DNS prerequisite. The description largely restates those defaults and the force semantics already present in the schema descriptions, adding little syntax or format detail beyond them. Baseline 3 applies 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?

First sentence states a specific verb and resource ('Stellt ein neues Let's-Encrypt-SSL-Zertifikat für eine Domain aus') and adds the critical scope note that it replaces the current certificate. This cleanly separates it from read-only siblings like get_ssl_status and fix_https_redirect.

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

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

It gives concrete operating conditions: which names are covered by default, that include_mail requires an existing mail.<domain> DNS record, and when force should be used. It does not explicitly name a sibling alternative (e.g. 'use get_ssl_status to inspect first'), 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?

Goes well beyond the annotations: it discloses that the clone runs asynchronously and only an acceptance is returned, that the staging URL is composed rather than verified (no reachability or SSL check), that the customer should be told to check back, and that the subdomain intentionally persists if the clone fails. This is exactly the extra behavioral context annotations cannot carry.

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

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

Front-loaded with the action, then the side effects and the required customer messaging. It is long, but nearly every sentence carries a distinct behavioral constraint; only slight tightening is possible.

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

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

There is no output schema, and the description fully compensates by explaining what the response does and does not mean ('angestoßen' not 'angelegt') and what to communicate to the customer. Nothing an agent needs to call and interpret this tool 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 baseline is 3, but the description adds real semantics: automatic numbering on name collision (staging, staging2, ...) and the explicit rule that site_url is needed only with multiple installs on one domain. That exceeds what the schema alone conveys.

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 ('Erstellt eine Testkopie einer WordPress-Installation auf einer neuen Subdomain') plus the mechanism (WP Toolkit). No sibling tool does the same thing, so the agent can distinguish it immediately.

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 gives the condition under which site_url is required ('Bei mehreren WordPress-Installationen auf derselben Domain'), which is genuine usage guidance. It does not name an alternative tool or a when-not-to-use case, but no close sibling exists to route 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 declare readOnlyHint=false and destructiveHint=false, so the write nature is already conveyed, but the description adds meaningful operational context: a hard cap of 5 tickets per day to prevent accidental duplicates. That rate limit is not derivable from the annotations or schema, so it earns credit.

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

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

Two compact sentences with no waste: the action is front-loaded and the rate-limit caveat follows. 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 annotations covering the mutation safety profile, a fully documented 2-parameter schema, and no output schema required, the description only needs to clarify purpose and constraints. It does so adequately, though it omits what the created ticket returns (e.g., ticket ID).

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 (subject, message) are already documented in the schema. The description adds no syntax, format, or length constraints for these fields, 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 combination ('Eröffnet ein neues Support-Ticket'), which clearly distinguishes it from siblings like close_support_ticket and reply_to_ticket by implication. It does not explicitly name those siblings, so it falls short of a 5.

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

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

The description gives no explicit guidance on when to create a ticket versus closing, replying, or listing tickets. The rate-limit note implies caution but does not tell the agent which condition selects this tool over its 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 state readOnlyHint=false and destructiveHint=false. The description adds meaningful context beyond annotations: 'Rein additiv, kein Risiko für bestehende Daten' and the site_url requirement for multiple installations. It still does not cover permissions, timing, or storage impact.

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

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

Three sentences, front-loaded with the core action, then use case, safety, and parameter condition. 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?

For a two-parameter creation tool with no output schema, the description covers purpose, safety, and the main parameter nuance well. It could be more complete by mentioning how to check backup status afterward or any prerequisite that WordPress must already exist.

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 baseline is 3. The description adds extra semantic value by clarifying that site_url is required when multiple WordPress installations exist on the same domain, including subdomains.

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: 'Erstellt ein neues On-Demand-WordPress-Backup (über WP Toolkit)'. It distinguishes itself from siblings such as get_wordpress_backups, delete_wordpress_backup, and restore_wordpress_backup by naming the create action and the on-demand nature.

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 concrete usage context: 'z. B. als Absicherung vor einem riskanten Plugin-Update'. However, it does not explicitly say when not to use it or name alternative tools for listing, restoring, or deleting 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 only provide destructiveHint=true/readOnlyHint=false; the description goes far beyond by disclosing server-side ID validation against the domain's task list, rejection of guessed/stale IDs before any deletion, non-stable IDs, irreversibility, and the real-world consequence (wp-cron stops scheduled posts, backups, newsletters). It even describes the response contract, including honest reporting of 'ungeprüft' when the list cannot be re-read.

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?

Dense but front-loaded: purpose, alternative, prerequisite, and warnings arrive in a logical order. Every sentence carries operational information, though the non-stable-ID/fresh-fetch warning is stated more than once, adding minor 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?

No output schema exists, so the description compensates by describing the return behavior (explicit confirmation the task is gone, or 'ungeprüft' on failure). For a destructive, irreversible operation with two required params, nothing essential 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 baseline is 3. The description reinforces and extends the schema by explaining that cronjob_id is validated server-side against the task list of exactly this domain, and that the agent should announce the task's command/schedule/description to the customer rather than only the number.

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 ('Löscht EINE geplante Aufgabe (Cronjob) einer Domain') and immediately names the sibling it pairs with (create_cronjob). An agent can distinguish it from create_cronjob and get_cronjobs 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?

Explicitly frames the use case (recovering from a wrongly created task), states the alternative path for modification (delete + recreate via create_cronjob), and gives a hard prerequisite: fetch get_cronjobs freshly before deleting. When-to-use and when-not-to-use are both covered.

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 only say destructiveHint=true; the description goes far beyond that, spelling out irreversibility, absence of trash/undo, the fact that support cannot recover it, the side effect on WordPress sites (posts/pages/orders/users, DB error on the site), server-side name validation against the subscription's databases, and the specific response semantics including the ungeprüft case when the list is unavailable.

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

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

Front-loaded with the verb, resource, and irreversible-loss warning; every subsequent sentence adds operative detail (prerequisites, validation, response behavior). It is long, and the emphasis-heavy capitalization is somewhat noisy, but no sentence is filler.

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

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

Given a two-parameter destructive mutation with no output schema, the description covers the safety profile, prerequisites, side effects, name validation, and even the response's success/unverified distinction. An agent has everything needed to call it responsibly.

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 baseline is 3, but the description adds that the name is validated against this subscription's database list and deleted via its identifier, so a guessed or foreign name never reaches the hosting system, and it reinforces that the name must be freshly fetched from get_databases rather than recalled. That is meaningful semantics beyond the schema strings.

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 (löscht) and resource (MySQL-Datenbank) with scope (samt Inhalt) and explicitly names the sibling that is its inverse (create_database). An agent can distinguish this from create_database, delete_database_user, and delete_dns_record 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?

Explicit preconditions: check size and WordPress usage with get_databases first, tell the customer both, and explicitly ask for an existing backup. It also names the alternatives and their limits (Papierkorb, Rückgängig, Support, create_database only returns an empty DB). That is a full when-to-use protocol, not just an implied one.

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 well past the destructiveHint annotation: explains that data is not lost but access is, that dependent apps will fail, that the password is unrecoverable and a same-named user gets a new one, and that if the user list could not be fetched nothing is deleted (which must not be misread as 'user does not exist'). It also explicitly flags the DB state as unmeasured and forbids asserting it — exactly the kind of honesty an agent needs.

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

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

Front-loads the action and its inverse before the edge cases, and every paragraph carries real content (preconditions, irreversibility, failure semantics, unverified claims). It is nonetheless long for a two-parameter tool, with some emphatic repetition ('Sage es genau so, statt es zu behaupten') that could be tightened.

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 no output schema, the description covers preconditions, irreversibility, side effects on dependent applications, failure semantics, and the limits of what is verified. Nothing needed to invoke or interpret 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 both parameters are already documented, including the 'don't guess the login' warning in the schema itself. The description echoes that warning and adds the consequence that a guessed/foreign identifier never reaches the hosting system, but adds little beyond the schema 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+resource ('Löscht einen Datenbank-Benutzer') and immediately positions it against its inverse sibling create_database_user. It further distinguishes itself from delete_database by clarifying that it deletes ACCESS, not the database itself, so an agent can route among the delete_* siblings without opening schemas.

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

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

Gives clear operational preconditions: ask the customer whether anything still uses the user, and check wp-config.php in WordPress. It names create_database_user as the reverse operation. It stops short of an explicit when-to-use/when-not routing rule (e.g. delete_database vs this), but the context 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 declare destructiveHint=true, but the description adds substantially more: server-side validation of the record_id against the domain's zone before any deletion occurs, rejection of guessed/stale IDs, no undo via this tool, and the real-world impact of a missing SPF/DKIM/MX record. It also discloses response semantics (explicit confirmation of removal, or 'ungeprüft' when the zone can't be read).

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

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

Front-loaded with the core action and the record_id provenance constraint, then layered with recovery and impact warnings. It is dense and somewhat repetitive against the schema's own record_id description, but every sentence carries operational value rather than 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 no output schema, the description covers prerequisites, safety consequences, irreversibility, the alternative tool, and how to interpret the response. Nothing an agent needs to call it safely 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 baseline is 3, but the description adds a constraint the schema does not: the ID is validated server-side against the zone of exactly this domain, and rejection happens before deletion. It does partially duplicate the schema's warning about guessed/stale IDs, keeping it below 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 ('Löscht EINEN DNS-Eintrag einer Domain') and immediately frames itself as the inverse of add_dns_record with concrete examples (DKIM, SPF, DMARC). An agent can distinguish it from siblings like delete_cronjob or delete_database 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 precondition (record_id must come from get_dns_records), warns that IDs are not stable and must be re-fetched before deleting, and names add_dns_record as the only path to recreate a deleted value. When-not-to-trust-stale-data and the customer-confirmation step are both 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 only declare readOnlyHint=false and destructiveHint=true; the description goes well beyond by disclosing server-side validation of the login against the domain's own list, that a guessed login is rejected before anything is deleted, that deletion is permanent rather than a suspension, that the old password never revives, and that the response explicitly distinguishes 'removed' from 'unverified' and treats a pre-existing list outage as a no-op.

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?

Long but densely packed and front-loaded: the destructive scope appears in the first clause, then validation, exclusions, permanence, and response semantics follow. Every sentence carries non-obvious information, though the warning about the start directory and main-account explanation could be trimmed slightly.

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, it covers everything an agent needs: prerequisites (login from get_ftp_accounts), refusal cases (main account, foreign/guessed login), irreversibility, and how the response reports success versus an unverifiable outcome. Nothing material is missing.

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

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

Schema description coverage is 100%, so the baseline is 3; the description nonetheless adds semantics the schema lacks — the login must originate from get_ftp_accounts and must not be the main account, and it explains why the start directory matters when confirming with the customer. This meaningfully complements the schema.

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

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

States a precise verb and resource with scope qualifier ('Löscht EINEN zusätzlichen FTP-Zugang einer Domain'), immediately distinguishing it from create_ftp_account, reset_ftp_password and the read-only get_ftp_accounts. An agent can identify the operation and its target 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?

Explicitly frames itself as the inverse of create_ftp_account with a concrete scenario (Dienstleister no longer needed), names get_ftp_accounts as the required source of the login, and states the hard exclusion (main_account cannot be deleted here, with the reason). When/when-not/alternative are all present.

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 destructiveHint=true, and the description goes well beyond them: it warns the deletion is irreversible, discloses server-side filename validation, and details the post-delete verification behaviour (list is re-read; an unverifiable result is reported as 'ungeprüft' rather than success). This is unusually rich behavioural disclosure for a mutation tool.

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

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

Purpose is front-loaded and each sentence carries weight (prerequisite, irreversibility, verification semantics, client-communication instruction). It runs longer than typical, but the extra sentences encode genuinely non-obvious behaviour rather than 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 tool with no output schema, the description supplies exactly what an agent needs: irreversibility, filename provenance, and how to interpret the (self-described) response including the unverified case. Nothing essential is missing.

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

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

Schema description coverage is 100%, so the schema already documents domain, filename and site_url, and the description's filename guidance largely mirrors the schema text. Baseline 3 applies — the description adds intent but no new syntax or format 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?

States a specific verb (Löscht) and a precisely scoped resource ('ein einzelnes On-Demand-Backup einer WordPress-Installation'), with the added motive (Platz im Backup-Kontingent). An agent can distinguish it from create_wordpress_backup, restore_wordpress_backup, and get_wordpress_backups without opening any schema.

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

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

Gives a clear prerequisite — the filename must originate from get_wordpress_backups, and invented names are rejected server-side — plus the intent (free quota). It stops short of explicitly naming the alternative tools (restore vs. delete) or stating when not to delete, so it is strong context rather than 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?

With annotations only declaring readOnlyHint=false and destructiveHint=false, the description carries the real burden and does so richly: it defines expected input (finished static HTML/CSS/JS, relative paths, index.html), forbids build steps and framework source, prescribes form markup conventions, and warns against hotlinking and base64 binary payloads.

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

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

Front-loaded with purpose, then the numbered workflow, then constraints – a sensible order. It is dense and long for a single-parameter tool, with some convention detail (form fields, image import) that borders on sibling-tool territory, but nearly every sentence carries operational value.

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

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

No output schema exists, yet the description states it returns the deploy_id, and it supplies prerequisites, sequencing, formatting rules and a user-facing help link. An agent has everything needed to call it and to drive the surrounding workflow 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% for the single domain parameter, so the schema already documents it. The description adds the meaningful constraint that the domain must be on the turbopress AI Launch plan, which is not in the schema and materially affects valid usage.

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 (starts a new website deploy) and resource (domain under the turbopress AI Launch plan), and explicitly notes it returns the deploy_id. It is unmistakably distinguished from siblings deploy_put_file, deploy_preview and deploy_publish, which it names directly.

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

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

Provides an explicit ordered workflow: 1) deploy_begin, 2) deploy_put_file for EVERY file, 3) deploy_preview plus showing the preview link and warnings, 4) deploy_publish only after explicit user confirmation. This tells the agent not just when to call this tool but how it sequences with 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 the safety profile (readOnly=false, openWorld=true, destructive=false), and the description adds substantial context beyond them: the repo must contain finished static HTML with no build step, private-repo tokens must never be requested in chat, and auto_publish bypasses approval so it needs explicit consent. This is exactly the behavioral detail the structured fields 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?

The core concept and the four actions are front-loaded before the operational caveats. It is a long paragraph, but for a four-action tool with safety constraints most sentences earn their place; some of the parameter restatement is redundant with the schema.

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

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

With no output schema, the description carries the burden and does so: it explains what 'get' returns (settings plus webhook URL, secret, and last-run result), the full lifecycle of the other actions, and the hand-off to deploy_publish. For a 7-parameter, four-action tool this is complete enough to invoke correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds value beyond the schema by giving concrete formats and defaults: repo as 'besitzer/name', subdir example 'dist' (empty = repo root), branch default 'main', and the semantics of auto_publish. It does not fully re-explain every parameter, which is fine since the schema handles them.

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

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

The description states a specific verb+resource ('Git-Anbindung einer Website verwalten') and enumerates the four actions (get/set/run/remove) with what each does. It explicitly positions itself relative to siblings deploy_preview and deploy_publish, so an agent can distinguish 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?

It gives explicit when-to-use per action, names the alternative workflow (deploy_preview then deploy_publish with the deploy_id), and states a hard condition for auto_publish=true ('nur ... wenn der Nutzer das ausdrücklich so will'). Post-set follow-up (webhook_help, handing over URL and secret) is also prescribed.

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 openWorldHint=true and destructiveHint=false, so the description focuses on operational traits: a 10 MB size cap, the https-public requirement, the file-type/extension match, and a license caveat. It does not say what happens to an existing file at the same path or whether the fetch can fail/timeout, which are the remaining gaps for a server-side network fetch.

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

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

Front-loaded with purpose and the sibling it replaces, then constraints, then the post-step ('reference "/<path>" in HTML'). Dense but nearly every sentence earns its place; the license and unsplash notes are useful if slightly aside from the core instruction.

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

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

For a 4-parameter mutation tool with no output schema, the description covers purpose, alternatives, input constraints, and the required follow-up action. 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?

Schema coverage is already 100%, so the baseline is 3, but the description adds real constraint detail beyond the schema: url must be public https, path must match the file extension (JPEG→.jpg, WebP→.webp, PNG→.png), and the 10 MB size limit. This meaningfully sharpens how the two key params should be filled.

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: the server fetches a file from the web and places it into an open deploy. It explicitly distinguishes itself from deploy_put_file (Base64 upload) and from hotlinking, so an agent can tell it apart from its closest siblings 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 explicit when-to-use (importing images, fonts, PDFs for the website), names the alternatives it replaces (deploy_put_file, hotlinking) and states the rule 'always use this tool' for that case. It also carves out an exclusion: unsplash/pexels images are handled automatically by deploy_publish.

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 the safe read profile (readOnlyHint=true, destructiveHint=false). The description adds genuinely useful behavioral context beyond that: the plan constraint (turbopress AI Launch) and a retention policy (last 10 published releases kept, unpublished deploys purged after 24 hours). It does not describe pagination or output format, keeping it from a 5.

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

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

Front-loaded with purpose and returned fields, followed by the integration point and retention rules. Every sentence earns its place with no filler, though the density of constraints makes it slightly heavier than necessary for a one-parameter 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?

There is no output schema, so the description carries the return burden and does so well: it names the fields returned (timestamp, status, live release) and the deploy_id. Combined with the retention policy and the rollback linkage, an agent has everything needed to call and interpret this tool.

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

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

Schema description coverage is 100% with a single required 'domain' parameter, so the schema already documents the parameter fully. The description reinforces the domain scope and plan tier but adds no syntax or format details beyond the schema. Baseline 3 applies 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 (listet) and resource (Releases/Deploys einer Website) and enumerates the returned fields (Zeitpunkt, Status, live status). It also differentiates itself among the deploy_* siblings by naming its consumer: 'Liefert die deploy_id, die deploy_rollback braucht.'

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 context for use — retrieve the deploy_id required by deploy_rollback — which tells the agent when this tool is the right call. It stops short of explicit exclusions or naming alternative listing tools, so it is not a full 5.

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

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

Annotations only declare readOnlyHint=false and destructiveHint=false, so the description usefully adds that the live site stays unchanged, the preview is a non-public random URL, BLOCKING aborts the preview, and the automated check inlines Google Fonts/CDN/stock photos and wires forms. However, the description frames this as a read-ish check while readOnlyHint=false, and the side-effect of actually hosing files at a new URL is only implied, leaving a minor tension rather than a clear 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?

Front-loads the purpose before the process guidance, and every sentence carries operational value (preview URL, warning categories, BLOCKING branch). It is dense and multi-sentence but not 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?

No output schema, yet the description compensates by describing what the report contains (Impressum/Datenschutz, fields without name, external services) and how BLOCKING should be handled. An agent has everything needed to call it and act on the result.

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 (domain, deploy_id) are documented in the schema, including the deploy_id origin from deploy_begin. The description 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 (prüft + stellt bereit) and resource (einen offenen Deploy) with a concrete outcome (preview URL) and explicitly contrasts with the live site and with deploy_publish. An agent can distinguish it from deploy_begin/deploy_publish without opening any schema.

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

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

Gives explicit ordering (after uploading all files, ALWAYS call deploy_preview first), the follow-up actions (show link, name warnings, offer fixes), and the condition that gates the alternative (deploy_publish only after explicit user approval). Also handles the BLOCKING branch with clear remediation steps.

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/destructive profile, but the description adds substantial behavior beyond them: immediate replacement of the live site, automatic form rebinding and spam protection, the BLOCKING/WARNINGS report semantics, and the rollback guarantee. It also warns that a blocked run publishes nothing, which is critical for correct agent 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?

Front-loads the core action and the mandatory user-confirmation gate before operational detail, and every sentence covers a distinct need (confirmation, auto-checks, error recovery, warnings, rollback). It is longer than a simple tool warrants, but for a destructive publish operation the length is justified rather than 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?

Covers the full lifecycle an agent needs: precondition, what happens during the automatic check, interpretation of BLOCKING versus WARNINGS, the recovery flow, and reversibility via deploy_rollback. With no output schema, the description still explains the response report adequately.

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, so the schema already documents domain and deploy_id, including the deploy_begin origin. The description adds no format, constraints, or meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

States a specific verb and resource ('schaltet ihn live', 'ersetzt die aktuelle Website sofort') and clearly distinguishes itself from siblings like deploy_preview and deploy_rollback. An agent can tell exactly what this tool does without opening the schema.

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

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

Gives an explicit precondition ('NUR aufrufen, nachdem der Nutzer ... ausdrücklich bestätigt hat'), explicit exclusions ('nie automatisch nach dem Hochladen und nie ohne Rückfrage'), and a recovery path naming deploy_put_file and a renewed confirmation. This is about as complete as usage guidance gets.

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 well beyond the annotations: it warns that re-uploading overwrites the file, that it publishes nothing, and lays out path rules (charset, no umlauts/spaces, hidden-file exception for .well-known/, no _tp/), allowed file types, encoding mapping, and a 1 MB per-call limit. This is the behavioral context an agent needs for a mutating staging write.

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

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

Front-loaded with purpose and sibling routing, then constraints. It is long, but essentially every clause carries a hard rule (charset, extensions, size, encoding) with no filler; a slightly tighter phrasing of the path examples could trim 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 5-param staging upload tool with no output schema, the description covers purpose, alternatives, mutation semantics, validation constraints, and the fact that it does not publish. 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?

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: concrete path syntax and examples, allowed character set, and the utf8/base64 encoding-to-content mapping with a size cap. It enriches the enum and content parameters rather than just restating them.

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?

Opens with a specific verb+resource+scope: loads a file into an open deploy (created by deploy_begin). It explicitly distinguishes itself from siblings by naming deploy_import_asset for web images and deploy_publish for publication.

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?

States one call per file, routes web images to deploy_import_asset ('nicht hotlinken'), forbids large binaries as Base64, and clarifies that publishing is deploy_publish's job after user confirmation. When-to-use and when-to-use-alternatives are both explicit.

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

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

Annotations only declare readOnly=false and destructive=true. The description adds that the swap is atomic, causes no downtime, and that the currently live version is replaced but preserved. These are meaningful behavioral details beyond what annotations provide.

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

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

Three sentences, front-loaded with the action and key behavior, then the parameter source, then the user-confirmation requirement. No fluff, though the final clause slightly mixes confirmation and preservation.

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 rollback tool with no output schema, the description covers purpose, key behavior, and usage prerequisites. The only gap is the conflicting deploy_id source, which is a significant inconsistency.

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 schema already defines both parameters. The description adds that deploy_id comes from deploy_list, but the schema says it comes from deploy_begin, creating a contradiction that could mislead the agent about where to obtain the required ID.

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

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

The description states a specific action ('Schaltet eine früher veröffentlichte Version ... wieder live') with the resource (Website) and adds atomic-swap/no-downtime scope. It references deploy_list for the deploy_id, but it does not explicitly distinguish itself from sibling tools like restore_wordpress_backup or deploy_publish.

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 clear prerequisite: before rolling back, clarify with the user which version is meant and obtain confirmation. However, it does not state when not to use this tool or name alternative tools for comparison.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds substantial context beyond them: the log is read at query time, only hits from the last 48 hours are reported, a no-hit result means 'nothing in this window' not 'never an error', older hits appear in the footer, and an unreadable log is explicitly flagged. These are exactly the operational caveats an agent needs.

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

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

Front-loaded with the core aggregation purpose in the first sentence, followed by the ideal use case. Subsequent sentences about the 48h window and unreadable-log behavior earn their place, though the passage is dense and could be slightly tightened.

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 describing what the response contains (a prioritized main diagnosis, footer with older errors, explicit unreadable-log notice). Combined with the rich behavioral caveats, an agent has enough to call and interpret the tool correctly.

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

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

One parameter (domain) with 100% schema coverage and an example ('example.com'), so the schema already carries the semantics. The description adds no format or syntax detail beyond what the schema provides, making the baseline 3 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 function: aggregating all relevant domain signals (live HTTP/SSL/storage/databases/PHP fatals + report-based security/DNS/CloudLinux/WordPress) into ONE prioritized main diagnosis. It explicitly contrasts with the pattern of calling many individual tools, so an agent can distinguish it from siblings like get_website_report or get_security_status 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 a concrete use case ('meine Seite ist kaputt/langsam, was ist los?') and explicitly says to use this instead of calling multiple tools individually. It also names the alternative (search_domain_error_log) for cases outside its scope (other message types or a custom search pattern).

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?

Adds rich behavioral detail beyond the annotations: reversibility, single-setting scope, real TLS handshake validation before enabling with specific rejection reasons, deliberate force bypass, no validation on disable, and read-back from Plesk with fallback messaging if read-back fails. This is exactly the kind of context annotations cannot carry.

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?

Although lengthy, the description is front-loaded with the core operation and every sentence carries unique operational detail (TLS validation, rejection cases, force bypass, read-back behavior). No filler, and the complexity justifies the size.

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

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

Given the mutation nature, lack of an output schema, and multi-step validation logic, the description covers all essential aspects: prerequisites, failure modes, bypass option, and response behavior. An agent has everything needed to invoke and interpret the result 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 all three parameters (domain, enabled, force) are already documented in the schema. The description adds some nuance about force bypassing the TLS check, but it largely reiterates what the schema provides, so the baseline 3 for high 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?

States a specific verb (enable/disable) and resource (automatic HTTP→HTTPS redirect for a domain), and names the finding it resolves. It references diagnose_website/get_website_report as the source of the finding and create_ssl_certificate as a prerequisite, clearly distinguishing itself from generic redirect siblings like redirect_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?

Explicitly states when to use (to fix a reported 'no HTTPS redirect' finding), prerequisites (a valid TLS certificate, otherwise use create_ssl_certificate first), rejection conditions for missing/expired/foreign certificates and failed handshakes, the force=true bypass, and that disabling requires no check. Alternatives and when-not conditions are clearly covered.

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 cover the read-only/safe profile, but the description adds substantial context beyond them: the value is server-wide and identical across domains, a non-parsable value is reported as a measurement failure (not as 'no backup exists'), and the data originates from a once-daily turbocheck report with a timestamp in the response.

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

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

Purpose and the key caveat (server-wide, not domain-specific) are front-loaded, and each sentence carries distinct information. It is somewhat dense and emphatic (capitalized KEINE/NICHT), but nothing is genuinely 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?

With no output schema, the description covers the return fields, the failure/missing-value semantics, and the data freshness source. An agent needs nothing more to call and correctly interpret this tool.

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

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

With 100% schema coverage the baseline is 3, but the description adds real meaning to the domain parameter by clarifying that the returned value is server-wide and therefore identical for every domain pointing at the same server, so the agent knows the parameter does not scope the result.

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 (abrufen) and resource (Stand der nächtlichen Gesamtsicherung des Servers), including the concrete returned fields (Datum, Status, Alter). It explicitly marks itself as NOT a per-domain backup, which separates it from the WordPress backup siblings.

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

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

Explicitly names the alternatives get_wordpress_backups and create_wordpress_backup and the selecting condition: single-site backup or restore goes there, not here. This is a clear when-to-use/when-not-to-use split rather than inferred 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 only declare the safe-read profile, but the description adds a genuinely important behavioral trait beyond them: the data is refreshed once daily, counters reflect the last polling period rather than the query moment, and a recent throttling may not surface until the next run. That freshness caveat materially changes how an agent should interpret and report results.

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 the capability front-loaded and the caveat second, and the parenthetical metric list earns its space. It is slightly dense but 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?

With no output schema, the description does some of the return-value work by naming the limit dimensions and overages, and it fully covers data freshness. It does not describe the response structure or whether limits and current usage are returned separately, which is the main remaining gap for a tool with no output schema.

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

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

Schema description coverage is 100% with a single well-described domain parameter, so the schema already carries the parameter burden. The description implies the domain scoping ("einer Domain") but adds no format or validation detail beyond the schema's "z. B. example.com".

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 ("abrufen") and resource (CloudLinux/LVE-Ressourcenlimits) scoped to a single domain, and enumerates the metric families returned (CPU, Speicher, Prozesse, I/O). An agent can distinguish this from siblings like get_performance_alerts or get_webspace_usage 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 explains the data's provenance and staleness (daily turbocheck report, counters from the last collection period), which implicitly tells the agent when the result is trustworthy. However, it never names an alternative tool or states a when-not-to-use condition, so selection guidance remains inferred.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, yet the description adds non-obvious traits: identifiers are not stable and can be recycled by newly created jobs, tasks may be present but disabled, and failures are reported explicitly rather than as an empty list. This is genuinely supplemental context beyond 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?

Purpose is front-loaded in the first clause, followed by distinct operational warnings with no filler. Every sentence contributes a separate, actionable fact (ID instability, disabled state, failure semantics).

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 carries the return-shape burden — and it does: rows begin with the identifier, disabled status appears inline, and unavailable lists are self-declaring. Combined with the mutation-safety warning tied to delete_cronjob, the agent has everything needed to call and interpret this tool correctly.

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

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

Schema coverage is 100% with a single well-documented `domain` parameter, so the schema carries parameter semantics. The description adds meaning about the output shape (row-leading Kennung = cronjob_id) but nothing about the input parameter format itself, 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 verb and resource ("Zeigt die geplanten Aufgaben (Cronjobs) einer Domain") and anchors it to the Plesk concept "Geplante Aufgaben". It also distinguishes itself from create_cronjob/delete_cronjob by naming delete_cronjob's expected cronjob_id, making the read-vs-write 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 concrete when-to-use rules: re-fetch immediately before deleting, never reuse an ID from an earlier response, and forward disabled-task state verbatim. It also handles the negative case (list unavailable → do not claim there are no cronjobs).

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 cover the safety profile (readOnlyHint=true, destructiveHint=false). The description adds genuinely non-obvious behavioral context: names are live but size figures come from the last turbocheck report and are absent for newly created databases, which tells an agent to distrust missing sizes rather than treat them as an error.

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 with zero waste; the data-source caveat is attached directly to the operation description rather than 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?

With no output schema, the description usefully explains what comes back (names vs. sizes) and the staleness caveat for sizes. It stops just short of describing structure or ordering, but covers the key pitfall an agent would otherwise trip on.

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 the single 'domain' parameter, so the schema carries the parameter semantics. The description adds no format or syntax detail beyond the schema, making the baseline 3 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: retrieves the list of databases for a domain, live from Plesk. It clarifies the relationship to create_database and is easily distinguished from siblings like get_domains or create_database.

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

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

Usage is implied rather than stated – the mention that names are current 'even directly after create_database' signals a use case, but no alternatives are named and there is no explicit when/when-not guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds real behavioral value beyond that: data is fetched live from Plesk, each row is prefixed with the identifier, and IDs are reassigned on create/delete, which affects correct usage.

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

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

Three sentences, all front-loaded and purposeful: purpose, output shape, then the instability caveat that drives correct timing. 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 read-only list tool with no output schema, the description discloses the key structural fact (rows are prefixed with the record identifier) and a critical timing constraint. It stops short of describing all returned fields or pagination, but covers what an agent needs to pair this with the delete 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 the single 'domain' parameter, so the schema already documents it (with an example format). The description adds no additional parameter syntax or constraints, so this lands at the baseline for high-coverage schemas.

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 (abrufen) and resource (DNS-Zone-Records einer Domain) and scopes it as a live read from Plesk. It also positions itself relative to the sibling delete_dns_record by explaining which value feeds that tool's record_id, so an agent can distinguish it from get_dns_security or add_dns_record.

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

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

Gives a clear operational rule: fetch fresh immediately before deleting because identifiers are not stable. That is strong context-specific guidance, though it doesn't explicitly enumerate when to prefer this over other DNS-related 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 mark it as read-only and non-destructive, but the description adds important behavioral context: the data is sourced from a once-daily turbocheck report, the response includes a timestamp, and recent record changes may be delayed. This goes well beyond the structured 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 front-loaded with the tool's purpose, then adds the freshness caveat and the alternative in a compact way. Every sentence earns its place and nothing is wasted.

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

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

Given the simple one-parameter schema, read-only annotations, and no output schema, the description provides everything needed: what is retrieved, when cached data may lag, and which sibling to use for live results. No critical invocation detail is missing.

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

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

Schema description coverage is 100%, and the single domain parameter is already documented in the schema. The description implies the domain input but adds no syntax or format detail beyond what the schema provides, 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?

The description gives a specific verb and resource: retrieve a domain's DNS mail security settings, explicitly listing SPF, DKIM, DMARC and MX. It also distinguishes the tool from the sibling get_dns_records by naming that alternative for live data.

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

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

It clearly explains when to use this tool: for data from the daily turbocheck report, with the caveat that newly set records may not appear until the next run. It names the explicit alternative get_dns_records for immediately reliable live DNS data.

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 only the safety profile (readOnly, non-destructive), yet the description adds substantial behavior: email running over the redirecting domain is lost on removal by default, an empty list is a valid answer while an unfetchable list is an explicit outage that must never be read as 'no redirects', and staging copies appear but are not removable by remove_domain_redirect.

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?

Dense and front-loaded with the core purpose before the caveats, and every sentence carries operational value (direction, email loss, empty-vs-outage, staging). It is long, but the length is justified by the number of distinct edge cases rather than 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 single-parameter read tool with annotations already covering safety and no output schema, the description covers the intended answer shape, the empty-result semantics, failure semantics, and the staging ambiguity plus the caution not to guess. Nothing an agent needs to call and interpret 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 baseline is 3, but the description meaningfully reinforces the counterintuitive direction of the single argument with a concrete 'alte-domain.de leitet auf neue-domain.de' scenario, reducing the risk of passing the wrong domain.

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: lists the domain redirects pointing to a given domain, with ID and attached data. It explicitly positions itself against siblings, naming redirect_domain as the writing counterpart and remove_domain_redirect as the follow-up, so an agent can distinguish it without opening schemas.

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

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

Explicitly says when to use it (read counterpart to redirect_domain, prerequisite for remove_domain_redirect) and which domain to pass, including a worked example clarifying that the argument is the TARGET of the redirect, not the source. This is exactly the kind of when/when-not routing an agent needs.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered; the description goes further by explaining anomalies in the returned data (missing expiry = registered elsewhere, trial subdomains never registered) and that all other tools may edit hosted domains regardless of registrar. It stops short of stating rate limits or result shape, but the added interpretive context is substantial.

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

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

The core purpose is front-loaded in the first clause, and most sentences carry actionable meaning (registrar vs. host, trial subdomains, WordPress-vs-AI-Launch routing). It is a dense single paragraph in German with slightly overlapping clauses, so it is efficient but not maximally tight.

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

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

With no output schema and no parameters, the description must itself explain what comes back, and it does: registrar status, expiry/auto-renew, hosting tariff, and WordPress presence per domain, plus how to interpret edge cases. An agent can call it and interpret the result correctly without further context.

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

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

The tool takes zero parameters, so the schema cannot carry parameter meaning and there is nothing to describe; the baseline of 4 applies. No parameter-related confusion is possible.

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

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

The description opens with a specific verb+resource ('Den vollständigen Domainbestand des Kunden abrufen') and immediately scopes it into the two categories it covers (turbopress-registered vs. hosted-but-registered-elsewhere). It also enumerates the per-domain attributes returned (Ablaufdatum, Registrar-Status, Auto-Renew, Tarifart, WordPress-Stand), so an agent distinguishes this from get_wordpress_sites or get_dns_records 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 routes the agent downstream explicitly: WordPress tools only for domains with WordPress, and for AI Launch (static, no PHP) domains use the deploy_* tools. It also pre-empts a misread of the result ('a domain without expiry date is not an error'). What is missing is explicit guidance on when to call get_domains versus e.g. get_wordpress_sites or get_hosting_packages as the starting point.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered, but the description adds real operational context: data is live from Plesk, an absent forwarding is an affirmative 'none configured' answer rather than missing data, and forwarding targets are emitted verbatim even for foreign domains. It doesn't discuss pagination or freshness/rate limits, 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?

Front-loads the verb and returned fields, then layers semantic caveats. Mildly verbose — the aside about what chat previously couldn't show is historical justification rather than actionable instruction — but each sentence still carries usable meaning.

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 and does so by listing the exact fields returned plus how empty forwarding/alias values should be interpreted. Nothing essential for correct invocation is missing for a one-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?

Single required 'domain' parameter with 100% schema description coverage ('Die Domain, z. B. example.com'), so the schema already carries the meaning. The description adds no format or scoping detail beyond what the schema states, which is 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 verb and resource ('E-Mail-Konten einer Domain auflisten') and enumerates the returned fields (Adresse, Speicherkontingent, Weiterleitung, Aliase). It explicitly positions itself against siblings set_email_forwarding and set_email_alias as their read counterpart, so an agent can distinguish 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?

Names the write siblings it complements and describes the gap it closes ('wohin die Post eines Postfachs geht'). This gives clear context for when to reach for it, though it stops short of explicit when-not-to-use conditions or comparison with other read tools like get_email_status.

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 only declare the safe-read profile; the description adds substantial behavioral context: data is from a once-daily turbocheck report with a timestamp, events since the last run are absent, incoming mail is excluded, and an unreadable log yields an explicit message rather than a misleading zero. It also separates stuck-queue mails from these figures.

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

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

Purpose is front-loaded in the first clause, followed by tightly packed caveats that each add non-obvious information. It is dense and slightly long, but no sentence is 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?

There is no output schema, yet the description explains what is returned (counts by category plus a timestamp) and the critical edge cases around missing data. For a single-parameter read tool this is 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 coverage is 100% for the single 'domain' parameter, so the schema already carries the parameter meaning. The description adds domain scoping semantics (counts only outgoing mail of that domain), which is useful but not a substitute for additional syntax detail. 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 verb and resource (retrieving a domain's email sending status) and enumerates the exact categories reported (gesendet/gebounced/verzögert heute). No sibling tool covers this resource, so the agent can identify it immediately.

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 through the scope constraints (outgoing mail only, daily report, current day), which tells the agent when the numbers are meaningful, but no alternative tool or when-not-to-call condition is named. Adequate but leaves routing 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?

Beyond readOnlyHint/destructiveHint, the description discloses that data is read live from Plesk, that the main account's password is the SSH password and cannot be reset via chat (must be changed in Plesk), and that zero additional accounts is a normal state. These are exactly the operational caveats annotations cannot express.

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

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

Front-loaded with the core action, then layered caveats; every clause carries information an agent needs (password reset limitation, normal-state clarification). The long parenthetical makes it dense but not 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?

With no output schema, the description compensates by describing what is returned (main login plus additional accounts with start directory) and by pre-empting the most likely misinterpretation of an empty result. Nothing needed to call or interpret this tool 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?

There is a single parameter ('domain') and schema description coverage is 100%, so the schema already carries the semantics. The description adds no syntax, format or scope detail about the domain parameter. 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 ('FTP-Zugänge einer Domain auflisten') and immediately splits the result into two distinct classes: the subscription's main account and the additionally created accounts with start directory. This lets an agent distinguish it from create_ftp_account, delete_ftp_account and reset_ftp_password 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?

Explicitly routes the agent: the additional accounts supply the login that reset_ftp_password requires, and it warns that customers rarely know their FTP username. It also defuses a false error signal ('no additional accounts is normal'). It stops short of naming the sibling tools it is not (create/delete), so it is strong context rather than a full when/when-not matrix.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds valuable context beyond annotations: it specifies that the catalog is public and independent of the user's own contract, and it describes the return fields ('mit Preis und Kurzbeschreibung'). This helps the agent understand both access scope and output content.

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

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

The description is a single, efficient sentence that front-loads the action and resource, then adds a crucial scope clarification in parentheses. Every element earns its place with no redundancy.

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

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

Given the tool's simplicity (no parameters, no output schema, annotations covering safety), the description is complete: it explains what is listed, the fields returned, and the public/contract-independent nature. No additional behavioral details are necessary 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?

The tool has zero parameters, so the description does not need to explain parameter semantics. The baseline of 4 applies because there are no parameters to document and the schema is empty.

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 ('Listet') and resource ('Hosting-Pakete'), and adds a scope qualifier ('öffentlicher Produktkatalog, unabhängig vom eigenen Vertrag') that clearly distinguishes it from sibling tools that retrieve the user's own resources. An agent can immediately tell this tool is for browsing available packages, not managing owned services.

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

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

The parenthetical note 'öffentlicher Produktkatalog, unabhängig vom eigenen Vertrag' provides clear context for when to use this tool: to see available offerings rather than the user's contract-specific data. However, it does not name any alternative tool (e.g., prepare_hosting_order) or explicitly 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 only cover the safety profile (readOnly/destructive), so the description adds substantial new behavior: live read from the hosting system, server-side domain validation against this customer's contracts, handling of a duplicated/contradictory upstream response, and the critical distinction between an empty list and a field that was never read. These are non-obvious traits an agent cannot derive from 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?

Front-loaded with purpose and the set/verify relationship, and the two downstream caveats are clearly numbered. It is longer than typical and the parenthetical asides add bulk, but every sentence carries operational content rather than 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?

There is no output schema, so the description must describe returns — and it does: state, protected extensions, permitted foreign domains, plus explicit guidance on how to report contradictory or unread values. Given the single required parameter and absent output schema, an agent has everything needed to call and interpret this correctly.

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

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

Schema coverage is 100% and the schema itself is thin (just an example format), so the baseline would be 3. The description adds real semantics beyond it: the domain must belong to this customer and a foreign domain is rejected before anything is read. It does not, however, discuss case handling, subdomain vs apex matching, or validation-error behavior.

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

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

States a precise verb+resource ('Liest den Hotlink-Schutz EINER Domain') and enumerates exactly what is read: on/off state, protected file extensions, and allowed foreign domains. It explicitly positions itself against the sibling set_hotlink_protection as its read counterpart.

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

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

Gives explicit when-to-use ('Vor jedem Setzen sinnvoll') with the concrete reason that a set list REPLACES the existing one, and names the alternative read route ('der einzige Weg, eine Änderung daran nachzuprüfen'). Nothing about selection 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?

Die Annotations decken nur readOnly/destructive ab. Die Beschreibung liefert entscheidende zusätzliche Informationen: die Liste ist bewusst gefiltert (alle offenen + 25 neueste abgeschlossene), was fehlt, und dass die Gesamtzahlen den vollen Bestand abbilden. Das ist essentiell für korrekte Antworten.

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?

Der Text ist recht lang, aber jeder Satz trägt wichtige Informationen (Filter, Gesamtzahlen, ID-Hinweis, Entwurfserklärung). Die Front-loading ist gegeben, aber die Länge könnte für manche Agenten abschreckend wirken.

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?

Das Tool hat keine Parameter und kein Output-Schema; die Beschreibung erklärt vollständig, was zurückgegeben wird (Liste plus Gesamtzahlen) und wie diese zu interpretieren sind. Es fehlt nichts Wesentliches.

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?

Es gibt keine Parameter, daher Baseline 4. Die Beschreibung definiert dennoch die Semantik der Rückgabewerte (Summen, Zählungen), was für ein parameterloses Tool wertvoll ist.

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?

Der erste Satz nennt klar Verb (abrufen) und Ressource (Rechnungen des Kunden). Der Rest grenzt den Umfang präzise ab und unterscheidet das Tool so von allen anderen get_*-Tools.

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

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

Es wird explizit gesagt, wann welche Zahlen zu verwenden sind ('Fragen nach Gesamtbeträgen ... ausschließlich aus diesen Summen beantworten und niemals die aufgelisteten Zeilen aufaddieren'). Das ist eine seltene, sehr hilfreiche Anweisung für die korrekte Nutzung.

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 a safe read (readOnlyHint=true, destructiveHint=false), and the description adds substantial context: it reads directly from the installation so results are correct even right after an update, and it warns that the slug field can be null and, when null, the entry is unusable for update_wordpress_item/set_wordpress_plugin_state. This materially exceeds what the annotations 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?

Purpose and differentiator are front-loaded, then the slug caveat. The paragraph is dense but each sentence carries distinct, actionable information; only slightly long.

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 carries the return-shape burden and does so precisely (display name plus slug in parentheses, slug may be null). Combined with the upstream accuracy note and downstream tool dependency, an agent has everything needed to call and use the result 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?

Single parameter ('domain') is fully documented in the schema (100% coverage), so the description need not explain it. The description adds no syntax or format detail beyond the schema's own 'z. B. example.de' example, 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?

Names a specific verb+resource ('Listet WordPress-Plugins und -Themes mit verfügbarem Update') and distinguishes itself from the sibling get_wordpress_status by noting it is more precise than that tool's counter. An agent can separate it from the update/state tools immediately.

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 contrasts with the alternative get_wordpress_status ('Genauer als der reine Zähler...') and gives the selecting condition: use this when you need to know which specific plugins/themes are affected. It also routes the agent forward by stating which tools consume the output and that they require the slug.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered structurally. The description adds genuine behavioral context beyond that: an empty result is not a blanket all-clear and the response distinguishes 'monitored/nothing open', 'domain not monitored at all', and 'not determinable'. It does not describe alert object structure or freshness/staleness of the events, so it stops short of 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?

Front-loaded with the question it answers, then scope, then alternatives, then the empty-list caveat — a logical order with no filler. It is somewhat dense and the final sentence about the three empty-list states is long, though it earns its place.

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

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

With no output schema, the description does the important work of explaining what an empty list means and that three distinct states can be returned. It still leaves the shape/freshness of individual alert entries unaddressed, which an agent inspecting results would want.

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?

Single required parameter 'domain' with 100% schema description coverage, so the schema already carries the semantics and the baseline is 3. The description adds no domain format, scoping, or permission nuance beyond what the schema states.

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 — the OPEN alerts of the running turbometrics monitoring — and pins down the scope ('Ereignisse über die Zeit, keine Momentaufnahme und keine Messwerte'). It explicitly distinguishes itself from the sibling tools get_performance_findings (measurement numbers) and get_performance_score (cached overall score).

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

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

Opens with the question the tool answers ('hat die Überwachung zuletzt etwas gemeldet?') and then routes the agent to the two alternatives by naming what they return instead. The when-to-use condition and the when-to-use-something-else conditions are both explicit.

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

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

Annotations only cover safety (readOnly/destructive=false); the description adds real behavioural context beyond that: the scan list is read live at query time (hence ordering effects), the two numbers can diverge, missing domain knowledge is reported as missing activation, and — importantly — an indeterminate measurement is reported as exactly that, explicitly warning the agent not to read it as 'not activated' or as an all-clear.

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

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

Front-loaded with the core question it answers, then layers in the sibling distinctions and failure semantics. Nearly every sentence earns its place, though the conversational framing adds some length for a single-parameter read tool.

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

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

For a one-parameter read tool with no output schema, the description covers purpose, sibling boundaries, live-read timing effects, and the three-way outcome semantics (findings / not activated / indeterminate) that an agent needs to interpret the response 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?

Only one parameter (domain) and schema description coverage is 100%, so the schema already carries the meaning. The description adds no format or syntax detail about the domain argument, 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: the itemised findings (Einzelbefunde) of the LAST ACTUALLY RUN turbometrics scan, each with a recommended action, plus that scan's overall value. It also names the two siblings it is not — get_performance_score (cached nightly value) and get_performance_alerts (open monitoring warnings).

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 explains the condition under which this differs from get_performance_score, notes that a run triggered via start_performance_scan will appear here first, and routes the agent to get_performance_alerts for open warnings. When/when-not/alternatives are all present.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds substantial non-obvious context: the source is a once-daily report rather than live data, the report date and the embedded scan timestamp are routinely one day apart, and a missing value means 'no measurement' rather than slow or never-scanned. That is exactly the kind of freshness/caveat disclosure annotations cannot express.

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

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

Front-loaded with the answer to 'what does it return', then the source and freshness caveats. It is dense for a one-parameter read tool and slightly repetitive in restating the routing, but every sentence carries real information, so it is not 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 read-only, single-parameter, no-output-schema tool, the description covers purpose, source, freshness semantics, sibling routing, and the meaning of missing values. Nothing an agent needs to call it correctly or to interpret the result 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?

There is a single required parameter (domain) with 100% schema description coverage, so the schema already documents it. The description adds nothing about the domain format beyond the schema's own example, so the baseline 3 for fully-covered params 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+resource (returns one score per area) and enumerates the areas (Gesamt, Speed, Bilder, Caching, WordPress, Technik, TTFB). It also names the data source (daily turbocheck report) and explicitly distinguishes itself from get_performance_findings and start_performance_scan, so an agent can tell it apart from siblings without opening any schema.

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

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

Gives explicit when-to-use routing: use this for the scored daily value, use get_performance_findings for the last actually-run scan, and a start_performance_scan run only appears here after the next nightly pass. It also explains that divergence between the two tools' numbers is expected and not an error.

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 carry the safety profile (readOnlyHint=true, destructiveHint=false), so the bar is lower. The description still adds real context: data is read live from the hosting system, the returned selectable values ('8.4') map exactly to what switch_php_version accepts, and an unreadable value must not be interpreted as 'none'. Return format/pagination is not covered, keeping it at 4 rather than 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?

Front-loaded correctly: what it reads first, then its relation to switch_php_version and the question it answers, then the edge-case warning. Every clause carries operational value despite the dense em-dash style.

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

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

For a read-only, single-parameter tool with annotations already covering the safety profile and no output schema, the description supplies everything needed: purpose, sibling routing, value-format contract with switch_php_version, and a failure-mode warning.

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 domain parameter is fully documented in the schema (including the 'example.de' example). The only description-level addition is emphasizing the single-domain scope ('für EINE Domain'), which is marginal. Baseline 3 is appropriate 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 with scope ('Liest für EINE Domain die eingestellte PHP-Version und die Versionen, die auf ihrem Server wählbar sind') and explicitly names its sibling counterpart switch_php_version. An agent can distinguish it from switch_php_version and every other get_* tool 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?

Names the exact alternative (switch_php_version) and the condition selecting this one, plus the question it answers ('Welche PHP-Versionen gibt es?'). It even gives when-not guidance: if a value is reported unreadable, don't guess and don't trigger a trial switch.

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 only carry the safety profile (readOnly, non-destructive); the description adds genuinely new behavioral context: the data comes from a once-daily turbocheck report, the response contains a timestamp, and "keine Funde" is explicitly warned not to mean an active scan just ran. This freshness caveat prevents a real misinterpretation.

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

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

Front-loaded with purpose, then the freshness caveat, then the alternative-tool pointer, in three tight sentences with no filler. 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 simple read-only status tool with full schema coverage and annotations covering safety, the description supplies the data source, staleness semantics, and sibling routing. Nothing an agent needs in order to call it correctly and interpret the result 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?

There is a single parameter (domain) and schema description coverage is 100%, so the schema already documents it ("Die Domain, z. B. example.com"). The description adds no syntax or format detail beyond that, making the baseline 3 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?

Specific verb ("abrufen") plus resource ("Sicherheitsstatus einer Domain") with the concrete contents enumerated (Malware-Funde, Schwachstellen, offen erreichbare Dateien). It also explicitly distinguishes itself from the sibling get_wordpress_hardening, so an agent can route correctly without opening either schema.

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

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

States when to use it and names the alternative explicitly ("Für den Härtungsstand von WordPress selbst stattdessen get_wordpress_hardening verwenden"). The condition selecting the alternative is spelled out, leaving nothing to inference.

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

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

Annotations only declare readOnlyHint=true/destructiveHint=false, but the description adds substantial behavioral context: it reads live from the hosting system, validates the address server-side against mailboxes of exactly this hosting package, and rejects guessed/foreign addresses before reading anything. It further warns that the spam-action value is output differently than it is set, and that a 'nicht gelesen' marker means neither 'empty' nor 'off' — both high-value disclosure beyond 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?

Purpose is front-loaded in the first clause, followed in a logical order by the sibling relationship, the inputs/validation, then the two caveats. It is dense and somewhat long, but each sentence carries operational value; nothing is redundant filler.

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

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

There is no output schema, so the description carries the burden and does so well: it enumerates what the response contains and explains two non-obvious output-format traps (differently-encoded spam action, and the 'nicht gelesen' state). An agent has everything needed to call it and to relay results accurately.

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 baseline is 3, but the description adds validation semantics beyond the schema: the address is checked server-side against mailboxes of this hosting package, and a guessed or foreign address is rejected before any read occurs. That meaningfully extends the two documented 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?

States a specific verb and resource ('Liest die Spamfilter-Einstellung EINES Postfachs') and enumerates the fields returned (on/off, score threshold, spam action, subject tag, block/allow lists). It explicitly positions itself against the sibling 'set_spam_filter', so an agent can distinguish the read side from the write side without opening either schema.

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

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

Names the counterpart tool ('Das lesende Gegenstück zu set_spam_filter') and the condition that selects it ('der einzige Weg, eine Änderung daran nachzuprüfen'). It also states the required inputs (Domain und Adresse des Postfachs), leaving nothing to inference for correct invocation.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful traits beyond them: a real TLS handshake with no cache, and an explicit limitation that auto-renew status is not retrievable. This is genuine behavioral context, though it says nothing about failure/timeout 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 tightly-packed sentences with the core scope front-loaded ('live prüfen') and the key limitation last. No filler or repetition.

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

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

For a single-parameter read-only status check with full schema coverage and annotations covering the safety profile, this is complete. It even describes the return content (issuer, SANs, validity) despite having no output schema, and sets correct expectations about the auto-renew limitation.

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 'domain' parameter is fully documented in the schema (including the example.com example). The description adds no format or syntax detail beyond what the schema already provides, so the baseline 3 applies.

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

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

States a specific verb and resource ('SSL-Zertifikatsstatus einer Domain live prüfen') and enumerates the returned content (Aussteller, SANs, verbleibende Gültigkeit). It clearly distinguishes itself from siblings like create_ssl_certificate or get_dns_security by being a live read of an existing certificate.

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

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

The description gives clear context for use (live status check of an existing certificate) and adds a useful boundary — that auto-renew configuration cannot be determined — which steers the agent away from expecting that from this tool. It does not, however, name specific alternative tools for those other needs.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds real context beyond that — the data is fetched live from Plesk, and the scope is one domain — but it says nothing about response size, latency, or whether the numbers are cached. With annotations carrying the safety profile, a 3 is appropriate.

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

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

One dense sentence enumerates the payload, then a short second sentence routes to the alternative — zero filler and the scope is front-loaded. It is a little list-heavy, but every clause maps to a real output section rather than 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?

There is no output schema, so the description compensates well by naming the returned sections (quota comparison, item breakdown, database sizes with overhead). It stops short of describing ordering, pagination, or units (bytes vs MB), which an agent would still have to discover at call time.

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 required parameter with 100% schema description coverage ("Die Domain, z. B. example.com"), so the schema fully documents it. The description adds no format, wildcard, or ID-vs-hostname nuance beyond what the schema already states. Baseline 3 applies 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 ("Aufschlüsselung des belegten Speicherplatzes einer Domain") and enumerates the exact contents: total vs quota, breakdown by web files/databases/mailboxes/logs, plus per-database size and overhead. It explicitly distinguishes itself from the sibling get_webspace_usage, so an agent can choose between them without opening either schema.

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

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

Gives an explicit decision rule and names the alternative: the diagnostic question "Was frisst meinen Speicherplatz?" is this tool, while the plain "Wie voll ist es?" is served by get_webspace_usage. Nothing is left to inference about when to prefer which.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds useful behavior beyond that: the list is capped at the last 20 tickets, ticket_id returns the full thread, and the ID is the internal ticket ID rather than the customer-facing ticket number. Auth and response format are not covered, but the added context is meaningful.

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 no-parameter list mode, then the parameterized detail mode, then the ID clarification. Every sentence earns its place and the structure matches how an agent would decide whether to pass ticket_id.

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 tool with one optional parameter, full schema coverage, and safety annotations, the description covers the meaningful gaps: list cap, detail behavior, and internal-vs-public ID semantics. It could mention whether the 20-ticket limit is paginable, but no output schema means return-shape detail is less critical.

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 describes ticket_id as the internal ID from the ticket list, not the ticket number. The description reinforces this with a concrete example (#12345), but adds little beyond the schema's own parameter description, 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?

States a specific verb and resource (Support-Tickets auflisten/abrufen), the scope (eigene, max. letzte 20), and two distinct modes: list view or full thread via ticket_id. The dual-mode framing makes it clearly distinct from sibling tools like create_support_ticket, reply_to_ticket, and close_support_ticket.

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 explains when to omit ticket_id (list own tickets, capped at 20) versus when to include it (retrieve the full thread of a single ticket). It also gives a crucial usage nuance about which ticket ID to pass, though it does not name alternatives or state when the 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 read-only and non-destructive behavior. The description adds important behavioral context beyond annotations: it explicitly warns that the URL is generated without checking DNS existence or certificate validity, and that it may not resolve with external DNS lacking a webmail 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?

Two tightly written sentences with zero waste. The purpose is front-loaded and the important caveat follows immediately, making it easy to scan.

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

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

There is no output schema, but the description makes clear that the tool returns a constructed webmail URL and explains its limitations. For a one-parameter, read-only utility, nothing essential is missing.

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

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

Schema description coverage is 100%, so the single 'domain' parameter is already documented. The description adds the URL construction pattern, which clarifies how the parameter is used, but does not add constraints or format details beyond what the schema 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 and resource: constructs the webmail access address for a domain, including the exact URL scheme. It is clearly distinguishable from sibling read/status tools because it only generates a URL rather than measuring or verifying anything.

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

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

The description provides clear context for when the tool is appropriate and explicitly states a key when-not condition: it is not a measurement and does not verify DNS or certificates. It does not, however, name an alternative tool to use when verification is actually needed.

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

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

Die Annotationen belegen nur readOnly/destructive=false. Die Beschreibung ergänzt wesentliche Verhaltensdetails: Der Bericht stammt aus einem einmal täglich aktualisierten Lauf, enthält einen Zeitstempel in der Antwort und beschreibt den Stand des letzten Durchlaufs, nicht den Abfragezeitpunkt. Damit wird die Aktualität der Daten eindeutig offengelegt.

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?

Drei Sätze mit klarer Front-Loading-Struktur: zuerst Zweck, dann Aktualitätshinweis, dann Abgrenzung zu Alternativen. Kein Satz ist überflüssig oder wiederholt lediglich strukturierte Felder.

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?

Für ein Tool ohne Output-Schema und mit nur einem Parameter ist die Beschreibung ausreichend: Sie erklärt Inhalt (Fließtext mit Findings), Herkunft und Aktualität des Berichts sowie die Abgrenzung zu Alternativen. Ein Agent hat alles Nötige, um das Tool korrekt einzusetzen.

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?

Die Schema-Beschreibungsabdeckung liegt bei 100 %, der einzige Parameter 'domain' ist dort bereits vollständig dokumentiert. Die Beschreibung fügt keine zusätzlichen Format- oder Syntaxdetails hinzu, sodass hier nur der Baseline-Wert angemessen ist.

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?

Die Beschreibung nennt ein klares Verb und Ressource: den zusammenfassenden turbocheck-AI-Statusbericht (Fließtext mit allen Findings) für eine Domain abrufen. Sie grenzt das Tool zudem explizit von den spezialisierten Geschwister-Tools ab.

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?

Es wird klar gesagt, wann dieses Tool passt (zusammenfassender Gesamtbericht) und wann stattdessen Alternativen zu verwenden sind: für gezielte Fragen zu Backup, WordPress, Sicherheit, DNS oder Performance werden die jeweiligen Tools namentlich aufgeführt.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds a non-obvious limitation: Plesk updates this statistic only about once a day, so values can be up to 24 hours old and are not real-time. Lacks auth/rate-limit detail, so not 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 sentences with the purpose front-loaded, followed by the key caveat. Every sentence earns its place; no wasted words.

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

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

A simple read tool with one fully documented parameter and safety annotations. The description covers what data is returned and the staleness caveat, but does not describe response structure (and there is no output schema). Adequate but not exhaustive.

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 domain parameter is fully documented with an example. The description adds no syntax or format detail beyond the schema, 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?

States a specific verb (abrufen) and resource (Speicherplatz-, Traffic- und Postfach-Nutzung einer Domain) with source (direkt von Plesk). It does not differentiate from sibling tools like get_storage_breakdown, 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?

No when-to-use guidance, no alternatives named, and no exclusions. The note about daily updates is a behavioral caveat, 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=true and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: these are on-demand WP Toolkit backups independent of Plesk full backups, the customer has no direct access to the latter, and it clearly reports when no WordPress is found.

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 resource and scope, no redundant filler. Slightly dense with parenthetical asides but every clause carries meaning.

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-only list tool with no output schema, the description is largely complete, covering scope, the backup-type distinction, and the empty-result behavior. It does not describe return shape, but that is minor given it is a simple listing.

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

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

Only one parameter (domain) with 100% schema description coverage, so the schema already documents it. The description adds no format or syntax detail beyond the schema, making the baseline 3 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 (listet) and resource (On-Demand-WordPress-Backups) and scopes it to WP Toolkit, explicitly distinguishing it from the daily automatic Plesk full backups. An agent can tell it apart from get_backup_status and create_wordpress_backup 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?

The contrast with Plesk full backups implies the usage context (this is for on-demand WP backups specifically), but it never states an explicit when-to-use rule or names an alternative tool to prefer instead. Usage is inferable but not 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?

The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful output-level context by saying the result includes a plain-text title, whether the measure is considered critical, and whether it can be reverted. It does not cover auth or rate limits, but those are minor for a simple read-only status tool.

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

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

The description is front-loaded with the core purpose, then immediately handles sibling disambiguation. It uses two sentences with no filler, and every clause adds either scope or differentiation value.

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

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

With no output schema, the description must carry return-value expectations, and it does so by mentioning plain-text titles, criticality, and reversibility. Combined with the explicit sibling contrast, it gives an agent enough to call and interpret the tool correctly.

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

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

Schema description coverage is 100%, and both parameters (domain, site_url) are documented in the schema. The description adds no extra parameter meaning, so the baseline of 3 is appropriate 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 a specific verb („Zeigt“) and resource (WordPress-Härtungsmaßnahmen auf einer Installation) and clarifies the exact scope: which measures are active and which are missing. It also explicitly distinguishes this tool from get_security_status, so an agent can identify 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?

It states exactly when to use this tool versus the closest alternative, get_security_status. The contrast is concrete: one reports malware findings and exposed files from the nightly turbocheck report, the other reports the WordPress hardening state itself.

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 well beyond the readOnlyHint/destructiveHint annotations: distinguishes an empty list (a real answer) from a failed retrieval (must never be read as 'no WordPress'), clarifies that 'currently not responding' does not mean deleted, and states that host-unsupplied fields are labelled rather than invented.

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

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

Front-loaded with the core action and scope, and every sentence carries usable information (return fields, error semantics, non-deletion caveat). Slightly padded by framing phrasing such as 'Das Werkzeug, das die Lücke schließt', 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?

No output schema exists, so the description correctly covers return content (address, version, state) and the two ambiguous-result cases an agent could misread. For a one-parameter read tool with annotation coverage, nothing needed is missing.