wordpress-mcp

Server Quality Checklist

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

Latest release: v1.0.5
Disambiguation5/5
Each tool targets a distinct resource and action (e.g., wp_get_page vs wp_list_pages, wp_create_post vs wp_create_comment). There is no ambiguity between tools that operate on different WordPress entities.
Naming Consistency5/5
All tools follow a strict wp_verb_noun pattern (get, list, create, update, delete) with clear resource names. The convention is consistent across the entire set, making the API highly predictable.
Tool Count4/5
20 tools is slightly heavier than the typical 3-15 range, but each tool corresponds to a specific WordPress operation across posts, pages, comments, media, and taxonomies. The count feels justified for the domain, though it borders on heavy.
Completeness3/5
Posts, pages, and comments have solid CRUD coverage, but media lacks upload/create and update capabilities, and categories/tags have only list operations. These are notable gaps for a WordPress management server, though core content workflows are supported.
Average 3.8/5 across 20 of 20 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits 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?
Annotations already declare readOnlyHint=false and destructiveHint=false, but the description adds no additional behavioral context such as required permissions, return value, or side effects on existing fields. The word 'existing' implies a constraint but is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the core action and resource. There is zero wasted text, making it highly efficient.
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 lacks essential context for an update tool: return value (no output schema), accepted status enum values, and prerequisite conditions. This leaves the agent uncertain about what to expect on success or failure.
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 schema provides 100% description coverage for all four parameters, so the description adds no extra meaning beyond what is already in the schema. Baseline of 3 is appropriate since the schema does the heavy lifting.
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 'update' and the resource 'WordPress page', which distinguishes it from get/create/delete siblings. However, it lacks specifics about updatable fields, though the schema covers that.
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 like wp_update_post, nor are there any prerequisites or exclusions. The description is purely a statement of function.
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?
Annotations already cover the destructive nature (destructiveHint=true) and readOnlyHint=false. The description adds no additional behavioral context such as permanence of deletion, cascading effects, permission requirements, or whether the page is moved to trash. This provides no extra transparency beyond the annotations.
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 directly states the tool's purpose without unnecessary words. It is appropriately sized for a tool of this simplicity, though it omits some potentially useful context.
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 low complexity, annotations, and full schema coverage, the description is just sufficient. However, it does not mention return values or side effects, and with no output schema the agent relies on assumed delete semantics. This is acceptable but not 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 100% with the single parameter 'id' documented as 'Page ID to delete.' The tool description adds no further semantic detail, so the baseline of 3 is appropriate given the schema already fully documents the parameter.
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 (delete) and the specific resource (WordPress page), unambiguously distinguishing it from sibling tools like wp_delete_post which targets posts. It directly answers what the tool does without ambiguity.
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, nor any mention of prerequisites, exclusions, or context such as 'use this for page-type content only.' The description only states the action without any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations. readOnlyHint=false indicates a write operation, and destructiveHint=false indicates non-destructive, which the description simply restates via 'Create.' No extra details about auth, side effects, or return behavior are provided.
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, concise sentence with no redundant words. It is front-loaded with the action and target, making it easy to parse.
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 description is sufficient for basic invocation, but it omits potential return value information (e.g., created comment ID, status) and prerequisites (e.g., post must exist). While the schema and annotations cover parameters and safety, there's no output schema to clarify results, leaving slight 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?
The input schema has 100% coverage, documenting all four parameters with clear descriptions. The tool description adds no additional meaning for parameters, so the baseline of 3 applies.
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 ('Create') and resource ('new comment on a WordPress post'), clearly distinguishing it from sibling tools like wp_update_comment and wp_delete_comment. It unambiguously states the action and target.
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 'use wp_update_comment to modify existing comments' or 'use wp_list_comments to retrieve comments.' It is a bare definition, leaving the agent to infer the use case from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds little beyond annotations. It claims to list 'all' tags but does not disclose that per_page defaults to 100, effectively paginating results. This is a potential behavioral gap. It does add 'post counts' as a return detail, but no pagination or response format information is provided.
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 immediately communicates the core function. It avoids any fluff or redundancy.
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?
While the tool is relatively simple and annotations cover safety, the description lacks important context such as pagination behavior (per_page) and what 'post counts' means in the response. Given no output schema, the description should be more complete about return values and defaults.
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 input schema already fully documents both parameters (search and per_page) with descriptions, so the baseline is 3. The tool description adds no additional parameter semantics beyond what the schema provides.
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 'List all WordPress tags with post counts' uses a clear verb 'list', a specific resource 'WordPress tags', and adds a scope 'all' and a return detail 'with post counts'. This distinguishes it from sibling tools like wp_list_categories and wp_list_posts.
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. It does not mention that wp_list_categories should be used for categories, or any context about filtering or pagination. There are no explicit exclusions or alternative references.
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?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the mutation safety is covered. However, the description adds little beyond that: it does not disclose whether unspecified fields remain unchanged or are reset, nor does it explain the return value despite having no output schema. For a mutation tool, these are meaningful gaps.
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 concise sentence that front-loads the action and resource. It lists the updatable fields efficiently without redundant words. Every phrase earns its place.
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 a straightforward update with 6 parameters, a required ID, and full schema descriptions. Annotations cover idempotence and non-destructiveness. However, the absence of an output schema means the description should ideally mention what the response looks like, but it does not. For its simplicity, the description is adequate but not 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 100%, so the input schema already documents each parameter. The description simply repeats the field names (title, content, status, categories, tags) without adding extra meaning, such as array formats or replacement semantics. Baseline 3 is appropriate.
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 'Update an existing WordPress post' with a specific verb (update), resource (WordPress post), and scope (existing). It lists the updatable fields (title, content, status, categories, tags), which distinguishes it from sibling tools like wp_create_post, wp_delete_post, and wp_get_post. The mention of 'post' implicitly excludes pages (wp_update_page).
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 when an existing post needs modification (via the qualifier 'existing'), but provides no explicit alternatives or exclusions. It does not say 'for new posts use wp_create_post' or 'for pages use wp_update_page.' This is implied usage rather than clear when-to-use guidance.
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?
Annotations already indicate non-read-only and non-destructive behavior, and the description adds that content is HTML and statuses (draft/publish) can be set. However, it omits the default status (draft), any side effects, and what the response will be. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the action and key inputs. Every word adds value; no fluff or repetition.
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 simple create tool, the description covers the essentials and works in tandem with the schema. It does not mention the default status or the return value, but these are not critical for invocation. The presence of sibling tools is not addressed, but this is a minor 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?
The input schema already covers all 5 parameters with descriptions (100% coverage). The description rehashes the main parameters but omits the 'pending' and 'private' statuses mentioned in the schema, and does not add meaningful semantics beyond the schema.
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 identifies the action ('Create'), the resource ('WordPress post'), and distinguishes it from sibling tools by specifying 'post' rather than 'page'. It also lists the core inputs, making the tool's purpose unmistakable.
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 like wp_update_post or wp_create_page. It does not mention any exclusions, prerequisites, or context where a different tool 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds that the tool returns 'full content and metadata', providing some insight into the response payload, but no additional behavioral specifics such as error handling or auth requirements.
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, direct sentence that immediately conveys the tool's purpose without unnecessary detail.
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?
With one simple parameter and an explicit read-only annotation, the tool is low complexity. The description gives a general idea of response content ('full content and metadata'), but lacks detail on return format or error scenarios; still, it is sufficient for a basic retrieval tool.
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 covers the only parameter 'id' with 'Page ID' at 100% coverage, so the baseline is 3. The description does not elaborate on the id format or any usage constraints beyond what the schema provides.
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 clearly states 'Get a single WordPress page with full content and metadata' – a specific verb and resource. It distinguishes from siblings like wp_list_pages (plural) and wp_get_post (post type) through the explicit use of 'page' and 'single'.
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 such as wp_get_post or wp_list_pages. The description neither mentions context nor exclusions, leaving the agent to infer usage from the tool name alone.
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?
Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds valuable context that posts move to trash by default, implying reversibility. This goes beyond the schema and annotation, though it does not describe return values or permission requirements.
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, front-loaded with the core action and including the extra trash detail without redundancy. Every word earns its place.
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 simple delete tool, it covers the action and default trash behavior, but it leaves ambiguity around the phrase 'by default' given no parameter for permanent deletion, and does not specify the return value. The description is adequate but has clear 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?
The schema fully documents the single 'id' parameter as 'Post ID to delete', and the description adds no additional semantics. With 100% schema coverage, the baseline score of 3 is appropriate.
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 'Delete' and resource 'WordPress post', distinguishing it clearly from sibling tools like wp_get_post, wp_update_post, and wp_list_posts. The added trash behavior does not confuse the primary purpose.
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 explicit guidance on when to use this tool versus alternatives such as wp_delete_page or wp_update_post. It does not mention permanent deletion options or context where trash behavior might be insufficient, leaving usage to be inferred 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?
Annotations already indicate readOnly and non-destructive behavior. The description claims to list 'all' categories, but the schema shows a default per_page of 100, which may mislead about pagination. It does not disclose this limitation or other behavioral traits beyond what annotations provide.
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 states the core action and resource. Every word earns its place, with no wasted detail.
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 simple list tool, the description and schema cover most essentials, but the discrepancy between 'all' and the default per_page limit leaves a meaningful gap. Also, it lacks explicit usage context relative to sibling tools, making completeness slightly below ideal.
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 100%, with clear descriptions for search and per_page. The description does not add any additional parameter semantics beyond what the schema already provides, so it meets the baseline but doesn't exceed it.
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 the specific verb 'List' and clearly identifies the resource as 'WordPress categories' with the added detail 'with post counts'. This distinguishes it from sibling tools like wp_list_tags and wp_list_posts, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies use for category listing but does not explicitly state when to use this over alternatives such as wp_list_tags. It gives a clear context but lacks explicit exclusions or alternative recommendations.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, establishing a safe read operation. The description adds minimal behavioral context—comments on posts, filter by post ID—but does not disclose ordering, pagination behavior, default scope when post is omitted, or moderation status filtering. This matches the baseline of 3 given 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences that front-load the primary purpose and then add the key filter. Every word is purposeful, with no filler or redundancy.
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 simple 2-parameter, read-only list tool with good annotations and complete schema descriptions, the description is mostly sufficient. It states the operation and filter clearly. However, it does not explicitly clarify default behavior when no post ID is provided (e.g., all comments) or any ordering/pagination defaults, though these are inferable from the schema and tool name.
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 100%—both parameters (post, per_page) have descriptions. The description's 'Filter by post ID' simply restates the schema's post parameter and adds no new semantic value, especially for per_page. With high schema coverage, the baseline of 3 is appropriate.
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 identifies the action (list) and resource (comments on WordPress posts), with an explicit filter by post ID. It distinguishes from sibling tools like wp_get_page or wp_list_posts by focusing on the comment resource and its post-scoped filtering.
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 for listing comments, but provides no explicit when-to-use guidance, exclusions, or alternative tools. It does not mention that wp_get_post or wp_list_posts might be used for other purposes, nor does it clarify when to use this over comment mutation tools (wp_create_comment, wp_update_comment, wp_delete_comment).
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?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is established. The description adds information about the output (URLs, types, metadata) but does not disclose behaviors like pagination defaults, sorting, or access restrictions. This is acceptable for a simple read-only tool but adds limited depth beyond the annotations.
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, concise sentence that front-loads the core purpose and then lists the key return information. Every word earns its place, with no redundancy or extraneous detail.
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 simple list tool with two optional parameters and no output schema, the description adequately covers the essential context: what it lists and what it returns. It does not explicitly mention pagination behavior, but the schema handles that. Given the low complexity, the description is nearly 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?
The input schema has 100% coverage for both parameters (per_page and media_type) with clear descriptions. The tool description does not add any additional meaning beyond the schema, so it meets the baseline for high schema coverage but provides no extra value.
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 clear verb-resource pair ('List media files') and specifies the resource ('WordPress library'), distinguishing it from sibling list tools like wp_list_posts. It also mentions the return type, which reinforces its purpose as a read/list operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for listing media files, but it does not provide explicit guidance on when to use it versus alternatives, nor does it mention any exclusions or prerequisites. It is straightforward enough that a user can infer usage, but it lacks proactive comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description only adds the detail that roles are included. No mention of pagination behavior or search semantics beyond what the schema already provides, but the description does not contradict annotations and adds minimal context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence that efficiently states the tool's purpose. No unnecessary words or repetition, and it is front-loaded with the action.
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?
The tool is simple with two optional parameters, and the description covers the basic purpose and output detail. While there is no output schema and the description does not detail return structure, the simplicity and annotations make the description adequately complete for an agent to select and invoke the tool.
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 100% for both parameters, so the baseline is 3. The description itself adds no parameter-specific meaning; 'with their roles' refers to the output, not the inputs.
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 'list' and resource 'WordPress users', and adds 'with their roles' to clarify output content. It is clearly distinct from sibling tools, which cover pages, posts, media, comments, etc., with no other user-listing tool present.
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 by stating the tool lists users, but it does not explicitly mention when to use it over alternatives or any exclusions. The sibling context shows no other user tool, so the intended use is fairly obvious, but the description itself lacks direct guidance.
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?
Annotations indicate readOnlyHint=false and destructiveHint=false, consistent with a create operation. The description adds a small behavioral detail that content is HTML and parent is for hierarchy, but does not disclose response behavior, permissions, or default status. It's adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action, and contains no redundant fluff. Every phrase earns its place.
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 simple create tool with four parameters and no output schema, the description covers the required inputs but omits optional status and any mention of return values. Schema fills some gaps, but the description could better specify default behavior (e.g., draft).
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 has 100% coverage with descriptions for all parameters. The description only restates title/content/parent without adding new parameter details, so baseline 3 applies.
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 ('Create') and resource ('WordPress page'), clearly differentiating from sibling tools like wp_create_post. It also mentions title/content and optional parent, making the tool's scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the tool creates a page and notes that title and content are required, with parent optionally for hierarchy. This provides clear context for when to use it, but it doesn't explicitly mention alternatives or exclusions compared to wp_create_post or wp_update_page.
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?
The annotation destructiveHint=true already indicates destructiveness, and the description adds the word 'permanently' to clarify that deletion is irreversible. However, it does not disclose side effects, permissions, or return behavior, so it adds minimal context beyond annotations.
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, concise sentence that is front-loaded with the action and resource. Every word earns its place with no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one parameter fully documented in the schema and destructive behavior flagged by annotations, the description is complete. No output schema exists, and return values are not critical for typical invocation. The description sufficiently covers all needed context.
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 100%, with the 'id' parameter described as 'Comment ID to delete.' The description adds no additional parameter information, so the schema carries the burden. A score of 3 is appropriate for full schema coverage.
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 ('Permanently delete') and the resource ('a comment'), distinguishing it from sibling tools like wp_delete_post or wp_update_comment. The verb is specific and the resource is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly mention alternatives or when to use this tool, but the word 'permanently' provides an implicit distinction from update operations that might trash or moderate comments. It lacks explicit guidance on alternatives, which lowers the score.
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?
Annotations already provide readOnlyHint=true and destructiveHint=false, covering safety. The description adds that the tool returns full content, metadata, categories, and tags, which is useful context beyond annotations. No contradiction; not rich enough for a higher score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, first directly identifies the action and resource, second adds usage guidance. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool, the description fully covers what it does, what it returns, and when to use it. Annotations cover the read-only safety profile, and no output schema is needed due to the return description.
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 schema covers 100% of parameters with 'id' described as 'Post ID'. The description doesn't add additional parameter meaning, but the baseline of 3 is appropriate given full schema coverage for a trivial parameter.
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 tool 'Get a single WordPress post' with specific return details ('full content, metadata, categories, and tags'). This distinguishes it from sibling tools like wp_list_posts (multiple) and wp_update_post (modification).
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 says 'Use to inspect post content before editing', providing clear context for when to use. However, it does not explicitly exclude alternatives like wp_list_posts or mention when not to use, so it falls short of a 5.
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?
Annotations (readOnlyHint=true, destructiveHint=false) already cover the safety profile. The description adds the return format details, which is useful but not extensive. It does not disclose behaviors like slug handling or additional filters, but given annotations, this is adequate.
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?
Three concise, front-loaded sentences cover purpose, return fields, and usage. No wasted words, and the structure is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with no output schema, the description provides essential details: what it does, what it returns, and when to use it. The schema and annotations cover the remaining specifics, making it complete for agent selection and invocation.
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 schema has 100% coverage with clear descriptions for all three optional parameters (search, status, per_page). The description adds little beyond echoing the schema, so the baseline of 3 is appropriate.
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 tool lists WordPress posts with optional filters, and identifies the return fields (post ID, title, status, date, categories). This distinguishes it from sibling tools like wp_list_pages or wp_list_media, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use for browsing existing content or finding posts by keyword, providing clear context. However, it does not directly mention when not to use it or alternatives like wp_get_post for single post retrieval, so it lacks exclusions and alternative comparison.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to restate that. It adds value by specifying the return fields (page ID, title, status, parent page) and the browsing purpose, which is contextual behavior beyond the annotations. No contradictions with annotations are present.
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 concise sentences. The first sentence states the primary action, and the second adds return fields and a use case. Every word earns its place; there is no redundancy or filler.
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?
The tool is simple (two optional parameters, no output schema). The description covers the core purpose, return fields, and typical use. It does not explicitly mention pagination or default limits, but those are documented in the schema. Given the richness of the schema and annotations, the description is adequately complete for this tool.
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 input schema provides 100% coverage for both parameters (status and per_page) with clear descriptions. The tool description itself does not explain any parameter semantics, but because the schema already handles this, the baseline of 3 is appropriate.
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 opens with 'List WordPress pages', a specific verb and resource that clearly indicates the tool returns multiple pages. It further details the returned fields (page ID, title, status, parent page) and distinguishes it from siblings like wp_get_page (which retrieves a single page) and wp_list_posts (which lists posts, not pages). The phrase 'browse site page structure' reinforces its purpose.
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 provides a clear use case: 'Use to browse site page structure.' This implies when to use this tool versus fetching a specific page or listing posts. However, it does not explicitly state when not to use it or name alternative tools, so it lacks the explicit exclusion or alternative guidance seen in higher-scoring examples.
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?
Annotations already indicate a non-read-only, non-destructive, idempotent operation. The description adds behavioral context beyond the annotations by explicitly naming the aspects that can be updated (content and approval status), which helps the agent understand what 'update' entails. It does not add additional caveats like permissions or reversibility, but given the annotation coverage, this is acceptable.
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 concise and efficient: two sentences that cover the purpose and the main capabilities. It is front-loaded with the primary action ('Update or moderate a comment') and each phrase adds value. There is no fluff or redundant information.
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 is a simple update operation, the description is adequate: it states the core action, mentions the two modifiable attributes, and the schema fully documents all parameters. The annotations cover safety aspects. The absence of an output schema is fine for a mutation tool, and the description does not need to detail return values. It is complete enough for an agent to use correctly.
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 input schema covers 100% of the parameters with descriptions, so the schema itself provides the baseline. The description adds the semantic grouping of 'content' and 'approval status', linking the parameters to real-world concepts, but does not add syntax details beyond what the schema already has. The baseline of 3 is appropriate.
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 tool's purpose with a specific verb ('Update') and resource ('comment'), and it distinguishes itself from sibling tools like wp_create_comment and wp_delete_comment by focusing on updating an existing comment. It also adds the key actions (change content or approval status), making its role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/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 you need to update or moderate an existing comment) and clarifies the two main usage modes (content change or status change). It doesn't explicitly mention exclusions or alternatives, but the context is clear enough for an agent to select this tool over siblings that create, list, or delete comments.
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 goes beyond the annotations by specifying 'permanently', which adds important context about irreversibility that destructiveHint alone doesn't convey. It also clarifies the resource type, but does not detail any side effects or permissions, though the annotations already cover the destructive nature.
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 contains no extraneous information. Every word earns its place, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one parameter, clear schema coverage, and annotations indicating destructiveness, the description fully covers the necessary context. It states the permanent nature and the resource type, leaving no critical gaps for an agent to invoke it correctly.
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 input schema already provides 100% coverage with a clear description for the only parameter ('Media ID to delete'). The tool description adds no additional parameter-level semantics beyond what the schema offers, so baseline 3 is appropriate.
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 ('Permanently delete') and the target resource ('a media file from WordPress'). It unambiguously distinguishes this from sibling tools for deleting posts, pages, or comments by specifying 'media'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for deleting media files, which implicitly defines when to use it. However, it doesn't explicitly mention alternatives or exclusions, but given the tool's name and the siblings, the use case is obvious.
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?
Annotations already declare the operation as read-only and non-destructive. The description adds behavioral detail by specifying the exact categories of information returned, which is useful and goes beyond the schema's parameter documentation.
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, well-structured sentence conveys the tool's purpose and output without redundancy. 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 simple tool with one optional parameter and no output schema, the description adequately conveys the tool's purpose and return content. The phrase 'available features' is slightly vague, but overall the context is complete.
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 schema already fully describes the _fields parameter with format and examples. The description adds value by listing valid field values (name, description, URL, timezone, features), helping the agent understand what can be requested.
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 tool retrieves WordPress site information, naming specific data items (name, description, URL, timezone, features). This resource is distinct from the sibling tools that operate on pages, posts, media, and other entities.
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 implies the tool is for retrieving general site-level settings, which provides clear context for when to use it. It does not explicitly mention alternatives, but the naming and scope make the intended use unambiguous.
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:

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

Score Badge

Copy to your README.md:

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

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

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