The WordPress MCP Server enables programmatic interaction with WordPress sites via the REST API. Key capabilities include:
Content Management: Create, retrieve, update, and delete posts with advanced filtering and pagination
User Administration: Manage users including creation, retrieval (by ID/login), updating, deletion, and filtering by roles/capabilities
Comment Handling: Retrieve and create comments with filtering options
Taxonomy Management: Create, update, retrieve, and delete categories and tags
Site Statistics: Access comprehensive stats on views, visitors, likes, comments, top posts, country views, and publishing streaks
Spam Control: Report and remove referrer spam
Analytics: Track outbound clicks and search terms used to find the site
Custom Functionality: Make custom requests to any WordPress REST API endpoint with support for different HTTP methods and parameters
Enables interaction with WordPress sites through the WordPress REST API, providing tools for managing posts, users, comments, categories, tags, and custom endpoints. Supports creating, retrieving, updating, and deleting WordPress content programmatically.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@WordPress MCP Server create a draft post titled 'Weekly Update' with content 'Here's what happened this week'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with WordPress sites through the WordPress REST API. This server provides tools for managing all aspects of WordPress programmatically, including posts, users, comments, categories, tags, and custom endpoints.
Create, retrieve, update, and delete WordPress posts
Filter posts by various parameters
Pagination support for post listings
Retrieve user information by ID or login
Update user details
Delete users
Create, retrieve, update, and delete comments
Filter comments by post
Pagination support for comment listings
Manage categories and tags
Create, retrieve, update, and delete taxonomies
Find categories and tags by slug
Retrieve general WordPress site information
Support for custom REST API endpoints
Custom HTTP methods (GET, POST, PUT, DELETE)
Custom data and parameters
Related MCP server: WordPress MCP Server
Node.js v18 or higher
A WordPress site with REST API enabled
WordPress application password for authentication
Clone this repository:
git clone [repository-url]
cd wordpress-mcp-serverInstall dependencies:
npm installBuild the server:
npm run buildBefore using the server, you need to set up your WordPress site:
Ensure your WordPress site has REST API enabled (enabled by default in WordPress 4.7+)
Create an application password:
Log in to your WordPress admin panel
Go to Users → Profile
Scroll down to "Application Passwords"
Enter a name for the application (e.g., "MCP Server")
Click "Add New Application Password"
Copy the generated password (you won't be able to see it again)
Add the server to your MCP settings file (usually located at ~/AppData/Roaming/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json):
{
"mcpServers": {
"wordpress": {
"command": "node",
"args": ["path/to/wordpress-mcp-server/build/index.js"]
}
}
}Creates a new WordPress post.
Parameters:
siteUrl (required): Your WordPress site URL
username (required): WordPress username
password (required): WordPress application password
title (required): Post title
content (required): Post content
status (optional): Post status ('draft', 'publish', or 'private', defaults to 'draft')
Example:
{
"tool": "create_post",
"siteUrl": "https://example.com",
"username": "admin",
"password": "xxxx xxxx xxxx xxxx",
"title": "My First Post",
"content": "Hello, world!",
"status": "draft"
}Retrieves WordPress posts with pagination.
Parameters:
siteUrl (required): Your WordPress site URL
username (required): WordPress username
password (required): WordPress application password
perPage (optional): Number of posts per page (default: 10)
page (optional): Page number (default: 1)
customParams (optional): Additional query parameters
Example:
{
"tool": "get_posts",
"siteUrl": "https://example.com",
"username": "admin",
"password": "xxxx xxxx xxxx xxxx",
"perPage": 5,
"page": 1
}Updates an existing WordPress post.
Parameters:
siteUrl (required): Your WordPress site URL
username (required): WordPress username
password (required): WordPress application password
postId (required): ID of the post to update
title (optional): New post title
content (optional): New post content
status (optional): New post status ('draft', 'publish', or 'private')
Example:
{
"tool": "update_post",
"siteUrl": "https://example.com",
"username": "admin",
"password": "xxxx xxxx xxxx xxxx",
"postId": 123,
"title": "Updated Title",
"content": "Updated content",
"status": "publish"
}Deletes a WordPress post.
Parameters:
siteUrl (required): Your WordPress site URL
username (required): WordPress username
password (required): WordPress application password
postId (required): ID of the post to delete
Example:
{
"tool": "delete_post",
"siteUrl": "https://example.com",
"username": "admin",
"password": "xxxx xxxx xxxx xxxx",
"postId": 123
}Retrieves WordPress users.
Parameters:
siteUrl (required): Your WordPress site URL
username (required): WordPress username
password (required): WordPress application password
perPage (optional): Number of users per page (default: 10)
page (optional): Page number (default: 1)
Retrieves a specific WordPress user by ID.
Parameters:
siteUrl (required): Your WordPress site URL
username (required): WordPress username
password (required): WordPress application password
userId (required): ID of the user to retrieve
Retrieves a WordPress user by login name.
Parameters:
siteUrl (required): Your WordPress site URL
username (required): WordPress username
password (required): WordPress application password
userLogin (required): Login name of the user to retrieve
Retrieves WordPress comments.
Parameters:
siteUrl (required): Your WordPress site URL
username (required): WordPress username
password (required): WordPress application password
perPage (optional): Number of comments per page (default: 10)
page (optional): Page number (default: 1)
postIdForComment (optional): Filter comments by post ID
Creates a new comment on a post.
Parameters:
siteUrl (required): Your WordPress site URL
username (required): WordPress username
password (required): WordPress application password
postIdForComment (required): ID of the post to comment on
commentContent (required): Content of the comment
customData (optional): Additional comment data
Retrieves WordPress categories.
Parameters:
siteUrl (required): Your WordPress site URL
username (required): WordPress username
password (required): WordPress application password
perPage (optional): Number of categories per page (default: 10)
page (optional): Page number (default: 1)
Creates a new WordPress category.
Parameters:
siteUrl (required): Your WordPress site URL
username (required): WordPress username
password (required): WordPress application password
categoryName (required): Name of the category to create
customData (optional): Additional category data (description, parent, etc.)
Makes a custom request to any WordPress REST API endpoint.
Parameters:
siteUrl (required): Your WordPress site URL
username (required): WordPress username
password (required): WordPress application password
customEndpoint (required): API endpoint path
customMethod (optional): HTTP method ('GET', 'POST', 'PUT', 'DELETE', default: 'GET')
customData (optional): Data for POST/PUT requests
customParams (optional): URL parameters for GET requests
Example:
{
"tool": "custom_request",
"siteUrl": "https://example.com",
"username": "admin",
"password": "xxxx xxxx xxxx xxxx",
"customEndpoint": "wp/v2/media",
"customMethod": "GET",
"customParams": {
"per_page": 5
}
}All tools return responses in the following format:
{
"success": true,
"data": {
// WordPress API response data
},
"meta": {
// Optional metadata (pagination info, etc.)
}
}{
"success": false,
"error": "Error message here"
}Always use HTTPS URLs for your WordPress site
Use application passwords instead of your main WordPress password
Keep your application passwords secure and don't share them
Consider using WordPress roles and capabilities to limit access
Regularly rotate application passwords
To contribute to the development:
Fork the repository
Create a feature branch
Make your changes
Run tests (when available)
Submit a pull request
For development mode with automatic recompilation:
npm run devThis project is licensed under the ISC License.
Contributions are welcome! Please feel free to submit a Pull Request.
Create a new WordPress category
| Name | Required | Description | Default |
|---|---|---|---|
| description | No | HTML description of the term | |
| meta | No | Meta fields | |
| name | Yes | HTML title for the term | |
| parent | No | The parent term ID | |
| password | Yes | WordPress application password | |
| siteUrl | Yes | WordPress site URL | |
| slug | No | An alphanumeric identifier for the term unique to its type | |
| username | Yes | WordPress username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a creation operation but doesn't mention authentication requirements (implied by parameters), potential side effects, error conditions, or what happens on success. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently communicates the core purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse while conveying essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 8 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain authentication needs, return values, error handling, or how it differs from sibling tools. Given the complexity and lack of structured data, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 8 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema, maintaining the baseline score of 3 for adequate but not enhanced parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('a new WordPress category'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'update-category' or 'list-categories' beyond the basic verb, missing explicit distinction that would warrant a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'update-category' or 'list-categories', nor does it mention prerequisites or contextual constraints. It simply states what the tool does without indicating appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new comment on a WordPress post
| Name | Required | Description | Default |
|---|---|---|---|
| author_email | No | Comment author email (for users who can't set this) | |
| author_name | No | Comment author name (for users who can't set this) | |
| content | Yes | Comment content | |
| password | Yes | WordPress application password | |
| postId | Yes | ID of the post to comment on | |
| siteUrl | Yes | WordPress site URL | |
| username | Yes | WordPress username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Create a new comment' which implies a write/mutation operation, but fails to mention authentication requirements (implied by parameters), potential side effects, error conditions, or response format. This leaves significant gaps for a tool that modifies data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with zero wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain authentication requirements, error handling, what the response contains, or how it differs from sibling tools. Given the complexity of a 7-parameter write operation, more contextual information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing clear documentation for all 7 parameters. The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting without compensating for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new comment') and target resource ('on a WordPress post'), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like 'create-post' or 'create-category' beyond the resource type, missing explicit sibling comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get-comments' or 'update-post'. It lacks context about prerequisites (e.g., authentication needs) or exclusions, offering only a basic statement of purpose without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new WordPress post
| Name | Required | Description | Default |
|---|---|---|---|
| author | No | The ID for the author of the post | |
| categories | No | The terms assigned to the post in the category taxonomy | |
| commentStatus | No | Whether or not comments are open on the post | open |
| content | Yes | The content for the post | |
| date | No | The date the post was published, in the site's timezone | |
| dateGmt | No | The date the post was published, as GMT | |
| excerpt | No | The excerpt for the post | |
| featuredMedia | No | The ID of the featured media for the post | |
| format | No | The format for the post | standard |
| meta | No | Meta fields | |
| password | Yes | WordPress application password | |
| pingStatus | No | Whether or not the post can be pinged | open |
| postPassword | No | A password to protect access to the content and excerpt | |
| siteUrl | Yes | WordPress site URL | |
| slug | No | An alphanumeric identifier for the post unique to its type | |
| status | No | A named status for the post | draft |
| sticky | No | Whether or not the post should be treated as sticky | |
| tags | No | The terms assigned to the post in the post_tag taxonomy | |
| template | No | The theme file to use to display the post | |
| title | Yes | The title for the post | |
| username | Yes | WordPress username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Create a new WordPress post' implies a write operation but doesn't specify required permissions, whether it's idempotent, what happens on failure, or the format of the response. For a mutation tool with 21 parameters and no annotation coverage, this leaves critical behavioral aspects undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without unnecessary words. It's front-loaded with the essential action and resource. Every word earns its place, making it maximally concise while still being clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex mutation tool with 21 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what happens after creation (e.g., returns post ID), error conditions, authentication requirements, or how it integrates with sibling tools. The agent lacks sufficient context to use this tool effectively beyond basic parameter passing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with detailed descriptions for all 21 parameters including enums and defaults. The description adds no parameter-specific information beyond what's in the schema. According to guidelines, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new WordPress post' clearly states the action (create) and resource (WordPress post), making the purpose immediately understandable. It distinguishes from siblings like update-post or delete-post by specifying creation. However, it doesn't explicitly differentiate from other creation tools like create-category or create-user beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like authentication via username/password), when to choose create-post over update-post for existing posts, or how it differs from other creation tools. The agent must 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.
Create a new WordPress user
| Name | Required | Description | Default |
|---|---|---|---|
| description | No | Description of the user | |
| Yes | Email address for the new user | ||
| firstName | No | First name for the user | |
| lastName | No | Last name for the user | |
| locale | No | Locale for the user | |
| name | No | Display name for the user | |
| newPassword | Yes | Password for the new user | |
| newUsername | Yes | Login name for the new user | |
| nickname | No | The nickname for the user | |
| password | Yes | WordPress application password | |
| roles | No | Roles assigned to the user | |
| siteUrl | Yes | WordPress site URL | |
| slug | No | An alphanumeric identifier for the user | |
| url | No | URL of the user | |
| username | Yes | WordPress username |
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. 'Create a new WordPress user' implies a write/mutation operation, but it doesn't disclose critical behavioral traits like authentication requirements, permission levels needed, whether the operation is idempotent, what happens on duplicate usernames/emails, or error handling. For a mutation tool with 15 parameters, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the essential action and resource, making it immediately scannable. Every word earns its place in conveying the core purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex mutation tool with 15 parameters, 6 required fields, no annotations, and no output schema, the description is inadequate. It doesn't address authentication, error cases, return values, or system constraints. The agent lacks sufficient context to use this tool effectively beyond basic parameter passing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-specific information beyond what's already in the schema (which has 100% coverage). It doesn't explain relationships between parameters (e.g., 'username' vs 'newUsername'), required fields beyond the schema's 'required' array, or formatting expectations. With complete schema coverage, the baseline is 3, but the description doesn't enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('new WordPress user'), making the purpose immediately understandable. It distinguishes this tool from other user-related tools like 'get-user' or 'update-user' by specifying it's for creation. However, it doesn't explicitly differentiate from all siblings like 'create-post' or 'create-category' beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like authentication needs), when not to use it, or what alternatives exist for similar operations. The agent must 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.
Delete a WordPress category
| Name | Required | Description | Default |
|---|---|---|---|
| categoryId | Yes | ID of the category to delete | |
| force | No | Required to be true, as terms do not support trashing | |
| password | Yes | WordPress application password | |
| siteUrl | Yes | WordPress site URL | |
| username | Yes | WordPress username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose that this is a destructive operation (implied but not explicit), authentication requirements, rate limits, error conditions, or what happens to posts in the category. The 'force' parameter description hints at irreversibility, but the main description lacks behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable and efficient for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description is inadequate. It doesn't explain what 'delete' entails (permanent removal vs. trashing), authentication needs, error handling, or return values. Given the complexity and risk of deletion, more context is needed beyond the bare minimum.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain categoryId format or password requirements). Baseline 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('WordPress category'), making the purpose immediately understandable. It distinguishes from siblings like 'get-category' or 'update-category' by specifying the destructive operation. However, it doesn't explicitly differentiate from 'delete-post' or 'delete-user' beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like needing authentication), consequences of deletion, or when to choose this over similar deletion tools for posts or users. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a WordPress post
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | Whether to bypass Trash and force deletion | |
| password | Yes | WordPress application password | |
| postId | Yes | ID of the post to delete | |
| siteUrl | Yes | WordPress site URL | |
| username | Yes | WordPress username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Delete a WordPress post' implies a destructive mutation but doesn't specify whether deletion is reversible, what permissions are required, whether it affects related content (like comments), or what the response looks like. The description mentions nothing about the 'force' parameter's behavior regarding trash bypass.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's perfectly front-loaded with the core action and resource. No structural issues exist - every word earns its place in this minimal but complete statement of purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with 5 parameters, no annotations, and no output schema, the description is inadequate. It doesn't cover authentication requirements, deletion consequences (trash vs permanent), error conditions, or return values. The description should explain more about the behavioral implications of deleting a WordPress post given the complexity of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds no parameter-specific information beyond what's in the schema. It doesn't explain the relationship between parameters (e.g., that siteUrl, username, and password are for authentication) or provide context about postId format. Baseline 3 is appropriate when schema does all the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Delete') and resource ('a WordPress post'), making the purpose immediately understandable. It distinguishes from siblings like 'delete-category' and 'delete-user' by specifying 'post', but doesn't mention what type of post or differentiate from similar operations like 'update-post' beyond the obvious action difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like needing authentication), when deletion is appropriate versus updating or archiving, or what happens to deleted posts (trash vs permanent deletion). The sibling tools include 'update-post' and 'get-post' but no comparison is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a WordPress user
| Name | Required | Description | Default |
|---|---|---|---|
| password | Yes | WordPress application password | |
| reassignId | Yes | ID of the user to reassign posts to | |
| siteUrl | Yes | WordPress site URL | |
| userId | Yes | User ID or 'me' for current user | |
| username | Yes | WordPress username |
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. While 'Delete' implies a destructive mutation, the description doesn't specify whether this action is reversible, what permissions are required, how reassignment works, or what the response looks like. For a high-stakes operation like user deletion with 5 required parameters, this lack of behavioral context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core functionality without unnecessary words. It's appropriately sized for a tool with a clear primary action, though the brevity comes at the cost of missing important contextual information that would be valuable for a destructive operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with 5 required parameters and no annotations or output schema, the description is insufficiently complete. It doesn't address critical context like authentication requirements, irreversible consequences, reassignment implications, or error conditions. The agent would need to infer too much about this high-risk operation from the minimal description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the input schema. The description adds no additional parameter information beyond what's already in the schema (e.g., it doesn't explain why 'reassignId' is required or what happens if 'me' is used as userId). With complete schema coverage, the baseline score of 3 is appropriate as the description doesn't enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Delete') and resource ('a WordPress user'), making the purpose immediately understandable. It distinguishes this from sibling tools like 'create-user' or 'update-user' by specifying the destructive action. However, it doesn't explicitly differentiate from other deletion tools like 'delete-category' or 'delete-post' beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication requirements), when deletion is appropriate, or what happens to user data. With sibling tools like 'get-user' for checking existence or 'update-user' for modifications, there's no context for choosing deletion over other options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific category by ID
| Name | Required | Description | Default |
|---|---|---|---|
| categoryId | Yes | ID of the category to retrieve | |
| context | No | Scope under which the request is made | view |
| password | Yes | WordPress application password | |
| siteUrl | Yes | WordPress site URL | |
| username | Yes | WordPress username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action without disclosing behavioral traits. It doesn't mention authentication needs (implied by parameters), rate limits, error handling, or what data is returned, leaving significant gaps for a tool with multiple required parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without any wasted words. It's appropriately sized for a simple retrieval tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters (4 required), no annotations, and no output schema, the description is inadequate. It doesn't explain authentication requirements, return values, or error conditions, leaving too much undefined for proper agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds no additional meaning beyond implying 'categoryId' is used for retrieval, which is already clear from the schema. Baseline 3 is appropriate as the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('a specific category by ID'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'list-categories' or 'get-post' beyond the resource name, missing explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'list-categories' for browsing or 'get-post' for other resources. The description lacks context about prerequisites or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View a site's outbound clicks
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of click items to return | |
| password | Yes | WordPress application password | |
| period | No | Time period for stats | |
| siteId | Yes | WordPress site ID | |
| siteUrl | Yes | WordPress site URL | |
| username | Yes | WordPress username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states 'View' without disclosing behavioral traits like authentication requirements (implied by parameters but not described), rate limits, or output format. It adds little beyond the basic action, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('View a site's outbound clicks') with zero waste. It's appropriately sized for the tool's complexity, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 6 parameters (4 required), the description is incomplete. It lacks details on authentication needs, return values, or how parameters interact, making it inadequate for a tool with this complexity and missing structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds no additional meaning beyond implying 'outbound clicks' as the data type, aligning with the baseline score for high schema coverage without extra param info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('View') and resource ('a site's outbound clicks'), providing specific functionality. However, it doesn't differentiate from sibling tools like 'get-site-stats' or 'get-referrers' that might also provide click-related data, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get-site-stats' or 'get-referrers' from the sibling list. The description lacks context about prerequisites or typical scenarios, offering minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of comments from a WordPress site
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number | |
| password | Yes | WordPress application password | |
| perPage | No | Number of comments per page | |
| postId | No | Filter comments by post ID | |
| siteUrl | Yes | WordPress site URL | |
| username | Yes | WordPress username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but only states the basic action. It doesn't cover critical aspects like authentication requirements (implied by parameters but not described), pagination behavior, rate limits, error conditions, or output format. For a tool with 6 parameters and no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly. Every part of the sentence contributes to understanding the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, no annotations, no output schema), the description is insufficiently complete. It doesn't explain authentication needs, pagination behavior, filtering options, or return values, leaving the agent with gaps in understanding how to use the tool effectively. For a data retrieval tool with multiple parameters, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 6 parameters. The description adds no additional meaning beyond implying filtering by post (via 'postId') and pagination (via 'page' and 'perPage'), but these are already clear in the schema. This meets the baseline of 3 for high schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('list of comments from a WordPress site'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'get-post' or 'get-user' beyond the resource type, lacking specificity about scope or filtering capabilities that might distinguish it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention siblings like 'get-post' (which might include comments) or 'create-comment', nor does it specify prerequisites like authentication or filtering options. This leaves the agent with minimal context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View a site's views by country
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of countries to return | |
| password | Yes | WordPress application password | |
| period | No | Time period for stats | |
| siteId | Yes | WordPress site ID | |
| siteUrl | Yes | WordPress site URL | |
| username | Yes | WordPress username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states 'view' which implies a read-only operation, but doesn't clarify authentication requirements, rate limits, data freshness, or what 'views' specifically means (e.g., page views, unique visitors). The description lacks crucial context about what this tool actually returns and how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with zero waste. It's appropriately sized for a tool with good schema documentation and is perfectly front-loaded with the core functionality. Every word earns its place in this concise statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for this 6-parameter tool. While the schema covers parameters well, the description doesn't address authentication needs (implied by username/password parameters), doesn't explain what 'views' means, and provides no information about return format or data structure. For a tool that requires authentication and returns statistical data, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema - it doesn't explain relationships between parameters or provide usage examples. Baseline 3 is appropriate when schema does the heavy lifting, though the description could have added value by explaining parameter interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'View a site's views by country' clearly states the action (view) and resource (site's views by country), making the purpose immediately understandable. It distinguishes from siblings like 'get-site-stats' or 'get-stats-summary' by specifying country-level view data. However, it doesn't explicitly contrast with 'get-clicks' or 'get-referrers' which might also involve geographic data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this tool is appropriate compared to siblings like 'get-site-stats' (which might include country data) or 'get-stats-summary'. There's no context about prerequisites or typical use cases beyond the basic action stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific post by ID
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Scope under which the request is made | view |
| password | Yes | WordPress application password | |
| postId | Yes | ID of the post to retrieve | |
| postPassword | No | The password for the post if it is password protected | |
| siteUrl | Yes | WordPress site URL | |
| username | Yes | WordPress username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a read operation ('Get'), which is helpful, but lacks details on authentication needs (implied by parameters), rate limits, error handling, or what the return format looks like (no output schema). For a tool with 6 parameters including authentication, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core purpose and efficiently communicates the essential action without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters (including authentication), no annotations, and no output schema, the description is incomplete. It doesn't address authentication requirements, return format, error conditions, or how it differs from sibling tools. The high parameter count and lack of structured metadata mean the description should provide more contextual guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 6 parameters. The description adds no additional parameter information beyond implying 'postId' is required, which is already in the schema. This meets the baseline of 3 when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('a specific post by ID'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get-post-stats' or 'get-top-posts', which also retrieve post-related information but with different scopes or aggregations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get-post-stats' (for statistics) or 'list-posts' (for multiple posts). It also doesn't mention prerequisites such as authentication requirements, which are implied by the required parameters but not explicitly stated in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View a specific post's views
| Name | Required | Description | Default |
|---|---|---|---|
| password | Yes | WordPress application password | |
| postId | Yes | Post ID to get stats for | |
| siteId | Yes | WordPress site ID | |
| siteUrl | Yes | WordPress site URL | |
| username | Yes | WordPress username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states 'View' which implies a read-only operation, but doesn't clarify authentication needs, rate limits, or what 'views' specifically entails (e.g., time range, metric details). The description adds minimal context beyond the basic action, leaving significant behavioral aspects undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. There's zero wasted language or redundancy, making it immediately scannable and appropriately sized for a simple retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 required authentication/identification parameters and no output schema, the description is insufficient. It doesn't explain the WordPress context, authentication flow, what 'views' data includes, or error conditions. With no annotations and rich parameter requirements, the description should provide more operational context to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all 5 parameters clearly documented in the schema (siteUrl, username, password, siteId, postId). The description adds no parameter-specific information beyond implying 'postId' identifies the target post. This meets the baseline of 3 since the schema does the heavy lifting, but the description doesn't compensate with additional semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('View') and resource ('a specific post's views'), making the purpose immediately understandable. It distinguishes from siblings like 'get-site-stats' or 'get-top-posts' by focusing on a single post's views. However, it doesn't explicitly mention the WordPress context or authentication requirements, which slightly reduces specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get-site-stats' for overall stats or 'get-top-posts' for ranking information. It doesn't mention prerequisites (authentication) or contextual constraints, leaving the agent to infer usage from the parameter schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View a site's referrers
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of referrers to return | |
| password | Yes | WordPress application password | |
| period | No | Time period for stats | |
| siteId | Yes | WordPress site ID | |
| siteUrl | Yes | WordPress site URL | |
| username | Yes | WordPress username |
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. 'View' suggests a read-only operation, but it doesn't specify whether this requires authentication (implied by parameters but not stated), rate limits, pagination behavior, or what format the referrer data returns. For an analytics tool with 6 parameters and no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a tool with clear parameters in the schema, though the brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter analytics tool with no annotations and no output schema, the description is insufficient. It doesn't explain what referrers are in this context, what data format to expect, authentication requirements (though parameters imply them), or how this differs from other stats tools. The combination of rich parameters and lack of structured metadata demands more descriptive context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description adds no additional parameter context beyond implying the tool operates on a 'site' (matching siteId and siteUrl parameters). No syntax hints, format details, or relationship explanations are provided beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'View a site's referrers' clearly states the action (view) and resource (referrers), making the purpose immediately understandable. It distinguishes this tool from siblings like get-clicks or get-country-views by focusing on referrers specifically. However, it doesn't explicitly mention that this is for WordPress site analytics, which could help differentiate it further from other analytics tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like get-stats-summary or get-site-stats that might provide overlapping or complementary functionality. There's no indication of prerequisites (e.g., authentication requirements) or typical use cases for referrer data versus other analytics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View search terms used to find the site
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of search terms to return | |
| password | Yes | WordPress application password | |
| period | No | Time period for stats | |
| siteId | Yes | WordPress site ID | |
| siteUrl | Yes | WordPress site URL | |
| username | Yes | WordPress username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'view' which implies a read-only operation, but doesn't disclose authentication needs (though implied by required parameters), rate limits, data format, pagination, or what happens if parameters are invalid. For a tool with 6 parameters including authentication, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It's appropriately sized for a simple tool, with zero waste or redundancy, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (6 parameters including authentication), no annotations, and no output schema, the description is minimally adequate but incomplete. It states what the tool does but lacks behavioral context, usage guidance, and output details, which are needed for the agent to use it effectively in a WordPress stats context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add any meaning beyond what the schema provides—it doesn't explain how parameters interact (e.g., that 'period' affects the search terms returned) or provide usage examples. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'View search terms used to find the site' clearly states the verb ('view') and resource ('search terms'), specifying it's about terms used to find the site. It distinguishes from siblings like 'get-clicks' or 'get-referrers' by focusing on search terms, though it doesn't explicitly differentiate from similar tools like 'get-site-stats' which might overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention when to choose it over other stats-related tools like 'get-site-stats' or 'get-stats-summary', nor does it specify prerequisites or exclusions, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive stats for a WordPress site
| Name | Required | Description | Default |
|---|---|---|---|
| password | Yes | WordPress application password | |
| period | No | Time period for stats | |
| siteId | Yes | WordPress site ID | |
| siteUrl | Yes | WordPress site URL | |
| username | Yes | WordPress username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a 'get' operation (implying read-only), but doesn't mention authentication requirements, rate limits, error conditions, or what 'comprehensive stats' actually includes. For a tool with authentication parameters, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point. There's no wasted verbiage or unnecessary elaboration, though it could be slightly more specific about what 'comprehensive stats' entails.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters (including authentication), no annotations, and no output schema, the description is insufficient. It doesn't explain what 'comprehensive stats' returns, how authentication works, or how this differs from similar statistical tools. The agent lacks crucial context for proper tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so all parameters are documented in the schema. The description adds no additional parameter information beyond what's already in the schema, which is acceptable given the complete schema coverage. The baseline of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('comprehensive stats for a WordPress site'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get-stats-summary' or 'get-stats-highlights', which appear to offer similar statistical functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get-stats-summary' or 'get-stats-highlights'. There's no mention of prerequisites, use cases, or exclusions, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get highlight metrics for a WordPress site from the last seven days
| Name | Required | Description | Default |
|---|---|---|---|
| password | Yes | WordPress application password | |
| siteId | Yes | WordPress site ID | |
| siteUrl | Yes | WordPress site URL | |
| username | Yes | WordPress username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves data ('Get'), implying a read-only operation, but doesn't mention authentication requirements, rate limits, error handling, or what 'highlight metrics' includes. This is inadequate for a tool with four required parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. It avoids unnecessary words, though it could be slightly more informative (e.g., specifying metrics types). Every part of the sentence contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (four required parameters, no annotations, no output schema), the description is insufficient. It doesn't explain what 'highlight metrics' returns, authentication implications, or error cases. For a tool that likely involves API calls and data retrieval, more context is needed to ensure proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all four parameters. The description adds no additional parameter information beyond what's in the schema, such as explaining how 'siteId' relates to 'siteUrl' or format specifics. Baseline 3 is appropriate since the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get highlight metrics') and resource ('for a WordPress site'), with a specific time constraint ('from the last seven days'). It distinguishes from siblings like 'get-site-stats' or 'get-stats-summary' by specifying 'highlight metrics' and the fixed time window, though it could be more explicit about what 'highlight metrics' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get-site-stats' or 'get-stats-summary'. It mentions the time window but doesn't explain why this tool is preferred over others for similar metrics, leaving usage context implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View a site's summarized views, visitors, likes and comments
| Name | Required | Description | Default |
|---|---|---|---|
| password | Yes | WordPress application password | |
| siteId | Yes | WordPress site ID | |
| siteUrl | Yes | WordPress site URL | |
| username | Yes | WordPress username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a 'View' operation (implying read-only), but doesn't mention authentication requirements, rate limits, error conditions, or what the summarized output looks like. For a tool with 4 required parameters and no annotations, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a straightforward retrieval tool and gets directly to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 required authentication parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the summarized statistics include, how they're formatted, or provide any context about the WordPress API integration. The agent would need to guess about the output structure and behavioral characteristics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema descriptions. This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('View') and the resource ('a site's summarized views, visitors, likes and comments'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from similar sibling tools like 'get-site-stats' or 'get-post-stats', which might offer overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get-site-stats' or 'get-post-stats'. It doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get stats for Calendar Heatmap showing publishing activity
| Name | Required | Description | Default |
|---|---|---|---|
| password | Yes | WordPress application password | |
| siteId | Yes | WordPress site ID | |
| siteUrl | Yes | WordPress site URL | |
| username | Yes | WordPress username |
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. While 'Get' implies a read operation, the description doesn't address authentication requirements (though parameters suggest WordPress auth), rate limits, error conditions, or what specific statistics are returned. For a tool with 4 required parameters and no annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a tool with a clear purpose and doesn't suffer from verbosity or structural issues.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 required parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what statistics are returned, how they're formatted, what time periods are covered, or any behavioral aspects. The agent would need to guess about the tool's behavior and output based solely on the name and minimal description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 4 parameters with clear descriptions. The description doesn't add any meaningful parameter context beyond what's in the schema. The baseline score of 3 is appropriate when the schema does the heavy lifting for parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('stats for Calendar Heatmap showing publishing activity'), making the purpose understandable. It distinguishes itself from siblings by focusing on streak/heatmap statistics rather than general stats, but doesn't explicitly differentiate from similar tools like 'get-post-stats' or 'get-site-stats'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools for retrieving statistics (get-post-stats, get-site-stats, get-stats-highlights, etc.), there's no indication of what makes this tool unique or when it's the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View a site's top posts and pages by views
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of posts to return | |
| password | Yes | WordPress application password | |
| period | No | Time period for stats | |
| siteId | Yes | WordPress site ID | |
| siteUrl | Yes | WordPress site URL | |
| username | Yes | WordPress username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool is for viewing, implying a read-only operation, but doesn't mention authentication requirements, rate limits, or what the output looks like (e.g., format, pagination). For a tool with 6 parameters including credentials, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without any wasted words. It's appropriately sized for the tool's complexity and gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters (including authentication), no annotations, and no output schema, the description is incomplete. It doesn't address authentication needs, output format, or how it relates to sibling tools, leaving the agent with insufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no additional meaning beyond implying the tool involves 'views' and 'top posts/pages,' which is already suggested by the tool name. This meets the baseline for high schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('View') and resource ('a site's top posts and pages by views'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get-post-stats' or 'get-site-stats' that might provide related statistics, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'get-post-stats' and 'get-site-stats' available, there's no indication of how this tool differs in context or when it's the appropriate choice, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific user by ID
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Scope under which the request is made | view |
| password | Yes | WordPress application password | |
| siteUrl | Yes | WordPress site URL | |
| userId | Yes | User ID or 'me' for current user | |
| username | Yes | WordPress username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it 'gets' a user, implying a read operation, but doesn't disclose behavioral traits like authentication requirements (implied by parameters but not explicit), rate limits, error conditions, or what happens with invalid IDs. For a tool with 5 parameters and no annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. There's zero waste or redundancy, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain the return values, authentication requirements, or how parameters interact (e.g., 'userId' with 'me' option). For a user retrieval tool in a WordPress context with multiple siblings, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds no parameter-specific meaning beyond implying 'userId' is the key input. This meets the baseline of 3 where the schema does the heavy lifting, but the description doesn't compensate with additional context like explaining the 'context' enum or authentication flow.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('a specific user by ID'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'get-users' (plural) which likely retrieves multiple users, so it misses full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get-users' for listing users or 'update-user' for modifications, nor does it specify prerequisites or contextual constraints beyond what's implied by the parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of users from a WordPress site with advanced filtering options
| Name | Required | Description | Default |
|---|---|---|---|
| capabilities | No | Limit result set to users matching at least one specific capability | |
| context | No | Scope under which the request is made | view |
| exclude | No | Ensure result set excludes specific IDs | |
| hasPublishedPosts | No | Limit result set to users who have published posts | |
| include | No | Limit result set to specific IDs | |
| offset | No | Offset the result set by a specific number of items | |
| order | No | Order sort attribute ascending or descending | asc |
| orderby | No | Sort collection by user attribute | name |
| page | No | Current page of the collection | |
| password | Yes | WordPress application password | |
| perPage | No | Maximum number of items to be returned | |
| roles | No | Limit result set to users matching at least one specific role | |
| search | No | Limit results to those matching a string | |
| siteUrl | Yes | WordPress site URL | |
| slug | No | Limit result set to users with one or more specific slugs | |
| username | Yes | WordPress username | |
| who | No | Limit result set to users who are considered authors |
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 mentions 'advanced filtering options' but fails to describe key traits like pagination behavior (implied by 'page' and 'perPage' parameters), authentication requirements (implied by required 'username' and 'password'), or potential rate limits. This leaves significant gaps for a tool with 17 parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get a list of users from a WordPress site') and adds a useful qualifier ('with advanced filtering options'). There's no wasted text, though it could be slightly more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (17 parameters, no annotations, no output schema), the description is insufficient. It doesn't explain the return format, pagination behavior, authentication needs, or error handling, leaving the agent with incomplete guidance for proper tool invocation in a real-world context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 17 parameters thoroughly. The description adds minimal value by hinting at 'advanced filtering options,' but doesn't provide additional context beyond what the schema specifies, such as explaining how filters interact or typical use cases for parameters like 'context' or 'who.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('list of users from a WordPress site'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get-user' (singular) or 'list-posts', which handle different resources, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'advanced filtering options' but provides no explicit guidance on when to use this tool versus alternatives. For example, it doesn't clarify when to use 'get-users' versus 'get-user' (singular) or other list tools like 'list-posts', leaving usage context implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of categories with filtering options
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Scope under which the request is made | view |
| exclude | No | Ensure result set excludes specific IDs | |
| hideEmpty | No | Whether to hide terms not assigned to any posts | |
| include | No | Limit result set to specific IDs | |
| order | No | Order sort attribute ascending or descending | asc |
| orderby | No | Sort collection by term attribute | name |
| page | No | Current page of the collection | |
| parent | No | Limit result set to terms assigned to a specific parent | |
| password | Yes | WordPress application password | |
| perPage | No | Maximum number of items to be returned | |
| post | No | Limit result set to terms assigned to a specific post | |
| search | No | Limit results to those matching a string | |
| siteUrl | Yes | WordPress site URL | |
| slug | No | Limit result set to terms with one or more specific slugs | |
| username | Yes | WordPress username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but lacks behavioral details. It mentions 'filtering options' but doesn't disclose that this is a read-only list operation (implied by 'Get'), pagination behavior (via 'page' and 'perPage'), authentication requirements (siteUrl, username, password are required), or rate limits. It adds minimal context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action. However, it could be more specific (e.g., 'Get a paginated list of WordPress categories with filtering by ID, parent, search, etc.') to better earn its place without adding unnecessary length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 15 parameters, no annotations, and no output schema, the description is minimally adequate but incomplete. It hints at filtering but doesn't cover authentication needs, pagination, or return format. For a complex tool with many parameters, more context (e.g., 'Requires WordPress credentials, returns paginated results') would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds little beyond mentioning 'filtering options', which loosely references parameters like 'exclude', 'include', 'search', etc., but doesn't explain their semantics or relationships. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a list of categories with filtering options' clearly states the verb ('Get a list') and resource ('categories'), but it's vague about scope and doesn't differentiate from siblings like 'get-category' (singular) or 'list-posts'. It doesn't specify what kind of categories (e.g., WordPress taxonomy categories) or the full extent of filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention when to choose 'list-categories' over 'get-category' (for a single category) or 'list-posts' (for posts instead of categories), nor does it specify prerequisites like authentication needs implied by required parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of posts with comprehensive filtering options
| Name | Required | Description | Default |
|---|---|---|---|
| after | No | Limit response to posts published after a given ISO8601 compliant date | |
| author | No | Limit result set to posts assigned to specific authors | |
| authorExclude | No | Ensure result set excludes posts assigned to specific authors | |
| before | No | Limit response to posts published before a given ISO8601 compliant date | |
| categories | No | Limit result set to items with specific terms assigned in the categories taxonomy | |
| categoriesExclude | No | Limit result set to items except those with specific terms assigned in the categories taxonomy | |
| context | No | Scope under which the request is made | view |
| exclude | No | Ensure result set excludes specific IDs | |
| include | No | Limit result set to specific IDs | |
| modifiedAfter | No | Limit response to posts modified after a given ISO8601 compliant date | |
| modifiedBefore | No | Limit response to posts modified before a given ISO8601 compliant date | |
| offset | No | Offset the result set by a specific number of items | |
| order | No | Order sort attribute ascending or descending | desc |
| orderby | No | Sort collection by post attribute | date |
| page | No | Current page of the collection | |
| password | Yes | WordPress application password | |
| perPage | No | Maximum number of items to be returned | |
| search | No | Limit results to those matching a string | |
| searchColumns | No | Array of column names to be searched | |
| siteUrl | Yes | WordPress site URL | |
| slug | No | Limit result set to posts with one or more specific slugs | |
| status | No | Limit result set to posts assigned one or more statuses | |
| sticky | No | Limit result set to items that are sticky | |
| tags | No | Limit result set to items with specific terms assigned in the tags taxonomy | |
| tagsExclude | No | Limit result set to items except those with specific terms assigned in the tags taxonomy | |
| taxRelation | No | Limit result set based on relationship between multiple taxonomies | |
| username | Yes | WordPress username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal information. It doesn't mention that this is a read-only operation (implied by 'Get'), doesn't discuss authentication requirements (though schema shows required credentials), doesn't mention pagination behavior (implied by 'page' and 'perPage' parameters), and doesn't describe rate limits or error conditions. The description adds almost no behavioral context beyond what's already obvious from the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that efficiently communicates the core purpose. It's front-loaded with the main action ('Get a list of posts') and adds only the essential qualifying information ('with comprehensive filtering options'). There's zero wasted verbiage or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 27 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what kind of data is returned (post objects with what fields?), doesn't mention authentication requirements (though schema shows them), and doesn't provide any context about WordPress-specific behaviors. The description fails to compensate for the lack of annotations and output schema documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'comprehensive filtering options' which aligns with the 27 parameters in the schema, but adds no specific parameter semantics beyond what the schema already provides. With 100% schema description coverage where each parameter is well-documented, the description doesn't need to compensate, but also doesn't add value. This meets the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('list of posts'), making it immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'get-post' or 'get-top-posts' by specifying that this is for comprehensive filtering rather than single-post retrieval or specific analytics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get-post' for single posts, 'get-top-posts' for analytics, or 'search' tools that might exist elsewhere. The phrase 'comprehensive filtering options' hints at usage context but doesn't provide explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unreport a referrer as spam
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to remove from spam list | |
| password | Yes | WordPress application password | |
| siteId | Yes | WordPress site ID | |
| siteUrl | Yes | WordPress site URL | |
| username | Yes | WordPress username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but lacks behavioral details. It implies a mutation ('Unreport') but doesn't disclose permissions, side effects, or response format. This is inadequate for a tool with 5 required parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded and appropriately sized for the tool's complexity, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 required parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain the mutation's impact, error conditions, or return values, leaving significant gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds no extra meaning about parameters, sticking to the baseline since the schema handles semantics effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Unreport') and resource ('a referrer as spam'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'report-referrer-spam' beyond the opposite action, missing a direct comparison that would warrant a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing a referrer already reported as spam, or contrast with sibling tools like 'report-referrer-spam' for context, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report a referrer as spam
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to report as spam | |
| password | Yes | WordPress application password | |
| siteId | Yes | WordPress site ID | |
| siteUrl | Yes | WordPress site URL | |
| username | Yes | WordPress username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but doesn't explain what 'reporting' entails—e.g., whether it's a read-only action, if it triggers notifications, requires specific permissions, or has side effects like logging or alerts. This leaves critical behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words, making it highly concise and front-loaded. It immediately conveys the core purpose without unnecessary elaboration, which is efficient for agent comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation action with 5 required parameters), no annotations, and no output schema, the description is insufficient. It doesn't cover behavioral aspects, output expectations, or error handling, leaving significant gaps for the agent to operate effectively in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds no additional meaning beyond the schema, such as explaining the relationship between parameters or usage context. This meets the baseline of 3, as the schema handles the heavy lifting without description enhancement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Report') and the target ('a referrer as spam'), which is specific and unambiguous. However, it doesn't differentiate from its sibling 'remove-referrer-spam', which likely handles removal rather than reporting, leaving room for confusion about their distinct roles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'remove-referrer-spam' or other referrer-related tools. The description lacks context about prerequisites, such as needing authentication or when reporting is appropriate versus removal, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing WordPress category
| Name | Required | Description | Default |
|---|---|---|---|
| categoryId | Yes | ID of the category to update | |
| description | No | New HTML description of the term | |
| meta | No | New meta fields | |
| name | No | New HTML title for the term | |
| parent | No | New parent term ID | |
| password | Yes | WordPress application password | |
| siteUrl | Yes | WordPress site URL | |
| slug | No | New alphanumeric identifier for the term | |
| username | Yes | WordPress username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states 'Update' which implies mutation, but doesn't describe what happens on success/failure, whether changes are reversible, permission requirements, or rate limits. For a mutation tool with 9 parameters and no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that states exactly what the tool does with zero wasted words. It's front-loaded with the core purpose and doesn't contain any unnecessary elaboration or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 9 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't address authentication requirements (though parameters suggest them), error conditions, return values, or how this tool differs behaviorally from similar update operations. The agent lacks critical context for proper tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema. The description adds no additional parameter information beyond what's in the schema - it doesn't explain relationships between parameters, provide examples, or clarify edge cases. Baseline score of 3 is appropriate when the schema does all the parameter documentation work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('an existing WordPress category'), making the purpose immediately understandable. It distinguishes this from creation tools like 'create-category' by specifying 'existing', but doesn't explicitly differentiate from other update tools like 'update-post' or 'update-user' beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites like authentication requirements, nor does it contrast with sibling tools like 'get-category' for reading or 'delete-category' for removal. The agent must 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.
Update an existing WordPress post
| Name | Required | Description | Default |
|---|---|---|---|
| author | No | New author ID for the post | |
| categories | No | New categories for the post | |
| commentStatus | No | New comment status for the post | |
| content | No | New content for the post | |
| date | No | New publication date in the site's timezone | |
| dateGmt | No | New publication date as GMT | |
| excerpt | No | New excerpt for the post | |
| featuredMedia | No | New featured media ID for the post | |
| format | No | New format for the post | |
| meta | No | New meta fields | |
| password | Yes | WordPress application password | |
| pingStatus | No | New ping status for the post | |
| postId | Yes | ID of the post to update | |
| postPassword | No | New password to protect access to the content and excerpt | |
| siteUrl | Yes | WordPress site URL | |
| slug | No | New slug for the post | |
| status | No | New status for the post | |
| sticky | No | New sticky status for the post | |
| tags | No | New tags for the post | |
| template | No | New template for the post | |
| title | No | New title for the post | |
| username | Yes | WordPress username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It states the tool updates a post, implying mutation, but fails to mention critical aspects like authentication requirements (though hinted by required params), side effects, error handling, or response format. This leaves significant gaps for a mutation tool with no structured safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste, front-loading the core action. It is appropriately sized for its purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (22 parameters, mutation operation, no annotations, no output schema), the description is inadequate. It lacks details on behavioral traits, usage context, and output expectations, making it incomplete for effective agent use despite the rich schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting all 22 parameters. The description adds no additional meaning beyond the schema, such as explaining parameter interactions or constraints. Since the schema does the heavy lifting, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing WordPress post' clearly states the verb ('Update') and resource ('WordPress post'), distinguishing it from siblings like 'create-post' or 'delete-post'. However, it lacks specificity about which fields can be updated or scope, making it slightly less distinct than a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'create-post' for new posts or 'get-post' for retrieval. It also omits prerequisites like authentication or post existence, leaving usage context implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing WordPress user
| Name | Required | Description | Default |
|---|---|---|---|
| description | No | New description of the user | |
| No | New email address for the user | ||
| firstName | No | New first name for the user | |
| lastName | No | New last name for the user | |
| locale | No | New locale for the user | |
| name | No | New display name for the user | |
| newPassword | No | New password for the user | |
| newUsername | No | New login name for the user | |
| nickname | No | New nickname for the user | |
| password | Yes | WordPress application password | |
| roles | No | New roles assigned to the user | |
| siteUrl | Yes | WordPress site URL | |
| slug | No | New alphanumeric identifier for the user | |
| url | No | New URL of the user | |
| userId | Yes | User ID or 'me' for current user | |
| username | Yes | WordPress username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Update an existing WordPress user' implies a mutation operation but reveals nothing about permissions required, whether changes are reversible, rate limits, error conditions, or what happens when only partial fields are provided. This is inadequate for a mutation tool with 16 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized and front-loaded with the essential information. Every word earns its place in this minimal description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 16 parameters, no annotations, and no output schema, the description is severely incomplete. It doesn't explain what happens during updates, what permissions are needed, how partial updates work, or what the tool returns. The agent must rely entirely on the schema for understanding, which is insufficient for safe tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema itself. The description adds no additional parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('an existing WordPress user'), making the purpose immediately understandable. It distinguishes this from sibling tools like 'create-user' and 'delete-user' by specifying it's for existing users. However, it doesn't specify what aspects of the user can be updated, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like authentication), when to use 'update-user' versus 'create-user' or 'delete-user', or any constraints on usage. The agent must infer usage entirely from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0create-categorycreate-commentcreate-postcreate-userdelete-categorydelete-postdelete-userget-categoryget-clicksget-commentsget-country-viewsget-postget-post-statsget-referrersget-search-termsget-site-statsget-stats-highlightsget-stats-summaryget-streak-statsget-top-postsget-userget-userslist-categorieslist-postsremove-referrer-spamreport-referrer-spamupdate-categoryupdate-postupdate-userEach tool has a clearly distinct purpose targeting specific resources and actions. For example, create/delete/get/update operations are separated by resource type (category, post, user), and analytics tools (get-clicks, get-country-views, etc.) each focus on different metrics without overlap.
All tools follow a consistent verb_noun pattern with hyphens (e.g., create-post, get-category, update-user). The naming is uniform across all 29 tools, making them predictable and easy to understand.
With 29 tools, the count feels heavy for a WordPress server, as it combines content management (posts, categories, users) with extensive analytics. While each tool is useful, the set might be overwhelming for agents, suggesting it could be split into separate servers for content vs. stats.
The tool surface provides complete CRUD/lifecycle coverage for core resources (posts, categories, users) and includes comprehensive analytics for site stats, referrers, and spam management. There are no obvious gaps for the WordPress domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Publish to self-hosted WordPress from AI agents: markdown, images, SEO, and Notion sync.
Security-first WordPress MCP server. 129 tools for Claude, ChatGPT, Gemini. Free on wp.org.
WordPress MCP server: publish posts, AI images, SEO and full site management, self-hosted
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/prathammanocha/wordpress-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
