wp_get_content

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

With no annotations provided, the description must carry the behavioral burden. It discloses that the result is a lean list (id, title, slug, status, type), explains defaults for post_type, and notes query is an optional search term. However, it does not mention pagination, sorting, permissions, or the exact return format beyond the field list. For a simple listing tool, this is acceptable but not rich.

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 description is extremely concise—two sentences—and front-loads the primary purpose. Every sentence adds value: the first states the action and result fields, the second clarifies parameter defaults. There is zero fluff, and the structure is efficient.

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 lean list tool with no output schema and no annotations, the description covers the core purpose, returned fields, and parameter defaults. It omits details such as pagination, sorting, filtering beyond post_type, and any rate limits or auth requirements. These are not critical for a simple list, but the absence means the description is not fully comprehensive.

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 0%, so the description must compensate. It explains that post_type defaults to 'page' and query is an optional simple search term, adding meaning to two of the three parameters. The 'install' parameter is not described, leaving its meaning (likely the install identifier) to inference. This is partial compensation, not complete.

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 clearly states the verb (List) and resource (posts/pages on an install) and specifies the returned fields (lean: id, title, slug, status, type). It is distinguishable from siblings like wp_find_page (which likely finds a specific page) and wp_extract_page (which extracts content), though it does not explicitly name them. The purpose is specific and unambiguous.

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 description implies the use case (listing content) and gives parameter defaults, but it does not explicitly state when to use this tool versus alternatives such as wp_find_page for finding a specific page or wp_create_content for creating content. There is no mention of when not to use it or exclusions. The guidance is adequate but not explicit.

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