WordPress MCP Custom Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.9.0
Disambiguation2/5
The tool set has 32 tools, but many are deprecated aliases for the same underlying operations. There are also overlapping validation tools (validate_urls_raw vs validate_pages vs validate_and_recheck vs autofix_safe) that are quite similar in purpose, and overlapping checklist tools. The deprecated aliases create significant ambiguity about which tool to use.
Naming Consistency2/5
The set mixes namespace-dotted versioned names (content.list.v1, site.request.v1) with deprecated snake_case aliases (list_posts, wp_request). Even within the main names, there's inconsistent structure: some use domain.action form (content.publish.v1) while others use flat action form (read_project_file, benchmark.compare_ab.v1).
Tool Count1/5
32 tools is excessive for what is genuinely a moderate-scope WordPress automation server. Critically, roughly half of the tools (13+) are deprecated aliases that should have been removed, meaning only about 19 are real and roughly half of those are legitimate. The deprecation burden inflates the count enormously.
Completeness3/5
The core surface covers content publishing, ACF updates, project file management, site options, SEO meta, W3C validation, playbooks, and benchmarks. However, there are notable gaps: no tool to update existing posts (only list and publish new), no get single post, and no delete. Content update appears limited to ACF fields rather than general post editing.
Average 2.6/5 across 32 of 32 tools scored. Lowest: 1.3/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
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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.json to 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

Behavior1/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. The description only states it's a deprecated alias but provides zero information about mutations, side effects, permissions, or behavioral traits. The agent cannot know what this tool does to pages or data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence). While brevity itself is not bad, this is under-specification rather than genuine conciseness. A single sentence that does no informative work doesn't earn points for efficiency. However, it is at least front-loaded and unambiguous about being deprecated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a complex schema with 5 parameters, 2 required nested object arrays, and an output schema, the description provides zero contextual information. It doesn't describe the return value, the validation process, what 'safe' autofix means, or how this differs from the non-safe alternatives. A deprecated alias should at minimum explain what the canonical tool does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds nothing about the parameters. The schema requires baseline_pages and after_pages but the description doesn't explain their meaning or relationship. The name 'autofix_safe' hints at validation comparison, but the 'safe' semantics and what baseline vs after means is entirely unexplained. With 5 parameters and 0% coverage, the description should compensate significantly but doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is simply 'DEPRECATED alias for validation.w3c.autofix_safe.v1.' It only tells the agent this is a deprecated alias pointing to another tool. It does not state what the tool does, what action it performs, or what resource it operates on. There's no verb+resource structure at all.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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 vs its siblings. It doesn't explain when to prefer this over w3c_validate_pages, w3c_validate_and_recheck, or the sibling validation.w3c.autofix_safe.v1 tool. The only hint is that it's deprecated and aliased to another 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state whether this is a read-only operation, whether it modifies pages, what 'recheck' implies, rate limits, or side effects. Being an alias to another tool, at minimum it should describe the canonical tool's behavior, which it does not.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (one sentence). While brevity itself isn't a flaw, here it's under-specification, not effective conciseness. It wastes the tiny space it has on a deprecation notice rather than conveying tool purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, 0% schema coverage, no annotations, and a non-obvious comparative operation (baseline vs after), the description is severely incomplete. An output schema exists but the description gives no context about what is validated, what 'recheck' means, or how the results relate to baseline vs after pages.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. The description names the two required parameters (baseline_pages, after_pages) only via the schema, not in the text. The description provides zero explanation of what baseline_pages vs after_pages mean, what URL vs html fields represent, or what the 'level' enum controls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is just a deprecation notice pointing to validation.w3c.validate_and_recheck.v1, but never explains what the tool actually does. The verb and resource (what it validates, why 'and_recheck') are entirely unspecified. An agent cannot infer the tool's function from the description alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Given the many sibling validation tools (validate_urls_raw, validate_pages, autofix_safe, validate_and_recheck), the description provides zero differentiation. The only hint is to use the canonical alias instead, but there's no explanation of what that tool does or when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations to carry any burden, and the description provides essentially zero behavioral disclosure. It's an alias to another tool, so the behavior is that of site.request.v1, but the description doesn't disclose what that behavior entails — no mention of mutating operations, approval requirements, or the dry_run/require_approval semantics. For a tool with no annotations, the description shoulders the full burden and fails to convey any behavioral characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief ('DEPRECATED alias for site.request.v1.'), which is structurally minimal and front-loaded. However, this brevity crosses the line from conciseness into under-specification—there's nothing beyond the deprecation note, and the sentence earns only partial credit for efficiently communicating the deprecation status.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generic HTTP request tool with 5 parameters, no annotations, and a low-coverage schema, the description provides almost no contextual value. The output schema exists but the description doesn't contextualize what the tool returns or how it behaves. The deprecation note is the only useful context, which addresses the 'use site.request.v1 instead' decision but leaves the rest uncovered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is low (20%), and the description adds no parameter-level information whatsoever. Parameters like dry_run, require_approval, body, method, and path are only documented via the single 'path' description in the schema. The description does not compensate for the coverage gap, leaving 80% of parameter semantics to the agent's inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says it's a 'DEPRECATED alias for site.request.v1.' This provides the essential purpose (it's a deprecated alias pointing to site.request.v1), which is clear about what it does. However, it doesn't state the underlying action (making HTTP requests to the WordPress REST API) beyond the deprecation note, so an agent unfamiliar with site.request.v1 wouldn't know its purpose from this description alone. It identifies the relationship to a sibling but doesn't define the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'DEPRECATED,' which implies it should NOT be used in favor of site.request.v1, providing a clear exclusion. However, it doesn't explain when one might still use this alias, whether site.request.v1 is a drop-in replacement, or any migration guidance. The deprecation note gives minimal 'use the sibling instead' guidance but nothing more.
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 burden. The description is a single sentence and says nothing about the behavior of the tool beyond listing posts. It doesn't disclose pagination behavior, whether this is read-only, what happens with no status specified (despite default in schema), or how list ordering/sorting works. Despite having an output schema, the behavioral surface is undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is minimal and efficiently states the core purpose in a single sentence. No wasted words. However, extreme brevity borders on under-specification rather than conciseness, which keeps it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Though an output schema exists (which helps with return values), the description lacks essential context for a potentially complex listing tool. There's no information about ordering, pagination semantics, behavior with no lang specified (return all languages?), or how this differs from sibling list tools. With no annotations and minimal description, the agent gets insufficient information to confidently select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, with 2 of 3 parameters (status, per_page) lacking meaningful descriptions. The description only mentions 'lang' explicitly (the Polylang filter). It doesn't explain default behaviors of status or per_page (e.g., default of 10, status default of publish exist in schema defaults but their semantics—what happens with status='any', what pagination means—are unexplained). The description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List WordPress posts with optional Polylang language filter' which is clear about verb+resource. However, it doesn't differentiate from sibling tools like 'list_posts' (which appears to be a similar listing function) or other content tools, and the name 'content.list.v1' is somewhat generic given multiple content-related siblings exist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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 vs alternatives. No exclusions, no mentioned alternatives, no preconditions. The description doesn't distinguish it from sibling 'list_posts' or indicate whether it's preferred for Polylang-filtered queries, only that such filter exists. No when-not-to-use guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. The description only states it is a deprecated alias and gives no information about side effects, required permissions, whether this mutates data, or what happens when invoked. For a tool that clearly mutates SEO metadata (given 'update' in name), there is zero transparency about behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one clause), which is efficient, but it does not front-load any purpose or usage information. It's under-specified rather than concise. A single sentence could still be high-quality if it conveyed purpose, but this one only communicates deprecation status.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is completely inadequate for a mutation tool with 3 parameters, no annotations, and 0% schema coverage. The agent cannot determine what this tool does, what the parameters mean, what effects it has, or how it differs from the many sibling tools like update_acf_fields, content.update_fields.v1, or seo.set_meta.v1. The deprecation note is partially helpful but the tool is otherwise opaque.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 3 parameters (title, post_id, description) are documented in the schema. The description mentions none of the parameters either. Post_id is required, and one can infer title and description relate to Yoast SEO title/meta description fields, but the description provides no explicit explanation of what each parameter means or expects.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'DEPRECATED alias for seo.set_meta.v1' which explains the tool is a deprecated alias, but does not actually state what the tool does. It references another tool rather than describing its own function. The name 'update_yoast' implies updating Yoast SEO fields, but the description itself is tautological in that it defines the tool only by its relationship to another tool without saying what operation it performs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly tells the agent to use seo.set_meta.v1 instead ('DEPRECATED alias'), which serves as a when-not-to-use signal. However, it does not explicitly state when one would use this tool vs alternatives, and it doesn't explain what seo.set_meta.v1 does or why it's preferred. The deprecation hint is useful but the guidance is minimal.
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 behavioral burden. The description only states deprecated status and alias relationship but discloses no behavioral traits such as what it returns (posts list), pagination behavior, or any side effects. The out-of-band deprecation is useful but insufficient for a tool the agent might still invoke.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence), which earns conciseness, but it is under-specified rather than efficiently complete. The deprecated alias note is brief and front-loaded, yet it doesn't function as an adequate description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is an output schema present, but the description still needs to convey what the tool does. For a tool with 3 parameters and no clear functional description, the completeness is poor. The deprecation note redirects to content.list.v1, which is helpful context, but the tool itself is left undefined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 33% (only 1 of 3 params has description text). The description adds zero parameter information, so it does not compensate for the coverage gap. Params like lang, status, and per_page are self-evident in naming, but the description offers nothing beyond what the schema sparse descriptions provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a single sentence: 'DEPRECATED alias for content.list.v1.' It tells the agent this is deprecated and an alias for another tool, but does not state what the tool actually does (list content/posts). The verb 'list' and noun 'posts' in the name imply the function, but the description itself fails to describe the purpose aside from deprecated alias 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs that this is deprecated and implies the agent should prefer content.list.v1, which names an alternative. However, it gives no guidance on WHEN to use this tool versus any alternatives beyond the deprecation note. There's no context about use cases for listing posts or when not to use this.
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. The description only states the write action and location but does not disclose whether existing files are overwritten, whether directories are auto-created, whether content is truncated or appended, or any permission/encoding details. For a mutation tool with zero annotation coverage, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is efficient in length. However, it is under-specified rather than appropriately concise - it packs minimal information into its one sentence. At this brevity, it's borderline tautological with the tool name 'project.files.write'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, an output schema exists but the description does not explain what it returns, and several sibling write-related tools (write_project_file, project.files.write.v1) create ambiguity without differentiation. With a simple 2-param tool this could be adequate with good annotations, but with zero annotation coverage the description should disclose overwrite behavior, path handling, and return semantics. It's incomplete for the complexity of a file-write operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning neither the schema nor the description documents the parameters' meaning. The description mentions 'text file' (implying content is text) and location, but doesn't clarify what 'path' should be (relative or absolute, subdirectory support), or the encoding/format expectations for 'content'. With 0% coverage, the description must compensate but does so only minimally.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says "Write text file to WP_PROJECT_ROOT," which identifies a write verb and a resource (files at project root). It's clear this writes a file, but it doesn't explain the write semantics (create vs overwrite, append behavior), and with sibling tools like project.files.read.v1 and project.files.list.v1, only read/list are contrasted implicitly. The purpose is minimally clear but lacks depth about whether existing files are overwritten or if path can point into subdirectories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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. Sibling write_project_file and project.files.write.v1 appear to be near-duplicates, yet the description offers no differentiation. No exclusions, prerequisites, or context for choosing this over write_project_file or content-related tools are given.
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. It discloses deprecation status and aliasing relationship, which is genuinely useful. However, it doesn't describe what the tool actually does behaviorally (creates content, publishes?) or what side effects occur. For a write-capable tool ('create post'), the lack of mutation behavior disclosure is a gap given zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (one sentence). While brevity is generally good, this is under-specification rather than conciseness — it's a single clause that conveys deprecation but omits the tool's fundamental purpose. A single effective sentence could score higher if the content was substantive, but here the sentence is thin.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a nested object parameter, an output schema, and no annotations. For a tool that creates posts with multi-language translations, the description is deeply inadequate — it never explains the tool's function, the translation structure implications, or the relationship between this and content.publish.v1 in practical terms. The output schema exists but the description doesn't help an agent understand when/how this tool fits into a publish workflow, especially with content.publish.v1 directly available as a sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% — the 'translations' parameter has a helpful example showing structure, and 'status' has a default but no description. The tool description adds nothing about parameters. The schema's translations example is good, but the description itself contributes zero parameter meaning. With partial schema coverage, the description doesn't compensate for the undocumented status parameter or explain the translations structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'DEPRECATED alias for content.publish.v1' does convey that this is a deprecated alias pointing to content.publish.v1, which gives some purpose information via indirect reference. However, it never states what content.publish.v1 actually does — the tool's actual function (creating a post with multilanguage translations) is entirely implicit from the name and schema. The description is a tautology about deprecation rather than explaining the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells the agent this is deprecated and an alias, which implies it should use content.publish.v1 instead — this is implicit guidance. However, it doesn't explicitly say 'use content.publish.v1 instead of this' nor explain when someone would ever legitimately call this tool. The deprecation note is the only usage signal, and it's not stated as an explicit recommendation with alternative naming.
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 behavioral burden. It mentions dry-run and post-publish checks but doesn't disclose what dry-run actually prevents, what post-publish checks entail, whether this triggers side effects on the environment, or what happens with the status parameter. For a tool named 'publish' which implies potentially consequential actions, this is under-specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence, no filler or redundancy. It front-loads the action and names two key feature flags. However, it may be TOO terse given the schema has zero coverage and the tool needs more explanatory content — but as a standalone for conciseness, it earns the score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There IS an output schema, which helps. But with 4 undocumented parameters (0% coverage), a nested translations object, no annotations, and no mention of alternative tools in a crowded sibling space, the description is incomplete. A publish workflow tool needs far more context about what checks run, what draft status means, and what dry_run protects against.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the 4 parameters. It mentions dry-run and post-publish checks but gives zero detail on what the 'translations' object structure means, what 'status' (draft) affects, or how the boolean flags alter behavior. The nested translations object with title/content per language is completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Run multilingual publish checklist with dry-run and optional post-publish checks' states a clear verb (run) and resource (multilingual publish checklist), and names the dry-run and post-publish check capabilities. It's adequate but doesn't explain what the checklist actually validates, what 'publish' means in this context, or how it differs from content.publish.v1 and content.update_fields.v1 among many sibling content/checklist tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs content.publish.v1, checklist.seo_landing_audit.v1, or checklist.w3c_validate_and_fix_plan.v1. The description doesn't state conditions for use, prerequisites, or when the tool is NOT appropriate. Given the large sibling set with overlapping 'checklist' and 'publish' concepts, this is a notable gap.
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. The description doesn't state whether it modifies any files, whether it performs network requests to each URL, whether autofix actually applies changes, how many URLs it processes, or what the fix plan output looks like. Given the apply_autofix parameter suggests potential mutation, the lack of disclosure about side effects is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with minimal waste. However, it's under-specifying rather than being efficiently terse — the short length is more a function of missing critical information than disciplined conciseness. The front-loading is fine but there's essentially nothing substantial to evaluate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, which relieves some burden for explaining return values. However, for a tool with 5 parameters at 0% schema coverage, a generate-and-fix-plan workflow with potential autofix side effects, and six closely related sibling tools, the description is notably incomplete. It doesn't explain the relationship between validation and the fix plan, how paths vs urls interact, or what triggers autofix behavior. It's marginally acceptable for an agent that might explore the schema, but fails to deliver meaningful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter is documented in the schema itself. The description names zero of the five parameters. The agent must infer that 'urls' is the target list, 'apply_autofix' might trigger fixes, and 'level' filters severity — but none of this is stated. With 0% coverage and 5 parameters (including a potentially dangerous apply_autofix), the description completely fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it runs W3C validation and builds a fix plan, naming the verb (validate/fix) and resource (plan). However, it doesn't specify what distinguishes it from sibling tools like validation.w3c.validate_pages.v1, validation.w3c.autofix_safe.v1, and w3c_validate_live_urls_raw, which likely do the same fundamental W3C validation work. The phrase 'for typical landing/template issues' adds scope but isn't precise enough to differentiate from the six W3C-related sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 extensive set of sibling W3C validation tools (validate_pages, validate_and_recheck, autofix_safe, validate_urls_raw). The description says it builds a 'fix plan' which implies a planning-purpose distinction, but this is only implied, never stated explicitly. There are no exclusions or alternative tool names mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 reveals nothing about side effects, reversibility, field overwrite semantics, error behavior, or the return payload. It does not even mention that fields are replaced wholesale or merged incrementally. This is a mutating operation with zero safety disclosure, a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that is efficient and unambiguous. However, its brevity is not true conciseness but rather under-specification. It earns a mid-range score for not wasting words while failing to convey necessary operational detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool operates on a complex nested object ('fields' with additionalProperties=true) that is entirely undocumented. The description does not explain field format, post state requirements, or overwrite semantics. For a mutating WordPress-content tool with no annotations and a free-form nested parameter, this level of detail is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and only minimal parameter names in the schema, the description adds essentially no meaning about either parameter. It does not explain what keys/values 'fields' expects (ACF field key vs. field name format, nested structure), nor what format post_id should take. The description does not compensate for the near-total lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update'), the resource ('ACF fields'), and the target ('a WordPress post/page'). It identifies the operation and subject accurately. However, it does not differentiate from siblings like update_acf_fields (which appears to be a near-duplicate) or provide scope specifics, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 update_acf_fields, seo.set_meta.v1, or content.publish.v1. There is no mention of prerequisites (e.g., post must be a published/trashed state, ACF plugin required), no exclusions, and no alternative tooling referenced. The agent must infer usage purely from the name.
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?
There are no annotations provided, so the description carries the full burden of behavior disclosure. The description tells the agent the tool is deprecated (useful) but reveals nothing about side effects, return format, pagination behavior, or whether it's a read-only operation. The deprecation status is transparent, but virtually nothing else about behavior is 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short—a single sentence fragment. While minimal, it's not bloated, and for a deprecated alias tool, brevity may be acceptable since the real documentation lives on the replacement tool. Nothing is wasted, but the under-specification is a weakness rather than intentional conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 undocumented (0% coverage) parameters, no annotations, but an output schema, the description should at least explain what the tool returns and how parameters behave. The description only flags deprecation and names a replacement. It's arguably acceptable for a deprecated alias since users should be redirected, but it leaves the agent without sufficient context if it still needs to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate for the undocumented path and limit parameters. It provides no parameter information at all—no explanation of what 'path' defaults to, what format it expects, or how 'limit' behaves. The schema has defaults, but the description adds nothing beyond what's in the schema; given zero coverage, the description should have filled this gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only says it's a 'DEPRECATED alias for project.files.list.v1.' It tells the agent this tool is deprecated and points to a sibling as the replacement, but it doesn't state what the tool itself does (i.e., lists project files). The purpose is only implied through the alias target name, so an agent has to infer functionality from the sibling tool's name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly tells the agent to use project.files.list.v1 instead of this tool, which functions as a when-not-to-use directive. However, it doesn't explain when one would use this deprecated alias vs. alternatives, nor does it describe what the tool actually accomplishes. The deprecation guidance is useful but minimal—it names the replacement but gives no context on usage scenarios.
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 confirms this is a read operation, but it doesn't describe what the output looks like (output schema exists but isn't summarized), whether the playbook_id must match a specific format, or what happens if the file is not found. For a tool lacking annotation coverage, more behavioral detail would be expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no waste. It's appropriately short for a simple one-parameter read tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with one parameter and an output schema, so the bar is relatively lower. However, with 0% schema coverage, no annotations, and no description of the output format or how playbook_id is obtained, the description leaves too much to inference. The sibling playbook.list.v1 suggests playbook IDs come from a list call, but this isn't stated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the single parameter. The description mentions playbook_id in its prose ('by playbook_id') which adds some meaning, but it doesn't explain what a playbook_id is, where to obtain one, or whether it references a file path or a semantic identifier documented elsewhere. The single parameter is barely described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource: 'Read a playbook/checklist text file by playbook_id.' It identifies what the tool does, though it conflates playbook and checklist somewhat. However, it doesn't distinguish from the sibling playbook.list.v1 (which presumably lists playbooks), so the differentiation from siblings 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided beyond the basic action. The sibling tools like playbook.list.v1 suggest there is a list-vs-read distinction that could be drawn, but the description doesn't clarify when to use this vs alternatives, nor does it state any prerequisites or context for 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 carries the full burden of behavioral disclosure. It fails to mention the 200-item default limit, whether pagination exists, what happens when the path doesn't exist, whether hidden files are included, or what the return structure looks like. For a listing tool covering potentially huge recursive trees, the absence of limit/overflow caveats is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, no filler, front-loads the core purpose. Appropriate size for the tool's simple surface area. It earns its place, though a second sentence on limits would strengthen it without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool involves directory traversal with a default limit, root-boundary constraints, and a path that defaults to '.'. The description leaves all behavioral nuances to inference. Given zero annotations and zero schema description coverage, the description does not compensate for a recursive listing tool that clearly carries more edge-case behavior than its text conveys.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so both params (path, limit) are undocumented in the schema itself. The description mentions recursion but says nothing about what 'path' means relative to WP_PROJECT_ROOT, what the default '.' resolves to, or the semantics/cap of 'limit'. The description adds essentially zero parameter meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it lists files inside WP_PROJECT_ROOT recursively, which is a clear verb+resource+scope statement. However, it doesn't add meaningful differentiation from sibling tools like list_project_files or project.files.read.v1, and the scope 'recursively' is the main distinguishing feature that isn't emphasized relative to alternatives. It's adequate but minimal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs project.files.read.v1, project.files.write.v1, or the near-duplicate sibling list_project_files. No mention of the root-boundary constraint (files outside WP_PROJECT_ROOT cannot be listed) or the default limit behavior. The 'recursively' scoping is the only implied usage signal.
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 behavioral burden. It indicates 'Update' implies mutation but doesn't disclose whether the change is reversible, whether it requires specific permissions, how partial updates (title only vs description only) are handled, or what happens to the other field when only one is provided. This is a write operation with no safety disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with zero waste. It's appropriately brief, though it could have used the space to add parameter clarification rather than just restating the tools' purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a simple 3-parameter schema with 1 required parameter, the description is thin for what is presumably a key SEO editing operation. There's no output schema explanation (though the tool has one in the output), no mention of validation behavior, and no note about how the custom endpoint differs from standard Yoast updates. The tool updates permanent SEO metadata, which warrants more behavioral disclosure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter documentation. The description mentions 'title and/or meta description' which maps loosely to the 'title' and 'description' parameters, but doesn't explain the semantics of partial updates (e.g., what happens if only title is provided). The 'post_id' parameter requirement is implied but never explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update Yoast SEO title and/or meta description via custom endpoint' clearly states the verb (update), resource (Yoast SEO title/meta description), and indicates it's a custom endpoint. However, it doesn't distinguish itself from the sibling 'update_yoast' tool which appears to serve the same purpose, creating ambiguity about which to use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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. Notably, there's a sibling tool named 'update_yoast' that likely serves a very similar purpose, yet no distinction or recommendation is offered. No prerequisites or context for when this custom endpoint should be preferred.
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 burden for behavioral disclosure. The phrase 'with write safety guards' hints at some protective mechanism but is vague—it doesn't explain what guards exist, whether they relate to the dry_run and require_approval fields, or what happens on write attempts. There's no mention of authentication requirements, rate limits, or intended effect for GET vs mutation methods.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise and front-loaded, but it's under-specified rather than efficiently concise. 'Universal WP REST request' repeats the tool's generic intent without adding discriminating detail, and the 'write safety guards' clause is imprecise without elaboration. It earns a pass for brevity but loses points for vagueness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generic passthrough tool with 5 parameters, 33 siblings, no annotations, and an output schema, the description is underdeveloped. It fails to clarify the relationship between dry_run/require_approval and the claimed safety guards, doesn't explain when to prefer this over specialized tools like wp_request or update_option, and leaves the agent to guess request shaping. While an output schema exists, the description's low value overall means the tool is incomplete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%—of 5 parameters, only 'path' has a schema-level description. The description compensates minimally by hinting at 'write safety guards' which may relate to dry_run and require_approval, but this is too indirect. Variables like body, method, dry_run, and require_approval receive no clarification in the description; the agent must infer their semantics from naming and schema types alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as a 'Universal WP REST request to /wp-json path' which is reasonably clear about what it does (make arbitrary WordPress REST API requests). 'Universal' hints at its generic nature, distinguishing it from the many specialized siblings. However, it lacks a specific verb+resource pattern and leaves ambiguity about scope beyond the wp-json prefix, though 'Universal' and the path schema provide some differentiation from sibling tools like wp_request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this generic tool versus the specialized alternatives (content.publish.v1, site.update_option.v1, etc.). With 33+ sibling tools offering targeted operations, an agent cannot determine when 'Universal...request' is appropriate versus using a purpose-built tool. No exclusions, no prerequisites, no when-not-to-use guidance 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 carries full burden for behavioral disclosure. It does not state what happens to inputs (destroyed?), whether it makes network calls to validate against a service, rate limits, expected output format, or side effects. It adds no meaningful behavioral detail beyond the stated action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no waste. However, it is under-specified — efficiency is high but at the cost of omitting needed information. For a one-line description with zero supplementary detail, it cannot earn a higher score for structure as it does nothing beyond the bare minimum.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (which offloads return-value documentation) and the tool's complexity (3 params, baseline/after comparison concept, level selection, raw HTML handling), the description provides almost no guidance. It does not explain the baseline/after comparison semantics, processing steps, expected inputs, or how results relate to sibling validate tools. Notably under-specified for the conceptual complexity implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for explaining the three parameters. It does not explain what baseline_pages vs after_pages means (beyond their names), how level ('error' vs 'warning') affects output, or what the url field is for. The names are somewhat self-explanatory but the description adds no semantic guidance beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Run baseline and after validation for provided raw HTML pages' has a specific verb (validate) and states the resource type (raw HTML pages). However, 'baseline and after validation' is a niche concept not explained, and it resembles sibling tools w3c.validate_pages.v1 (and its python alias) that likely also validate HTML. The purpose is moderately clear but lacks distinguishing detail against those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is given. The description does not explain what 'baseline and after' means, when this tool is preferred over validate_urls_raw or validate_pages siblings, nor what scenarios warrant running both baseline and after validation. There are no exclusions or alternatives named.
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 only states it's a DEPRECATED alias pointing to validation.w3c.validate_urls_raw.v1. It provides no behavioral detail about what the tool does with the URLs, what level filtering means, or any side effects. With no annotations provided, the description carries the full burden but fails to convey the actual validation behavior beyond the name itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences—one stating it's deprecated and one pointing to the replacement. It's compact and front-loaded with the key deprecation signal, but in the context of being an alias for the real tool it omits substantive operational detail that should accompany its brief form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for an 2-parameter tool with a validation verb. It doesn't explain what validation returns, what 'level=error' filtering accomplishes, or how it differs from sibling validation tools like validate_and_recheck or autofix_safe. Despite having an output schema, the description doesn't orient the agent on when results are actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is 0% schema description coverage, so the description must compensate by explaining what 'urls' and 'level' mean in the validation context. However, the description adds zero parameter information—'urls' and 'level' are only documented by the schema itself. The description completely fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies this as a deprecated alias for the canonical tool 'validation.w3c.validate_urls_raw.v1', which gives the agent a clear pointer to the intended behavior. However, it doesn't actually state what the tool does on its own—the purpose is only inferred from the referenced target. It does distinguish itself from siblings by name, but the substantive purpose is deferred entirely to the alias target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells the agent not to use this (since it's deprecated) and to use the replacement instead. This is an explicit exclusion and alternative, which is genuinely helpful guidance. However, it says nothing about when the underlying validation operation itself is appropriate, which is a context the agent still needs from the referenced 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 alias relationship and deprecation status. It does not describe what validation performs (e.g., W3C HTML conformance checking), return behavior, network dependencies, rate limits, or auth requirements. The deprecation warning is behaviorally relevant and useful, but beyond that, the agent learns nothing about how this tool behaves or what side effects (if any) it has. For a validation tool with zero annotations, this is a substantial gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that conveys deprecation and alias identity in minimal words. There is zero waste. However, this is under-specification rather than genuine conciseness—the description is brief because it omits nearly all functional content rather than because it efficiently captures everything needed. I'm crediting the brevity but noting the lack of functional substance prevents a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a validation tool with zero annotations, no behavioral detail, and an output schema present, the description should clarify what the validation covers, what the returns mean, and how the deprecated alias differs from its canonical replacement. It provides none of that. The target tool name in the description (validation.w3c.validate_pages.v1) is a sibling, which helps the agent locate the canonical implementation, but the description itself is not self-contained. For a tool meant to be invoked directly, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and there are only 2 parameters: pages (required, array of {url, html}) and level (enum error/warning, default error). The description adds nothing about these params. However, since both parameters have well-structured schemas (pages is self_explanatory as the HTML content to validate, and level is fully enumerated), the schema carries most of the semantic load. With only 2 params and clear enum values, the baseline-3 applies because the schema does the heavy lifting and the description doesn't need to compensate heavily.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'DEPRECATED alias for validation.w3c.validate_pages.v1.' This identifies the purpose via the alias target, but it's essentially a pointer to another tool rather than a self-contained statement of what the tool does. It tells the agent this is the deprecated alias of the v1 canonical tool, which conveys that its functionality matches that target, but it doesn't describe the actual behavior (validating HTML pages) in its own words. The naming and target-reference make the core purpose inferable, but for a deprecated alias the description arguably heightens rather than resolves confusion: the agent must look up the canonical tool to understand what this does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states this is deprecated, implying the agent should prefer the canonical sibling (validation.w3c.validate_pages.v1) and not use this alias. That's a form of when-not-to-use guidance. However, it does not explicitly say 'use validation.w3c.validate_pages.v1 instead' nor explain any alternative like w3c_validate_live_urls_raw vs pages-level validation, or the validate_and_recheck/autofix siblings. For a deprecated alias, the when-to-use guidance is effectively 'when you want the old version'—but minimal practical alternative direction is missing.
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. The description mentions 'safe file autofix' which implies in-place modification of files, but it does not state whether this permanently mutates project files, what files are affected, whether the operation is reversible, or the nature/volume of validation output. For a tool that performs file autofix (a side-effecting operation), this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, which is structurally sound. However, it fails to front-load any parameter or usage guidance, packing limited value into the sentence available. Given the tool's complexity (5 params, autofix with side effects), a single 13-word sentence under-specifies rather than demonstrating genuine efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the description needn't explain return values, which helps. However, for a tool combining file autofix (a destructive/mutating operation) with W3C validation, the description omits critical context: which files get modified, whether paths restricts the scope, how level (error vs warning) affects the autofix threshold, and how baseline_pages/after_pages interplay. The 'safe' qualifier does some work but leaves too much to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full burden for parameter meaning. The description 'Run safe file autofix and W3C before/after validation' implies the baseline_pages/after_pages parameters map to before/after states, and 'safe' implies max_files limits scope, but none of the 5 parameters (level, paths, max_files, after_pages, baseline_pages) are explicitly explained. With high parameter count and zero schema coverage, the description does not compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource combination: 'Run safe file autofix and W3C before/after validation on raw HTML pages.' It distinguishes the tool from siblings by mentioning 'safe' autofix and 'raw HTML pages,' which differentiates it from w3c_validate_urls_raw (URL-based, no autofix), w3c_validate_pages (validation only), and w3c_validate_and_recheck. The purpose is clear, though it doesn't explicitly name sibling 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/5
Does 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. Given the sibling set includes w3c_validate_urls_raw, w3c_validate_pages, and w3c_validate_and_recheck, an agent would benefit enormously from knowing when autofix is appropriate versus when only validation or URL-based checking should be used. The description offers no 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It doesn't state what the tool returns (output schema exists but the description doesn't mention it), whether there are network dependencies on the W3C service, rate limits, or what happens on validation failure. For a tool that makes an external network call to a validation service, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that's easy to parse. It's appropriately short for a validation tool with simple parameters. However, it could have added a bit more value in the same length (e.g., mentioning it's non-destructive, or the level default behavior).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is an output schema and the parameters are relatively simple, but as a network-dependent external service call with multiple similar sibling tools, the description should clarify the distinguishing scenario (raw HTML vs live URLs) and what the tool does after validation (just reports? Does it optionally fix warnings?). It's adequate for basic use but incomplete for ambiguity resolution.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, the schema itself is fairly self-documenting: pages (array of objects with html and url), level (enum error/warning). The description mentions 'raw HTML pages' which maps to the pages.html field. The level parameter is not explained in the description but its enum values are self-explanatory. Does not fully compensate for 0% coverage but the schema does decent work on its own.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool validates raw HTML pages through the W3C Nu Validator, which is specific enough (verb=validate, resource=raw HTML pages, through=Nu Validator). However, it doesn't distinguish from sibling tools like validate_urls_raw.v1 or validate_and_recheck.v1, which presumably also involve W3C validation. The scope (raw HTML vs URLs) is a differentiator, but the description doesn't explicitly call it out.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 vs alternatives. Given siblings like validation.w3c.validate_urls_raw.v1, validation.w3c.validate_and_recheck.v1, and validation.w3c.autofix_safe.v1, the agent needs to know that this tool is for raw HTML content (not URLs) and that it's validation-only (no recheck, no autofix). None of this is stated.
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 behavioral burden. It does not disclose that this is a network operation hitting an external service, potential rate limits, latency, side effects, or what happens on validation failure. 'Using fetched raw HTML' hints at the fetch mechanism but provides no details about network behavior or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is appropriately brief, though it could benefit from one additional sentence about usage or parameters without hurting conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool is a network-mutating external-service call with two undocumented parameters, zero annotation coverage, and a meaningful sibling cluster (validate_pages, validate_and_recheck, autofix_safe). The description does not clarify how this tool differs from validate_pages, what level thresholds mean, or how results are signaled. This is materially incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for both parameters. It mentions neither 'urls' nor 'level'. The 'level' parameter has an enum (error/warning) but no explanation of what each value means in context, and 'urls' semantics (format, count limits) are entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('Validate live URLs through W3C Nu Validator using fetched raw HTML'). It clearly distinguishes from siblings like validate_pages (which likely validates rendered pages) by noting it uses 'fetched raw HTML', giving some differentiation among the w3c_* sibling cluster.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no when-to-use guidance, no exclusions, and no mention of alternatives. Among siblings like validate_pages and validate_and_recheck, there is no indication of when to choose raw HTML validation over page-based validation or when rechecking/autofix would be more appropriate.
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 does not mention error handling for nonexistent files, whether large files are truncated, encoding assumptions, or what the response structure looks like. Since there is an output schema, some return structure may be captured there, but behavior around access, errors, and file-size limits is undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no wasted words. It is appropriately minimal and front-loaded for such a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, text-only reads), the description is adequate but not complete. The output schema exists, which likely covers return values. However, it lacks details on file-size limits, error cases, path conventions, and differentiation from the closely named sibling 'read_project_file.' For a single-verb single-parameter tool this is acceptable but leaves notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter (path) and schema description coverage is 0%, which is low. The description adds 'text file' indicating non-binary files, but does not clarify whether path is relative to WP_PROJECT_ROOT, whether absolute paths are allowed, or expected format (e.g., leading slashes). With a single parameter and a naming convention suggesting 'project.files' scope, the description does not significantly enrich the schema's bare 'path' string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Read text file from WP_PROJECT_ROOT,' which specifies a verb (read) and a resource (text file within a project root). It's clear about the tool's basic function, but does not describe what content is returned, whether binary files are supported, or how it differs from the sibling 'read_project_file' tool whose name suggests overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like 'read_project_file' or 'content.list.v1.' There's no mention of prerequisites (e.g., whether the file must exist, path requirements) or when an alternative should be chosen. The context implies it's for reading text files from a project root directory, but this is only implicit.
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 disclosing behavior. The description only marks it as deprecated; it doesn't reveal what operation it performs (mutation), what it affects, or whether it still functions or errors. The deprecation status is the only behavioral signal, which is minimal for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one short sentence: 'DEPRECATED alias for site.update_option.v1.' It's concise and front-loaded with the most important information (deprecation and replacement). It earns its place despite being short, though it could be less terse by including the replacement tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter mutation tool with no annotations and 0% schema description coverage, this is under-specified. The description gives only deprecation info. While the output schema exists and the enum self-documents, the description doesn't explain what each key does (blogname, blogdescription, blog_public), what the value format should be, or what the outcome is. Since the tool is deprecated and points to a live sibling, completeness is somewhat mitigated, but it's still thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. However, the input schema itself is fairly self-explanatory: 'key' is an enum of three options (blog_public, blogdescription, blogname), and 'value' is a generic field. The schema provides the semantics via the enum values, and the description adds nothing about parameter formats or effects. Baseline 3 is appropriate since the enum makes key self-documenting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only states it's a 'DEPRECATED alias for site.update_option.v1.' This tells the agent the tool is deprecated and points to a replacement, but doesn't describe what the tool actually does (updates site options). The purpose is only indirectly inferrable from the sibling name and parameter names, not from the description itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states this is deprecated and should be replaced with site.update_option.v1. This is excellent deprecation guidance — the agent knows to prefer the sibling tool. It doesn't elaborate on when to use it, but the deprecation notice effectively tells the agent NOT to use this tool in favor of the named alternative.
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. The description says 'Create' implying a write action, but doesn't disclose side effects — whether it publishes, replaces existing content, requires authentication, has rate limits, what happens to drafts, or how Polylang relationships are managed. For a mutation tool with zero annotation coverage, this is a clear gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with zero waste. It front-loads the core purpose. Could arguably be expanded with behavioral details, but for what it contains, it's tight and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with no annotations and incomplete schema coverage (50%). It has nested object structures and an output schema, but the description doesn't explain return values, error cases, how translations are keyed to locales, or what 'publish' means in context (draft default vs published state). For a tool with nested complexity and this many siblings, the description is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%. The translations parameter has a helpful example showing the locale-title-content structure, which carries much of the semantic load. However, the 'status' parameter (default 'draft') is only in the schema with no description in the description text, and its allowed values/behavior are not explained. The description adds minimal parameter value beyond the schema example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('Create multilingual WordPress post variants via Polylang'). It clearly identifies what the tool does — creating multilingual post variants. However, it doesn't distinguish itself from sibling tools like create_post_multilang or content.update_fields.v1, which could overlap in function. The purpose is clear but sibling differentiation is missing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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. Sibling tools include create_post_multilang (likely overlapping purpose), content.update_fields.v1, and checklist.multilang_publish.v1, yet the description provides no when-to-use or when-not-to-use direction. No exclusions or alternative recommendations are offered.
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 fails this: it doesn't state whether this is a read-only operation, whether it makes external HTTP requests to the URL, whether it modifies anything, or what side effects occur (e.g., does it consume crawl quota?). 'Run a checklist' implies analysis but gives no transparency about what happens behind the scenes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with zero filler. However, it is notably under-specified for a tool with 3 parameters including a boolean flag and an enum, so while concise, it doesn't carry enough information to be 'front-loaded' with value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, which offloads return-value documentation. The tool is moderately complex (3 params, enum, boolean with defaults). However, the description leaves significant gaps: the meaning of 'level' and 'include_messages' is unexplained, and no guidance on expected URL format or prerequisites. It's minimally viable but not complete for a 3-param tool with an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for documenting the parameters, but it doesn't. It doesn't explain what 'level' (error/warning) controls, what 'include_messages' returns, or what format the 'url' must be in. With an output schema present, some return details may be discoverable, but the meaning of the two optional flags is undocumented in the description entirely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Run') and resource ('a standard SEO landing QA checklist') for one URL. It distinguishes the scope ('one URL' singleton) from sibling tools like 'checklist.w3c_validate_and_fix_plan.v1' which imply plan generation, and SEO meta sibling tools like 'seo.set_meta.v1' which mutate rather than audit. However, it doesn't explicitly name an alternative or contrast behavior beyond implying single-URL scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage is for running an SEO QA check on a single landing page URL, which gives some context. But it provides no explicit when/when-not guidance, no mention of prerequisites (e.g., URL must be live/public, or already published), and no contrast with sibling tools like validation.w3c.validate_urls vs this SEO-specific audit. Usage is only weakly implied.
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 does not disclose return format, whether the list includes read-only data, pagination behavior, or any ordering/filtering semantics. For a read/list operation with zero annotation coverage, the description should at least hint at what kind of output to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, zero filler. Front-loads the verb 'List' and specifies the resource type. Slightly abbreviated ('MCP-guided SEO workflows') but efficient given the tool has no parameters to document.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is an output schema present, which lowers the burden for documenting return values. The tool is a simple parameterless list operation, so the description is mostly adequate. However, without annotations and with no clarity on how it relates to playbook.read.v1 or checklist.* tools, it falls short of fully complete for a complex sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so there is nothing for the description to explain. The baseline for 0-parameter tools is 4. The description accurately sets context that the result is a list of playbooks/checklists, which is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List text playbooks/checklists for MCP-guided SEO workflows' clearly states the verb (list), resource (playbooks/checklists), and purpose context (SEO workflows). It differentiates reasonably from siblings like playbook.read.v1 (which presumably reads a specific playbook). It doesn't distinguish from checklist.* siblings, but the 'playbooks/checklists' combined mention covers both.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. With siblings like playbook.read.v1 and various checklist.* tools, an agent would benefit from knowing that this tool lists available playbooks before reading one, or how it differs from checklist tools. No exclusions or contextual cues beyond the generic SEO workflow mention.
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. The description reveals the tool is deprecated but says nothing about what it returns, side effects, access requirements, or any other behavior. For a file-read tool with zero annotation coverage, this leaves the agent unsure of the actual operational semantics beyond knowing it's a deprecated alias.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, a single declarative sentence stating deprecation and the canonical replacement. There is zero waste; however, it borders on under-specification rather than genuine efficient fullness, which caps the score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, which reduces the need to document return values. Given the tool is a simple deprecated alias with one parameter, the description arguably provides necessary guidance (deprecation status + canonical reference). However, for a tool that an agent might actually need to invoke (the alias may still function), omitting any behavioral detail is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and there is only one parameter 'path'. The description adds no semantic detail about the 'path' parameter beyond the schema's type declaration. However, given the tool is a deprecated alias, the parameter semantics are reasonably inferable from the canonical tool; still, the description itself contributes no added meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool is a 'DEPRECATED alias for project.files.read.v1', which identifies its purpose as the deprecated version of reading a project file. However, it never states what the tool actually does (read file contents) directly; it only references the canonical tool. The verb 'read' is implied via the alias target, but the description lacks an explicit statement of the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
By explicitly marking itself as 'DEPRECATED' and pointing to 'project.files.read.v1', the description gives clear guidance: do not use this tool, use the canonical alias instead. This effectively differentiates it from the active sibling project.files.read.v1 and directs the agent to the correct alternative.
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 behavioral disclosure. It confirms this is a write/mutation operation ('Update') but does not disclose whether changes take effect immediately, whether site cache is invalidated, whether multi-site options are affected, or any side effects. With zero annotation coverage, the description should disclose more about behavioral consequences of modifying site options.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the verb and resource, and includes the critical allowed-keys list. No filler. It's efficient, though it could be restructured to lead with the allowed keys more prominently rather than appending them.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-param tool with an enum covering one param and an output schema present, the description is adequate but not complete. The open 'value' parameter lacks any guidance on expected formats (boolean for blog_public, string for blogname/blogdescription), and no behavioral context is given. Given zero annotations, a mutation tool that writes to a site's wp_options should disclose more to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. 'Allowed keys: blog_public, blogdescription, blogname' adds value by clarifying which keys are valid, which reinforces the enum. However, it does not explain the expected format/type of the 'value' parameter (e.g., string vs int for blog_public), which is critical since 'value' is typed as an open object with no schema constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('Update wp_options via custom endpoint') and lists the allowed keys, which clearly differentiates what keys can be updated. It's clear in purpose, though the mention of 'custom endpoint' is slightly vague about what underlying mechanism is used. It distinguishes itself reasonably from siblings like update_option and wp_request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description names the allowed keys, which implicitly communicates scope. However, it provides no when-to-use guidance, no exclusions relative to siblings like 'update_option', 'wp_request', or 'content.update_fields.v1', and no indication of when one should prefer this over alternatives. The usage context is implied by the key enum 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 carries the full burden. While 'DEPRECATED' signals that it should not be used, the description provides no behavioral details: whether it still functions, whether it will fail, whether it maps identically to the alias target, or what side effects occur on invocation. The agent cannot infer the operational behavior from this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single terse sentence that fully conveys the essential information (deprecated, alias target). Zero waste, perfectly front-loaded with the DEPRECATED signal at the very start. Though minimal to the point of sparseness, this is high-value efficiency for a tool that should simply route elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this tool is a deprecated alias with an output schema present, the description is arguably adequate to route users away. The output schema covers return-value expectations. However, nothing documents the update semantics, partial-update behavior, or error conditions. For a tool flagged as deprecated, completeness relative to need is moderate — it fulfills the disambiguation role but lacks behavioral depth.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 2 undocumented parameters (post_id as number, fields as free-form object), neither the schema nor description provides type-specific context. The field names themselves (post_id, fields) are suggestive but the description adds nothing beyond the schema. Baseline 3 is warranted since the parameter names are reasonably self-explanatory but no semantic refinement is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'DEPRECATED alias for content.update_fields.v1' clearly states the tool's purpose: it updates fields, and specifically identifies it as a deprecated alias pointing to the canonical sibling content.update_fields.v1. This gives good verb+resource clarity and immediately differentiates it from siblings by instructing users to use the non-deprecated version instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly directs users to the replacement tool (content.update_fields.v1), which serves as an exclusion/alternative guidance. However, it does not explicitly state 'do not use this' beyond the DEPRECATED marker, nor describe when one might still need it (if ever), leaving slight ambiguity about whether it remains functional.
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 states the tool writes a file to the filesystem, but does not disclose whether 'write_report=true' is required, whether the write overwrites existing content, what failure modes exist (e.g., insufficient permissions), or the format/structure of the generated summary. A file-writing tool with zero annotation coverage should disclose more behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no filler, front-loaded with the verb+action. Could arguably add a bit of detail (report format or side effects), but as a compact statement of intent it is efficient and complete for its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a 5-parameter schema with 2 required arrays, 3 optional/defaulted params, a writable boolean, and a nested object structure in the arrays. There is an output schema present, so return-value explanation isn't required. However, with zero annotation coverage and a file-write side effect, the description remains thinner than warranted—it doesn't state what the benchmark summary contains, how statistics are computed, or any behavior around the output_path/write_report flags.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The description clarifies the semantic relationship between the two required run arrays (prompt-only vs MCP comparison) and the report-writing behavior. However, it does not individually explain what 'manual_fixes', 'retries', and 'duration_ms' measure—though the schema field names are fairly self-explanatory, and the description covers the core intent of the two large array params and the output file behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Compare prompt-only vs MCP runs and write benchmark-summary.md'. This clearly distinguishes the tool from content/project/seo/w3c siblings by situating it in the benchmark domain. The comparison and file-write outcomes are both explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the when-to-use context ('for developer demos') but provides no explicit guidance on when NOT to use this tool or what alternatives exist among the benchmark-adjacent siblings. The sibling set has no comparable benchmark tool, so differentiation isn't required, but no exclusion criteria or prerequisite steps (e.g., requiring completed run logs) are stated.
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?
The description clearly discloses the deprecation status, which is a critical behavioral trait. With no annotations provided, the description carries the full burden, and 'DEPRECATED' is a strong signal that this is an older/legacy entry point. The implication is that the canonical tool should be preferred and may have more up-to-date behavior or parameters. This is adequate disclosure given the tool is intentionally a thin alias.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that delivers maximum signaling value. 'DEPRECATED' is front-loaded and the canonical tool reference is unambiguous. For a pure alias/deprecation notice, this is appropriately minimal — nothing extraneous, though more param guidance would have been welcomed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deprecated alias pointing to a fully specified canonical tool, the description is functionally adequate — the agent can route to project.files.write.v1 which presumably has a complete description. Output schema exists, so return values are covered. However, it doesn't convey the actual behavior (writing a file to a project), leaving the agent with only the canonical tool name to infer semantics. Given the complexity of the tool is low, this is mostly but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 2 parameters (path, content), the description adds no parameter meaning whatsoever. It doesn't explain what path and content should contain — though these are semantically straightforward for a file-writing tool. The description's entire value is the deprecation notice, not parameter documentation. For 0 params a baseline of 4 applies, but with 2 meaningful params and no help, a lower score is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies this as a deprecated alias for project.files.write.v1. The word 'DEPRECATED' signals the tool should not be preferred. The reference to the canonical tool is specific and helpful for an agent to route to the correct alternative. However, it doesn't explicitly state what the tool does (write a project file), instead relying on the referenced canonical 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly points to the correct tool to use instead (project.files.write.v1), giving clear routing guidance. The 'DEPRECATED' marker strongly signals to avoid this tool. However, it doesn't explain when someone might still want to use this alias, though for a deprecated alias, steering to the alternative is the primary guidance needed.
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:

[![wp-mcp-custom MCP server](https://glama.ai/mcp/servers/YanaShuvaieva/wp-mcp-custom/badges/card.svg)](https://glama.ai/mcp/servers/YanaShuvaieva/wp-mcp-custom)

Score Badge

Copy to your README.md:

[![wp-mcp-custom MCP server](https://glama.ai/mcp/servers/YanaShuvaieva/wp-mcp-custom/badges/score.svg)](https://glama.ai/mcp/servers/YanaShuvaieva/wp-mcp-custom)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/YanaShuvaieva/wp-mcp-custom'

If you have feedback or need assistance with the MCP directory API, please join our Discord server