Click on "Deploy 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., "@Pressable MCP Server list all my WordPress sites and their current status"
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.
An MCP server for the Pressable API, providing a comprehensive set of tools for management and automation of WordPress sites.
56 Comprehensive Tools: 100% coverage of the Pressable API v1.
Workflow Templates: Preset guides for common tasks (Site Launch, Security Audit).
Preset Prompts: High-signal prompts for AI agents.
Managed Authentication: Auto-token retrieval and caching.
Related MCP server: WordPress MCP Server
Obtain your Client ID and Client Secret from Pressable API Applications.
Create a .env file in the project directory:
PRESSABLE_CLIENT_ID=your_client_id
PRESSABLE_CLIENT_SECRET=your_client_secretAdd the following to your MCP settings file:
{
"mcpServers": {
"pressable": {
"command": "node",
"args": ["/Users/pcw_admin/.gemini/antigravity/scratch/pressable-mcp-server/index.js"],
"env": {
"PRESSABLE_CLIENT_ID": "your_client_id",
"PRESSABLE_CLIENT_SECRET": "your_client_secret"
}
}
}
}The server is organized into 13 specialized modules:
Account: Details, Activity Logs, Account Add-ons.
Sites: Full lifecycle, Conversions, Domains, PHP Permissions, phpMyAdmin access.
DNS: Zone management, Record CRUD, Email provider presets.
Edge Cache: Status, Toggling, Purging, Defensive Mode.
Content: Plugins, Themes, WordPress Users.
Server: SFTP users, PHP versions, Logs, SFTP password resets.
Automation: WP-CLI, Bash, Cron Jobs.
Backups: On-demand snapshots, Restores, Downloads.
Usage: Metrics, Filesystem/Database limits.
Collaborators: Site-level access management.
Bookmarks: Shared Bash/WP-CLI command presets.
Must-Use Plugins: Management of MU-Plugins.
Security: Centralized Plugin/Theme vulnerability alerts.
Check the templates/ directory for:
Add a collaborator to a site.
| Name | Required | Description | Default |
|---|---|---|---|
| site_id | Yes | ||
| Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for revealing behavior. It only states the action but does not disclose permissions needed, whether the operation is idempotent, what happens if the collaborator already exists, or any side effects. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it is under-specified. It omits essential information about usage and parameters, making it less a model of conciseness and more a minimal placeholder. The sentence does not earn its place by providing sufficient actionability.
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 lack of annotations and output schema, the description should compensate by explaining the tool's context and outcome. It fails to mention what the API call returns, whether it requires existing site collaboration settings, or any prerequisites. For a simple tool, it is still incomplete.
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 0% description coverage, and the description adds no clarification about the parameters 'email' or 'site_id'. It does not explain the expected format, where to find the site_id, or any relationship between the two parameters. The agent must rely solely on the parameter names.
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 'Add' and the resource 'collaborator to a site', making the core action unambiguous. It distinguishes itself from the sibling tool pressable_list_collaborators, which lists collaborators, by implying the create action.
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 usage guidance is provided. The description does not mention when to use this tool versus alternatives, nor any prerequisites or exclusions. The agent is left to infer context from the sibling tool list, but the description itself offers no direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a domain to a site.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| domain | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only says 'Add a domain to a site' without indicating side effects, reversibility, or any potential destructive impact. For a mutation tool, this lack of transparency 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, concise sentence with zero wasted words. It is front-loaded with the action and object, making it immediately understandable.
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?
The tool is simple with two parameters, but the description omits important contextual details such as return value, error conditions, or any prerequisites (e.g., domain ownership verification). Since there is no output schema, the description should have explained expected outcomes. Still, the basic purpose is clear, making it minimally viable.
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 indicates two required string parameters, 'id' and 'domain', but the description does not elaborate on their semantics. 'id' is ambiguous; while the description implies it's the site identifier, it does not explicitly say so. The schema coverage is 0%, so the description should compensate, but it does not.
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 ('Add') and the object ('a domain to a site'). It effectively distinguishes this from sibling tools like 'pressable_list_site_domains' by indicating a mutation operation. However, it lacks any additional context about the domain being added, such as verification or ownership requirements.
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 usage guidance is provided. The description does not mention when to use this tool versus alternatives, nor any prerequisites or constraints. It simply states the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a site between staging and live, or to DupliKit/Sandbox.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| target_type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavioral implications. 'Convert' implies a potentially impactful change (e.g., moving between staging and live may cause downtime or affect production), but no side effects, reversibility, or prerequisites are mentioned.
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, concise sentence that front-loads the verb and includes the essential target types without any fluff or repetition. Every word earns its place.
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 mutating tool with no annotations, no output schema, and sparse parameter descriptions, the description lacks crucial context such as potential downtime, whether the conversion is reversible, or what the response contains. It is only marginally complete for an agent to safely invoke the tool.
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 0%, so the description must compensate for lack of parameter explanations. It mentions the target_type values but does not clarify the 'id' parameter or elaborate on the meaning of 'DupliKit' vs 'Sandbox'. The description adds little beyond the enum values already present 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 uses the specific verb 'Convert' and clearly identifies the resource ('a site') and the possible target environments ('staging', 'live', 'DupliKit/Sandbox'). This distinguishes it from sibling tools like update_site or restore_site, which serve different purposes.
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 given on when to use this tool versus alternatives. The description only states what the tool does, not when an agent should select it (e.g., 'Use this to change environment type; for other site modifications, use update_site').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Bash/WP-CLI command bookmark.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| description | No | ||
| command | Yes | ||
| command_type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It merely restates the action ('Create') without mentioning side effects, permission requirements, duplicate handling, or idempotency. It adds no information beyond what the tool name already implies.
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 short sentence, but it is under-specified. It does not earn its place because it is effectively a tautology of the tool name. True conciseness would deliver the necessary information in an efficient manner; this simply omits it.
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 4 parameters, no output schema, no annotations, and 48 sibling tools, the description is severely incomplete. It does not explain what a bookmark is for, the meaning of command_type, or the expected behavior after creation. The agent is left without critical context for correct 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 0%. The description does not explain any of the four parameters (name, command, description, command_type), the enum choices (bash vs wp_cli), or how they relate to each other. It fails to add value beyond the raw 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 uses a specific verb ('Create') and clearly identifies the resource ('Bash/WP-CLI command bookmark'). This distinguishes it from sibling tools like pressable_list_bash_bookmarks and pressable_get_bash_bookmark, which are read operations.
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 explicit guidance on when to use this tool versus alternatives. It does not mention that this is for storing recurring commands or that running commands directly is possible via pressable_run_bash_commands or pressable_run_wp_cli. Usage is only implied by the action itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new DNS record.
| Name | Required | Description | Default |
|---|---|---|---|
| zone_name | Yes | ||
| type | Yes | ||
| name | Yes | ||
| content | Yes | ||
| priority | No | ||
| ttl | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only paraphrases the action ('Create a new DNS record') without revealing side effects, idempotency, validation rules, or permissions. This adds no insight beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It is front-loaded and easy to scan. However, it essentially restates the tool name, so it adds minimal new information, preventing a perfect score.
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?
The tool has six parameters (four required) and no output schema, but the description provides no context about parameter relationships, required formats, or what the response will contain. It is completely inadequate for understanding how to invoke the tool correctly.
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 0%, and the description does not explain any of the six parameters. Critical fields like 'name', 'content', and 'type' are left undefined, making it impossible for an agent to know what values to provide. The description fails to compensate for the schema's lack of explanations.
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 DNS record' uses a specific verb and resource, clearly distinguishing it from sibling tools like pressable_get_dns_records and pressable_delete_dns_record. The purpose is immediately obvious and unambiguous.
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 relative to alternatives. It doesn't mention exclusions, prerequisites, or contrast with get/delete/generate DNS record operations. The user is left to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an on-demand backup of a site.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention whether the backup is asynchronous, requires specific permissions, has rate limits, or what the response contains. The phrase 'on-demand backup' hints at immediate action but lacks operational 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, clear sentence with no redundancy. It could be richer, but it is appropriately front-loaded and free of fluff for a tool with only two parameters.
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 create operation with two parameters and no output schema or annotations, the description is notably incomplete. It does not explain the backup type choice, the expected outcome, or how the backup can be later retrieved, leaving the agent with insufficient 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 0%, so the description must explain the parameters. It mentions 'a site' but does not clarify that 'id' identifies the site or that 'type' selects between filesystem and database backups. The enum information in the schema is not reinforced or elaborated.
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 an on-demand backup of a site' uses a specific verb and resource, clearly distinguishing it from backup listing, restoration, and download operations. It is concise and unambiguous about the tool's core function.
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 given on when to use this tool versus alternatives like scheduled backups, restore, or obtaining download URLs. The description states only what it does, not when it should be invoked or any prerequisites.
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 site.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The name of the site | |
| datacenter | No | Datacenter ID | |
| php_version | No | PHP version (e.g., 8.1) | |
| install_option | No | Install option (e.g., "none", "wp_latest") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations are provided, the description carries the full burden for behavioral disclosure. It only states that a site is created, but does not mention side effects such as potential costs, required permissions, irreversibility, or whether the operation is synchronous. This is a minimal disclosure, similar to a mutation tool without annotations.
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 concise sentence with zero wasted words. It is front-loaded with the action and object, making it easy to parse and process. The length is entirely appropriate for the simplicity of the task.
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?
Without an output schema and with no annotations, the description is incomplete for a create operation. It lacks context about what the response looks like, whether the operation is immediate, any prerequisites, and the real-world effects (e.g., billing, provisioning time). A new WordPress site creation likely has nuances that are not covered.
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% coverage for its four parameters, each with a clear description. The tool description itself adds no parameter-specific information, so the schema does the heavy lifting. Per the rubric, baseline 3 is appropriate when schema coverage is high and description adds no additional meaning.
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 uses the specific verb 'Create' plus the resource 'a new WordPress site', clearly indicating the action. This distinguishes it from sibling tools like pressable_list_sites or pressable_delete_site, and even adds 'WordPress' beyond the tool name, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, no preconditions, and no exclusions. It simply states the action without any contextual advice or mention of alternatives, leaving the agent without decision-support information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a specific DNS record.
| Name | Required | Description | Default |
|---|---|---|---|
| zone_name | Yes | ||
| record_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only implies a destructive operation, but with no annotations, it fails to disclose reversibility, permissions, side effects, or error behavior. It does not contradict annotations, but it does not compensate for their absence.
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 single sentence is short but merely restates the tool name. It is under-specified and does not earn its place by conveying useful 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?
With no output schema and no extra context, a delete tool of this complexity needs at least basic details on return values or failure modes. The description provides none, leaving the agent without enough information for confident 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 0%, and the description does not mention either parameter (zone_name, record_id), their formats, or how they interact. No value is added beyond the schema's bare field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Delete' and the resource 'DNS record', clearly indicating the tool's function. It is unambiguous although it does not explicitly contrast with sibling tools like create_dns_record.
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, prerequisites, or how it differs from alternatives. The description lacks any contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a specific site.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The site ID or name to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is nearly a tautology of the tool name and provides no additional behavioral context. For a destructive action, it should reveal that deletion is irreversible, what cascading effects occur (e.g., related domains, backups), or any prerequisites. No annotations are provided to compensate.
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 short sentence with no fluff. It is front-loaded and easy to parse, though the phrase 'specific' is slightly redundant. It earns brevity points but suffers from under-specification.
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 operation with no annotations and no output schema, the description is severely incomplete. It lacks any mention of irreversibility, side effects, prerequisites, or expected results. Given the large sibling set, more context is essential to avoid accidental misuse.
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 already documents the single required parameter 'id' with a clear description ('The site ID or name to delete'). The tool description adds nothing new, but with 100% coverage, the schema carries the meaning, warranting the baseline score of 3.
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 the resource (site), and 'specific' indicates it targets one site. It distinguishes from other site-related actions like list, create, or update, though it doesn't explicitly note that deletion is permanent.
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 given on when to use this tool versus alternatives. For instance, there's no mention that disable_site might be a non-destructive alternative for temporarily taking a site offline. The description simply states the action without any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Disable a specific site.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The site ID or name |
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 only states the action 'disable' without explaining side effects, reversibility, permissions required, or impact on the site. This is insufficient for a mutating operation.
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 concise sentence with zero wasted words. However, it is extremely terse and lacks supportive context, so it does not fully earn its place as an informative description, though it is structurally efficient.
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?
The tool is a mutation with no annotations and no output schema. The description does not explain return values, side effects, or reversibility, and the single parameter is not elaborated. The description is inadequate for a mutating tool, leaving the agent without critical operational 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?
The input schema covers 100% of parameters with a clear description for 'id' ('The site ID or name'), so the tool description adds no additional parameter meaning. Baseline of 3 is appropriate given 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 states a clear verb 'disable' and resource 'a specific site', making the purpose immediately understandable. It is distinguishable from sibling tools like pressable_enable_site and pressable_delete_site, though it does not elaborate on what 'disable' 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?
There is no guidance on when to use this tool versus alternatives. The description does not mention prerequisites, typical scenarios, or mention the opposite tool pressable_enable_site. This leaves the agent without context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enable a specific site.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The site ID or name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks behavioral disclosure beyond the bare 'Enable' action. With no annotations, it should explain consequences (e.g., site becoming accessible), permissions required, or reversibility, but none are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundancy. It is front-loaded and efficient, though slightly under-structured for a tool with only one parameter.
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 state-changing tool with no annotations and no output schema, the description is incomplete. It doesn't clarify operational effects, what responses to expect, or any prerequisites, leaving too much unstated.
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 fully describes the 'id' parameter as 'The site ID or name', providing complete coverage. The description adds no extra meaning beyond the schema, so the baseline 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 uses a specific verb 'Enable' with resource 'site', clearly stating the operation. It distinguishes itself from sibling tools like pressable_disable_site and pressable_get_site by the unique action of enabling.
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 on when to use this tool versus alternatives. It does not mention that it is for re-enabling a previously disabled site, nor does it compare with pressable_disable_site or other site management tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Flush the object cache for a specific site.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
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 only says 'flush' without explaining side effects, reversibility, required permissions, or impact on site performance. The description lacks any contextual detail about what happens when the cache is flushed.
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 concise sentence that front-loads the verb and object. No unnecessary words or repetition—ideal for a simple 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?
The tool is simple with one parameter and no output schema, so a one-liner might be acceptable. However, the absence of usage context, parameter semantics, and behavioral details leaves room for misinterpretation. For a cache flush operation, one would expect at least a note on what the 'id' references and any immediate effects.
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 0%, so the description must compensate for the undocumented 'id' parameter. Saying 'for a specific site' implies id refers to a site but does not explicitly state 'id: The site ID' or provide format/validation details. This minimal implication adds only slight meaning beyond the schema's bare property name.
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 ('Flush'), the resource ('object cache'), and the scope ('for a specific site'). It distinguishes itself from sibling cache-related tools like pressable_purge_edge_cache by specifying 'object cache' rather than edge cache.
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 such as purge_edge_cache or toggle_edge_cache. There is no mention of prerequisites, scenarios, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate DNS records for a specific email provider.
| Name | Required | Description | Default |
|---|---|---|---|
| zone_name | Yes | ||
| provider | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the action without explaining side effects, return format, or potential destructive outcomes. It is unclear whether this tool actually modifies DNS records in the zone or merely outputs recommended records, which is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 8-word sentence with no fluff or repetition, making it very concise. However, it is so terse that it omits essential details, so it does not fully earn its place as a standalone explanation. Still, for sheer efficiency, it scores above average.
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 absence of annotations and output schema, the description leaves out critical information such as whether records are created or returned, what the output looks like, and any dependencies (e.g., existing DNS zone, provider-specific requirements). The tool is too ambiguous for an agent to invoke confidently without additional help.
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 0%, so the description was expected to compensate for the bare schema. It does not explain what 'zone_name' represents or clarify the meaning of the provider enum values, despite the schema having no property descriptions. The enum itself offers some context, but the description adds no semantic value beyond the tool name.
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 uses a specific verb ('generate') and resource ('DNS records') combined with a clear scope ('for a specific email provider'), which is unambiguous. However, it does not differentiate from sibling tools like pressable_create_dns_record or pressable_get_dns_records, so it receives a 4 rather than 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 offers no guidance on when to use this tool versus alternatives. It does not mention that it is for setting up email provider DNS records, nor does it reference related tools like pressable_create_dns_record or pressable_list_dns_zones. There is no context about prerequisites or selection criteria.
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 all available activity log actions for the account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. The description implies a read-only operation via 'Get a list', but it does not explicitly state that it is safe, nor does it disclose any response format, pagination, or authentication requirements. For a simple read-only list tool, this is acceptable but still leaves some gaps, so a score of 3 is appropriate.
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 gets straight to the point. It contains no extraneous words and is perfectly sized for its 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 parameterless read-only list tool with no output schema, the description is largely complete: it states what is returned (a list of all available activity log actions). It could potentially specify whether these are identifiers or names and how they might be used, but that is a minor gap. The overall context is clear.
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 tool has zero parameters, so per the rubric a baseline of 4 is assigned. The description does not need to explain parameters, as there are none.
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 uses a specific verb 'Get a list' and a clear resource 'activity log actions for the account', which precisely defines what the tool does. It also distinguishes itself from sibling tools like pressable_get_account_activity_logs (which retrieves the logs themselves, not the list of available action types).
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 gives clear context: it is used to retrieve all available activity log actions for the account. It does not explicitly state when not to use it or mention alternatives, but the purpose is unambiguous given the tool name and the sibling set. This is clear context without exclusions, so it earns a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve activity logs for the account.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| per_page | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It merely says 'Retrieve activity logs for the account' without mentioning read-only nature, pagination behavior, data volume, or any other behavioral nuance. This adds no value beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it is under-specified. It is not verbose, but it does not provide enough information to be considered appropriately sized for a tool with pagination parameters. The sentence is front-loaded but lacks substance.
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 two optional parameters and no output schema, the description is severely incomplete. It does not explain what the parameters do, how to use them, or what the response contains. The agent cannot infer key usage details from this 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?
The input schema has two parameters (page, per_page) with no descriptions, and schema description coverage is 0%. The description does not mention these parameters at all, failing to compensate for the lack of schema-level detail.
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 states a clear verb (Retrieve) and resource (activity logs for the account), making the primary purpose understandable. However, it does not explicitly differentiate from the sibling tool pressable_get_account_activity_log_actions, relying on the noun 'logs' vs 'actions' to distinguish. Thus it is clear but lacks 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?
No guidance is provided on when to use this tool versus alternatives, nor are any prerequisites or exclusions mentioned. The description simply states the action with no context about pagination or typical use cases.
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 add-ons attached to your account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavior. It clearly indicates a read-only 'get' operation and clarifies that it returns a list (plural 'add-ons'), but it does not disclose potential details like permissions, pagination, or response structure. This is adequate for a simple read tool but lacks depth.
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, front-loaded sentence that is clear and direct. It contains no fluff or repetition, making it highly concise and well-structured.
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 low complexity (no parameters, no output schema), the description is complete enough for an agent to understand the tool's purpose and invoke it correctly. It could be more detailed about what 'add-ons' encompasses, but for a simple list operation, the coverage is sufficient.
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 tool has zero parameters, so the baseline is 4. The description adds no parameter-specific information because none are needed; the empty input schema already covers everything. There is no gap to compensate for.
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 uses a specific verb ('Get') and resource ('add-ons') and scopes it to 'your account,' clearly distinguishing it from the sibling 'pressable_get_available_addons' which likely lists available add-ons. The one-line description fully states what the tool does.
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 implies this tool is for viewing add-ons already attached to the account, but it does not explicitly mention when to use it over alternatives or provide exclusionary guidance. The differentiation from 'get_available_addons' is implicit via the word 'attached' rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve account profile and settings information.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 'Retrieve' indicates a read-only operation, but it does not disclose potential errors, response format, or authorization requirements, leaving behavior only partially transparent.
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, concise sentence that front-loads the action and target. It contains no wasted words and is appropriately sized for the tool's simplicity.
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?
The tool is simple with no parameters or output schema, so the description covers the basic operation. However, it does not clarify what specific 'settings' are included or how this interacts with other account-level tools, leaving minor gaps in 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?
The input schema has zero parameters, so the baseline score is 4. The description adds no parameter details, but none are needed since the tool takes no arguments.
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 retrieves 'account profile and settings information', with a specific verb and resource. This distinguishes it from sibling tools like activity logs and addons, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for account-level information but does not provide explicit when-to-use guidance or alternatives. It lacks exclusions, such as noting that site-specific details should use pressable_list_sites or pressable_get_site.
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 available account add-ons.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 only says 'Get a list,' which implies a read operation, but it does not mention whether any special permissions are needed, whether the list is paginated, or what a typical response looks like.
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 sentence, making it very concise and front-loaded. It earns its place by stating the core function, but it borders on under-specification, missing opportunities to add useful context.
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 parameterless tool, the description adequately states the primary function. However, it does not explain the meaning of 'available' or differentiate this from the sibling 'pressable_get_account_addons'. The lack of an output schema means the description could provide more detail on the returned list.
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 tool has zero parameters, so the schema is empty and the description is the only source of parameter-related semantics. It identifies the resource as 'available account add-ons,' which provides some meaning, though it could clarify what 'available' encompasses.
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 the resource ('available account add-ons'). However, it does not distinguish this from the similarly named sibling tool 'pressable_get_account_addons', which likely lists add-ons already assigned to the account.
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?
There is no guidance on when to use this tool versus the alternative 'pressable_get_account_addons' or any other sibling. No context is provided about what 'available' means (e.g., available for purchase vs. available to the account).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a download URL for a specific backup.
| Name | Required | Description | Default |
|---|---|---|---|
| site_id | Yes | ||
| backup_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral transparency. It identifies the operation as 'Get' (implying a read), but does not disclose whether the URL expires, whether authentication is needed, or any side effects. This is minimal and adds little beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the action and target. No unnecessary words are present.
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 no output schema, the description does not explain the return value's format or potential caveats (e.g., URL expiration). It lacks guidance on how the download URL should be consumed, making it incomplete for a straightforward tool.
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 0% and the description does not elaborate on site_id or backup_id. While the parameter names are reasonably self-explanatory, the description adds no additional semantic context for constructing valid calls.
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 states the tool's function clearly: 'Get a download URL for a specific backup.' This uses a specific verb and resource, and it is distinct from sibling tools like list_backups or restore_site.
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 offers no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites such as obtaining a backup_id from list_backups. The context implies usage but provides no direct instruction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific Bash command bookmark by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get', which implies a read operation, but does not describe the return format, error behavior when the ID is invalid, authentication requirements, or any side effects. For a retrieval tool, this is a minimal disclosure but lacks meaningful behavioral context beyond the verb.
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 sentence of eight words, front-loading the verb and resource. Every word carries meaning, with no filler 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 simple one-parameter read tool with no output schema, the description is minimally adequate: it tells what the tool does and what parameter is needed. However, it does not describe the return value (e.g., the structure of the bookmark object) or potential errors, which would be valuable given the absence of an output schema and annotations.
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 only defines 'id' as an integer. The description adds semantic meaning by stating 'by ID', making it clear that the parameter is the unique identifier of the Bash command bookmark to retrieve. This compensates for the 0% schema description coverage, though it could further specify where to obtain the ID or its format (e.g., a numeric database ID).
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 states a specific verb ('Get') and resource ('specific Bash command bookmark'), and clarifies the scope with 'by ID', distinguishing it from sibling tools like list_bash_bookmarks (which retrieves all) and create_bash_bookmark (which creates). This is a clear, unambiguous purpose.
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 phrase 'Get a specific Bash command bookmark by ID' implies the tool is for retrieving a single known item when you have its ID, but it does not explicitly name alternatives, prerequisites, or scenarios where other tools (e.g., list_bash_bookmarks) would be more appropriate. Usage context is 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 DNS records for a specific zone.
| Name | Required | Description | Default |
|---|---|---|---|
| zone_name | Yes | The zone name/domain |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. The verb 'Get' implies a read-only operation, which is inherently transparent. However, it does not explicitly state that no modifications occur, nor does it mention any edge cases or output behavior. This is adequate but minimal.
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, front-loaded sentence with zero waste. It conveys the essential purpose and scope 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?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is sufficiently complete. It states what the tool does and the required input. It lacks detail on return format or error handling, but for a straightforward getter, this is not a significant gap.
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% (the single parameter 'zone_name' has its own description). The tool description does not add meaningful parameter semantics beyond the schema, so 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 clearly states the tool's function with a specific verb ('Get') and resource ('DNS records'), and scopes it to 'a specific zone', distinguishing it from sibling tools like 'pressable_list_dns_zones' which lists zones, and 'pressable_create_dns_record'/'pressable_delete_dns_record' which modify records.
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, no prerequisites (e.g., needing to obtain the zone name from 'pressable_list_dns_zones'), and no exclusions. Usage is only implied by the name and simple sentence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the status of edge caching for a specific site.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Site ID or name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The verb 'Get' implies a read-only operation, but the description does not explicitly state that it has no side effects, nor does it disclose any permissions, rate limits, or what constitutes the 'status' (e.g., enabled/disabled, defensive mode). It essentially restates the tool name without adding 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 sentence of ten words, front-loaded with the main action and resource. Every word contributes meaning, and there is no filler or redundant information. It is an excellent example of conciseness.
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 simple one-parameter getter, the description is minimally sufficient, but it lacks an output schema and does not explain what the 'status' contains or how it relates to sibling tools like toggle or purge. Without any output description, an agent cannot fully anticipate the response format, and without usage guidance, it may not know when to choose this over alternatives.
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 already fully documents the single parameter `id` with a description ('Site ID or name'), and schema coverage is 100%. The description adds no additional meaning or usage details about the parameter, so it receives the baseline score without any bonus.
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'), the resource ('status of edge caching'), and the scope ('for a specific site'). It effectively distinguishes this tool from siblings like pressable_toggle_edge_cache and pressable_purge_edge_cache, which perform different operations on the same resource.
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 usage is implied: it is used to retrieve the current state of edge caching. However, there is no explicit guidance on when to use this tool versus related tools (e.g., toggle or purge), nor any mention of alternative tools or exclusions. The description is minimal and does not provide strategic context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details for a specific MU plugin.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only says 'Get details' without disclosing read-only nature, error handling, or response format. The behavior is safe but unstated.
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 concise sentence, front-loaded, with no unnecessary words.
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?
The tool is simple, but with no output schema or annotations, the description is too sparse. It doesn't mention return details, error cases, or why to use this instead of pressable_list_mu_plugins.
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 coverage is 0% for the 'id' parameter. The description adds some context by implying the id identifies the MU plugin, but it doesn't explicitly describe the parameter or its expected format.
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 (details for a specific MU plugin). It implies single-item retrieval, distinguishing it from list_mu_plugins, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 that it should be used when a specific MU plugin ID is available, nor does it reference list_mu_plugins or other getter tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get PHP error logs for a site.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It provides no details on output format, authentication, or side effects, only a bare statement of function.
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, front-loaded sentence with no filler. It is appropriately minimal for a simple getter, though it could include more detail without becoming verbose.
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 absence of an output schema and annotations, the description should explain what the agent will receive (e.g., log content, format) and any limitations. It does not, leaving the tool under-specified 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?
The only parameter 'id' is not described in the schema (coverage 0%). The phrase 'for a site' hints that it is a site identifier, but this is not explicit, and the description adds no concrete 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 'Get PHP error logs for a site' uses a specific verb and resource, clearly distinguishing this tool from siblings like get_site_metrics or get_site. It is unambiguous about its function.
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 simply states what it does, leaving the agent to infer context, with no mention of alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a time-limited phpMyAdmin URL for a site.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
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 mentions 'time-limited' (indicating the URL expires), but does not disclose other important aspects such as authentication requirements, side effects, whether the operation is read-only, or what happens if the site ID is invalid. This is minimal 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, concise sentence with no unnecessary words. It is front-loaded and clearly conveys the core function without any padding.
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 simple tool with one parameter and no output schema, the description provides the core purpose but leaves gaps. It does not describe the return format (e.g., that the response contains the URL), how long the URL remains valid, or any additional context about the site requirement. Given the minimal complexity, the description is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required 'id' parameter with no description, and schema description coverage is 0%. The description does not explicitly explain what 'id' represents, though the phrase 'for a site' hints that it is a site ID. This is insufficient compensation for the complete lack of schema-level 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 the resource ('a time-limited phpMyAdmin URL for a site'), making the tool's purpose immediately obvious. It uniquely distinguishes this tool from all sibling tools, since no other sibling provides a phpMyAdmin URL.
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 implies the tool is used to obtain a phpMyAdmin URL, but it provides no explicit guidance on when to use it versus alternatives, nor any exclusions or prerequisites. Since the purpose is so specific, the usage context is implied, but not clearly articulated.
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 SFTP users for a specific site.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. The description only says 'Get a list' which is already evident from the tool name. It does not mention whether the operation is read-only (though implied), any rate limits, required permissions, or response format.
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, concise sentence that conveys the essential purpose without any redundancy or unnecessary detail.
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 simple read tool with one parameter and no output schema, the description provides the core purpose and parameter mapping. However, it lacks detail about expected response contents, possible edge cases, or any prerequisites, making it minimally adequate.
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 meaning to the single 'id' parameter by indicating it refers to 'a specific site'. This compensates for the lack of schema descriptions (0% coverage). However, it does not specify the format or source of the id.
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'), resource ('list of SFTP users'), and scope ('for a specific site'). This distinguishes it from sibling tools like pressable_reset_sftp_user_password and pressable_list_wp_users.
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, prerequisites, or alternatives. It simply states what it does without any 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 details for a specific site by ID or name.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The site ID or site name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the purpose; it does not mention what 'details' include, what happens if the site is not found, required permissions, or whether the operation is a safe read. The word 'Get' implies read-only, but that is insufficient given the lack of annotations.
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 filler. It front-loads the core purpose and is appropriately concise for a simple get-by-id 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?
With no output schema, the description should clarify what 'details' means or the expected return shape, but it does not. It is adequate for invoking the tool (ID or name is clear) but lacks context about the response, which is a gap for a get operation in an API with many siblings.
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 already documents the single parameter as 'The site ID or site name' with 100% coverage. The description's 'by ID or name' adds no meaning beyond what the schema provides, so the baseline score of 3 applies.
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 uses the specific verb 'Get' and clearly identifies the resource ('details for a specific site') and the lookup mechanism ('by ID or name'). It is distinct from siblings like pressable_list_sites, which lists all sites, and other getters that target different entities.
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 phrase 'for a specific site' implies the tool is used when you need detail for one site rather than a list, but it provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives like pressable_list_sites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get performance metrics for a specific site.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It only says 'Get performance metrics,' without explaining what metrics are returned, the response format, or any potential side effects (though unlikely for a read operation). This is minimal 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, concise sentence that front-loads the main purpose with no redundant words. It is extremely efficient and appropriately sized for a simple read 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?
Given the lack of output schema and annotations, the description should clarify what 'performance metrics' entails (e.g., uptime, response time, traffic) and what the response looks like. It does neither, leaving the agent with insufficient context about the tool's output.
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 has one required parameter 'id' with no description (0% schema coverage). The description does not explain what 'id' refers to, though it is implicitly the site ID. This fails to compensate for the lack of schema 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 (performance metrics for a specific site), which distinguishes it from other 'get' tools like get_site or get_site_usage. However, it does not explicitly differentiate itself from sibling tools, so it misses the top 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, no prerequisites, and no context about typical use cases. It simply states what it does, leaving the agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get storage and resource usage for a specific site.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'Get' implies a read-only operation, but the description does not disclose authorization needs, response format, or limitations. No contradiction with annotations exists.
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?
A single concise sentence, front-loaded with the action, contains no filler or redundant information. This is appropriately sized for a simple one-parameter 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?
The basic purpose is clear, but the description omits what the returned usage data contains (units, limits, current usage) and does not address overlap with get_site_metrics. With no output schema or annotations, more detail would be needed for an agent to fully understand the tool's response.
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 single 'id' parameter is left with 0% schema description coverage; however, the phrase 'for a specific site' gives some indication that id is the site identifier, adding marginal meaning beyond the bare schema. It does not specify format or constraints, but the simple context mitigates the gap.
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 uses a specific verb ('Get') and resource ('storage and resource usage for a specific site'), making the primary action clear. However, it does not differentiate from sibling pressable_get_site_metrics, which could cover similar ground.
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 given about when to use this tool versus siblings like get_site_metrics or set_site_usage_limits. It merely states functionality without context, exclusions, or alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Install and activate a plugin on a site.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| plugin_slug | Yes | Slug of the plugin from WP.org |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It states the action but does not describe potential side effects, required permissions, behavior on conflicts (e.g., already installed plugin), or any other important operational details.
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. However, it may be under-specified for a tool with mutation side effects, so it is concise but lacks necessary 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 state-changing tool with no annotations and no output schema, the description is too minimal. It leaves out important context about return values, error cases, and operational behavior, making it incomplete for reliable agent decision-making.
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 coverage is only 50% (plugin_slug has a description, id does not). The description does not clarify what 'id' refers to (presumably the site ID) and does not elaborate on the plugin_slug beyond the schema. It adds minimal semantic 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 action ('Install and activate') and the resource ('a plugin on a site'), making the tool's purpose unambiguous. It is distinct from sibling tools like pressable_list_plugins, though it does not explicitly name alternatives or scope.
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 others. It does not mention prerequisites, exclusions, or alternative tools, leaving the agent to infer usage from the name and description.
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 backups for a specific site.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of conveying the operation's nature. 'Get a list' implies a read-only operation, which is helpful, but it does not disclose additional behavioral details such as pagination, ordering, or whether all backup types are included. For a simple list tool, this is minimally adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It efficiently communicates the tool's 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 simple one-parameter list tool, the description is mostly adequate, and since there is no output schema, return details are not required. However, the existence of a closely related sibling (list_site_backups_by_type) means the description should have clarified whether this returns all backup types or a specific subset, which is missing.
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 contains a single required 'id' parameter with no description (0% coverage). The description adds some context by saying 'for a specific site', implying the id is a site id, but it does not explicitly define the parameter, leaving room for ambiguity.
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 'Get a list of backups for a specific site' with a specific verb and resource. However, it does not distinguish this from the sibling tool 'pressable_list_site_backups_by_type', which also lists backups but by 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?
No guidance is provided on when to use this tool versus alternatives such as pressable_list_site_backups_by_type. The description only states what it does, with no context about the relationship to sibling backup tools or when one should be preferred.
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 Bash command bookmarks for your account.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Search term for name or command | |
| per_page | No | ||
| page | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavioral traits. It merely states 'Get a list' without mentioning pagination, filtering, authentication, or return format. The presence of page and per_page parameters suggests pagination behavior, but the description does not surface this, leaving the agent without critical 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, concise sentence that states the core function without any filler. It is front-loaded with the action and resource, making it easy to parse quickly. Every word earns its place, and there is no 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 has three parameters, no output schema, and no annotations, the description is far too minimal to be complete. It does not explain pagination, search filtering, or what the response list contains. The absence of any mention of the return format or usage caveats leaves a significant gap for an agent trying to invoke the tool correctly.
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 coverage is only 33% (only 'search' has a description). The tool description adds no information about the 'page' or 'per_page' parameters, which are bare in the schema. It does not explain that these control pagination, nor does it clarify the search behavior beyond the schema's minimal description. The description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb 'Get a list' and clearly identifies the resource as 'Bash command bookmarks' scoped to 'your account'. This distinguishes it from sibling tools like pressable_get_bash_bookmark (singular) and pressable_create_bash_bookmark, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that pressable_get_bash_bookmark should be used for retrieving a specific bookmark, nor does it clarify any prerequisites or exclusions. The usage context is only implied by the tool's name and resource type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all collaborators for an account or specific site.
| Name | Required | Description | Default |
|---|---|---|---|
| site_id | No | Optional site ID to filter by |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. 'List' clearly implies a read-only operation, but it does not disclose response format, pagination, or permission requirements. This is minimal but acceptable for a simple list tool.
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 sentence that is front-loaded with the action and resource, with zero wasted words. It is appropriately concise and well-structured.
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 simple read-only list tool with one optional parameter and no output schema, this description is adequate. It states the purpose and the optional scope, but could be slightly more complete by explicitly mentioning account-level vs site-level selection via site_id.
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 already covers the only parameter (site_id) with a clear description. The tool description reinforces this by mentioning 'specific site', but adds little beyond the schema. Baseline of 3 is appropriate given 100% 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 uses a specific verb ('List') and resource ('collaborators'), and clearly scopes to 'account or specific site', distinguishing it from sibling tools like pressable_add_collaborator and other list 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 clearly states when to use the tool: to list collaborators for an account or a specific site. It does not explicitly mention alternatives or exclusions, but the optional site_id implies filtering, providing adequate context for a simple list operation.
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 cron jobs for a specific site.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
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 only states the operation ('Get a list') without revealing any additional traits, such as whether the operation is read-only, pagination behavior, response format, or required permissions. The lack of any transparency beyond the verb leaves the agent with incomplete expectations.
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, concise sentence that is front-loaded with the action and resource. There is no redundant or filler content; every word contributes to the meaning. It is appropriately sized for a simple list 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?
Given the tool has only one parameter, no output schema, and no annotations, the description is somewhat minimal. It states that the tool lists cron jobs for a site, but it omits details like the structure of the returned cron jobs, whether pagination exists, or any error conditions. For a straightforward read operation, this may be adequate but leaves gaps in expectations.
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 only defines 'id' as a string with no description. The description compensates by saying 'for a specific site', which semantically links 'id' to the site identifier, providing crucial context. This adds meaningful meaning beyond the schema, though it doesn't explicitly state that 'id' is the site ID or where to obtain it.
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 a list') and the specific resource ('cron jobs for a specific site'). It distinguishes itself from sibling tools by naming a unique resource (cron jobs) not covered by other 'list' tools. The purpose is unambiguous and directly tied to the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use case: to retrieve cron jobs for a site, with the 'id' likely representing the site ID. However, it provides no explicit guidance on when to prefer this tool over alternatives, such as other list tools, nor does it mention any exclusions or prerequisites. The usage context is clear but not elaborated.
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 all DNS zones.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 clearly indicates a read-only operation ('Get') and the scope ('all DNS zones'), but it does not add context about pagination, authentication requirements, or response structure. The description is minimally adequate and not misleading.
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 concise sentence that front-loads the action (Get) and the resource (list of all DNS zones). It contains no unnecessary words or fluff.
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 parameterless list tool with no output schema, the description provides enough context for an agent to select and invoke the tool correctly. It could optionally mention response format or empty-list behavior, but given the simplicity, it is sufficiently 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?
This tool takes zero parameters, so the description is not required to explain parameter semantics. Per the rubric, a baseline of 4 is appropriate when there are no parameters.
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 uses a specific verb 'Get' and a specific resource 'DNS zones', clearly indicating the action and object. The word 'all' clarifies that this returns the full set of zones, distinguishing it from related tools like pressable_get_dns_records which operate on records within a zone.
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 its alternatives. It does not mention any prerequisites, exclusions, or situations where a different tool (e.g., pressable_get_dns_records) would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of must-use (MU) plugins for your account/sites.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| per_page | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states 'Get a list' without mentioning pagination, account/site scoping details, or any side effects. It does not reveal that the tool uses page and per_page parameters or how results are returned, leaving significant behavioral ambiguity.
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 concise sentence that front-loads the action and resource, with no unnecessary words. While it is brief, it is structurally clear and easy to parse, though it sacrifices completeness for brevity.
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 is a simple list operation with no output schema and no annotations, the description still fails to provide essential context such as pagination or how it differs from other plugin-related tools. The minimal description does not compensate for the lack of schema documentation, making it inadequate for full 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?
The schema has 0% description coverage, and the tool description completely ignores the 'page' and 'per_page' parameters. The description adds no meaning beyond the bare parameter names, failing to explain their purpose or format. This is the lowest score because the description neither lists nor explains the parameters.
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 action ('Get') and resource ('list of must-use (MU) plugins'), including scope ('for your account/sites'). It distinguishes from sibling tools like pressable_list_plugins (regular plugins) and pressable_get_mu_plugin (single plugin), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 pressable_list_plugins or pressable_get_mu_plugin. It does not mention pagination or any specific scenarios, leaving the user to infer usage from the tool name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of plugins for a specific site.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must fully convey behavioral traits. The verb 'Get' implies a read-only operation, but the description does not explicitly state this, nor does it disclose any permissions, potential errors, or return behavior beyond the basic listing.
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 sentence of nine words, delivering the core purpose without any unnecessary content. It is concise and front-loaded.
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 simple list tool with one parameter and no output schema, the description covers the basic purpose but lacks detail on the return structure, potential edge cases, or prerequisites. It is minimally adequate but not complete for an agent to fully anticipate the tool's behavior.
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 one required 'id' parameter with no description, while the tool description says 'for a specific site', indirectly suggesting that 'id' is the site ID. This partially compensates for the lack of schema coverage, but the description does not specify the format or expected values for the parameter.
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 the resource 'list of plugins for a specific site', which distinguishes it from sibling tools like list_themes or list_mu_plugins. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any conditions, prerequisites, or alternative tools, despite there being several similar list tools in the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get security alerts for plugins and themes across all sites.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Type of alerts to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. The verb 'Get' implies a read-only operation, and 'across all sites' adds scope context. However, it does not explicitly state non-destructiveness, output format, or any potential side effects, which is a moderate 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 sentence that is direct and front-loaded with the action ('Get security alerts'), followed by the object and scope. There is no wasted wording; every word contributes to understanding the tool's 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?
The tool is simple with one optional parameter and no output schema, so the description suffices for basic selection. It conveys the key scope ('across all sites') which is important for choosing between this and site-specific tools. However, it could have mentioned whether resolved alerts are included or any default filtering, but this is a minor omission given the tool's simplicity.
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 already provides 100% coverage with a clear enum and description for the 'type' parameter (plugin/theme). The tool description mentions plugins and themes, but adds no new parameter-level meaning beyond matching the schema values. Baseline 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 clearly states the tool gets security alerts, specifies the resources (plugins and themes), and indicates the scope (across all sites). This distinguishes it from sibling tools like list_plugins or list_themes, which list the plugins/themes themselves rather than alerts.
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 implies when to use the tool: when you need security alerts rather than general plugin/theme listings. However, it does not explicitly mention alternatives or provide exclusions, so usage guidance is only implicit rather than directly 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 backups filtered by type (filesystem or database).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| type | Yes |
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 'Get' implying a read operation, but does not disclose permissions, effects on the system, return format, or any limitations. This is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. It contains no filler or redundant phrasing, though it could have incorporated brief parameter information without becoming verbose.
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 lack of output schema, annotations, and parameter descriptions, the description is too sparse. It omits the meaning of the 'id' parameter, return behavior, and any caveats. For a tool with two required parameters, this is not a complete 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?
The schema has 0% description coverage. The description explains the 'type' parameter by listing the enum values in parentheses, but the required 'id' parameter is not described at all, leaving its purpose ambiguous. The description only partially compensates for the missing schema descriptions.
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 uses a specific verb 'Get' and names the resource as 'list of backups filtered by type', making the core function clear. It also distinguishes from the sibling tool 'pressable_list_backups' by the 'by_type' qualifier, even though it does not explicitly name that alternative.
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 such as pressable_list_backups. The description does not mention prerequisites, context, or when this filter is needed.
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 domains for a specific site.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden of behavioral disclosure. It only states the basic operation without mentioning read-only intent, return format, error behavior, or any side effects. The name 'list' implies safety, but this is not explicit.
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, succinct sentence that front-loads the key information. It contains no irrelevant words or repeated schema details, earning a high score for structure and conciseness.
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 simplicity (one parameter, list operation), the description captures the core purpose adequately. However, it lacks information about return structure, permissions, or edge cases, which would be useful for an agent invoking the tool, so it remains minimally viable.
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 has one 'id' parameter with 0% description coverage. The description's phrase 'for a specific site' provides minimal context that the id refers to a site identifier, partially compensating for the lack of schema descriptions, though it does not specify format or constraints.
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 uses a specific verb 'Get' and clearly identifies the resource as a list of domains scoped to a specific site, distinguishing it from siblings like pressable_list_sites and pressable_add_site_domain. It is concise and unambiguous.
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, nor does it mention exclusions or prerequisites. It simply states what the tool does without any contextual or alternative-based usage hints.
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 sites belonging to your account. Sites can be filtered by tag name or paginated.
| Name | Required | Description | Default |
|---|---|---|---|
| paginate | No | Request a paginated response | |
| per_page | No | Amount of sites returned in a response | |
| page | No | Page of the response | |
| tag | No | Filter sites by tag name |
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 only states the basic action and mentions filtering/pagination, but does not disclose authentication requirements, default pagination behavior, response format, or any side effects. This is minimal and leaves many behavioral aspects to the agent's speculation.
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 exactly two sentences, front-loading the primary purpose and then adding the key option (filter/paginate). Every word earns its place, with no filler 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?
Given the tool has 4 parameters, no annotations, and no output schema, the description is adequate but not complete. It covers the core purpose and introduces pagination, but does not explain return values or response structure, which would be helpful since there is no output schema. It remains minimally viable but with clear gaps in 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 coverage is 100%, so the parameters are already well-documented with descriptions for tag, page, paginate, and per_page. The description reiterates that sites can be filtered by tag or paginated, but adds no new meaning beyond the schema. This aligns with the baseline of 3 for full 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 uses a specific verb ('Get') with a clear resource ('a list of sites') and scope ('belonging to your account'), distinguishing it from sibling tools like pressable_get_site (singular) and pressable_list_site_domains (domains). It accurately captures the tool's function as a listing operation.
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 implies usage for listing sites with optional tag filtering and pagination, but does not explicitly state when to prefer this over alternatives like pressable_get_site for a single site. There are no exclusions or when-not-to-use scenarios, leaving the context partially implied.
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 themes for a specific site.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
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 disclosure. It only states a simple read operation with no details about response content, sorting, or limitations. It adds no behavioral 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 concise sentence that gets straight to the point with no fluff. It is appropriately front-loaded, though very brief.
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?
The tool is simple (1 param, no output schema, no annotations), but the description leaves the 'id' parameter undocumented and provides no details about the returned theme list. It is minimally adequate but incomplete.
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 has one 'id' parameter with no description (0% coverage). The description does not explain what 'id' refers to (presumably the site ID), leaving the parameter ambiguous.
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 a list) and resource (themes) with scope (for a specific site). It distinguishes from siblings by naming 'themes' as the resource, though it doesn't explicitly contrast with other list 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?
No guidance is provided on when to use this tool versus alternatives like pressable_list_plugins or pressable_list_sites. There is no context about prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List WordPress users for a specific site.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| page | No | ||
| per_page | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only restates the tool's purpose without disclosing behavioral traits such as pagination limits, error handling, or read-only semantics. The sentence adds nothing beyond what the tool name already implies.
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, concise sentence that immediately states the purpose. There is no filler, redundant detail, or unnecessary structure, making it appropriately front-loaded and efficient.
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 simple tool and lack of output schema, the description is still incomplete. It does not clarify the required 'id' parameter's role, explain the optional pagination parameters, or indicate what the response will contain. This leaves a new agent without essential operational details.
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 three parameters (id, page, per_page) with no descriptions (0% schema coverage). The description does not explain the meaning of 'id' directly, though it implies a site ID. Pagination parameters are completely unaddressed, so the description fails to compensate for the absence of schema descriptions.
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 'List WordPress users for a specific site' clearly states the action (list) and resource (WordPress users), with an explicit scope ('specific site'). This distinguishes it from sibling list tools like pressable_list_sites or pressable_list_plugins.
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 does not mention that the 'id' parameter is required, nor does it offer any exclusions or prerequisites. No context about site-level permissions or choosing this over other list tools is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Purge the edge cache for a specific site.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Site ID or name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Purge' implies a destructive action, but the description does not explain effects, reversibility, or any side effects. It adds no detail beyond the operation itself.
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 concise sentence that directly states the tool's function. Every word is purposeful, and the structure is front-loaded with the verb and target.
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?
The tool is simple with one parameter and no output schema, so the description is minimally adequate. However, it lacks any mention of prerequisites, edge cases, or what happens after the purge, which would be helpful for an agent to invoke it correctly. It meets the minimum viable bar but no more.
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 provides a description for the id parameter ('Site ID or name'), giving 100% coverage. The tool description does not add additional meaning beyond what the schema already states, so the baseline of 3 applies.
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 ('Purge') and the resource ('edge cache for a specific site'), making the tool's purpose specific. However, it does not explicitly distinguish it from sibling tools like pressable_get_edge_cache_status or pressable_toggle_edge_cache, which are similarly scoped.
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 about when to use this tool versus alternatives. The description only states what it does, leaving the agent to infer usage from the tool name and sibling context. There are no exclusions or explicit references to other cache-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reset the password for a specific SFTP user.
| Name | Required | Description | Default |
|---|---|---|---|
| site_id | Yes | ||
| username | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral effects. It fails to mention that this is a mutating action with security implications, whether the new password is returned (since no password parameter exists in the schema), what happens to the old password, or any permission requirements. The bare 'reset' provides no insight into consequences or response 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, front-loaded sentence with no wasted words. It states the action and resource directly, earning its place without any fluff 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?
Given the lack of annotations and output schema, the description is insufficient for an agent to fully understand invocation. It does not specify what the tool returns (likely the new password), the necessity of site_id, or any side effects. The description is too short to cover the operational context for a sensitive mutation 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 0%, so the description must compensate for the parameters. While 'specific SFTP user' clarifies that 'username' identifies an SFTP user, it does not explain the role of 'site_id' or that the username is scoped to a site. The description adds minimal meaning beyond the parameter names and types.
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 uses a specific verb 'reset' with a clear resource: 'the password for a specific SFTP user.' It clearly distinguishes from sibling tools like pressable_get_sftp_users (listing users) and pressable_reset_wp_admin_password (resetting WordPress admin passwords), making the tool's purpose unambiguous.
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, nor are any prerequisites mentioned (e.g., the user must already exist, or how to obtain the username via pressable_get_sftp_users). The description merely states the action, leaving the agent to infer context entirely from the tool name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reset the WordPress admin password for a site.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It only states the action without explaining effects such as whether a new password is returned, emailed, or immediately invalidates existing sessions, or whether special permissions are required.
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 one concise sentence with no unnecessary words or redundant 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 security-sensitive mutation operation with no annotations and no output schema, the description is incomplete. It does not cover expected return values, potential side effects, or any requirements like authentication or existing password.
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 provides a single 'id' string parameter with no description. The phrase 'for a site' implies id refers to a site, but it does not explicitly define the parameter's meaning, format, or constraints.
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 ('Reset'), the target ('WordPress admin password'), and the scope ('for a site'). This differentiates it from siblings like pressable_reset_sftp_user_password.
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. There are no mentions of prerequisites, exclusions, or alternative tools (e.g., WP-CLI).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restore a site from a backup.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Site ID to restore | |
| filesystem_id | No | ||
| database_id | No | ||
| restore_on_site_id | No | Optional ID of site to restore onto |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not disclose that restoring is a destructive operation that likely overwrites current site content, nor does it mention permissions, reversibility, or response behavior. The description is too minimal to warn the agent of potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It earns its place but offers minimal information. It is appropriately short, though not as structured or informative as could be expected for a tool with multiple parameters.
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?
The tool has 4 parameters, no annotations, and no output schema, so the description must compensate. A one-sentence description does not explain the underlying backup model, what database_id and filesystem_id refer to, or any side effects or return values. This is insufficient for a restore operation that could logically require coordination of multiple backup components.
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 50% (only id and restore_on_site_id have descriptions). The description itself adds no parameter information, so it does not compensate for the undocumented database_id and filesystem_id parameters. This leaves ambiguity about which backup components are being restored and how they relate.
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 (restore) and the resource (a site from a backup), which is a specific verb+resource combination. However, it does not explicitly distinguish itself from sibling tools like pressable_get_backup_download_url or pressable_list_backups, so it lacks 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 explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. The usage is only implied by the action itself, which does not meet the bar for clear context or alternative selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run Bash commands on a specific site.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| commands | Yes | List of Bash commands |
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 merely states that it runs bash commands on a site, but does not disclose important traits such as whether the commands are destructive, whether they require elevated permissions, how output is returned, or execution semantics (sequential vs parallel). This is a high-risk tool with zero added 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 concise sentence and is front-loaded with the core action. However, it is under-specified for a tool that executes arbitrary bash commands; the brevity is not a virtue when critical behavioral details are omitted. It is not wasteful but it is insufficient.
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?
This tool is complex and potentially dangerous (running arbitrary bash commands on a site), with no annotations and no output schema. The description is severely incomplete: it does not mention expected outputs, side effects, prerequisites, or safety implications. It is only six words long and provides no contextual grounding.
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 coverage is 50% (only 'commands' has a description, 'id' does not). The description text adds no meaning beyond the schema: it does not explain that 'id' is likely the site ID or how the command array is processed. The command description 'List of Bash commands' is trivial and does not clarify execution order or error handling.
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 ('Run Bash commands') and the resource ('a specific site'), which is a specific verb+resource combination. However, it does not explicitly distinguish itself from the sibling tool 'pressable_run_wp_cli', so it lacks explicit 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 gives no guidance on when to use this tool versus alternatives like 'pressable_run_wp_cli' or 'pressable_list_bash_bookmarks'. It does not indicate prerequisites, exclusions, or typical use cases, leaving the agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run WP-CLI commands on a specific site. Commands are prefixed with "wp" automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| commands | Yes | List of WP-CLI commands (e.g., ["plugin list", "cache flush"]) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are available, so the description must disclose behavioral traits. It discloses that commands are prefixed with 'wp' automatically, which is useful. However, it does not mention that running arbitrary WP-CLI commands can be destructive, require certain permissions, or return specific output. This is a significant gap for a command execution tool.
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 two sentences with no wasted words. It front-loads the purpose and adds the key behavioral note about the prefix. Every sentence earns its place, making it appropriately concise.
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?
This tool runs arbitrary WP-CLI commands, which is a high-risk operation. Without annotations or an output schema, the description fails to mention potential side effects, authentication requirements, or return formats. It is not complete enough for an agent to invoke safely, especially given the powerful nature of WP-CLI.
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 coverage is 50% with 'commands' described but 'id' not. The description clarifies that 'id' refers to a site and that commands should omit the 'wp' prefix, adding some meaning beyond the schema. Yet it does not explain the execution order of multiple commands or error behavior, so it only partially compensates.
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 runs WP-CLI commands on a specific site, which is a specific verb+resource pair. It distinguishes itself from the sibling pressable_run_bash_commands by specifying WP-CLI rather than bash commands, and the scope of a specific site is explicit.
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 implies this tool is for WP-CLI commands, but it does not explicitly mention when to use it versus run_bash_commands or other site management tools. No alternatives or exclusions are provided, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set PHP file system permissions for a site.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only says 'Set PHP file system permissions' without explaining what permissions are changed, whether the operation is potentially disruptive, or what effects occur on the site. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It is appropriately sized for a simple one-parameter tool, though it lacks additional structure or helpful breakdown. It is efficient but not comprehensive.
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 one parameter and no output schema or annotations, the description still fails to provide essential context. It does not specify what the 'id' refers to, what permissions are set, or any side effects. For a mutation tool, this is incomplete and would leave an agent guessing.
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 0%, and the description does not mention the 'id' parameter or its meaning. The only parameter is a string 'id', but the description never explains that it likely refers to the site ID. The schema itself provides no additional context, so the parameter remains semantically opaque.
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 states the action clearly: 'Set PHP file system permissions for a site.' It has a specific verb ('Set') and resource ('PHP file system permissions'), and it names the target ('a site'). However, it could be confused with other setter tools like 'pressable_set_php_version' or 'pressable_set_site_usage_limits', so it lacks 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?
No guidance is provided on when to use this tool or when to prefer an alternative. The description is a single sentence with no context about prerequisites, typical use cases, or distinctions from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the PHP version for a specific site.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| php_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits beyond the bare action. For a mutation tool like this, it should mention potential side effects, such as whether changes take effect immediately or require a restart, and that this is a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose without any superfluous wording. It is front-loaded and easy to parse, earning all points for conciseness.
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 simplicity (two parameters, no output schema), the description still lacks essential context about usage when, side effects, and what happens after execution. There is no mention of return values or any warnings, leaving an agent without enough information to confidently invoke the tool.
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 does not explain the 'id' or 'php_version' parameters beyond saying 'specific site', leaving 'id' ambiguous. Although the schema includes an enum for php_version, the description adds minimal semantic value. With 0% schema description coverage, the burden falls on the description to clarify parameters, which it fails to do.
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 function with a specific verb ('Set') and resource ('PHP version for a specific site'). However, it does not differentiate from sibling tools like pressable_update_site, which might also modify site settings, so it lacks 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?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. It simply states the action without contextual usage hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set filesystem or database usage limits for a site.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| type | Yes | ||
| limit | Yes | Limit in bytes | |
| warning_headroom | No | Warning headroom in bytes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It only states the action without mentioning side effects, permissions, reversibility, or what happens to existing limits. This is a mutation tool, and critical behavioral context is missing.
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 is front-loaded and clear. Every word earns its place, and there is no repetition or unnecessary detail.
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?
The tool is a mutation operation with 4 parameters, no annotations, and no output schema. The description is far too brief to cover return values, side effects, or usage nuances. It leaves major gaps for the agent to infer.
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 coverage is 50%, so the description should compensate for undocumented parameters like 'id' and 'type'. It only hints at 'filesystem or database' (aligned with type) but says nothing about id, limit semantics, or warning_headroom. It adds minimal value over 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 clearly states the action ('set') and the resource ('filesystem or database usage limits for a site'), which is specific and distinguishes it from the sibling read tool get_site_usage. No ambiguity or tautology.
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, no prerequisites, and no mention of related read tools like get_site_usage. It is a bare factual statement with no contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enable or disable edge caching for a site.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| enabled | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states the action. It does not reveal side effects, reversibility, permission requirements, or return behavior, which is critical for a state-changing toggle operation.
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 sentence with no wasted words, immediately conveying the core action. It is optimally concise and front-loaded, earning a perfect score for this dimension.
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 lack of annotations and output schema, the description is incomplete. It provides no information about return values, side effects, or how the site is identified beyond the implicit 'id' parameter. The tool's simplicity is acknowledged, but the description still leaves substantial gaps for an agent.
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 0%, and the description does not adequately compensate. While 'enable or disable' hints at the 'enabled' boolean and 'for a site' implies the 'id' parameter, it does not explicitly explain their roles or expected values, leaving the agent to infer 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 verb 'Enable or disable' and the resource 'edge caching for a site', making the action unambiguous. However, it does not distinguish this from sibling tools like pressable_toggle_edge_cache_defensive_mode or pressable_purge_edge_cache, so it falls short of 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. The description does not mention prerequisites, exclusions, or relationships with sibling tools such as pressable_get_edge_cache_status or pressable_purge_edge_cache, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Toggle edge cache defensive mode for a site.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| enabled | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action without explaining side effects, whether it's reversible, what 'defensive mode' means, or any implications for the site's caching. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, a single sentence with no fluff. However, it is under-specified, which borders on under-specification rather than effective conciseness, but it does not contain tautology or unnecessary words.
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 simplicity of the tool and lack of output schema, the description should at least mention the effect of enabling/disabling defensive mode or the expected outcome. It is incomplete for an agent to understand the tool's behavior or when to invoke it.
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 0%, and the description does not compensate. It does not explain what 'id' refers to (likely site ID) or how the 'enabled' boolean maps to the toggle action. The description provides no additional meaning beyond the raw parameter names and types.
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: 'Toggle edge cache defensive mode for a site.' This specifies the verb (toggle), the resource (edge cache defensive mode), and the scope (for a site), which distinguishes it from sibling tools like pressable_toggle_edge_cache or pressable_purge_edge_cache.
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 lacks any mention of prerequisites, exclusions, or comparison with sibling tools like toggle_edge_cache or purge_edge_cache.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Toggle maintenance mode for a site.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| enabled | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It merely says 'toggle maintenance mode' but does not explain that this is a mutating action affecting site availability, nor does it mention reversibility, propagation time, or impact on visitors. The lack of warnings or consequences makes it opaque.
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 concise sentence that is easy to parse and front-loaded with the action. However, it is slightly redundant with the tool name and could have used the space to offer parameter hints, but it remains appropriately minimal for a simple toggle.
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?
The tool has two required parameters and no output schema, so the description is the only context. It fails to specify the semantics of 'enabled' or the effect on the site, and lacks any note about potential downtime or relationship to site status. This is incomplete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning for the parameters. It does not explain that 'id' refers to the site ID or that 'enabled' controls whether maintenance mode is on (true) or off (false). The agent must infer from property names alone, which is insufficient.
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 (toggle) and resource (maintenance mode for a site), which is specific enough to distinguish it from sibling tools like pressable_toggle_edge_cache or pressable_disable_site. The phrase 'maintenance mode' disambiguates the action despite the tool name being similar.
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 such as pressable_disable_site or pressable_enable_site. There is no mention of prerequisites, side effects, or contexts where this toggle is appropriate, leaving the agent without information to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update settings for a specific site.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| name | No | ||
| php_version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'update', implying mutation, but fails to explain side effects, required permissions, whether partial updates are supported, or what happens to unspecified fields. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, which is structurally concise. However, it is under-specified rather than appropriately concise, as it omits essential details about the update-able fields and effects.
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 3 parameters, no annotations, and no output schema, the description is highly incomplete. It does not explain what settings can be changed, what the response looks like, or any other contextual details needed for correct invocation, making the description nearly useless for guiding the agent.
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 zero description coverage and the tool description mentions none of the parameters (id, name, php_version). The agent receives no additional meaning beyond the parameter names, and the description fails to compensate for the schema's lack of 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 uses a clear verb 'Update' and a resource 'settings for a specific site', but 'settings' is vague and doesn't specify which settings (name, php_version) are updatable. It does not distinguish from sibling tool pressable_set_php_version, which overlaps with the php_version parameter.
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 about when to use this tool versus alternatives like pressable_set_php_version or pressable_get_site. There is no mention of prerequisites, typical scenarios, or any exclusion criteria, leaving the agent to guess.
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.
v1.0.0pressable_add_collaboratorpressable_add_site_domainpressable_convert_sitepressable_create_bash_bookmarkpressable_create_dns_recordpressable_create_on_demand_backuppressable_create_sitepressable_delete_dns_recordpressable_delete_sitepressable_disable_sitepressable_enable_sitepressable_flush_object_cachepressable_generate_email_provider_dns_recordspressable_get_account_activity_log_actionspressable_get_account_activity_logspressable_get_account_addonspressable_get_account_detailspressable_get_available_addonspressable_get_backup_download_urlpressable_get_bash_bookmarkpressable_get_dns_recordspressable_get_edge_cache_statuspressable_get_mu_pluginpressable_get_php_error_logspressable_get_phpmyadmin_urlpressable_get_sftp_userspressable_get_sitepressable_get_site_metricspressable_get_site_usagepressable_install_pluginpressable_list_backupspressable_list_bash_bookmarkspressable_list_collaboratorspressable_list_cron_jobspressable_list_dns_zonespressable_list_mu_pluginspressable_list_pluginspressable_list_security_alertspressable_list_site_backups_by_typepressable_list_site_domainspressable_list_sitespressable_list_themespressable_list_wp_userspressable_purge_edge_cachepressable_reset_sftp_user_passwordpressable_reset_wp_admin_passwordpressable_restore_sitepressable_run_bash_commandspressable_run_wp_clipressable_set_php_filesystem_permissionspressable_set_php_versionpressable_set_site_usage_limitspressable_toggle_edge_cachepressable_toggle_edge_cache_defensive_modepressable_toggle_maintenance_modepressable_update_siteScored across 56 tools
Most tools have distinct purposes targeting specific resources and actions, with clear boundaries (e.g., pressable_get_site vs. pressable_update_site). However, some overlap exists between pressable_run_bash_commands and pressable_run_wp_cli, and between pressable_list_site_backups_by_type and pressable_list_backups, which could cause minor confusion.
All tools follow a consistent pressable_verb_noun naming pattern with snake_case throughout. The structure is predictable and readable, making it easy to identify the action and target resource (e.g., pressable_create_site, pressable_delete_dns_record).
With 56 tools, the count is excessive for a WordPress hosting management server. This many tools creates cognitive overhead and likely includes redundant or overly granular operations that could be consolidated, making it feel bloated and difficult to navigate efficiently.
The tool set provides comprehensive coverage for WordPress site management, including CRUD operations for sites, domains, backups, DNS, and users, as well as advanced features like caching, plugins, themes, and command execution. No obvious gaps are present, supporting full lifecycle management.
Security-first WordPress MCP server. 129 tools for Claude, ChatGPT, Gemini. Free on wp.org.
Manage repositories, users, releases, and automate GitHub workflows
Manage websites, help documents and customer-support conversations with safe, scoped tools.
