MCP WordPress CrunchTools
Server Quality Checklist
Latest release: v0.5.0
- Disambiguation4/5
Most tools target distinct resources (posts, pages, media, comments, categories, tags, revisions), but there is redundancy: list_posts and search_posts overlap (both support keyword search), and update_comment and moderate_comment both manipulate comment status, creating potential confusion.
Naming Consistency5/5All tools follow a consistent 'wordpress_verb_noun' pattern, with standard verbs like list, get, create, update, delete, search, upload, moderate. Even page-revisions follow the same convention (list_page_revisions). No mixed naming styles or unpredictable variations.
Tool Count2/530 tools is excessive for a WordPress MCP server, exceeding the 'heavy' threshold of 25+. While WordPress has many entities, the set could be consolidated (e.g., merging search_posts into list_posts, reducing revision tools), and the count will likely overwhelm agents with too many options.
Completeness3/5Core content management is well covered: posts, pages, media, comments, and revisions. However, notable gaps exist: no update/delete for categories or tags, no search_pages (only list_pages with search), no get_page_revision (only list_page_revisions), and no user management. This leaves some workflows incomplete, but major operations are present.
Average 3.7/5 across 30 of 30 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under AGPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It implies mutation but does not explain partial update semantics (e.g., whether null values mean 'leave unchanged'), permissions required, or side effects. The return statement is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The structure with Args and Returns is tidy, but the individual argument descriptions are redundant and waste space. Every line repeats the param name with a 'New' prefix, which does not earn its place. The meaningful content is only two sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 11 parameters and no annotations, the description is inadequate. It does not explain allowed values for fields like status or template, how nulls are treated, or potential errors. The output schema exists, but it does not compensate for the lack of behavioral and parameter context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists all parameters but each description is tautological (e.g., 'title: New title', 'status: New status'), adding no meaning beyond the schema. Schema description coverage is 0%, and the description does not compensate with any clarification of valid values, formats, or relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it updates an existing WordPress page. The verb 'update' and resource 'WordPress page' are specific, and it distinguishes from sibling tools like create_page, delete_page, or get_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., page must exist) or contrast with create/delete operations. The description is purely action-oriented without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of revealing behaviors. It only says 'Update' which implies mutation but does not disclose potential side effects, whether changes are reversible, if permissions are required, or if there are any constraints (e.g., only certain fields can be updated). The description lacks this depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and structured with an Args/Returns list, making it easy to parse. It is appropriately sized, with no wasteful sentences, though it could be improved by adding usage context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has 5 parameters (with 0% schema coverage) and no annotations, the description is incomplete. It fails to provide the behavioral context or parameter semantics needed for a full understanding. The output schema exists, so return format is covered, but other aspects are lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 lists parameter names but provides no additional meaning beyond their names. For example, it doesn't explain the expected format or constraints for title, alt_text, caption, or description. This leaves the agent under-informed about parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Update WordPress media item metadata' which clearly identifies the action (update) and the resource (media item), and distinguishes it from siblings like upload, delete, and get media. However, it doesn't mention the specific fields beyond listing them in the Args, which is sufficient.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as when to update metadata versus re-upload media or when updates are irreversible. It doesn't state prerequisites like the need for an existing media item or the context of use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose safety and side effects. It only says 'Get' which implies read-only, but does not explicitly state non-mutating behavior, error handling, or any permissions needed. The description adds no value beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and uses a structured Args/Returns format, which is easy to parse. It contains no redundant phrases or filler, making it appropriately compact for a simple getter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given it has only one parameter and an output schema, the description covers the basic purpose. However, it omits edge cases like not-found behavior, versioning specifics, or any WordPress-specific nuances that might affect use. It is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The only parameter, comment_id, is described as 'Comment ID' in the args line, which merely repeats the schema property name without adding type hints, format, examples, or meaning. This provides zero additional context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a single WordPress comment by ID' with a specific resource (comment) and action (get), distinguishing it from list_comments and other comment mutation tools. The verb+resource pattern is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives like wordpress_list_comments or wordpress_get_post. The description does not mention prerequisites, exclusions, or typical scenarios, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose any behavioral traits such as whether revisions are returned in chronological order, whether the page must exist, or any error conditions. The description is minimal and lacks detail beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose. It includes a simple Args and Returns section, which is clear. However, it is slightly under-specified, but for a simple tool it is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (though not shown in detail), the description need not explain return values. However, with no annotations and minimal description, it lacks context about usage, prerequisites, or behavior. It is adequate for a simple list operation but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description does mention 'page_id: Page ID' which adds a tiny bit of meaning. However, it does not explain the format, constraints, or how the page_id is used beyond the schema. With only one parameter, the description adds minimal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists revisions for a WordPress page, using a specific verb and resource. It distinguishes from siblings like wordpress_list_revisions (which likely lists revisions for posts) by specifying 'page'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention that it is specific to pages, nor does it contrast with wordpress_list_revisions or wordpress_get_revision. The context is implied by the name and description but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of disclosing behavior. It only says 'Get' and 'Returns media item details,' but does not explicitly state that it is read-only, has no side effects, or requires any permissions/authentication. For a read operation, this is a notable omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main action in the first sentence. The Args/Returns sections are standard and add minimal overhead. It is appropriately sized for a simple tool, though the Returns line is generic and could be omitted given the output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-item retrieval with an output schema, the description is minimal but adequate. It does not mention prerequisites (e.g., the media must exist) or explicitly state that the operation is read-only, but the output schema covers return structure. Given the simplicity, a 3 seems fair.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description repeats the parameter name 'media_id' with 'Media ID', which adds no meaning beyond the schema's property name and type. With schema description coverage at 0%, the description was the sole chance to enrich the parameter, but it merely restates the obvious.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Get a single WordPress media item by ID.' This specifies the verb (Get), resource (media item), and scope (by ID), distinguishing it from list_media (which returns multiple) and get_media_url (which returns only a URL). The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you have a media ID and want its details. However, it does not explicitly state when to prefer this over alternatives like list_media or get_media_url, nor does it mention any exclusions. The context is clear enough but lacks direct guidance on sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states it 'gets' a revision and returns 'Revision details with content,' but does not explicitly confirm it is a read-only operation, any authorization requirements, or error behaviors. The output schema provides return structure, but the description adds little beyond intent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the purpose sentence, followed by a compact args and returns summary. It avoids unnecessary fluff and is easy to scan. Slight redundancy in the arg definitions, but overall it is well-structured and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (two integer params, read operation) and the presence of an output schema, the description covers the core action. However, it lacks usage context (when to use vs. alternatives) and does not mention any potential pitfalls, such as revision deletion or access restrictions. It is minimally complete but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 lists 'post_id: Post ID' and 'revision_id: Revision ID,' which merely restates the parameter names with generic labels. No additional semantics are provided (e.g., how to find revision IDs, constraints, or relationships between parameters). The value added over the schema is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get a specific revision') and the resource ('a WordPress post'), which distinguishes it from siblings like wordpress_list_revisions (listing) and wordpress_get_post (getting the post itself). 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.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While the name implies it is for a single revision, the description does not explicitly mention that get_post is for the current post or that list_revisions is for enumerating revisions. Users must infer usage from the name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It indicates the action is an update (implying mutation) but does not mention side effects, required permissions, reversibility, or the effect of leaving optional parameters null (e.g., whether null means no change). It also does not describe any rate limits or error behavior. This is a minimal disclosure for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured: a one-sentence purpose, then Args with each parameter described, and a Returns line. There is no wasted text. It adheres to a clear and scannable format that effectively front-loads the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 params, 1 required) and the lack of annotations and output schema details, the description provides only basic context. It mentions what parameters do and that the return is updated comment details, but it misses important clarifications like how null values affect the update, whether all parameters are optional aside from comment_id, and any potential interactions with comment moderation workflow. It is adequate but leaves ambiguities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to parameters by explicitly listing the allowed values for status ('approved', 'hold', 'spam', 'trash') and describing content as 'New comment content'. This goes beyond the schema, which only defines types and nullability. However, it doesn't clarify the semantics of null for these optional fields (whether null means 'no change'), and the schema coverage is 0% per the signal, so the description partially compensates but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an existing WordPress comment, specifying the resource (comment) and action (update). It lists the parameters involved, indicating what can be changed. However, it doesn't explicitly distinguish itself from the sibling tool 'wordpress_moderate_comment', which might also alter comment status, so differentiation is weak.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like wordpress_moderate_comment or wordpress_create_comment. It only states the basic action without any context about prerequisites, typical use cases, or exclusions. The description lacks any 'when to use' or 'when not to use' information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It correctly implies a read-only operation by using 'List', but does not disclose any additional behavioral aspects such as pagination, ordering, or whether the revisions include full content or just metadata. The output schema exists, so return value details are covered; the description adds minimal value beyond the read intent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences) and well-structured with an Args and Returns section. Every line carries necessary information without verbosity, making it efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, clear output schema), the description is adequately complete. It states the action and the parameter meaning, and the output schema covers the return structure. It does not mention optional details like ordering or pagination, but these are not essential for a basic list operation and may be implied by the WordPress API context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description restates the parameter as 'post_id: Post ID', which merely repeats the schema property name and its obvious purpose. With schema description coverage at 0%, it does add a slight semantic hint that the ID refers to a post, but this is already clear from the parameter name. No additional format, validation, or usage details are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'revisions for a WordPress post', which is specific and distinguishes it from get_revision (single revision) and list_page_revisions (page revisions) by implication. It does not explicitly name these alternatives, but the purpose is unambiguous and directly tied to the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the sibling tools like get_revision or list_page_revisions. The description gives no context on use cases, prerequisites, or exclusions, leaving the agent to infer that it lists all revisions for a given post.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It mentions status changes and possible actions but omits consequences (e.g., spam/trash irreversibility, permissions, side effects on comment content).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured with clear Args and Returns sections. Every sentence adds value and there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with an output schema, the description covers purpose and parameters well. However, without annotations or usage distinctions from update/delete comment, it remains slightly incomplete for confident tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description compensates by naming each parameter and explicitly listing valid action values (approve, hold, spam, trash). This adds meaningful semantics beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool moderates a WordPress comment by changing its status, with specific actions listed. However, it doesn't explicitly distinguish this from sibling tools like wordpress_update_comment, which could also alter comment status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as wordpress_update_comment or wordpress_delete_comment. The description only explains mechanics, not context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only restates 'List available WordPress tags' without elaborating on side effects, read-only guarantees, or edge behaviors. While 'List' implies a read operation, the safe/side-effect-free profile is not explicitly confirmed, leaving the agent with unsupported assumptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with clear Args and Returns sections. Each sentence serves a purpose. A small deduction for the 'Returns: List of tags' section, which is slightly redundant given the output schema exists, but overall it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While there is an output schema, which reduces the need to explain return values, the description misses the opportunity to clarify when tags are relevant in WordPress workflows or to distinguish behavior from the similar wordpress_list_categories tool. It's functionally adequate but lacks strategic context for broader usage scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section adds meaning by explaining each parameter beyond the schema: 'page: Page number', 'per_page: Results per page (max 100)', and 'search: Search tags by name'. Since the schema has no descriptions (coverage 0%), this documentation is essential and effectively compensates for the gap, hence not a maximum score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List available WordPress tags' with a specific verb (list) and resource (tags). It is unambiguous and distinct from sibling operations like listing categories or posts, even though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like wordpress_list_categories or other tag-related operations. It lacks context on scenarios favoring tags over other taxonomies. The rubric requires explicit when/when-not guidance or alternative naming, which is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It states it searches in title and content, which is helpful, but does not explicitly declare that it is read-only or mention any limitations (e.g., search semantics, pagination behavior, result ordering). The 'Returns: Search results' is minimal. Adequate 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise—two sentences for the core purpose plus a brief Args/Returns list. Front-loaded with the action, no filler or redundant details. Every piece earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given its simplicity and presence of an output schema, the description covers the basics but lacks nuances like search result sorting, pagination defaults beyond schema, or any note about query limitations. It's enough for a basic call but not fully complete for an agent that might need to filter or interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds little beyond the schema: it repeats parameter names and quotes defaults (from schema) with basic one-line hints like 'Search keyword' and 'Page number'. With 0% schema description coverage, it fails to enrich understanding (e.g., what 'search in title and content' means for keyword matching, or whether page is 1-indexed).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it searches WordPress posts by keyword in title and content, which is specific and distinguishes it from sibling tools like wordpress_list_posts (lists all) and wordpress_get_post (fetches one). The verb 'search' and resource 'posts' are precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It does not mention that it is for filtering by keyword unlike list_posts, nor does it suggest when not to use it. Usage context is entirely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the full burden. It states the function's return type ('Media URL information') and parameters, but does not disclose what the function actually returns (e.g., whether the URL is absolute or has size variants), nor any side effects (though this appears read-only). It is neutral and non-contradictory, but does not enrich behavioral understanding significantly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three short bullet points plus a header) and front-loads the core purpose. Every sentence earns its place, avoiding fluff. The format is structured for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (though not provided here), the description need not explain return values, but it does have one line about returns. The tool is relatively simple (2 parameters, one required), but it lacks guidance on edge cases (e.g., if media_id is invalid) or how size affects the URL. It is complete for a basic use case but lacks depth for robustness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 lists the parameters ('media_id' and 'size') but does not add additional context beyond the schema. It mentions allowed size values ('thumbnail, medium, large, full') inline, which is helpful, but no further semantics like format or example. This is adequate but minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving the public URL for a WordPress media item. It uses a specific verb ('Get') and resource ('media item'), and is distinct from siblings like 'wordpress_get_media' (which likely fetches media details) and 'wordpress_upload_media'. It is not as explicit about scope as it could be, but it is clear enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need a URL for a media item, but does not explicitly state when to use it vs. alternatives (e.g., 'wordpress_get_media' for metadata) or any prerequisites. It gives a basic sense of context but lacks exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It merely says 'Update an existing WordPress post' and lists parameters, but does not explain that it likely performs a partial update (only fields provided are changed), what happens if the post does not exist, authentication requirements, or error handling. This is insufficient for a mutating tool without annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence purpose, a parameter list, and a return note. It is front-loaded with the key action and avoids fluff. The parameter lines are short but cover each argument, making it easy to scan. Slight redundancy in the wording of each line ('New title' vs 'title') could be trimmed, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 11 parameters and no annotations, making it complex. The description lacks important context: it does not explain partial vs full update behavior, required fields beyond post_id, whether certain fields are mutually exclusive, any validation constraints, or the nature of the returned 'updated post details'. Given the output schema is not shown, the description's return note is vague and insufficient for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With a schema description coverage of 0%, the description's Args list adds meaningful semantics for all 11 parameters, e.g., 'post_id: Post ID to update' and 'categories: New category IDs'. This compensates for the schema's lack of human-readable explanations, though some entries are terse and could include more detail (e.g., formats or allowed values).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an existing WordPress post', using a specific verb and resource. It distinguishes from sibling tools like wordpress_create_post and wordpress_delete_post, and also implies post-specific behavior vs updates for pages, comments, or media.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to modify an existing post) but provides no explicit guidance on when not to use it or which alternatives to consider. It does not mention that for new posts one should use wordpress_create_post or that for pages one should use wordpress_update_page, so the context is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully convey behavioral aspects. The 'Returns' line merely restates the purpose without disclosing behavior like network latency, pagination defaults, or error handling. It mentions max 100 in Args but doesn't explain what happens beyond that limit or how large lists are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, using a clear Args/Returns format. Every word earns its place, with no filler or redundancy. It conveys all necessary information in under 30 words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing operation with an output schema, the description adequately covers the parameters and return type. It doesn't address edge cases or usage context, but given the tool's simplicity and the presence of an output schema, it's reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section compensates for the schema's lack of descriptions by providing concise explanations: 'page: Page number', 'per_page: Results per page (max 100)', 'search: Search categories by name'. This goes beyond the schema's bare types and defaults, though the explanations are minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'List available WordPress categories' - a specific verb+resource pairing that clearly matches the pattern of sibling tools. It maps directly to the tool name and differentiates from other list operations like posts or pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when this tool should be used over alternatives such as wordpress_list_tags or wordpress_list_pages. There is no mention of prerequisites, common use cases, or when to prefer a different listing tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and lists parameters, but does not describe side effects, permission requirements, error behavior, or implications of using the 'status' parameter. It lacks transparency about what happens on creation beyond returning details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an 'Args' section and 'Returns' section, making it easy to scan. It lists each parameter succinctly with brief clarifications. No unnecessary filler, though it largely restates the schema which is acceptable given the need for context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity with 10 parameters and no annotations, the description covers all parameters and mentions return details. The presence of an output schema also covers return structure. However, it does not address potential error conditions or prerequisites, which would enhance completeness for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful explanations beyond the schema's basic names, such as clarifying content format ('HTML or block format'), enumerating status values, and specifying 'Menu order' and 'Publication date (ISO 8601)'. Even though schema coverage is 0%, the description compensates well by covering all parameters with useful context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: 'Create a new WordPress page.' This distinguishes it from siblings like wordpress_create_post and wordpress_create_comment, as it explicitly targets pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives such as wordpress_create_post. It implies usage for page creation but does not state exclusions or conditions, leaving the agent to infer context from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It states the tool 'Get's' a page, which indicates a read-only, side-effect-free operation, and mentions returning full content. However, it does not disclose authentication requirements, error handling for missing/private pages, or any other behavioral caveats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the main purpose. The Args/Returns sections are minimal and every sentence adds useful information. No fluff or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-ID getter, the description covers the main action and return value, and an output schema exists. However, it lacks guidance on when to use this versus sibling tools (e.g., wordpress_get_post), and does not mention error or permission behavior. These gaps are notable given the rich sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only provides the parameter name and type; the description adds 'Page ID' as a semantic label, which is helpful but mostly redundant with the parameter name. It does not explain how to obtain the ID or any special constraints, so the added value is minimal but non-zero.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('single WordPress page by ID'), clearly distinguishing from list operations and from wordpress_get_post by specifying 'page'. It also notes 'full content', which clarifies what is retrieved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for retrieving a specific page when the ID is known, but it does not explicitly state when to use this over siblings like wordpress_list_pages or wordpress_get_post. No alternatives or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions the force parameter for permanent vs trash deletion, but does not mention permissions, consequences, or the irreversible nature beyond the force flag. It also does not describe the return value in detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and well-structured with Args and Returns sections, front-loading the main purpose in the first sentence. It contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool, the description covers purpose and parameters, but lacks usage guidance and deeper behavioral context like permissions or side effects. Given no annotations, this leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains both parameters in the Args section, adding meaning beyond the bare schema. It clarifies that comment_id is the target and force controls permanent deletion vs trash, which is valuable given 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete or trash) performed on a WordPress comment, distinguishing it from sibling tools like update_comment or moderate_comment. It explicitly names the resource and the two modes of operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, such as moderating or updating comments. It implies deletion is for removing comments, but no exclusions or comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides no behavioral details beyond the direct action and parameter list. It does not mention side effects, required authentication, rate limits, or what happens on success/failure. Since there are no annotations to cover these aspects, the description carries the full burden and falls short—it only restates the mechanics compressed into the function name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with a clear 'Args' section and a 'Returns' clause. Every sentence and parameter explanation earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation operation, the description covers all parameters and states the return value. However, it omits any mention of required permissions or the fact that certain fields (like author_name) are used only when creating anonymous comments. Given the presence of an output schema, it doesn't need to explain return structure, but a note about authentication or context would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context to every parameter that the schema lacks. For example, 'post: Post ID to comment on' clarifies the purpose, and 'author_name: Comment author name (for anonymous comments)' explains when this field is relevant. This is especially valuable because the schema provides no descriptions, so this is the only source of semantic information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new comment on a WordPress post.' It uses a specific verb and resource, and the context of creating a comment is unambiguous. This distinguishes it from sibling tools like wordpress_update_comment, wordpress_delete_comment, and wordpress_moderate_comment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the action word 'create' and the parameter list. However, there is no explicit guidance on when to use this tool versus alternatives, nor any mention of when not to use it. The description does not mention prerequisites or exclusions, so it sits at the 'implied usage' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It mentions return values (title, description, URL, timezone, settings) but lacks any mention of authentication, error behavior, or side-effect profile. The read-only nature is implied by 'Get' but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action and resource, followed by a concise list of return fields. No filler or redundant repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless getter with an output schema, this description is adequate. The return values are partially described, while the output schema likely covers full details. Missing explicit usage context versus sibling connection-test tool, but this is minor for such a straightforward operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty. Baseline for 0 params is 4, and the description adds no extra parameter semantics because there are none to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get WordPress site information' with a specific verb and resource. It is unambiguous and no similar sibling tool exists, so it distinguishes itself naturally.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when site information is needed) but provides no explicit guidance on alternatives or exclusions. The presence of siblings like test_connection is not addressed, so the agent must infer when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds value by explaining that 'status' defaults to 'draft' via the docstring, clarifies that 'date' is for scheduling with an ISO 8601 example, and notes that 'content' can be HTML or block format. However, it doesn't discuss side effects like publishing implications or authentication requirements, preventing a perfect score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a well-structured docstring with a clear purpose statement, an Args section listing each parameter on one line, and a Returns section. It is appropriately sized for 10 parameters, with no redundant text or fluff, making it easy to scan and parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's complexity (10 parameters, 2 required) and absence of annotations, the description covers all parameters with clear semantics and even includes return information. It does not elaborate on error handling or permission requirements, but since an output schema is present, the need to describe return values is reduced. This is nearly complete for the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides zero descriptions for parameters, so the description's docstring becomes the only source of semantic meaning. It gives a concise but informative explanation for each parameter (e.g., 'title: Post title', 'content: Post content (HTML or block format)') and adds practical details like the date format and default status. This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Create a new WordPress post.' which uses a specific verb and resource, clearly distinguishing it from sibling tools like wordpress_create_page. The purpose is immediately clear and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as wordpress_create_page or wordpress_update_post. There is no mention of prerequisites, exclusions, or scenarios where another tool would be more appropriate, leaving the agent to infer usage solely from the tool's name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It clearly states that media cannot be trashed, implying permanent deletion, and that force must be true, while also noting the return value. It does not mention permissions or side effects, but the key destructive behavior is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with clear sections for summary, arguments, and return value. The main purpose is front-loaded, and there is no filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter delete operation, the description adequately covers the action, the required force flag, and the return confirmation. Since an output schema exists, detailed return-value documentation is not necessary, and the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 media_id's role and, more importantly, clarifies the force parameter's requirement ('Must be true for media'), adding meaningful context beyond the raw schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Delete a WordPress media item,' a specific verb+resource statement that clearly identifies the tool's function. It also distinguishes it from sibling tools like wordpress_delete_post, wordpress_delete_page, and wordpress_delete_comment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful invocation context by stating that media cannot be trashed and force must be true. However, it does not explicitly explain when to prefer this tool over alternatives or mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the two operation modes: force=true permanently deletes, force=false moves to trash. This is essential for a destructive action. It also states the return as 'Deletion confirmation,' providing basic feedback context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with Args and Returns sections. Every line contributes to understanding the operation, with no extraneous information or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters) and the presence of an output schema, the description adequately covers the core behavior and parameter effects. It does not mention potential errors or side effects (e.g., deletion of related revisions), but these are not necessary for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by explaining post_id as 'Post ID to delete' and force as 'If true, permanently delete. If false, move to trash.' This adds meaning beyond the bare schema types. However, it does not mention the default value of force (false) explicitly, though it can be inferred.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Delete or trash a WordPress post,' clearly specifying the action (delete/trash) and resource (post). It distinguishes from sibling tools like wordpress_delete_page and wordpress_delete_media by naming the resource type directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. Usage is implied by the tool name and the clear resource reference, but no exclusions or recommendations are offered for distinguishing between post, page, media, or comment deletion tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. 'Get' implies read-only, and 'full content' indicates return scope. Missing details on error handling or nonexistent IDs, but adequate for a basic read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact with a clear one-line summary followed by concise Args and Returns sections. No filler words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-param getter with an output schema, the description covers the essential purpose and parameter. Output schema handles return values, so the lack of edge-case discussion is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explicitly identifies post_id as 'Post ID' and the main line clarifies it refers to the WordPress post ID, adding meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a single WordPress post by ID with full content. The verb 'Get' combined with 'single' and 'by ID' distinguishes it from sibling tools like list/search and page tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly implies use when you have a specific post ID and need full content. However, it does not explicitly mention alternatives like wordpress_list_posts or wordpress_search_posts, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses read-only list behavior, filtering options, and pagination, but does not address permissions, error cases, or side effects. This is adequate 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a summary line, an Args list, and a Returns line. Every sentence serves a purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has seven optional parameters and no annotated safety metadata, so the description carries a heavy burden. It covers all parameter semantics and return information, making the tool sufficiently complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully documents all seven parameters with meanings, defaults, valid values, and constraints such as 'max 100'. This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List WordPress media items with filtering', which is a specific verb and resource. This distinguishes it from sibling tools like wordpress_get_media, wordpress_upload_media, and wordpress_delete_media.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving filtered media collections, but it does not explicitly state when to choose this over alternatives or when not to use it. Sibling tool names help, but no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It says 'List
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with 'Args:' and 'Returns:' sections, listing each parameter concisely with its purpose. It's front-loaded with a clear summary sentence. No fluff, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema covers all parameters and the output schema exists, the description adds context by explaining filtering and pagination. It states 'with pagination info' which is useful. It might mention that results are ordered but not necessary. It's complete for a list tool. Could mention common use cases but not required. Score 4 because it doesn't explicitly distinguish from list_posts or list_categories, but it's clear enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly defines each parameter's meaning (e.g., 'Filter by status', 'Page number'), and it also specifies allowed values for status like 'publish, draft, private, future' and for orderby, though orderby values are listed. Since schema coverage is 0%, the description fully compensates by describing all parameters and their purpose. It also mentions defaults for some, though not all. This is strong.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'List WordPress pages with filtering and pagination.' It uses a specific verb (list) and resource (WordPress pages), and the mention of filtering and pagination distinguishes it from sibling tools like get_page, create_page, or get_post.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists parameters that imply usage scenarios (filter by status, search, etc.), providing clear context. However, it does not explicitly mention when not to use this tool or point to alternatives like wordpress_list_page_revisions or wordpress_get_page. Still, the intent is unambiguous, so slight deduction for missing exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosure. It mentions that it verifies credentials and returns connection status, which adds context beyond the name. However, it lacks details on error behavior, side effects, or the exact structure of the response (though an output schema exists). It is adequate 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary action. Every word serves a purpose, with no redundancy or filler. It is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no parameters, has an output schema), and the description sufficiently conveys its function. It lacks explicit guidance on failure handling or prerequisites, but given the tool's minimal nature, the description is complete enough for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100% (vacuously). Per the guideline, a baseline of 4 is appropriate. The description adds no parameter-specific information because none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Test connection to WordPress REST API' and 'Verifies API credentials and returns connection status.' This is a specific verb-resource pair (test connection, verify credentials) that distinguishes it from sibling tools focused on CRUD operations for posts, pages, media, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to test connectivity and credentials) but does not explicitly state when not to use it or compare it to alternatives. However, the intent is unambiguous and the tool's unique role among the siblings is obvious, so no exclusions are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description reveals key behavioral details: direct disk read, path requirements, container mount specifics, and a return promise of uploaded item details. It does not cover failure modes or permissions, but the primary operational hazards are clearly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat long but well-structured with a purpose statement, container note, Args list, and Returns line. Every section adds operational value, and the formatting supports quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all parameters (5 total, 1 required), the critical container path caveat, and the return value. It does not elaborate on field-level return details, but an output schema exists and the description is sufficient for correct invocation in container and non-container contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the Args section compensates by defining all five parameters: file_path with an example, title, alt_text, caption, and description. The example path makes the absolute-path requirement concrete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb and resource: 'Upload a media file to WordPress from a local file path.' It distinguishes itself from sibling media tools (list, get, update, delete) by focusing on the upload action and the local-source constraint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: requires an absolute path, reads directly from disk to avoid large base64 payloads, and clearly explains container filesystem semantics with host/container paths. It does not explicitly name alternative tools, but the upload action is unique among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosure. It explains the return shape ('List of posts with pagination info') and parameter options, but does not mention permissions, rate limits, or explicitly confirm read-only behavior. 'List' implies a safe read, but the lack of explicit safety or error-related context keeps it at a moderate level.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an 'Args' section listing each parameter on its own line and a 'Returns' section. Every sentence provides necessary information without fluff, making it easy for an agent to scan and extract parameter semantics quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 optional parameters, no required fields, and an output schema (as indicated), the description is complete enough: it states the purpose, defines all parameters, and summarizes the return value. There are no significant gaps for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description fully compensates by documenting all 8 parameters. It adds semantic value beyond the schema by enumerating allowed status values ('publish, draft, pending, private, future'), orderby fields, per_page max (100), and describes what each filter does (e.g., 'Filter by category IDs').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List WordPress posts with filtering and pagination', which states the verb ('List'), the resource ('WordPress posts'), and key capabilities ('filtering and pagination'). This clearly differentiates from siblings like wordpress_get_post (single post) and wordpress_search_posts (search-focused).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the tool's purpose clear enough for an agent to infer when to use it: when listing multiple posts with optional filters. However, it does not explicitly mention when not to use it or name alternatives like wordpress_search_posts, which would fully satisfy the 'explicit exclusions' bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses the key destructive behavior: force=true permanently deletes while force=false moves to trash. It also states a confirmation is returned, but it does not mention permission requirements or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the purpose, followed by clearly labeled Args and Returns sections. Every line adds useful information, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool with two parameters and an output schema, the description adequately covers the operation, including the trash/permanent distinction and return confirmation. It could add edge-case behavior, but nothing critical is missing for selecting and invoking this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema lacks descriptions, the Args section explains both parameters in plain terms: page_id identifies the page and force controls trash vs permanent deletion. This fully compensates for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence 'Delete or trash a WordPress page' states a specific action and resource, and the title/description make it clear this targets pages rather than posts/media. This distinguishes it from siblings like wordpress_delete_post and wordpress_delete_media.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly communicates that this is for deleting or trashing WordPress pages, which establishes the use context by resource. It does not explicitly name alternatives or state when not to use it, but the page-specific scope is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return behavior ('List of comments with pagination info') and filter options, which is sufficient for a read-only listing operation. It does not state read-only explicitly, but that is inherently clear from the verb 'List'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an Args list and a Returns line. Each parameter line is concise, includes defaults and constraints, and there is no filler or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With seven optional parameters and an output schema present, the description covers all parameters, their defaults, the per_page maximum, and the return type ('List of comments with pagination info'). This is sufficient for a complete understanding of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, but the description thoroughly explains every parameter: 'post' filters by post ID, 'status' enumerates allowed values, 'search' searches content, 'page' and 'per_page' control pagination with defaults and max, and 'orderby'/'order' specify sorting. This adds critical meaning the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and identifies the resource 'WordPress comments' with filtering, clearly distinguishing it from sibling tools like wordpress_get_comment (single comment retrieval) and wordpress_moderate_comment (moderation). The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies usage for retrieving multiple comments with optional filters and pagination. It does not explicitly mention alternatives or when-not-to-use, but the list-vs-single nature of the tool is obvious from the name and description, providing clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/crunchtools/mcp-wordpress'
If you have feedback or need assistance with the MCP directory API, please join our Discord server