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

Goes far beyond the readOnlyHint=true annotation: discloses that scans are cached up to 2 minutes with a cache-bypass after wp_tracking_configure, that scanning happens without a browser and without consent so an empty result is a false negative rather than proof of absence, that scan.scanned=false means the homepage was unreachable, and that connector plugin >= 1.2.0 with the Tracking module is required. Naming the concrete error payloads ('wp_timeout', 'wp_unreachable') is exactly the operational detail 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?

Information is front-loaded (what the result keys mean before the caveats, prerequisites, and error handling), and each paragraph carries distinct operational weight. It runs long and repeats the no-consent caveat twice, which costs it the top score, 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?

For a single-parameter read tool this is essentially complete: prerequisites, caching semantics, false-negative caveats, the wp_tracking_configure ordering constraint, and error/retry behavior are all covered, and an output schema exists so return values need no further explanation.

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

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

Schema description coverage is 0%, so the description must carry the single 'workspace' parameter — and it does, stating it is the customer workspace slug and is optional when only one workspace exists. That closes the only documentation gap; there is no further format or constraint to add for a slug parameter.

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

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

The opening rhetorical question plus the enumerated result keys ('config', 'output_active', 'consent_ack', 'scan', 'duplicates') make it unambiguous that this is a read-only status report on which GTM/GA4/Meta tag is actually embedded in the homepage source. It never uses a clean verb+resource phrasing (e.g. 'Liest den Tracking-Status'), and the German-language framing is indirect, but the scope is clear enough to distinguish it from wp_tracking_configure and ga4_report.

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 positions the tool against alternatives: it points to ga4_report to confirm live tracking and repeatedly warns not to recommend or run wp_tracking_configure before the setup is verified in a browser after consent, and it routes retries after 'wp_timeout'/'wp_unreachable'. It does not explain when to prefer this over other WordPress status siblings (wp_bridge_status, wp_site_health), which keeps it from a 5.

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