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

Beyond the annotations, the description discloses the single most consequential trait: 'nothing on the site changes until then' because a person must approve in Royally — an agent that assumes immediate creation would badly mis-sequence follow-up calls. It also covers content sanitization (safe-HTML allow-list shared with content), lossless backslash handling, and the target site, all of which are non-obvious behaviors.

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 operative facts — what it makes, how to schedule it, and the approval gate — are front-loaded and each clause carries information. The parenthetical '(site: demo.royalplugins.com)' duplicates the site_id enum in the schema and the excerpt sentence largely echoes the schema, which are the only small wastes.

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 10-parameter write tool with no output schema and a 60% coverage schema, the description covers the high-risk gaps: approval gating, scheduling semantics, HTML sanitization, and content escaping. What it omits is what the call returns before approval (pending ID? receipt?) and how to check the approval outcome, which would let an agent close the loop after invoking it.

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 60%, and most of what the description says about date/status and excerpt HTML is already restated verbatim in the schema's own parameter descriptions, so little new meaning is added there. The one genuinely additive point is that backslashes in content arrive stored as sent (relevant to content, which has no schema description), but categories, title, and the status enum values remain unexplained in both places.

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 clause states a specific verb and resource ('Create new post') and immediately extends scope with '(supports custom post types)', so an agent knows this is creation, not mutation of an existing item. It stops short of naming siblings such as wp_update_post or wp_create_page, so the create-vs-update boundary must be inferred from the tool name rather than the text.

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 usage recipe — 'Combine status="future" with date to schedule' — which is exactly the kind of conditional guidance an agent needs, and 'supports custom post types' points to the post_type path. There is no explicit when-not-to-use or named alternative (e.g. use wp_create_page for pages), so the routing is implied rather than spelled out.

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