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

Goes well past the annotations: it discloses that the call is gated on human approval in Royally and that "nothing on the site changes until then," that there is no undo, and that a tag created for a subsequently refused call persists unused. It also flags that content/excerpt are sanitized per the calling user's capability and that unregistered meta keys are dropped (reported as meta_ignored) — exactly the side effects an agent needs before calling a non-idempotent write.

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 body is a near-verbatim recital of a 22-parameter schema that is already fully documented, and the single most consequential fact — the Royally approval gate and absence of undo — is buried at the very end of a long run-on sentence. The text is also cut off mid-word ("`aut… Through Royally"), which breaks the flow of the most important sentence.

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?

A 22-parameter, non-idempotent write with no output schema needs to say what comes back (ID? pending-approval handle? status?), and it never does. Combined with the truncation that severs the approval/undo disclosure from its subject, the definition is not complete enough to tell an agent what a successful call actually yields. (Score raised concerns: purpose and parameters are mostly covered; the return contract is the gap.)

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 100%, so the schema already carries the parameter meaning and the baseline is 3. The description's long parameter enumeration largely restates what the schema says (date/date_gmt mutual exclusion, tag_names creation-on-miss, tax_input taxonomy keys), adding little that isn't already structured — and it is visibly truncated mid-list ("…aut…").

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?

Opens with a specific verb+resource: "Creates a new WordPress post." That cleanly separates it from siblings like wp_create_page and wp_update_post by resource and operation. It never explicitly names a sibling or its boundary condition (post vs. page vs. elementor page builder), so it stops short of a 5.

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?

There is no statement of when to choose this tool over the many overlapping create-post siblings (royal-mcp__wp_create_post, mcp-tools-for-elementor__emcp-tools-create-post, mcp-wordpress-com__wpcom-mcp-content-authoring), nor any precondition/eligibility guidance. The only usage-shaped advice is inline parameter mechanics ("use 'future' with date to schedule"), which is configuration, not tool selection.

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