Clearon WordPress MCP

by kwgoodwin

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation3/5
Most tools map to distinct actions, but get_server_health overlaps with get_auth_mode and get_endpoint_config, and get_post/find_posts have similar retrieval purposes. The three disabled tools set_social_meta, set_featured_image, and upsert_share_block share nearly identical 'use a reviewed payload workflow' descriptions, which adds ambiguity.
Naming Consistency4/5
The set mostly follows a verb_noun snake_case pattern like get_post, upload_media, audit_slug_state, and resolve_duplicate_posts. Minor deviations such as publish_now and the mix of set_/upsert_ for disabled mutation tools keep it from being fully consistent.
Tool Count4/5
13 tools is a reasonable size for a WordPress publishing server. However, three of those tools are disabled stubs that add clutter rather than functionality, so the effective tool surface is closer to 10.
Completeness3/5
The active tools cover post retrieval, payload-based upsert/publish, media upload, and duplicate management. Notable gaps remain: no direct way to set featured images or social meta, no general media retrieval, and no delete/update flow outside the payload workflow.
Average 3.2/5 across 13 of 13 tools scored. Lowest: 2.4/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
This repository is licensed under MIT License.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavior itself. 'Create or update' signals mutation but nothing about dry-run semantics, publishing/scheduling side effects, overwrite behavior, idempotency, or required permissions. The description is not misleading, but it is far too minimal.
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 filler and no redundant restatement of the tool name. It is concise, though its brevity comes at the cost of substance.
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?
This is a mutation tool with four parameters, two enums, no annotations, and no output schema, yet the description says almost nothing about behavior, modes, target selection, or expected effects. An agent would not be able to call this tool reliably based on the provided description alone.
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?
Schema description coverage is 0%, and the description provides no parameter-level explanation. It does not clarify payload_path, mode, intended_mode, or explicit_target_id, leaving the agent to guess the meaning and interaction of these parameters.
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 tool creates or updates a WordPress post from a payload JSON file, using a specific verb and resource. It is understandable on its own but does not explicitly distinguish itself from siblings like upload_media, publish_now, or upsert_share_block.
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 about when to use this tool versus alternatives. The phrase 'from an existing payload JSON file' implies a narrow use case, but no explicit conditions, exclusions, or preferred alternatives 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the upload action but does not mention side effects, required authentication, supported file types, destination behavior, or whether it replaces existing media. This is minimal for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler. However, it is so brief that it under-delivers on context that other dimensions measure. As pure conciseness it is good, though not exemplary because it omits important guidance.
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?
With no annotations, no output schema, four undocumented parameters, and sibling tools that could overlap, this description is incomplete. An agent would struggle to know how to set post_id or filename, what the upload returns, or how this relates to set_featured_image.
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?
Schema description coverage is 0%, and the description does not clarify any of the four parameters. 'path', 'post_id', 'alt_text', and 'filename' remain entirely unexplained, and the description adds no meaning beyond the schema's bare field names.
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 action ('Upload') and the resource ('a local asset to WordPress media library'). It is specific and distinguishes the operation from reads or post-related mutations, though it does not explicitly differentiate from sibling tools like set_featured_image.
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 implies usage when uploading local media, but provides no guidance on when to use this tool versus alternatives such as set_featured_image, no prerequisites, and no exclusions. An agent gets no routing help beyond the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does disclose the key behavioral trait: the tool is disabled. It does not describe what happens if called, such as an error or no-op, or explain why direct mutation is disallowed, but 'disabled' is meaningful and prevents the agent from expecting a normal mutation.
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 extremely compact, with both sentences earning their place: the first states the disabled status and the second gives the replacement path. It is front-loaded and contains no filler.
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 disabled tool with a single parameter and no output schema, the description adequately signals not to use it and points to an alternative workflow. However, it does not explain the original purpose, the exact alternative tool, or what 'reviewed payload workflow' refers to, leaving some ambiguity.
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?
The schema has one required parameter, post_id, with no description, and schema description coverage is 0%. The tool description does not explain the meaning, role, or format of post_id, so the agent receives no semantic guidance for this parameter.
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 labels the tool as a 'Disabled direct mutation tool,' which conveys status and general action type, but never states what a 'share block' is or what the tool originally did. It does not clearly distinguish this tool from siblings beyond saying it is disabled.
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 explicitly instructs to 'Use a reviewed payload workflow instead,' which provides an alternative path and implies this tool should not be used. However, it does not name a specific sibling tool or define what the reviewed payload workflow entails, leaving the routing somewhat vague.
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. 'Fetch' implies a read operation, but the description does not explain what happens when the post is not found, whether a single object is returned, or how the context parameter changes behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence with no filler. It leads with the verb and resource and immediately gives the key lookup parameters.
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 too thin for a tool with three parameters, zero schema-documented parameters, no output schema, and several closely related sibling tools. It omits the context parameter, does not describe the return value or error behavior, and gives no routing guidance versus find_posts.
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. It explains that id and slug are lookup identifiers, but it does not clarify whether they are mutually exclusive, preferred, or how the context parameter affects the result. The context parameter is left 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 ('Fetch'), a specific resource ('a WordPress post'), and the lookup keys ('by id or slug'). It is clear enough to distinguish a direct single-post fetch from sibling tools like find_posts, though it does not explicitly contrast them.
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?
Usage is implied: use this tool when you have a post id or slug and want the corresponding post. However, it provides no explicit guidance about when not to use it or which sibling tool to use instead for searching or listing multiple posts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It does not state what is returned, whether multiple matches are possible, whether matching is exact or partial, how to interpret both slug and title being provided, or any limits or side effects.
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 states the core function without filler. It is front-loaded and easy to parse, though the unexplained 'context' parameter means it is slightly too sparse to earn 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?
The description is not complete for a tool with no output schema, no annotations, and four undocumented parameters. Missing elements include return semantics, relationship to sibling tools, exact matching behavior, and the role of the 'context' parameter. An agent would likely need additional information to invoke it correctly in ambiguous cases.
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?
The description adds meaning for slug, title, and status, which is necessary since schema description coverage is 0%. However, the 'context' parameter is completely unexplained, and status values are not enumerated or clarified, leaving a meaningful gap in parameter understanding.
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 clearly states the action ('Find'), the resource ('WordPress posts'), and the lookup keys ('by slug or title'), with optional status filtering. This distinguishes it from sibling tools like get_post, which appears to retrieve a single post directly.
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 given about when to use find_posts versus get_post, audit_slug_state, or resolve_duplicate_posts. There is no mention of use cases, exclusions, or alternative tools, so the agent must infer usage from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully convey behavioral traits. 'Report' weakly implies a read-only operation, but the description does not explicitly state that it has no side effects, whether authentication is needed, or what 'endpoint basics' includes in practice. This leaves important behavior 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that names the core purpose immediately. Every word adds meaning and there is no repetition or filler.
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 is simple (no parameters, no output schema), so a short description is partly acceptable. However, because there is no output schema, the description should clarify what kind of health information and 'endpoint basics' are returned. The lack of distinction from sibling tools also leaves the overall context incomplete.
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 zero parameters and the schema coverage is effectively complete, so there is no parameter documentation burden for the description to carry. The baseline of 4 applies because no parameters exist and the description adds no parameter-related confusion.
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 names a specific action ('Report') and a clear resource scope: local server health, auth mode, and endpoint basics. It is understandable and distinguishes itself as a broad health/status aggregate, though 'endpoint basics' is somewhat vague and could overlap with sibling tools like get_auth_mode and get_endpoint_config.
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 is provided about when to use this tool versus the more specific sibling tools get_auth_mode and get_endpoint_config. Because this tool appears to aggregate those areas of information, an agent could mis-select it or the siblings without clearer direction.
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, so the description alone must disclose behavioral traits. It does add 'immediately', 'existing prepared post', and 'same safety gates and verification' as context, but it never explains what those gates are, whether publishing is reversible, who can do it, or what side effects occur. The optional publish_at_local parameter also sits awkwardly with the word 'immediately', creating unclarity about the actual scheduling 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?
The description is a single sentence with no filler, and it front-loads the core action and target. The clause 'same safety gates and verification used by payload upserts' is somewhat vague but does not make the definition bloated.
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?
Without annotations or an output schema, a publish operation needs more surrounding context: preconditions, irreversibility, expected result, and the meaning of publish_at_local. The description refers to an unnamed payload-upsert workflow and leaves these gaps, so it is incomplete for safe autonomous 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 0%, so the description had to compensate for the three parameters. It loosely ties post_ id to an existing post and payload_path to a reviewed payload, but it does not explain the format or role of either value, and publish_at_local is completely unaddressed. This leaves a required parameter path insufficiently defined for a rg entt to invoke the tool correctly.
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 names a specific verb, 'publish', a specific target, 'an existing prepared post', and a specific timing, 'immediately', which makes the tool's purpose clear. The phrase 'from a reviewed payload' further separates it from creating or upserting content, so an agent can distinguish it from sibling upsert_post_from_payload.
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 workflow: an existing, prepared post plus a reviewed payload should be published now. It does not explicitly state when to avoid this tool, nor does it name the sibling that handles creating/updating a post from a payload, so the routing guidance remains implicit rather than explicit.
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 entire burden. 'Audit' and 'expose' suggest a read-only diagnostic that returns candidate duplicates, which is useful behavioral context. However, it does not disclose whether the operation mutates state, what permissions are needed, or how failures are surfaced.
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?
Single sentence, front-loaded with the verb, and every phrase adds information: scope ('live state'), target ('slug'), and outcome ('expose duplicate candidates'). No wasted words.
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?
With no annotations, no output schema, and no sibling guidance, the description is too spare to fully support correct invocation and result interpretation. It explains what the tool does but not what the audit output looks like, when this audit should be run, or how it relates to the duplicate-resolution workflow.
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 only parameter is an undocumented 'slug' string. The description repeats the term 'slug' without adding format, source, examples, or constraints, so it does not compensate for the missing schema documentation.
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?
Description uses a specific verb ('Audit') with a clear resource ('live state of a slug') and an explicit outcome ('expose duplicate candidates'). This distinguishes it from sibling tools like get_post/find_posts (retrieval) and resolve_duplicate_posts (reselution): it is the diagnostic/screening step.
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 versus siblings such as find_posts or resolve_duplicate_posts. 'Expose duplicate candidates' implies a pre-reselution audit, but the description does not state that or exclude alternatives, so an agent must infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It does state the main outcomes—trashing, deleting, or downgrading—which is meaningful. However, it does not disclose that delete may be permanent, how confirm_permanent_delete factors in, or whether the operation is reversible.
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 a single sentence that front-loads the core purpose and immediate action categories. There is no wasted phrasing or filler that could dilute the instruction.
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 tool has no annotations, no output schema, and four parameters with zero schema descriptions. The description does not provide enough context for an agent to correctly construct the call, especially around which IDs are canonical vs duplicates and when confirmation is required. It is minimally functional but lacks important operational detail.
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 explain the parameters itself. It mentions 'duplicate posts' and the general action categories, but never explains canonical_post_id, duplicate_post_ids, or confirm_permanent_delete. The enum actions are partly reflected in the description, but the essential distinction between canonical and duplicate IDs is left implicit.
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 uses a specific verb 'clean up' and a clear resource 'duplicate posts', then names the exact actions: trashing, deleting, or downgrading. This clearly distinguishes it from sibling tools like find_posts or get_post, which are lookup-oriented rather than resolution-oriented.
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 given about when to invoke this tool versus alternatives. The word 'Explicitly' implies it should be used after duplicates are already identified, but it never states that prerequisites, nor does it name alternatives such as find_posts for detection. An agent must infer the context entirely from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It clearly states the tool is disabled for direct mutation, which is a critical behavioral trait that prevents misuse. It does not explain what happens if called, but 'disabled' is sufficiently transparent for an agent to avoid invoking it.
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 two short sentences with no filler. It front-loads the critical 'Disabled' status and immediately follows with the alternative workflow. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that is meant to be avoided, the description provides the essential information: it is disabled and an alternative workflow should be used. It could name the specific replacement tool, but the sibling list and the phrase 'reviewed payload workflow' give enough context to route the agent correctly.
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?
Schema description coverage is 0% and the description provides no explanation of post_id or media_id. Since the parameters are completely undocumented and the description adds no parameter context, an agent cannot understand what values to pass. Even though the tool is disabled, the description fails to compensate for the schema 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 says 'Disabled direct mutation tool' but never states what the tool actually does (i.e., setting a featured image on a post). It clearly communicates status, but the function is left to inference from the tool name. This is a vague purpose statement rather than a specific verb+resource description.
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 labels the tool as disabled and instructs to 'Use a reviewed payload workflow instead.' This provides clear when-not-to-use guidance and points to an alternative, though it does not name the exact sibling tool (e.g., upsert_post_from_payload).
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?
There are no annotations, so the description carries the full burden, and 'Disabled' is a critical behavioral disclosure: this tool should not be invoked directly. It does not detail what happens if called, but for a disabled tool the status itself is the primary safety-relevant signal.
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 compact sentence that front-loads the most important information ('Disabled') and immediately provides a redirect. There is no wasted text or redundant restatement of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a disabled mutation tool with no output schema, the description supplies the essential context: do not use it directly and route through a reviewed payload workflow. The only gap is that the reviewed payload workflow is not concretely identified, leaving some ambiguity for an agent.
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?
Schema description coverage is 0%, and the description adds no meaning or usage context for post_id, og_image_type, twitter_use_og, or twitter_image_type. The disabled guardrail makes calling unlikely, but parameter semantics are effectively 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 clearly communicates that the tool is disabled and is a mutation-type operation, but it never states what resource or property it mutates. An agent must rely on the tool name set_social_meta to infer the actual purpose, and the description does not distinguish it from sibling mutation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly warns that the direct tool is disabled and tells the agent to use a reviewed payload workflow instead. This is strong when-not-to-use guidance, but the alternative is not tied to a named sibling tool, so it is not fully actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. 'Report' signals a read-only, non-mutating operation, which is transparent about the core behavior. Yet it does not disclose the return format, potential failure modes, or whether any configuration is required before calling, leaving some behavioral aspects unspecified.
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 a single, front-loaded sentence with no filler. Every word contributes to meaning, making it an ideal example of concise, well-structured documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description gives enough to understand its purpose and expected informational result. It could add the exact return type or possible auth source values, but the lack of these is a minor gap given the tool's simplicity.
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?
With zero parameters and 100% schema coverage, the schema fully describes the input surface. The baseline for zero-parameter tools is 4, and the description correctly adds no parameter information because there is nothing to add.
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 (Report) and a precise resource (the WordPress auth source the server will use), making the tool's function immediately clear. The resource term 'auth source' is specific enough to distinguish it from siblings like get_endpoint_config or get_server_health, even without naming alternatives.
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 when to use the tool: when an agent needs to know the server's selected auth source. However, it provides no explicit context, exclusions, or comparison to alternatives such as get_endpoint_config, so the usage guidance remains inferred rather than explicit.
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 full burden. The word 'Report' correctly implies a read-only operation, but the description does not disclose output format, authentication implications, or failure behavior. For a simple no-parameter getter this is acceptable but not richly transparent.
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 a single, front-loaded sentence with no redundant wording. Every word contributes to understanding what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's zero-parameter simplicity, the description is largely complete: it names exactly what is reported. The absence of an output schema means exact return formats are not specified, but the core information an agent needs to invoke it correctly is present.
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 zero parameters, so there are no parameter semantics to document. The baseline of 4 is appropriate because the description cannot add meaningful parameter-level detail beyond what the empty schema already communicates.
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 uses a specific verb ('Report') and names the exact resource: the target WordPress base URL and REST endpoint configuration. This clearly distinguishes it from sibling tools like get_server_health and get_auth_mode.
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 this tool is used to retrieve endpoint/base URL configuration, but it provides no explicit when-to-use guidance or exclusions relative to sibling tools. The zero-parameter signature reduces ambiguity, but a brief alternative note would improve it.
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:

[![clearon-wordpress-mcp MCP server](https://glama.ai/mcp/servers/kwgoodwin/clearon-wordpress-mcp/badges/card.svg)](https://glama.ai/mcp/servers/kwgoodwin/clearon-wordpress-mcp)

Score Badge

Copy to your README.md:

[![clearon-wordpress-mcp MCP server](https://glama.ai/mcp/servers/kwgoodwin/clearon-wordpress-mcp/badges/score.svg)](https://glama.ai/mcp/servers/kwgoodwin/clearon-wordpress-mcp)

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/kwgoodwin/clearon-wordpress-mcp'

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