turbopress

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

Goes well beyond the annotations: it discloses idempotent semantics (existing account untouched), the side effect of creating an account at turbometrics.io, the conditional welcome email with a 60-minute password link, and the fact that no email is sent on the exists path. It even warns that the response does not mention the email, which is exactly the kind of behavioural detail annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false) 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?

Front-loaded with what the tool does and the created/exists branching, and every sentence carries behavioural information. It is somewhat long and repeats the email/created-exists point twice, plus an interjected provenance note, but there is little genuine 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 does the right thing by naming the created/exists response values and by pointing to the tools that surface scan results. It stops short of describing exact response fields or scan timing, but that information is available through the named sibling tools.

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

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

Only one parameter and schema description coverage is 100%, so the schema already carries the domain semantics including the 'example.de' format hint. The description adds nothing about the domain argument beyond what the schema states, 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?

Specific verb + resource ('Aktiviert turbometrics ... für eine Domain') with the scope (per-domain, for turbopress customers) stated up front. It is clearly distinguishable from the sibling read tools get_performance_score/get_performance_findings and from start_performance_scan, which the description implies is made redundant by the automatic scans.

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?

Explains the two operating conditions (first activation creates the account, subsequent calls leave it unchanged) and routes the agent to the right follow-up tools (get_performance_score, get_performance_findings). It does not explicitly state when NOT to use it versus start_performance_scan, so there is a small gap.

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

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

Annotations already declare destructiveHint=true and openWorldHint=true; the description adds real consequence context the annotations cannot convey — that a faulty record can break mail delivery or website reachability — and the DNS-specific pitfall that the server truncates an appended domain suffix, plus the instruction to report the name actually stored rather than the one supplied. It omits propagation/TTL timing and what happens on a duplicate/conflicting record, which keeps it below 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 the type list, then type-specific rules, then a risk warning — a sensible order with no filler. It is dense and slightly redundant where it re-enumerates the SRV field names that the schema already labels.

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 13-parameter tool with type-dependent field subsets and no output schema, the description covers the branching logic, the MX gotcha, TXT length, and the host-suffix trap. Missing pieces are the lifecycle questions — propagation timing, behavior on duplicate records, and that a bad entry is fixed via update/delete.

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 per-field meaning is already documented; the description largely restates the type-conditional field matrix. It does add one thing the schema lacks: MX priority is stated as mandatory because Plesk rejects MX without it (the schema only says 'meist erforderlich'), plus the 2048-character TXT limit rationale.

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 ("Legt einen neuen DNS-Record auf einer Domain an") and enumerates the supported record types, which immediately separates it from update_dns_record and delete_dns_record in the sibling list. Scope is unambiguous 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 clear conditional guidance: which field set to use for SRV, CAA and MX, and that TXT is the intended path for SPF/DMARC/DKIM. It never names the alternative tools (e.g. update_dns_record for changing an existing record, get_dns_records to inspect first), so it stops short of explicit when-not/alternatives guidance.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=true and idempotentHint=false, but the description adds substantial behavioural context: a mandatory confirmation click in the panel chat, a 10-additions-per-day limit, no background job for waiting domains, a 30-day expiry, and the exact DNS/SSL waiting semantics. It also tells the agent to pass the response verbatim and only report success when the response does.

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 purpose is front-loaded in the first sentence, and the length is justified by the tool's state machine and DNS/SSL edge cases. The body is a dense single block rather than structured sections, and some certificate/DNS points are repeated, so it is not maximally concise.

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

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

There is no output schema, and the description compensates by explaining expected response states (wartet_dns, zertifikat_folgt), DNS entries to set or remove, what aktion 'pruefen' does, and how the agent should handle the returned response. For an 8-parameter, multi-mode mutation tool, this covers what an agent needs in order to call and interpret it correctly.

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

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

Schema description coverage is 100%, so the schema already documents all eight parameters. The description still adds useful semantics: it explains the meaning of the three art values in operational terms, clarifies that pfad is deprecated in favour of unterordner, and describes when aktion 'pruefen' or 'pfad' 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 names a specific verb and resource (legt ... eine Subdomain oder eine Weiterleitung ... an) and immediately scopes it to the hosting package. It distinguishes the three creation modes and explicitly names sibling alternatives (redirect_domain, remove_added_domain), so an agent can separate it from neighbouring tools without opening a schema.

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

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

It states when to use the tool and clear exclusions: turbopress-owned domains go to redirect_domain, another package's main domain is rejected with dz_eigenes_paket, and foreign domains are rejected. It also gives the when-to-use condition for aktion 'pruefen' and the removal path via remove_added_domain.

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

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

Annotations only declare a generic destructiveHint=true/openWorldHint=true; the description goes well beyond them by naming concrete consequences for individual measures (securityKeys ends all sessions, adminUsername changes login name, dbPrefix alters the database, secureContent/disableUnusedScripting can break plugins) and flagging that 5 of 19 measures are irreversible.

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 sibling pointer, then high-value side-effect warnings. Every sentence earns its place and the dense enumeration of dangerous measures is the most useful content.

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

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

For a destructive, single-measure mutation tool with no output schema, the description supplies the discovery path, the irreversibility count, and per-measure side effects. Nothing an agent needs to decide whether and how to call it 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% and each parameter is already documented, including the get_wordpress_hardening reference for 'measure'. The description reinforces the 'exactly one measure' constraint but adds no syntax, format, or example detail 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 (anwenden), resource (Härtungsmaßnahme) and scope constraint (GENAU EINE) on a WordPress installation. It also points to get_wordpress_hardening as the source of valid identifiers, letting an agent separate it from the discovery-sibling 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?

The 'GENAU EINE' constraint plus the pointer to get_wordpress_hardening gives clear operating context, and the irreversibility warning shapes when it is safe to call. However it does not explicitly name revert_wordpress_security_measure as the undo path or state when-not-to-use, so it stops short of full routing.

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

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

Annotations already declare readOnlyHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuine behavioral context beyond that: the lookup is WHOIS-based, and it explicitly refuses to report an ambiguous status as 'registered' — an honesty/edge-case behavior an agent could not infer 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?

Purpose is front-loaded in the first clause and there is no filler. It is one long, slightly run-on sentence, but every clause adds a distinct fact (scope, method, ambiguity handling), so it is dense rather than bloated.

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

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

For a single-parameter read-only lookup with no output schema, the description supplies the essentials: method, scope, and the three possible outcomes (verfügbar / bereits registriert / nicht eindeutig). It never describes the response shape or how errors are surfaced, which keeps it just short of 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?

There is a single parameter with 100% schema description coverage ('Die zu prüfende Domain, z. B. example.de'), so the schema already carries the semantics. The description adds the WHOIS scope but nothing about the domain string format or whether it accepts subdomains/IDN, 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+resource (checks whether a domain is available for registration) and immediately scopes it with 'not limited to your own domains', which cleanly distinguishes it from the sibling get_domains that operates on the account's own domains. An agent can route to 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?

The parenthetical 'nicht auf eigene Domains beschränkt' gives a clear condition for choosing this over the account-scoped domain tools. It stops short of naming the nearest alternative (suggest_domain_alternatives) or stating when-not to use it, so it is clear context without explicit routing.

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

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

Annotations already establish the safe read-only profile (readOnlyHint=true, destructiveHint=false), yet the description adds substantial context beyond that: the three finding classes and what each means, including noting extra files as 'die klassische Stelle für eine Hintertür'. It also tempers interpretation, which is genuinely useful for an agent reporting 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?

Front-loaded with the core action, then the finding taxonomy, then the scope boundary, then the interpretation caveat. Every sentence carries information an agent needs; nothing is padding.

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

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

No output schema exists, but the description compensates by describing the return categories and that affected files are named per category. Combined with the scope exclusions and the interpretation caveat, an agent has enough to call it and interpret results 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 domain and site_url are already documented in the schema, including the multi-installation caveat. The description adds no parameter-level 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?

Specific verb+resource: it compares a WordPress installation against official checksums and enumerates the three finding categories it reports. It explicitly bounds the scope ('nur der WordPress-Kern, nicht Plugins, Themes oder Uploads'), which cleanly separates it from siblings like get_outdated_plugins or get_wordpress_status.

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

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

Usage context is clear: it explains when the core-only check applies and warns that a finding is not automatically an intrusion ('Auch ein von Hand verändertes WordPress fällt auf'). It does not, however, explicitly name an alternative sibling (e.g. scan_wordpress_vulnerabilities) or state when NOT to run it, which keeps it just below 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 destructive=true and idempotent=false, and the description goes far beyond them: an automatic verified backup precedes every change, deletion is aborted if no backup can be created or proven, deleted data is recoverable only via that backup, autosaves of the last 7 days are preserved, database size may not shrink immediately because no OPTIMIZE runs, and there is a hard rate limit of 5 runs per day.

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 destructive scope and the backup guarantee before the finer caveats, and nearly every sentence carries operational weight. It is dense and slightly long for a single tool, with some repetition around the explicit-consent requirement for comments.

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, non-idempotent, open-world tool with no output schema, the description covers everything an agent needs: backup precondition, abort paths, multisite and no-op behaviour, partial-run outcome plus the instruction to tell the customer to rerun, and the daily run limit.

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 real semantics: site_url is required specifically when multiple WordPress installations share a domain, and kommentare must only be set on explicit customer request. That meaning goes beyond the schema text, though domain itself gets no further elaboration.

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

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

States a specific verb and resource (Datenbank aufräumen) and enumerates exactly what is removed: ALL post revisions including the full version history, expired transients, and spam/trash comments only on request. It is clearly distinguishable from siblings such as clear_wordpress_cache, create_wordpress_backup, or delete_wordpress_backup.

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

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

Explicitly says NOT to call it for inspection ("NICHT zum Nachsehen aufrufen") because anything to clean is secured and deleted immediately, and requires the customer's explicit wish to run. It also names exclusion conditions (Multisite, unreadable install, nothing to clean) where the tool exits without action, and separately gates the comment deletion on explicit customer consent.

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, destructive=false, openWorld=true; the description adds substantial context beyond that: three distinct outcome states, that "nicht feststellbar" is NOT an all-clear (WordPress may not be starting, stale content may still be served), that content is not lost, that subsequent requests are briefly slower, and that a verified=false response is not a success signal. This is rich, non-obvious behavioral disclosure.

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 action is front-loaded, but the description is dense and meandering, with several em-dash asides ("live gemessen, wirkt nachweislich", "dann war nichts zu leeren") that dilute the message. Much of the content is valuable, but it could be structured more tightly.

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 compensates by describing the three return outcomes and the semantics of a verified=false response, which is exactly what an agent needs for a mutation tool. Combined with the annotation safety profile, nothing critical is missing.

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

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

Schema description coverage is 100%, so the enum values for scope and the meaning of site_url are already documented in the schema. The description adds that scope can also purge the object cache (Valkey), but this is largely duplicative of the enum descriptions, so the baseline of 3 applies.

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

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

The description names a specific verb and resource (clears the WordPress cache of a domain, via the real WP-CLI call "wp litespeed-purge") and states the scope of what is affected. An agent can distinguish it from sibling tools like start_performance_scan or diagnose_website 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?

"Erster Schritt, wenn Änderungen an der Website nicht sichtbar werden" gives an explicit triggering condition, and the optional scope usage is clarified. However, no alternative sibling tool is named for the case where cache clearing is not the right move (e.g. diagnosing the site instead), so guidance is clear but not fully comparative.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the mutation profile is partly covered. The description adds nothing beyond that: it does not say whether closing is reversible, whether it blocks further replies, or whether confirmation is required. Because destructiveHint=false could be read as "nothing is lost," some clarifying text about the effect of closing would be valuable.

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

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

One short sentence, front-loaded with verb and resource, with no filler. Its brevity is efficient rather than padded, though it borders on under-specification for a mutating 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 state-changing ticket operation with no output schema and no annotation coverage of reversibility or side effects, the description leaves the agent without the information needed to call it responsibly. It says what closes, but nothing about consequences or the resulting state.

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

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

Single parameter with 100% schema description coverage ("die in get_support_tickets angezeigte interne Ticket-ID"), so the schema already carries the semantics. The description adds nothing about the identifier and the baseline for fully documented single-param schemas is 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?

Names a specific verb ("Schließt") and resource ("Support-Ticket") with a scope qualifier ("eigenes" = own, "bestehendes" = existing) that arguably signals the counterpart to create_support_ticket. An agent can tell it is a state-ending operation rather than a read or a reply. It does not, however, explicitly name the sibling tools (get_support_tickets, reply_to_ticket) it must be distinguished from.

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

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

"Bestehendes eigenes" implies a precondition: the ticket must already exist and belong to the caller, which is more than pure restatement. There is still no explicit when-to-use/when-not guidance and no reference to alternatives such as replying instead of closing.

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: server-side validation of every command rule with the violated rule reported back, an extra file-existence check for type='exec'/'php', creation succeeding anyway with a warning, and a distinct indeterminate result. This tells the agent how to interpret and relay the outcome, which the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true) cannot.

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 command rules and the two response cases (missing file warning, indeterminate check). Dense but every clause carries an instruction the agent must act on; slightly long with some overlap around the command-validation point.

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 response shapes an agent must handle: a warning to pass on verbatim and an 'could not be checked' message. Combined with 100% schema coverage, nothing needed to call or interpret the 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 the baseline is 3, but the description adds semantics the schema does not carry: that the file-existence check applies specifically to type='exec' and type='php', and that 'command' rules are authoritative and enforced. It does not restate schedule/domain syntax, which the schema already covers.

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 maps it to the Plesk concept ('Geplante Aufgaben'), so the agent knows exactly what side effect to expect. It is trivially distinguishable from get_cronjobs and delete_cronjob by the creation verb.

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

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

Gives clear operational context: read the 'command' rules before proposing a command, and it is legal to create a cronjob before the target file is uploaded. It does not name sibling tools or state explicit exclusions, 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, destructiveHint=false and openWorldHint=true, so the safety profile is covered structurally. The description adds the engine (MySQL) and the domain scoping, but says nothing about name collisions, whether the operation is idempotent, or permission requirements beyond what annotations imply.

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

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

A single front-loaded sentence with no filler. It is efficient, though arguably terse given the tool mutates infrastructure.

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

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

For a low-complexity create tool with two fully documented required params and no output schema, the essentials are present. However, the relationship to database-user creation and any failure behavior on duplicate names is left unaddressed.

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

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

Schema description coverage is 100%: the schema documents both 'name' (allowed characters) and 'domain' (example format). 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+resource+scope: creating a new MySQL database tied to a domain. Clear enough to distinguish from delete_database and get_databases, though it does not explicitly contrast itself with create_database_user or other create_* 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?

No when-to-use or when-not-to-use guidance is given. Nothing tells the agent how this relates to create_database_user (whether a user must be created separately), nor any prerequisite such as the domain already existing.

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=false, destructiveHint=false, openWorldHint=true). The description adds genuinely useful behavior beyond that: the password is securely randomly generated and returned in the response, and the user is bound to an existing database. It stops short of stating permission requirements or idempotency/duplicate-user 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 written sentences with no filler, and the core action is front-loaded ahead of the password-generation behavior. Nothing needs trimming.

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 3-param mutation tool with no output schema, the description supplies the key missing return-value context (the generated password appears in the response) and the DB prerequisite. Only permission/error-handling detail is absent, which is a minor gap given the rich 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% and the schema itself is exceptionally detailed (login constraints, valid/invalid examples, the 32-char Plesk pitfall). The description adds no parameter-level meaning beyond the schema, so the baseline of 3 applies.

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

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

States a precise verb+resource: creates a new database user and links it to an existing database. This clearly distinguishes it from siblings like create_database and delete_database_user without ambiguity.

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

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

Usage is only implied: 'verknüpft ihn mit einer bestehenden Datenbank' signals that an existing database is a prerequisite. There is no explicit when-to-use/when-not guidance or reference to alternatives, leaving the agent to infer the workflow context.

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

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

Annotations only declare it is a non-read-only, non-destructive, open-world write. The description adds what those hints cannot: the password is generated server-side and displayed exactly once (an irrecoverable side effect), and a duplicate-address rejection leaves the existing mailbox untouched and is explicitly not an error. That is precisely the behavior an agent must know 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?

Front-loads the action, then immediately surfaces the two highest-risk facts (one-time password, duplicate rejection is normal), and closes by routing to the inspection sibling. No filler sentences.

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 – and does – explain the key return value: the generated password delivered once in the response. Combined with the failure-mode explanation, 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%: both 'domain' and 'local_part' are documented with format rules and valid/rejected examples, so the schema already carries the parameter semantics. The description adds no parameter-level information, 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 ('Legt ein neues E-Mail-Postfach auf einer Domain an') and names the sibling that inspects state instead ('get_email_accounts zeigt den Bestand'), making it distinguishable from delete_email_account and get_email_accounts at a glance.

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

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

Gives clear operational context: no pre-check of existence, the failure mode if the address is taken, and where to look at existing mailboxes. It does not explicitly contrast with alternatives like set_email_alias or setup_email_provider, so 4 rather than 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 declare a non-read-only, non-destructive, open-world mutation; the description adds materially: the password is generated server-side (the agent must not ask for one), the default-directory resolution and its '/' fallback, the security consequence of an explicit '/', and the instruction to report only the directory actually returned. These are behavioral facts an agent cannot derive from 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, followed by default behavior, then the safety warning, then the response-handling rule. Four sentences, each earning its place; only the parenthetical example '/httpdocs' is mildly 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 compensates by explaining that the effective directory is only trustworthy from the response. Schema already covers parameters fully. Minor gaps remain: no statement about required permissions, login uniqueness, or what happens on invalid input.

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 real meaning beyond it: it discloses that no password parameter exists because the server generates it, and it reinforces the default/explicit-'/' semantics of 'home' with a security rationale the schema only states mechanically.

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: 'Legt einen zusätzlichen FTP-Zugang für eine Domain an.' The 'zusätzlichen' qualifier and the FTP/domain framing make it unmistakable among siblings (no other create_* tool targets FTP accounts; create_email_account and create_protected_directory are clearly different resources).

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 conditional guidance: omitting 'home' yields the domain's directory, and it flags the dangerous case of explicitly passing '/'. It also supplies a crucial downstream rule ('nur das darf dem Kunden genannt werden'). However, it never names an alternative tool or a when-not-to-use condition (e.g., use reset_ftp_password for existing accounts), 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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true) the description discloses that the password is generated server-side, that validation happens server-side, and — importantly — why WordPress folders are rejected: Plesk's protection covers the whole folder and would break the site or its login (e.g. admin-ajax.php). This causal explanation of a behavioral constraint is exactly the kind of context the 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?

The core purpose and the strongest constraint (WordPress folders) are front-loaded in the first and last sentences, with the reading directive in between. It is a dense paragraph rather than a list, and the umlaut reminder partially duplicates the schema, but no sentence is wasted.

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

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

For a mutation tool with no output schema, the description covers effect, validation, and hard exclusions well. The notable gap is what the call returns — since the password is generated server-side, the agent is not told whether the response contains it, which matters for relaying credentials to 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 the baseline is 3; the description earns one step more by summarizing the cross-field rule (umlauts permitted in `title` but not in `directory` or `username`) and by directing the agent to the per-parameter rules before suggesting values. Most individual constraints still live in the schema, not the description.

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

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

The description names a concrete verb and resource — protecting a domain directory with HTTP Basic authentication — and spells out the effect (directory unreachable without login, hidden from search engines). It is unambiguous what the tool does, though it never names the sibling `remove_protected_directory` or any other alternative to contrast with.

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

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

It gives clear operative context: the password is generated server-side, and WordPress system folders (wp-admin, wp-includes, wp-content) cannot be protected, which is a concrete exclusion an agent must know before calling. It also instructs the agent to read character rules before proposing values to a customer. It stops short of naming which sibling tool to use for the reverse operation or for other security measures.

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 (which only flag destructive/openWorld). It discloses the Let's Encrypt 5-per-week limit, the two internal guard checks with their precise limitations (counting only Turbopress-issued certs = a lower bound; freshness check = an indicator, not a count), the force bypass, the explicit non-silent failure when a check cannot run, and the confirmed vs unconfirmed response semantics.

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 action and its replacement behavior are front-loaded, and the extended guard/limit detail is relevant to correct invocation. It is nonetheless dense and long for a single tool, with some over-explanation of the two checks that could be trimmed.

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: it states the live-confirmed result (issuer, covered names, validity) and the explicit unconfirmed alternative. Failure modes and the force escape hatch are all covered.

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

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

Schema description coverage is 100%, so every parameter (domain, include_www/webmail, include_mail, force) is already documented with defaults in the schema. The description restates the include_mail DNS prerequisite and that force overrides both checks, adding only marginal meaning beyond the schema.

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

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

States a specific verb and resource ('Stellt ein neues Let's-Encrypt-SSL-Zertifikat für eine Domain aus') and clarifies the side effect ('ersetzt damit das aktuelle Zertifikat'). This cleanly separates it from read-only siblings like get_ssl_status and from set_contact_form/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?

Gives clear conditions for the risky options: include_mail only 'auf Wunsch' and only when an existing mail.<domain> DNS record is present, and force only 'wenn wirklich nötig'. It does not explicitly route an agent to get_ssl_status first, so it stops short of full when/when-not/alternative 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 behavior beyond the annotations: the clone runs asynchronously and only acceptance is returned, the advertised staging address is composed rather than fetched, SSL/reachability are unverified, collisions are auto-numbered, and a failed clone deliberately leaves the subdomain behind. Annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true) do not convey any of this.

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 layers operational caveats in a logical order. It is dense and long, but nearly every clause carries distinct operational information; a tighter split between the tool summary and customer-facing guidance would improve 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?

With no output schema, the description carries the return-value burden and does so explicitly, warning that the response means 'triggered' not 'created' and instructing how to relay this to the customer. Nothing needed to call or interpret the 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 the baseline is 3, but the description adds value the schema lacks: the collision auto-numbering behavior for subdomain_name and the precise condition that triggers the site_url requirement. Naming-character rules are already fully in the schema, so it does not need to repeat 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?

States a specific verb and resource: creates a test copy of a WordPress installation on a new subdomain, and names the mechanism (WP Toolkit clone). This is instantly distinguishable from sibling tools like create_wordpress_backup or install_wordpress_plugin.

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 conditional: site_url must be supplied when multiple WordPress installations share a domain. It also implies the favorable case (single install) by omission. It does not explicitly route to a sibling alternative, which keeps it short of a 5.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the write/open-world profile is covered. The description goes beyond that by disclosing a concrete rate limit (5 tickets per day) and its intent, which is genuinely useful behavioral context an agent cannot derive from annotations or schema.

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

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

Two short sentences: the purpose first, then the constraint. Every clause earns its place and nothing is padded or repeated from 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?

For a two-parameter creation tool with no output schema and annotations already covering safety semantics, the description supplies what is needed: the action and the daily cap. It omits only minor details such as authentication requirements or what is returned after creation (ticket ID), which is a small gap.

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

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

Schema description coverage is 100% with only two required string parameters (subject, message), so the schema already carries the parameter documentation. The description adds no format, length, or content guidance beyond that, which matches the baseline for full schema coverage.

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

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

States a specific verb (eröffnet/creates) and resource (Support-Ticket), so the agent immediately knows this is the creation path for tickets. It does not explicitly differentiate itself from siblings like reply_to_ticket or close_support_ticket, but the verb+resource pairing makes the distinction inferable.

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 used (creating a new ticket) and adds an operational constraint of max 5 tickets/day, which tells the agent when a call may fail. However, it never names alternatives such as reply_to_ticket for existing threads or get_support_tickets for reading, so no explicit when-not guidance is given.

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

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

Annotations already declare destructiveHint=false and openWorldHint=true; the description reinforces this with 'Rein additiv, kein Risiko für bestehende Daten', which usefully clarifies existing data is untouched. However it says nothing about the backup being asynchronous or how/when to confirm completion (get_backup_status and get_wordpress_backups exist as siblings), which is the key behavioral fact for a create-backup 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?

One dense sentence with the action front-loaded, then the motivating scenario, then the conditional requirement. Efficient, though the em-dash clause stacks three ideas into a single sentence.

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

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

For a mutation tool with no output schema and only 2 well-documented params, the description covers the action, safety and the site_url edge case. It omits that the backup runs asynchronously and how to verify or restore it, which are relevant for an agent completing the task end-to-end.

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 only lightly extends the schema by noting the multi-install case relates to subdomains on the same domain, adding marginal nuance over the existing site_url description.

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

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

States a specific verb (erstellt), resource (On-Demand-WordPress-Backup) and mechanism (über WP Toolkit), which cleanly separates it from get_wordpress_backups, delete_wordpress_backup and restore_wordpress_backup. An agent can route to this tool without opening its 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 when-to-use scenario ('als Absicherung vor einem riskanten Plugin-Update') and a precondition for site_url (multiple WP installs on the same domain). It does not name sibling alternatives such as get_backup_status for verifying completion, so it stops short of full when-to-use/when-not coverage.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=true, so the safety profile is known. The description nonetheless adds substantive context: server-side validation of the ID against that domain's list before anything is deleted, IDs are not stable, running tasks (wp-cron posts/backups/newsletters) stop immediately, and the response explicitly reports whether the task actually disappeared or is unverified. That is genuine value 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?

Front-loaded action statement followed by prerequisites, irreversibility and response semantics; each sentence carries information. It is somewhat long and repeats the delete-then-create advice, and the aside about telling the customer the command/schedule/description is UX guidance rather than tool-selection content.

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

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

For a destructive two-parameter tool with no output schema, the description covers prerequisites (fresh ID from get_cronjobs), domain-scoped validation, irreversibility, side effects on running jobs, and how the response distinguishes verified deletion from unverified state. Nothing essential to correct invocation is missing.

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

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

Schema coverage is 100%, so the baseline is 3, and the schema already warns against guessed or stale cronjob_ids. The description still adds meaning the schema lacks: the ID is validated server-side against the task list of this specific domain, and identifiers are not stable so a fresh fetch is required before deletion.

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 with scope: 'Löscht EINE geplante Aufgabe (Cronjob) einer Domain'. It explicitly contrasts itself with the sibling create_cronjob (re-creation path) and rules out in-place modification, so an agent can distinguish it from its 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?

Explicit when-to-use ('der Weg zurück zu create_cronjob, etwa für eine falsch angelegte Aufgabe') and when-not ('Ändern kann dieses Werkzeug nichts: dafür löschen und neu anlegen'). It also states the prerequisite that cronjob_id must originate from a fresh get_cronjobs call, naming the exact alternative tool.

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

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

Annotations already declare destructiveHint=true, but the description adds far more: no trash, no undo, no recovery even via turbopress support, create_database only restores an EMPTY database, server-side name validation scoped to this subscription, and honest reporting semantics (explicit success confirmation vs. 'unverified' when the list could not 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?

Long and dense, but front-loaded with the single most important fact (irreversible data loss) before procedure and response semantics. For a destructive irreversible operation the length is defensible; only minor 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?

No output schema exists, and the description compensates by describing the response contract (explicit confirmation of removal, or 'unverified' if the list could not be re-read). Combined with preconditions and irreversibility warnings, an agent has everything needed to call this safely.

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 real semantics beyond the schema: the database name is validated server-side against this subscription's databases and deletion happens via the identifier from that list, so a guessed or foreign name never reaches the hosting system.

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 precise verb+resource: 'LÖSCHT eine MySQL-Datenbank samt Inhalt'. It explicitly positions itself against the sibling create_database ('der Weg zurück zu create_database') and distinguishes itself from other delete_* siblings by naming the exact object (database, not user/DNS/email).

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 preconditions: run get_databases first to size the database and check for a WordPress installation, tell the customer both facts, and explicitly ask about their own backup. It also explains what NOT to infer (a previously unavailable list means nothing was deleted).

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 adds substantial context beyond them: no data is lost but access is, dependent apps will throw a database error, the password is not recoverable, a same-named user gets a new password, and — crucially — it discloses what is NOT verified (the database's fate) and forbids over-claiming. It also states the list-not-retrievable failure mode and that it does NOT mean the user is 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 action and the sibling contrast, then layered with operational caveats. It is long for a 2-param tool and a few clauses (e.g. "Sage es genau so, statt es zu behaupten") are meta-instruction rather than tool semantics, but nearly every sentence carries actionable content.

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

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

Complete for a destructive mutation with no output schema: it covers prerequisites, downstream impact, irreversibility of credentials, an explicit uncertainty boundary, and failure-mode interpretation. Nothing an agent needs to call or accurately explain 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% and the schema already documents both params, so the baseline is 3. The description adds real meaning about the `user` param's resolution: the login is validated server-side against the subscription's own database users, so a guessed or foreign value never reaches the hosting system. That is genuine semantics beyond the schema, though it does not add format details.

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

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

States a specific verb and resource ("Löscht einen Datenbank-Benutzer") and immediately positions it relative to siblings: it is the reverse of create_database_user, and it explicitly is NOT a delete_database operation (the database presumably stays). An agent can distinguish it from both create_database_user and 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 instructs the agent to ask the customer beforehand whether anything still uses this user, and names the concrete place to check in WordPress (wp-config.php). It also names the counterpart tool (create_database_user) and distinguishes the operation from database deletion, so 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?

While annotations already flag the tool as destructive, the description adds substantial operational context: server-side validation against the zone of the exact domain, rejection of guessed or stale IDs before any deletion, ID instability requiring a fresh get_dns_records call, irreversibility (only add_dns_record can recreate), and potential immediate impact on mail delivery or website availability. It further describes response semantics, including that an inaccessible zone is reported as unverified rather than success.

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 purpose is front-loaded in the first clause, and the remaining sentences each add operational detail without filler. The description is dense and somewhat long, but for a destructive operation with real service-impact warnings this level of detail is justified rather than 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?

Given the tool's destructive nature, three parameters, and lack of an output schema, the description covers everything an agent needs: correct identifier sourcing, server-side validation, confirmation requirements, irreversibility, potential service impact, and the meaning of the response including unverified outcomes. No critical pre-invocation information is missing.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters well, making 3 the baseline. The description still adds meaning beyond the schema by explaining that record_id is validated server-side against the zone of that domain and that guessed or stale identifiers are rejected before anything is deleted, plus it reinforces ID instability and the need to fetch fresh values before calling.

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 precise verb and resource: 'Löscht EINEN DNS-Eintrag einer Domain'. It immediately distinguishes the tool from siblings by naming add_dns_record as the reversal path and get_dns_records as the source of the required identifier. An agent can tell this apart from other delete_* tools and from add_dns_record without opening a schema.

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

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

It explicitly states the use case ('der Weg zurück zu add_dns_record, etwa für einen falsch eingetragenen DKIM-, SPF- oder DMARC-Wert') and names the sibling tool to use for recreation. It also provides prerequisites: fetch fresh IDs via get_dns_records, show the customer type/name/value before deleting, and obtain explicit confirmation before sending the bestaetigung field. It even notes that NS and SOA records can never be deleted.

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?

Although annotations already declare destructiveHint=true and readOnlyHint=false, the description adds substantial context beyond them: irreversibility, loss of aliases/forwarding, no recovery, server-side validation that nothing is deleted when the mailbox doesn't exist or the list couldn't be retrieved, and how to interpret ambiguous responses. It stops short of being perfect only because the response-interpretation rules, while detailed, are lengthy and partly operational rather than purely descriptive.

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 destructive warning is correctly front-loaded and the sentence order follows the decision flow (what it does → consequences → check first → confirm → interpret response). It is long, but for an irreversible operation most sentences earn their place; a few (e.g. the repeated no-deletion scenarios) are slightly 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 and two parameters fully documented, the description carries the remaining burden excellently — it explains the possible response states (verified deletion, 'accepted but unverified', still present, confirmation_required) and warns never to report success unless the server re-checked. Nothing needed to call and interpret this tool 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% — the schema already explains that domain is the domain and local_part is the part before the @, with format constraints. The description adds the customer-facing example 'info@example.de' but no syntax beyond the schema, so the baseline of 3 applies.

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

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

The opening sentence states a specific verb and resource — permanently deleting an email mailbox including all its mails, aliases and forwarding. It explicitly contrasts with the sibling create_email_account ('a newly created mailbox with the same name is EMPTY'), so the 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 pre-conditions and routing: first look up mailboxes with get_email_accounts, name the exact address to the customer, ask for an explicit confirmation with a sample phrasing, advise on backups, and only call after a clear 'yes'. This is a complete when-to-use and how-to-proceed protocol.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, and the description goes well beyond them: server-side validation rejects guessed/foreign logins before any deletion, deletion is irreversible (old credentials dead, same-named re-creation gets a new password), and the response distinguishes verified deletion from an 'unprüft' outcome when the list could not 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?

The purpose is front-loaded in the first clause and every subsequent sentence carries operational content (rejection rules, irreversibility, response semantics). It is a single dense block with no headers or line breaks, which makes it heavier to parse than necessary, but there is no filler.

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

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

With no output schema, the description carries the return-value burden and does so: it explains that the response states whether the account actually vanished, that an unreadable post-delete list is reported as unverified rather than success, and that a pre-existing list failure means nothing was deleted. Prerequisites, guard rails, and failure modes are all covered.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning: the login is validated server-side against exactly this domain's access list, and a rejected login aborts before deletion. The domain parameter itself adds nothing beyond the schema's 'example.de' example.

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 zusätzlichen FTP-Zugang einer Domain') and immediately differentiates scope from its sibling by naming create_ftp_account as the inverse and ruling out the main account. An agent can distinguish this from reset_ftp_password or delete_email_account 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 when-to-use (a contractor's access is no longer needed), when-not (the 'main_account' marked in get_ftp_accounts, which is also the SSH access), and the required prerequisite that the login come from get_ftp_accounts. It even tells the agent to relay the login and home directory to the customer before deleting.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description goes well beyond them: it discloses irreversibility ('lässt sich danach nicht mehr zurückspielen'), server-side filename validation, a post-delete re-read verification step, and how unverified vs. success outcomes are reported. It even prescribes relaying the response sentence verbatim instead of saying 'erledigt'.

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 scope, then constraints, then the verification contract. Five sentences is longer than typical, but the closing instruction about passing on the response sentence is genuinely actionable rather than filler; only slight tightening would be 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?

With no output schema, the description carries the return-value burden and does so: it explains the post-delete re-read, the 'unverified instead of success' reporting semantics, and what to communicate to the customer. Nothing needed to invoke this destructive tool 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 description coverage is 100%, so the schema already documents all three parameters, including that filename must match get_wordpress_backups output. The description reinforces that constraint but adds no syntax or format detail for domain or site_url, 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 (löscht) and a precisely scoped resource ('ein einzelnes On-Demand-Backup einer WordPress-Installation'), plus the intent (Platz im Backup-Kontingent schaffen). An agent can immediately distinguish this from create_wordpress_backup and restore_wordpress_backup 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 precondition for use: the filename must originate from get_wordpress_backups, and an invented name is rejected server-side. It also implies the irreversible consequence that selects restore_wordpress_backup as the alternative path, though it never names that sibling explicitly or states when not to delete.

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 adds substantial context beyond them: a safety backup is created before deletion and nothing is deleted if it cannot be created or verified, refusals consume no backup quota, deletion is irreversible except via restore_wordpress_backup (which rolls back the whole installation), the chat-access confirmation-card flow, and post-delete verification by re-reading the installation.

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 hard constraint (inactive-only, single item) is front-loaded and every block covers a distinct concern. It is nonetheless long and repeats the irreversibility point twice ('das Löschen selbst ist endgültig' and the customer-warning sentence), which is defensible for a destructive tool 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?

For a destructive, four-parameter tool with no output schema, the description covers preconditions, refusal cases, backup/restore path, human-in-the-loop confirmation, and how success is verified afterwards. 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 schema already carries the heavy lifting, including the slug pattern, the 'not the display name' rule and the get_wordpress_plugins slug source. The description reinforces the slug rule ('Übergib IMMER der Slug ... nie den Anzeigenamen') but adds no new semantics for domain, site_url or item_type, so the baseline 3 applies.

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

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

The description opens with a specific verb and resource ('Löscht EIN WordPress-Plugin oder -Theme, das INAKTIV ist') and immediately scopes the operation to exactly one element per call. It explicitly names the sibling that must be used first for the alternative case (set_wordpress_plugin_state) and distinguishes itself from get_wordpress_plugins / get_outdated_plugins / scan_wordpress_vulnerabilities by role.

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 enumerates when the tool refuses (active theme and its parent, last default theme, active/network-active plugins, must-use plugins and drop-ins, platform plugins, multisite) and points to the correct preceding tool for the deactivation path. It also states the slug-discovery procedure ('ist der Slug nicht bekannt, zuerst get_wordpress_plugins aufrufen, statt zu raten') and the one-item-per-call rule.

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 generic safety profile (readOnly=false, destructive=false, openWorld=true); the description adds substantive behavior: it returns a deploy_id, expects finished static HTML/CSS/JS with relative paths and index.html, forbids build steps and framework source, and warns against base64 payloads and hotlinking. None of this is recoverable from the structured fields.

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

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

The workflow is front-loaded and the numbered sequence is easy to scan, but the block is long and mixes in guidance that arguably belongs to sibling tools (form action markup, set_contact_form, deploy_import_asset, deploy_put_file). Still, each element supports correct invocation, so only mild bloat.

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

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

No output schema exists, yet the description names the return value (deploy_id), the input expectations, and the mandatory follow-up sequence. An agent has everything needed to start a deploy and know what to do next.

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 with an example. The description restates the domain/plan constraint but adds no format or syntax detail beyond it, 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 ('Startet einen neuen Website-Deploy für eine Domain') plus the return value (deploy_id) and the plan constraint (turbopress AI Launch). An agent can distinguish it from deploy_git, deploy_preview and deploy_publish 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?

Gives an explicit ordered workflow (deploy_begin → deploy_put_file → deploy_preview → deploy_publish), names the condition for the final step ('ERST nach seiner ausdrücklichen Bestätigung') and points to the sibling tools to use for each stage. This is exactly the when/when-not/alternative guidance the dimension asks for.

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 destructive=false... rather destructiveHint=true and openWorldHint=true, but the description adds substantial behavioral context beyond them: webhook-driven push behavior, automatic fetch/check/preview, the security constraint on tokens, and the irreversible auto_publish consequence. This is rich disclosure well above the annotation bar.

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 dense paragraph but is front-loaded with the core purpose before action details, and nearly every sentence carries operational value. It is somewhat long, yet no sentence is filler given the four-action surface area.

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

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

For a multi-action mutation tool with no output schema, it covers all actions, what 'get' returns, the required static-HTML constraint, and the safe workflow around auto_publish and deploy_publish. An agent has everything needed to invoke it correctly.

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

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

Schema description coverage is 100% and each parameter already carries its own 'Bei set:' documentation, so the description's parameter notes (repo as 'besitzer/name', subdir 'dist', branch default main, auto_publish meaning) largely restate the schema. Baseline 3 applies, since the description adds little parameter meaning the schema does not already provide.

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+resource (managing a website's Git connection) and enumerates all four actions (get/set/run/remove) with their distinct effects. It also situates the tool relative to siblings by stating that pushes produce a preview 'wie deploy_preview' and that publishing continues via 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 explicit per-action guidance and a full workflow: after 'set' hand the user the webhook URL/secret and webhook_help, never request repo access tokens in chat, and only set auto_publish=true on explicit request, otherwise show the last preview and call deploy_publish with its deploy_id after approval. Alternatives and when-not conditions are 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 declare readOnlyHint=false, openWorldHint=true, destructiveHint=false, but the description adds real behavioral context beyond them: the 10 MB size cap, the requirement that path extension match the file type, the licensing prerequisite, and the follow-up step of referencing "/<path>" in HTML.

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 alternative-routing rule, then constraints, then follow-up. Every sentence is informative, though the license remark and unsplash/pexels coda make it slightly heavier than strictly necessary.

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 covers the mutation nature, prerequisites (public https, 10 MB, matching extension), and the downstream HTML step. Nothing material for correct invocation is missing.

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

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

Schema coverage is 100%, so baseline is 3; the description goes beyond it by tying url to a public https requirement and, crucially, stating that path must match the file type with concrete extension examples. domain and deploy_id are left to the schema, so it is not fully additive.

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 precise verb+resource: the server fetches a file from the web and places it into an open deploy. It scopes the use case (images, fonts, PDFs for the website) and clearly distinguishes itself from deploy_put_file and raw hotlinking.

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 selection guidance: use this instead of sending Base64 via deploy_put_file or hotlinking third-party servers, and it notes deploy_publish already handles images.unsplash.com / images.pexels.com automatically. When-to-use and when-an-alternative-applies are both stated.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely new behavioral context beyond that: the retention window (last 10 published releases kept, unpublished deploys purged after 24 hours) and the fact that a live release is identified. It stops short of describing ordering or exact response shape, but the added value is real.

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 tightly packed sentences, front-loaded with what the tool returns and immediately followed by the rollback linkage. The retention sentence is slightly tangential but still earns its place by explaining why the list may be short. No filler.

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

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

With no output schema, the description carries the burden of describing returns and does so (deploy_id, timestamp, status, live marker). It also covers retention limits and the downstream consumer of the ID, so 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?

Only one parameter and schema description coverage is 100%, so the schema already documents 'domain' fully. The description reinforces that the domain must belong to the turbopress AI Launch plan, which is a small semantic addition, but it adds no format or validation detail beyond the schema. Baseline 3 applies.

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

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

States a specific verb and resource (lists releases/deploys of a website) plus the plan scope (turbopress AI Launch) and exactly what each entry contains (timestamp, status, which is live). An agent can distinguish it from siblings like deploy_preview, deploy_publish or deploy_begin 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?

It gives a concrete routing signal: it supplies the deploy_id that deploy_rollback requires, implying 'call this before a rollback'. However, it never states when not to use it or contrasts it against the other deploy_* tools, so no explicit exclusions are offered.

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

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

Annotations already declare readOnly=false, destructive=false, openWorld=true. The description adds substantive context: live site unchanged, random non-discoverable preview URL, a report with specific warning categories, and that the automatic check locally embeds Google Fonts, CDN libraries, and stock photos while wiring forms.

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 in the first sentence, then provides workflow constraints and failure handling. Every sentence carries actionable information needed for correct invocation, and the length is justified by the multi-step deploy workflow.

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 explains what the generated report contains, how to react to warnings, and what BLOCKING means for next steps. It gives the agent enough operational context to call the tool and handle its results 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 the schema already documents both domain and deploy_id. The description adds no additional meaning about these parameters, so the baseline score of 3 applies.

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

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

States a specific verb 'prüft' and action 'stellt bereit' with the resource 'Vorschau-Adresse', and explicitly notes the live website remains unchanged, distinguishing it from deploy_publish. An agent can immediately tell what this tool does and what it does not do.

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/when-not instructions: always call deploy_preview after uploading files, show link, mention warnings, offer to fix, and only call deploy_publish after explicit user approval. Also defines BLOCKING behavior and the required follow-up 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 destructiveHint=true and openWorldHint=true, but the description adds substantial context beyond them: the automatic pre-publish validation (forms bound to /_tp/form.php with spam protection, single HTML file becomes index.html), the guarantee that BLOCKING means nothing was published, the nature of WARNINGS, and that previous versions remain restorable. This is exactly the kind of operational detail an agent needs before a destructive action.

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 confirmation gate, then the mechanism, then the report semantics and recovery. It is fairly long and dense, but essentially every sentence carries operational value; a slight tightening of the warning examples would help.

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

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

No output schema exists, and the description compensates by explaining the response shape (BLOCKING vs. WARNINGS and what each implies). Combined with the safety gate, side effects and recovery path, an agent has everything needed to invoke 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 description coverage is 100%, so both parameters (domain, deploy_id) are already documented in the schema. 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?

States a specific verb and resource ("Prüft den Deploy und schaltet ihn live") and immediately scopes the effect: the new version replaces the current website. It is clearly distinguishable from siblings like deploy_preview, deploy_put_file and deploy_rollback, which are even named.

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

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

Gives explicit when-to-use and when-not-to-use guidance: only after explicit user confirmation in this conversation ("ja, veröffentlichen"), never automatically after upload and never without asking. It also names the recovery alternative (deploy_rollback) and the follow-up path (deploy_put_file) when BLOCKING occurs.

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 openWorldHint=true, but the description goes further: re-uploading the same path overwrites it, only static file types are accepted, .php/.htaccess are rejected, size is capped at 1 MB per call, and nothing is published. That is exactly the kind of destructive/limit/auth context 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?

It is a dense single block, but every clause carries an actionable constraint and the core purpose is front-loaded. Slight deduction for the wall-of-rules formatting that makes scanning harder, though nothing is truly 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?

No output schema exists, and none is needed: the description explains that loading only stages the file and that deploy_publish finalizes, covering the 'what happens next' an agent needs for a write tool with a 5-param 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 baseline would be 3, but the description adds substantial meaning the schema lacks: path character set and forbidden patterns (umlauts, spaces, hidden files, _tp/), the allowed file-type whitelist, examples of valid paths, and the mapping rule for encoding (utf8 for text formats, base64 for binaries).

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+scope: 'Lädt eine Datei in einen offenen Deploy (aus deploy_begin)'. It ties itself to a specific lifecycle stage and even rules out the sibling path with 'Bilder aus dem Netz stattdessen mit deploy_import_asset laden'. An agent can distinguish it from deploy_import_asset, deploy_git and deploy_publish 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 ('Pro Datei ein Aufruf'), the alternative and its condition (web images via deploy_import_asset rather than hotlinking), and an explicit exclusion about the publish step ('Veröffentlicht NICHTS – das macht erst deploy_publish nach Bestätigung durch den Nutzer'). This is close to a routing rule, not just background.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the danger profile is known. The description adds genuinely new behavioral context: the swap is atomic with no downtime, and the version being replaced is retained rather than lost, which materially changes the agent's risk calculus.

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 dense sentences, front-loaded with the action and mechanism, then the parameter source, then the confirmation precondition. No filler, though the parameter-source sentence is the weakest and partly 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?

No output schema exists, but the description covers what an agent needs for a destructive mutation: what changes, that it is atomic and downtime-free, that the old version survives, and that user confirmation is required. The only gap is the unresolved deploy_list vs deploy_begin conflict.

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 and the baseline is 3. The description adds a source for deploy_id, but it names deploy_list while the schema says deploy_id comes from deploy_begin (26 characters) – a discrepancy that is more likely to confuse than help.

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 eine früher veröffentlichte Version ... wieder live') and adds the mechanism (atomarer Tausch, ohne Ausfall). An agent can distinguish this from deploy_publish/deploy_preview/deploy_begin without opening any schema, since it is explicitly a revert of an already-published version.

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

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

Gives a clear precondition chain: clarify with the user which version is meant, obtain confirmation, then use a deploy_id from deploy_list. It does not name a sibling alternative (e.g. deploy_publish) or state when not to use it, so it stops short of 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 readOnly/openWorld/non-destructive; the description adds substantial behavior beyond them: the log is read at query time, only the last 48 hours are reported, a no-hit result means 'nothing in this window' rather than 'never an error', and an unreadable log is explicitly reported as an open (not excluded) PHP error. This is exactly the interpretive 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?

Front-loaded with purpose and usage scenario, then dense edge-case semantics. It is long (multiple sentences) but nearly every sentence earns its place by clarifying result interpretation; a slightly tighter phrasing of the log-window caveats could still trim length.

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

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

For a diagnostic aggregator with no output schema, the description covers what is aggregated, the live vs. report sources, and the crucial interpretation caveats (48h window, unreadable log, footer note about older errors). 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 description coverage is 100% and there is a single 'domain' parameter, so the schema already carries the semantics. The description adds no format/syntax detail for the parameter beyond what the schema provides, so the baseline 3 applies.

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

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

The description states a specific verb+resource ('aggregiert alle relevanten Signale einer Domain ... zu EINER priorisierten Hauptdiagnose') and immediately delimits itself from the many single-signal siblings by naming search_domain_error_log as the tool for other log queries. An agent can tell what this tool is and what it is not 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?

It gives an explicit trigger scenario ('meine Seite ist kaputt/langsam, was ist los?') and explicitly contrasts the approach with calling several individual tools. It also routes a specific alternative case (warnings/notices or custom patterns) to search_domain_error_log.

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

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

Annotations already declare write (readOnlyHint=false), non-destructive, and open-world. The description adds a lot beyond that: reversibility, single-setting scope, a real TLS handshake pre-check with distinct rejection reasons, the force bypass, and post-write readback semantics with a fallback message when readback fails. On its own merits this is rich (5-level), but the safety profile is already carried by annotations, so the marginal value is good rather than exceptional.

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 remediation intent, and every clause carries real operational information (check conditions, rejection reasons, force, readback). It is a dense single block rather than a structured list, which slightly hurts scanability, but there is little waste.

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

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

With no output schema, the description compensates by explaining what the response reports, including the subtle readback-failure case where the returned state is desired rather than measured. For a mutation tool with a non-trivial pre-check, nothing an agent needs 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 all three parameters (domain, enabled, force) are fully documented in the schema, including force's warning about certificate warnings for visitors. The description adds only marginal nuance about force's typical timing, so baseline 3 applies.

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

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

States a specific verb (aktiviert/deaktiviert) and resource (die automatische HTTP→HTTPS-Weiterleitung für eine Domain) and explicitly distinguishes itself from the diagnostic siblings by noting it fixes the 'kein HTTPS-Redirect' finding from diagnose_website/get_website_report rather than only displaying it.

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 (fix the reported HTTPS-redirect finding), prerequisites (use create_ssl_certificate first when no valid cert), an escape hatch (force=true deliberately bypasses the check, e.g. when the cert is issued right afterwards), and an exclusion (disabling is never checked).

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 well beyond that by disclosing that the reported value is shared across all domains on the server, that a missing/unreadable value is reported as an explicit measurement failure rather than proof that no backup exists, and that the data comes from a turbocheck report refreshed once daily (timestamp in the response). Only the response shape/pagination is left unstated.

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 scope are front-loaded, and every sentence carries distinct information (scope warning, sibling routing, failure semantics, data freshness). It is on the dense side at five sentences, but none is filler and each removes a plausible agent error.

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

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

With no output schema, the description takes on the burden of describing returns and does so (date, status, age of the last backup), plus it explains the shared-per-server nature of the value and the failure case. 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 description coverage is 100% for the single 'domain' parameter, so the schema already documents it fully. The description adds no syntax, format, or default guidance for the parameter 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 verb and resource (retrieves the server's nightly full-backup status: date, status, age) and immediately pins the scope by declaring it is NOT a domain-specific backup, since the value is identical for every domain on the same server. It explicitly names the sibling tools it is not (get_wordpress_backups, create_wordpress_backup), 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?

Gives an explicit alternative and the selecting condition: for backing up or restoring a single WordPress site, get_wordpress_backups / create_wordpress_backup are the right tools, not this one. It also states the inverse usage case (server-wide backup state covering this domain), 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?

Beyond the readOnlyHint/non-destructive annotations, the description explains what 'ungeprüft' means and what the agent should do about it, and states an operational rule no annotation carries: a job still waiting after 3 hours is considered aborted and must be restarted. That is exactly the kind of domain behavior the structured fields 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 what is returned, then input, then usage rule, then two edge-case definitions. Every sentence carries information, though the status list and the 'ungeprüft' explanation occupy similar ground and could be slightly tighter.

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 explain return content — and it does, listing per-site states plus a summary. It also covers failure/timeout interpretation, which an agent needs to act on 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?

Only one parameter and schema description coverage is 100% — the schema already documents the 32-character hex format. The description adds the provenance of the value (the batch_id from start_bulk_wordpress_update), which is modest but useful linkage, without adding any new constraints.

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

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

Names a specific verb and resource ('shows the progress of a bulk job per site') and immediately enumerates the status vocabulary, so an agent knows exactly what comes back. It also implicitly separates this read tool from start_bulk_wordpress_update, which it names as the source of the input.

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 when-to-use and when-not-to-use: 'nur abfragen, wenn der Kunde den Fortschritt wissen will — nicht von sich aus nach dem Start wiederholt nachfragen.' This directly prevents the most likely misuse (polling loop) and pairs the tool with the sibling that produces the batch_id.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), so the description isn't obligated to restate that. It instead adds non-obvious behavioural context: the values come from a once-daily turbocheck report, reflect the last collection period rather than the query moment, and a recent throttle may only surface on the next run — exactly the kind of freshness limitation an agent cannot infer 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?

Two sentences, front-loaded with what is retrieved before the caveat. The parenthetical metric list is slightly dense but every clause carries information — nothing is padding.

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

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

For a single-parameter read-only tool this covers purpose, metric scope and the major staleness pitfall. With no output schema present, a brief hint at the shape of the returned counters (limits vs. current usage) would make it fully self-sufficient, but the gap is minor.

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

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

Only one parameter (domain) and schema description coverage is 100%, with the schema already providing an example value. The description adds no format, validation or scoping detail beyond the schema, so baseline 3 applies.

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

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

Names a specific verb+resource: retrieving CloudLinux/LVE resource limits for a domain, and enumerates the monitored dimensions (CPU, memory, processes, I/O). That is enough to separate it from generic siblings like get_webspace_usage or get_performance_score, though it never explicitly names the neighbouring tool it could be confused with.

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

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

Usage is only implied — an agent infers 'use this to inspect a domain's LVE limits'. There is no explicit when-to-use/when-not or named alternative such as get_webspace_usage, but the daily-report caveat does tell the agent when the data is and isn't appropriate (not for live/diagnostic queries).

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 this read-only and non-destructive, and the description adds substantial non-obvious behavior: identifier reuse after deletion, how a disabled task manifests in a row, and how an unavailable list is signaled. It even warns against asserting 'no cronjobs' when retrieval failed, which directly guards against a common hallucination.

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 stacked with operational caveats (identifier instability, disabled-task reporting, retrieval failure). Every sentence carries actionable information, though it is on the denser side 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?

With no output schema, the description compensates by describing the row format (leading identifier), the disabled marker, and the failure response. An agent has enough to call it and interpret the result without guessing.

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) at 100% schema description coverage, so the schema already documents it; the description only implies the domain scoping. Baseline 3 is appropriate since there is nothing extra to add.

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 Plesk's 'Geplante Aufgaben' concept, which separates it from generic list tools. It also names the sibling relationship by explaining the identifier is exactly what delete_cronjob expects.

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

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

Gives a clear precondition for the downstream delete flow: fetch fresh and never reuse an identifier from an earlier response. It does not explicitly contrast with create_cronjob or any alternative list source, so it falls short of full when/when-not coverage.

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 readOnly/destructive/openWorld profile, and the description adds genuinely new behavioral context: names are fetched live from Plesk while sizes come from the last turbocheck report and are absent for newly created databases. This data-source and freshness disclosure is valuable 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?

Two compact sentences with the main action front-loaded and the freshness caveat second. No filler, though the parenthetical could be tightened 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 single-parameter read tool with no output schema and full annotation coverage, the description supplies what an agent needs: the data source for each field and the caveat that sizes may be missing. The return shape (names plus sizes) is implied but not itemized, which is the only 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 exists and schema description coverage is 100%, so the schema already documents 'domain' with an example. The description refers to 'einer Domain' but adds no format or constraint detail beyond the schema; baseline 3 applies.

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

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

States a specific verb and resource ('Liste der Datenbanken einer Domain ... abrufen') and makes the scope explicit (one domain), so an agent can distinguish it from create_database/delete_database. It does not name a sibling alternative outright, but the parenthetical reference to create_database clarifies its role.

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 note that names are always live 'auch direkt nach create_database' hints at using this to verify state after a create. There is no explicit when-to-use/when-not guidance or named alternative for listing databases, leaving the agent to infer the trigger.

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, destructiveHint=false, and openWorldHint=false, yet the description adds substantial operational context beyond them: live retrieval from Plesk, a warning when the zone is not authoritative, unstable record IDs, the meaning of 'herkunft', handling of 'opt' fields, entries that cannot be edited, and the informational-only zone TTL. This is exactly the extra behavioral detail that annotations cannot 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?

The description is front-loaded with the core purpose and a critical warning, and every major sentence adds actionable context (ID instability, herkunft semantics, 'opt' mapping, TTL caveat). It is long but dense with relevant detail rather than filler; structure could be improved with paragraph breaks, but it remains readable and purposeful.

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 explain return content, and it does: each row begins with the record identifier, includes 'herkunft', exposes readable SRV/CAA fields with 'opt', and ends with the zone TTL when readable. It also covers the important edge cases (non-authoritative zone, uneditable entries) so an agent can 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?

There is only one parameter (domain), and schema description coverage is 100%, so the schema already documents its meaning with an example. The description adds no additional format, normalization, or validation guidance for the domain parameter beyond what the schema provides. Baseline 3 applies.

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

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

The first sentence states a specific verb and resource ('DNS-Zone-Records einer Domain live von Plesk abrufen') and clearly distinguishes this tool from the mutation siblings (delete_dns_record, add_dns_record, update_dns_record) that it references for IDs and editing. An agent can identify the tool's role without opening the schema.

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

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

The description gives clear context for when results are authoritative (nameservers at turbopress) and when they are not, plus a directive to re-fetch IDs immediately before delete/update. It references the editing siblings as alternatives for changes, though it does not explicitly say 'use this tool to inspect before editing' in a single sentence. Strong guidance but slightly implicit in places.

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 zeigen bereits readOnlyHint=true und destructiveHint=false; die Beschreibung ergänzt wichtige Verhaltensdetails zur Datenfrische, zum Zeitstempel in der Antwort und zur möglichen Verzögerung neu gesetzter Records. Zusätzlich wird die Einschränkung der Live-Alternative auf turbopress-Nameserver transparent gemacht.

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 Zweck steht voran, danach folgen Aktualitätshinweis und Alternative. Die Beschreibung ist dicht, aber ohne überflüssige Sätze und gut auf die Entscheidung des Agents ausgerichtet.

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 mit einem Parameter, klaren Read-only-Annotationen und ohne Output-Schema ist die Beschreibung ausreichend vollständig. Sie deckt Zweck, Datenquelle, Aktualitätsgrenze und Alternative ab.

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?

Der einzige Parameter domain ist im Schema bereits vollständig beschrieben, inklusive Beispiel. Die Tool-Beschreibung fügt dazu keine wesentliche zusätzliche Syntax oder Formatinformation hinzu, daher ist die Baseline von 3 angemessen.

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 Ressourcenobjekt: DNS-Mail-Sicherheitseinstellungen einer Domain abrufen, mit SPF/DKIM/DMARC/MX. Sie grenzt das Tool außerdem explizit von get_dns_records 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?

Sie erklärt klar, wann dieses Tool passt: Daten stammen aus dem täglich aktualisierten turbocheck-Bericht, neue Records können erst nach dem nächsten Lauf erscheinen. Für sofort aktuelle Zonendaten wird ausdrücklich get_dns_records als Alternative genannt, inklusive der Bedingung, dass die Nameserver bei turbopress liegen müssen.

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 still adds substantial behavioral context beyond that — entries carry a web-only vs. also-EMAIL scope flag (email is the default and is lost on removal), staging copies are included but marked and are NOT removable by remove_domain_redirect, and an empty result is a valid answer while a failed fetch is reported as a measurement failure that must never be read as 'no redirects'. That failure-semantics warning is exactly the kind of non-obvious behavior 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 purpose and the read/write relationship, then the parameter meaning, then return content, then the failure and staging caveats — a logical progression. It is dense and slightly repetitive (the staging point is restated across two sentences), but given the traps it must convey, most sentences earn their place.

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

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

There is no output schema, and the description compensates by describing what each entry contains (identifier, what depends on it, web vs. email scope, staging marking) plus the empty-result vs. failure distinction. For a single-parameter read tool with annotations covering safety, 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% and the schema already defines the single 'domain' parameter as the redirect target, so the baseline is 3. The description goes further by spelling out the direction with a worked example and stressing 'MIT dem Hosting', which resolves a genuine ambiguity for the caller rather than merely restating the schema.

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

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

The description states a specific verb+resource (listing domain redirects pointing at a given domain) and immediately disambiguates the direction — it lists domains that redirect TO the given one, not the other way round. It also names its siblings (redirect_domain, remove_domain_redirect) and positions itself relative to them, so an agent can distinguish it without opening another 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 read counterpart to redirect_domain and the prerequisite for remove_domain_redirect, and tells the caller exactly which value to pass (the redirect TARGET, with a concrete 'alte-domain.de → neue-domain.de' example). It also warns not to guess when staging vs. customer redirects are ambiguous — clear when-to-use and when-to-be-cautious 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?

Beyond the readOnlyHint and destructiveHint annotations, the description explains important data quirks: missing expiry dates can mean external registration, trial subdomains are never registered, and hosted domains may be edited regardless of registrar. It also clarifies that the response includes tariff type and WordPress status, and that everything other than email/DNS is read-only, which meaningfully supplements 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 core purpose and avoids filler, but it is a dense paragraph that includes considerable downstream tool guidance. That information is useful, though the length is notable for a zero-parameter tool.

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

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

With no output schema, the description carries the burden of explaining return data, and it does so thoroughly: registered versus hosted domains, expiry-date interpretation, trial subdomains, tariff type, and WordPress status. It also covers follow-up constraints, making the definition complete enough for an agent 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?

The tool has zero parameters, so the baseline score is 4. There are no parameter semantics to clarify, and the schema's empty properties object is consistent with the description.

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

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

The description states a specific verb and resource: retrieve the customer's complete domain inventory, including both turbopress-registered and externally registered but hosted domains. It is clear what the tool returns, but it does not explicitly distinguish get_domains from the sibling get_wordpress_sites tool.

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

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

The description gives clear context for using the returned domain data, including which tools apply to WordPress domains, AI Launch static sites, email accounts, and DNS records. It does not explicitly state when to prefer get_domains over a WordPress-specific sibling listing, but no direct alternative for a complete domain inventory is named.

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

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

Goes well beyond the readOnly/non-destructive annotations by disclosing that data is fetched live from Plesk, that a blank forwarding field means 'none configured' rather than missing data, that forwarding targets may point to foreign domains and are returned verbatim, and that autoreply status has specific states ('an mit Enddatum, aus, abgelaufen', 'Stand nicht lesbar'). It also notes the note text is not returned and that the autoreply field is absent for accounts beyond 30 mailboxes.

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 purpose and the most important edge-case semantics. It is fairly long, but nearly every sentence carries useful behavioral information (forwarding semantics, external targets, autoreply states, >30 mailbox limit). Slight redundancy around 'dasselbe gilt für Aliase' keeps it from a 5.

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

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

For a single-parameter read tool with no output schema, the description is unusually complete: it enumerates returned fields, defines null/blank semantics, discloses data-source freshness, and documents a size-based limitation. The annotations already cover safety, and the description fills the remaining behavioral and interpretation gaps.

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

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

There is only one parameter and schema description coverage is 100%, so the schema already documents 'domain' with an example. The description refers to 'einer Domain' but adds no syntax, format, or constraint beyond what the schema provides. 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 ('auflisten') and resource ('E-Mail-Konten einer Domain') and lists the exact fields returned (Adresse, Speicherkontingent, Weiterleitung, Aliase, Abwesenheitsnotiz). It explicitly distinguishes itself from sibling mutation tools set_email_forwarding, set_email_alias, and set_email_autoreply, so an agent can route correctly.

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?

Clearly frames itself as the reading counterpart to set_email_forwarding and set_email_alias, implying when to use it. It also explains a key interpretation rule (missing forwarding means 'none configured', not missing data) and notes the >30 mailbox limitation. It stops short of explicit 'use this instead of X when Y' phrasing, but the context is strong.

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

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

Beyond the annotations (which already declare readOnly and non-destructive), the description adds real behavioral value: it guarantees no password is ever returned, discloses a conditional warning when the domain's mail is hosted elsewhere, and states a security rule not to request passwords. No return-format or pagination detail, but for a read tool this is strong added context.

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

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

The use case is front-loaded and the return contents are packed efficiently. Minor redundancy: the 'never a password' prohibition is stated twice (once informatively, once as an instruction), costing a bit of economy.

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

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

With no output schema, the description carries the burden of explaining returns and does so well by enumerating server settings, the certificate note and the conditional warning. The only gap is that it does not clarify what the response looks like when settings are unavailable.

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 (domain, email) are already fully documented in the schema. The phrase 'für eine Adresse der Domain' hints that email must belong to domain, but adds no format or validation guidance beyond the schema. Baseline 3 applies.

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

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

States a concrete verb (delivers) and enumerates the exact resources returned: IMAP/SMTP server settings, ports, encryption, username, certificate note and a provider-mismatch warning. This distinguishes it in substance from get_email_accounts or get_webmail_url, though it never names a sibling 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?

Opens with an explicit triggering question ('Wie richte ich mein Postfach im iPhone/Outlook ein?') and routes the iPhone/Mac profile case to the panel instead (Reiter E-Mail → Auf Gerät einrichten). Clear when-to-use context, but no named tool alternatives or exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds substantial behavior beyond that: counting is limited to outgoing mail, data is refreshed only once per day, the response carries a timestamp, and an unreadable mail log at report time yields an explicit statement with no numbers rather than a misleading zero. That last point directly prevents a common misreading of the result.

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 purpose is front-loaded in the first clause, and the remaining sentences each carry a distinct caveat (outgoing-only counting, report staleness, failure mode, queue independence). It is somewhat dense and long for a one-parameter read tool, 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?

With no output schema, the description carries the response burden and does so: it names the metrics (sent/bounced/deferred today), notes the timestamp field, and explains the failure response explicitly. Combined with the single documented parameter, an agent has everything needed to call it and interpret 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?

There is a single parameter and schema description coverage is 100%, so the schema already documents 'domain' with an example. The description adds no further syntax, format, or constraint detail for the parameter, so the baseline 3 applies.

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

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

States a specific verb and resource ('E-Mail-Versandstatus einer Domain abrufen') and immediately narrows scope to sent/bounced/deferred today. The clarification that only outgoing mail for that domain is counted distinguishes it from sibling listing tools like get_email_accounts or get_spam_filter without the agent needing to open another 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 clear context for when the data is meaningful: it comes from the once-daily turbocheck report, so events since the last run are absent, and stuck mails come from a separate queue. It does not explicitly name alternative tools (e.g. get_email_accounts) or state when not to use this one, so it stops short of full 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 safety is covered. The description goes beyond that: it says the data is live from Plesk, notes that the main account's password cannot be reset by the chat and is also the SSH password, and clarifies that an empty additional-accounts list is not an error. This is meaningful operational context not present in 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?

The description is front-loaded with the core action, but it is fairly long for a single-parameter read tool and packs three distinct ideas (account types, password reset caveat, expected-empty state) into one dense paragraph. It is informative but not optimally 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?

For a simple read with one fully documented parameter and read-only annotations, the description covers the important behavioral nuances: what is returned, what can't be done with it, and what constitutes a normal result. Without an output schema, it sufficiently signals the shape of the return data (main account + additional accounts with start 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 coverage is 100% and the single 'domain' parameter is fully documented in the schema. The description implies the domain scoping but adds no format, syntax, or semantic detail beyond what the schema provides. 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?

Specific verb (auflisten) + resource (FTP-Zugänge einer Domain) with a clear scope split: the subscription's main account versus additionally created accounts with start directory. It is distinguishable from siblings like get_email_accounts or get_databases.

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

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

It explicitly names reset_ftp_password as the downstream consumer and explains why the list is needed (customers don't remember their FTP usernames). It also sets an expectation that 'no additional accounts' is a normal state, which prevents wasted follow-up. No explicit when-not-to-use is given, but the routing to a sibling is clear.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description usefully adds what the data represents (public catalog, not tied to the account's own contract) and what fields come back (price, short description), going slightly 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?

A single compact sentence that front-loads the action and resource before the clarifying parenthetical. Every clause carries information; nothing is redundant.

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

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

For a parameterless read-only listing tool with no output schema, the description supplies enough: what is listed and which fields are included. It could be slightly stronger by noting there is no input or filtering, but 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?

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to disambiguate, and it correctly implies no filtering inputs are required.

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

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

The description gives a specific verb (Listet) and resource (Hosting-Pakete) and even scopes the payload (Preis und Kurzbeschreibung). The parenthetical clarifying that it is the public product catalog, independent of the user's own contract, cleanly separates it from related siblings like prepare_hosting_order.

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

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

The phrase 'öffentlicher Produktkatalog, unabhängig vom eigenen Vertrag' implies the usage context (browsing offerings before ordering), but there is no explicit when-to-use or when-not-to-use statement and no named alternative such as prepare_hosting_order. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, but the description adds substantial behaviour beyond them: server-side validation of the domain against this customer's contracts with rejection of foreign domains before anything is read, the duplicated-response contradiction handling (report contradictory, deliberately return no value, never guess), and the empty-list vs not-read distinction that must not be misreported to the customer.

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?

Longer than typical, but front-loaded with purpose and the set_hotlink_protection relationship before the edge cases. The two numbered caveats are dense yet each carries actionable output-interpretation information; a small amount of phrasing could be tightened, but nothing 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?

With no output schema in play, the description carries the full burden and does so: it describes the returned fields, the contradiction case where no value is given, and the crucial distinction between an empty list and an unread field. An agent has everything needed to call it and to relay 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?

With 100% schema coverage on a single parameter, the baseline is 3, but the description adds real constraint semantics: the domain is validated server-side against exactly this customer's contracts and a foreign domain is rejected before any read occurs. That meaning is not derivable from the schema's bare 'Die Domain, z. B. example.de' example.

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 den Hotlink-Schutz EINER Domain') and enumerates exactly what is returned: on/off state, protected file extensions, and exempt foreign domains. It explicitly positions itself against the sibling set_hotlink_protection as its read counterpart, so an agent can distinguish the two 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 explicit when-to-use guidance ('Vor jedem Setzen sinnvoll'), names the alternative (set_hotlink_protection), and explains why: a supplied list replaces the existing one, so this read reveals what must be sent along to avoid data loss. It also states this is 'der einzige Weg, eine Änderung daran nachzuprüfen', covering the verification use case.

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), yet the description adds substantial behavioral context the agent could not otherwise know: the list is deliberately truncated (max 100 open, 25 newest completed, older completed ones absent), totals/counts/sums in the response cover the entire inventory, and drafts are unissued and not payable.

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 most sentences carry distinct, necessary information about truncation and aggregation. It is slightly verbose and repeats the 'entire inventory' caveat twice, which is the only real 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 fully carries the burden of explaining return values: totals, split counts and sums, status semantics, and the ID fallback. Nothing an agent needs to call and interpret this zero-parameter read 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?

The tool takes zero parameters, so the baseline is 4. The description instead clarifies response semantics (separate counts and sums for open vs. paid, document-ID fallback for invoices without a number), which compensates for the absent output schema.

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

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

States a specific verb and resource ('Rechnungen des Kunden abrufen') and immediately delimits scope: all open invoices plus the 25 newest completed ones. No sibling tool in the list covers invoices, so an agent can place it unambiguously.

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 guidance on how to answer amount questions ('ausschließlich aus diesen Summen beantworten und niemals die aufgelisteten Zeilen aufaddieren') and explains why some statuses appear only as counts. It does not, however, name a competing tool or state explicit when-not-to-use conditions, though none exist among the siblings.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so safety is covered. The description adds genuinely new behavioral context: data is read directly on the installation and is therefore accurate immediately after an update, and the slug field may be null with a stated cause and consequence. This goes well beyond the annotation surface.

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 every clause carries information, but the null-slug explanation and the repeated emphasis on slug-vs-display-name make it longer than strictly necessary. Dense rather than wasteful, so a 4.

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 full return-value burden and does so: each entry has a display name, a slug in parentheses that may be null, and the reason and downstream consequence of that null. Nothing needed to call or interpret the 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 description coverage is 100% with a single documented 'domain' parameter, so the schema already carries the parameter semantics. The description adds nothing about the domain argument itself. 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: lists WordPress plugins and themes that have an available update, including the current→available version transition. It explicitly differentiates itself from the sibling get_wordpress_status by calling that tool's output only a bare counter. An agent can distinguish it from get_wordpress_sites and get_wordpress_status 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: use this instead of get_wordpress_status when the concrete affected plugins/themes matter. It also gives downstream usage rules — the slug goes to update_wordpress_item/set_wordpress_plugin_state, never the display name — and states a when-not condition (entries whose slug is null cannot be fed to those tools). When-to-use, alternatives, and exclusions 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 cover the safety profile (readOnlyHint, openWorldHint, destructiveHint=false), so the bar is lower. The description still adds real value beyond them: it explains that an empty list has three distinct meanings ('monitored, nothing open', 'domain not monitored at all', 'not determinable'), which prevents a false all-clear. It does not mention auth, rate limits, or pagination, 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 core question and resource, then sibling routing, then the empty-list caveat — a logical progression with no filler sentences. Dense but every sentence earns its place; the illustrative examples cost a little length but add clarity.

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

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

For a read-only, single-parameter tool with no output schema, the description supplies exactly the missing context: what the returned events represent and how to interpret an empty result. Nothing an agent needs to call and interpret this tool correctly is absent.

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 carries the parameter meaning. The description adds nothing about the domain argument beyond what the schema states, 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 resource (the OPEN alerts of the running turbometrics monitoring) and verb-like framing ('has monitoring reported anything?'), with concrete examples (TTFB over threshold, visual regression, failed scan). It explicitly distinguishes itself from the two sibling tools get_performance_findings and get_performance_score by stating that it returns events over time, not measurements or snapshots.

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?

Routes the agent explicitly: raw measurement numbers live in get_performance_findings, the cached aggregate in get_performance_score. The opening question frames the use case (checking whether monitoring has flagged anything recently) so the agent knows when to reach for this tool versus 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 cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), and the description adds meaningful behavioral context beyond them: the scan list is read at query time, and it disambiguates three response states — missing activation, measurement failure, and real data — stressing that a failure is neither 'not activated' nor an all-clear. No contradiction with 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?

It opens with the user-facing question it answers and front-loads the core behavior before the sibling routing and edge cases. It is dense and slightly heavy on emphasis ('ZULETZT TATSÄCHLICH GELAUFENEN', 'GENAU DAS'), but each sentence carries a distinct behavioral nuance 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?

With no output schema, the description carries the burden of explaining what comes back (individual findings, recommendations, overall scan value) and does so, plus it covers the ambiguous outcome states an agent must interpret. Nothing needed to call and interpret the 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 only one parameter (domain) and schema description coverage is 100%, so the schema already carries the semantics. The description adds no domain format or syntax detail beyond the schema's own example 'example.com', making this the baseline case where structured data does the work.

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: the individual findings of the last actually-run turbometrics scan, with per-item recommendations (images, JS load, caching, server response time) plus that scan's overall score. It is unmistakably distinct from 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?

It explicitly names the alternatives and the condition for each: a run triggered via start_performance_scan shows up here first, the cached nightly value lives in get_performance_score, and open warnings belong to get_performance_alerts. It even explains why the two numbers can diverge, 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 already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so safety is covered. The description adds substantial context beyond that: the data-source restriction (daily turbocheck report, not turbometrics), the report-date vs scan-timestamp staleness gap of about a day, the write-to-read latency for triggered scans, and the meaning of a missing value (not a speed statement, not proof of never being scanned).

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 is my value?' and every sentence carries distinct semantics (source, staleness, alternative, missing-value caveat). It is somewhat long and dense for a one-parameter tool, with heavy capitalization, but no sentence is pure filler.

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

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

With no output schema, the description carries the full burden and does so: it names the returned metric areas, the two timestamps returned, the staleness relationship, and how a missing measurement is reported. An 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% and there is a single required 'domain' parameter already well documented in the schema. The description explains the returned areas but adds no syntax or format detail for the domain input beyond what the schema provides, so the baseline 3 is correct.

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

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

States a specific verb+resource: it returns ONE number per area (Overall, Speed, Images, Caching, WordPress, Technik, TTFB) and explicitly scopes the source to the daily turbocheck report. It distinguishes itself from siblings get_performance_findings and start_performance_scan by name, so an agent can route 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?

Explicit when-to-use guidance: describes when a score is available (only after the nightly run), when it is NOT the right choice (a run just triggered via start_performance_scan will not appear here), and names the alternative (get_performance_findings) with the condition that selects it. Nothing is left to inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered; the description still adds real value: values are fetched live from the hosting system, returned values are exactly the accepted inputs of switch_php_version, unreadable values are not 'none', and limits derive from the tariff. That is behavioral context an agent cannot get from the annotations or schema.

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

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

The core purpose and the sibling routing come first, then the fallback warning and field semantics. It is somewhat long at seven sentences, and the closing note on upload_max_filesize vs post_max_size sits at the tail where it is easy to skim past, but no sentence is pure filler.

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

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

With no output schema, the description carries the burden of explaining returns and does so: current version, selectable versions, tariff-derived limits, effective upload limit, and how to interpret an unreadable value. It stops short of describing the actual response shape or whether selectable versions are ordered, a minor remaining gap for a single-parameter read tool.

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

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

Schema coverage is 100% with one required 'domain' parameter, so the baseline is 3. The description only reinforces the scoping constraint ('EINE Domain', i.e. one domain per call, not a batch) and adds no format or validation detail beyond the schema's example.

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 für EINE Domain die eingestellte PHP-Version und die Versionen, die auf ihrem Server wählbar sind') and immediately names the sibling 'switch_php_version' as its write counterpart, plus the user question it answers. An agent can distinguish it from all 100+ siblings 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 the tool as the read counterpart to switch_php_version and the correct answer path for 'Welche PHP-Versionen gibt es?'. It also gives an exclusion-style rule: if a value is reported unreadable, do not guess and do not trigger a switch to probe — which prevents a concrete misuse of the sibling.

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

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

Even though annotations already declare readOnly/non-destructive, the description adds genuinely new behavioral context: the data comes from a once-daily turbocheck report, the timestamp is in the response, and "keine Funde" only means the last report found nothing rather than that a scan is running now. That staleness disclosure is exactly the kind of trait 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-loads the purpose, then the provenance/staleness caveat, then the alternative. Each sentence carries a distinct, decision-relevant fact — the parentheses compact the coverage list instead of padding it, and nothing is redundant.

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

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

With no output schema, the description compensates by naming the returned finding categories and noting the response carries a timestamp. Combined with the read-only annotations and the single fully-documented parameter, an agent has everything needed to call this correctly and to interpret a clean 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 the single "domain" parameter is already documented in the schema ("Die Domain, z. B. example.com"). The description only refers to "einer Domain" generically and adds no format, validation, or scope detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ("Sicherheitsstatus einer Domain abrufen") and enumerates exactly what it covers — malware findings, vulnerabilities, publicly reachable files. It names a sibling (get_wordpress_hardening) as the tool for a related-but-different concern, so an agent can separate the two 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 a clear routing rule: for the hardening state of WordPress itself, use get_wordpress_hardening instead. It also frames when the result should be trusted via the daily-report caveat. It stops short of positioning this against the other security-adjacent siblings (get_dns_security, scan_wordpress_vulnerabilities, get_ssl_status), so coverage is good but not exhaustive.

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 safe-read profile (readOnlyHint, destructiveHint=false, openWorldHint=false), yet the description adds substantial behavior beyond them: server-side validation rejects a guessed or foreign address before anything is read, the spam-action value is emitted in a different form than it is set, and a 'not read' field must not be confused with 'empty' or 'off'. These are non-obvious output behaviors an agent would not infer from annotations.

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

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

Well front-loaded: purpose, then sibling relationship, then parameters, then the two interpretation caveats. The caveats are long but earn their place by preventing misreporting, though the parameter-restriction sentence partly duplicates the schema and adds a little length.

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

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

With no output schema, the description carries the full burden of return-value semantics and does so: it explains the translated spam-action value, the explicit 'undecipherable' value, and the 'not read' ambiguity so the agent can relay results correctly. Complete for a two-parameter read tool.

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

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

Schema coverage is 100% and both parameters are already documented (email accepts full address or local part, must belong to this domain). The description largely restates the domain/email requirement and adds the server-side ownership check, but contributes little 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 and resource (reads the spam-filter setting of ONE mailbox, live) and enumerates exactly what is returned: on/off, spam threshold score, spam action, subject tagging, and block/allow lists. It explicitly names and distinguishes itself from set_spam_filter as its read counterpart, so an agent can separate the two 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 sibling alternative (set_spam_filter) and gives a concrete use context ('the only way to verify a change to it'), plus the prerequisite that domain/email must belong to this hosting package. Clear when-to-use, though it offers no explicit when-not-to-use case.

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, openWorldHint and destructiveHint, so the safety profile is covered. The description adds real value beyond that by disclosing that this is a live TLS handshake with no caching and, notably, that auto-renew configuration cannot be determined – a useful negative-capability statement.