Read or write post meta

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

Annotations already declare destructiveHint=true and openWorldHint=true, so the safety profile is partly covered. The description adds useful context — that it bypasses REST filtering and thus touches hidden keys — but does not say that 'set' overwrites existing values, that 'delete' is irreversible, or what auth is required for write actions.

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 tight sentences with zero filler; the capability scope is front-loaded and the action list is compact. Every clause carries information.

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 5-parameter, destructive, no-output-schema tool, the description covers the action set and the REST-bypass angle but omits return shape and any warning about overwriting or irreversible deletion. Adequate but leaves real 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?

Schema coverage is only 20%, so the description must compensate. It does clarify that 'get' can return all keys or a single key (implying key is optional for get), but 'value' is documented nowhere, and the 'hide_internal' flag is only explained in the schema itself.

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 (read/write) and resource (post meta keys) and enumerates the three actions it supports. It also differentiates itself from generic content/settings tools by noting direct access to keys hidden from REST, though it never names a sibling tool 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?

The phrase 'including keys hidden from REST (SEO plugins, page builders, custom fields)' implies when this tool is the right choice vs. wp_content_get/wp_settings_get, but that routing logic is left to inference. No explicit when-not-to-use or named alternatives are given.

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