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, and the description still adds real behavioral context: `edit` context exposes protected fields/meta and needs the edit_post cap, and `meta_keys` exists 'so the key cap cannot hide one', disclosing that an implicit meta-key cap otherwise applies. The closing fragment confirms the server-enforced read-only execution. The truncation leaves the tail of the parameter list and its final caveat incomplete.

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 opening sentence, which is good, but the body is a single dense run-on that walks parameter by parameter and partly restates what the 100%-covered schema already says. The description also ends mid-sentence ('only these taxonomies in `… Through Royally: its server marks it read-only...'), so the structure is visibly broken at the tail.

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

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

For an 11-parameter tool with no output schema, the description covers the return shape (post fields, meta, grouped terms, thumbnail, author, raw_post columns) and nearly every parameter's role. Remaining gaps are the truncated final sentence and unstated precedence when `include` and `exclude` overlap, which an agent would have to infer.

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 earns extra credit by adding cross-tool naming mappings that the schema cannot express ('called `post_id` on some sibling tools', '`post_type` is the same concept as `rest_base` on the CPT tools') and by giving a concrete `exclude` example (["content"] to drop large post_content). It also explains the interaction rules ('Needs meta in include', 'edit context only'), which the schema only states per-field.

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 ('Returns the complete view of a post') and then enumerates exactly what the view contains: post fields, meta, taxonomy terms grouped by taxonomy, featured image, author. It also implicitly separates itself from sibling readers by stating it 'Replaces 4–20 separate calls' and by mapping `id` to `post_id` on sibling tools, so an agent can pick between this and `wp_get_post` 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?

The 'Replaces 4–20 separate calls' framing plus the `include`/`exclude` notes give a clear steer on when this aggregation tool is the right choice over repeated single-purpose reads. The edit-context prerequisite ('requires edit_post cap') is stated. It stops short of explicit exclusions — there is no line saying when to prefer the lighter `wp_get_post` instead.

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