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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description goes further with real behavioral context: content is the stored value including block markup, a hash is provided specifically for the edit round-trip, and the caveat that empty content does not imply a plugin-managed snippet has no code warns the agent against a plausible misreading.

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

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

Three sentences, front-loaded with the return payload and with no filler. The closing caveat is slightly oblique in phrasing but earns its place by preventing a specific misinterpretation; overall it is dense 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 carries the burden of describing returns and does so adequately by naming the main fields and the categories/tags structure. The residual gap is 'basic post fields', which stays vague, but for a simple single-record read with fully documented parameters this is close to sufficient.

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

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

Schema coverage is 100%, so both parameters are already documented, including the warning to call list_sites first and not to pass a URL or WordPress post ID. The description adds no additional parameter-level semantics, so this sits at the baseline for a fully covered two-parameter 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 opens with a specific verb and resource ('Reads a single post by ID') and enumerates exactly what comes back: stored post_content with block markup, content_sha256, basic post fields, and categories/tags with IDs, names and slugs. That level of specificity distinguishes it from siblings like wp_read_block or wp_read_template without the agent needing to open 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 downstream use case by naming wp_update_post edit mode as the consumer of content_sha256, which tells the agent when this tool is the right prerequisite. It also states two exclusions (no custom post metadata, no plugin snippet source), but it stops short of explicitly saying when to prefer wp_read_block or other read siblings over this one.

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