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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, but the description adds substantial context: how muted-only sites are classified, how unlicensed sites appear, how not_monitored sites are handled, and provider-specific quirks for UpdraftPlus and Duplicator. These details materially affect interpretation of the returned statuses beyond what annotations provide.

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

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

The purpose is front-loaded and almost every clause carries useful behavioral detail, so it is appropriately sized for a complex status tool. However, the first sentence is very dense with nested parentheticals and long inline lists, making it harder to scan than it could be with clearer sentence breaks.

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 still explains what the response includes: provider, last answer, last successful backup, schedules, cloud_copy states, open alerts, muted_alerts, and statuses such as muted, unlicensed, and not_monitored. That is sufficient for an agent to understand the result without additional structured documentation.

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, site_ids, and the schema description fully covers it with 'Only these sites. Omit for every monitored site.' The description itself does not add further meaning about the parameter beyond the schema, so baseline 3 is appropriate given 100% 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?

The description states a specific resource and scope: backup health for every connected site using SiteVault, UpdraftPlus, or Duplicator. It enumerates the exact data returned, including provider, last answer, schedules, cloud copy status, alerts, muted alerts, unlicensed, and not_monitored. This distinguishes it in practice from single-site backup status siblings by emphasizing fleet-wide status categories and provider-specific behavior.

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

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

It gives a clear use case: report backup health across connected sites, and explicitly says to use recipe__run_backup_monitor to refresh when the last check is old. It does not explicitly compare against other backup-status siblings such as fleet__verify_backup_health or royal-mcp__sv_get_backup_status, so exclusions are absent.

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