SpinupWP MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose targeting specific resources and actions in the SpinupWP/WordPress domain. There is no ambiguity between tools like create_server vs. create_site, or list_servers vs. list_sites, as they operate on different entities with clear boundaries.
Naming Consistency5/5
All tools follow a consistent verb_noun naming pattern (e.g., add_ssh_key, create_server, list_events). The verbs are appropriate and predictable across the set, with no mixing of conventions or styles, making the tool names highly readable and systematic.
Tool Count5/5
With 17 tools, the server is well-scoped for managing SpinupWP servers and WordPress sites, covering provisioning, management, monitoring, and maintenance. Each tool earns its place by addressing specific needs in this domain without being excessive or too sparse.
Completeness5/5
The tool set provides complete CRUD/lifecycle coverage for servers and sites (create, get, list, delete), along with essential operations like SSH key management, event tracking, cache purging, rebooting, service restarting, and deployments. There are no obvious gaps that would hinder agent workflows in this domain.
Average 3/5 across 17 of 17 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'Add' implies a write operation, it doesn't specify whether this requires admin permissions, if there are rate limits, whether duplicate keys are allowed, or what happens on success/failure. The description lacks crucial operational context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It's perfectly front-loaded and wastes no space, making it immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after adding the key (e.g., returns key ID, success confirmation), doesn't mention error conditions, and provides no context about SSH key management within the SpinupWP ecosystem.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, both parameters are well-documented in the schema itself. The description adds no additional parameter information beyond what's already in the structured fields, so it meets the baseline expectation without providing extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and resource ('SSH public key to SpinupWP'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'list_ssh_keys' beyond the obvious action difference, missing an opportunity to clarify their distinct roles in SSH key management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives or any prerequisites for its use. With sibling tools like 'list_ssh_keys' available, there's no mention of whether listing should precede adding or if there are constraints on key management.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but does not explain what 'correct' entails (e.g., whether it modifies permissions, requires admin access, has side effects, or provides feedback). This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it efficient and easy to understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a mutation tool. It does not cover behavioral aspects like what 'correct' means, potential impacts, or return values, leaving the agent with insufficient context for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'site_id' well-documented in the schema. The description does not add any additional meaning or context beyond what the schema provides, such as format examples or constraints, so it meets the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('correct') and resource ('file permissions for a specific WordPress site'), making the purpose evident. However, it does not differentiate from sibling tools like 'restart_service' or 'purge_site_cache' in terms of specific use cases or scope, which prevents a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as when file permission issues arise or what prerequisites might be needed. It lacks explicit context or exclusions, leaving usage unclear beyond the basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a provisioning operation (implying creation/mutation) but doesn't describe what happens after provisioning (e.g., server state, time to complete, permissions required, or error handling). For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding the tool's behavior and implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Provision a new custom SpinupWP server') and adds clarifying context ('MVP using existing infrastructure') without unnecessary details. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool (provisioning) with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like what the tool returns, error conditions, or side effects, which are critical for an agent to use it correctly. The high schema coverage helps with inputs, but overall context for safe and effective usage is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters with clear descriptions. The description adds no additional parameter information beyond what's in the schema (e.g., it doesn't explain relationships between parameters or provide examples). Baseline 3 is appropriate when the schema does the heavy lifting, though the description could have added context like why these specific parameters are needed for provisioning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Provision a new custom SpinupWP server') and specifies the resource type ('server'), distinguishing it from sibling tools like create_site or delete_server. However, it doesn't explicitly differentiate from all siblings (e.g., reboot_server also involves servers). The 'MVP using existing infrastructure' adds useful context but doesn't fully articulate what makes this tool unique among server-related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing infrastructure), compare to sibling tools like get_server or list_servers, or specify when not to use it (e.g., for modifying existing servers). The 'MVP using existing infrastructure' hints at context but lacks explicit usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Create') but doesn't cover critical aspects like permissions required, whether this is a destructive/mutative operation, potential side effects (e.g., impact on server resources), rate limits, or what happens on failure. This leaves significant gaps for a tool that creates resources.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of creating a WordPress site (a mutative operation with no annotations and no output schema), the description is insufficient. It lacks details on behavioral traits, error handling, return values, or integration with sibling tools, making it incomplete for safe and effective use by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents both parameters (server_id and domain). The description adds no additional meaning beyond implying these are needed for creation, which doesn't compensate for or enhance the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('new WordPress site on a server'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'create_server' or 'add_ssh_key', which would require more specific context about what distinguishes creating a site versus other creation operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing server), exclusions, or comparisons to siblings like 'create_server' or 'delete_site', leaving the agent to infer usage context independently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action is 'Delete' but doesn't clarify if this is permanent, requires confirmation, has side effects (e.g., deleting associated sites), or what the response looks like. For a destructive tool, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that efficiently conveys the core action without unnecessary words. It is front-loaded with the key verb and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, the description is insufficient. It doesn't address critical context like irreversible effects, error conditions, or what happens to dependent resources (e.g., sites on the server). Given the high stakes of server deletion, more completeness is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-specific information beyond what's in the schema, which has 100% coverage with clear descriptions for both parameters. This meets the baseline for adequate parameter documentation, but the description doesn't enhance understanding of how parameters interact (e.g., implications of 'delete_server_on_provider').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('a specific SpinupWP server'), making the purpose immediately understandable. However, it doesn't differentiate this destructive operation from similar tools like 'delete_site' or 'reboot_server' beyond the resource name, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'delete_site' or 'reboot_server', nor does it mention prerequisites (e.g., server must be stopped) or warn about irreversible consequences. This lack of contextual guidance leaves 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Delete') but lacks critical details: it doesn't specify if deletion is permanent, requires admin permissions, affects associated data, or has confirmation steps. For a destructive operation, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero waste. It front-loads the core action ('Delete') and resource, making it highly efficient and easy to parse, which is ideal for tool selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature, lack of annotations, and no output schema, the description is incomplete. It fails to address critical context such as irreversible effects, error conditions, or return values, leaving the agent under-informed for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'site_id' clearly documented. The description adds no additional parameter semantics beyond implying the tool acts on a 'specific' site, which aligns with the schema. This meets the baseline for high schema coverage without enhancing understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Delete') and resource ('a specific WordPress site'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'delete_server' or 'purge_site_cache', which would require explicit comparison to achieve 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., site must exist), exclusions (e.g., irreversible action), or comparisons to siblings like 'delete_server' or 'purge_site_cache', leaving the agent with minimal context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it gets 'details and status' but doesn't specify what details are included, whether it's a read-only operation, if there are rate limits, or what happens with invalid event IDs. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the core purpose without unnecessary words. It's front-loaded with the main action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'details and status' include, potential error conditions, or how it differs from 'list_events'. Given the lack of structured data, more context is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting the 'event_id' parameter. The description adds no additional semantic context beyond implying it retrieves data for a 'specific' event, which is already covered by the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with the verb 'Get' and resource 'details and status of a specific SpinupWP event', making it easy to understand what it does. However, it doesn't explicitly differentiate from its sibling 'list_events', which might cause confusion about when to use each tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'list_events'. It doesn't mention prerequisites, such as needing an event ID, or contextual factors like whether this is for monitoring ongoing events or reviewing past ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but doesn't cover critical traits like whether this is a read-only operation, error handling, authentication needs, rate limits, or response format. This is inadequate for a tool with potential complexity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'details' include (e.g., server status, configuration), behavioral aspects, or error cases, leaving gaps for an AI agent to understand the tool fully in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'server_id' clearly documented. The description doesn't add any meaning beyond the schema (e.g., explaining ID sources or constraints), so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'SpinupWP server details', making the purpose evident. However, it doesn't distinguish this tool from sibling tools like 'get_site' or 'get_event', which follow the same pattern for different resources, missing explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a server ID), exclusions, or comparisons to siblings like 'list_servers' for broader queries, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a 'Get' operation which implies read-only, but doesn't specify authentication requirements, rate limits, error conditions, or what 'details' actually includes. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's appropriately sized for a simple retrieval tool and front-loads the essential information immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'details' will be returned, what format they'll be in, or any behavioral constraints. Given the context of WordPress site management with sibling tools for creation, deletion, and listing, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't add any parameter information beyond what's already in the schema (which has 100% coverage). It mentions 'specific WordPress site' which aligns with the site_id parameter, but provides no additional context about valid IDs, format, or where to find them. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get details') and resource ('for a specific WordPress site'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_server' or 'list_sites', which would be needed for 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'list_sites' or 'get_server'. It mentions 'specific WordPress site' which implies individual retrieval, but doesn't explicitly state this is for single-site details versus listing multiple sites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it's a list operation but doesn't describe return format (e.g., array of sites, pagination), permissions required, rate limits, or error conditions. For a read tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every element ('List all WordPress sites on a specific SpinupWP server') earns its place by specifying scope and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that likely returns a list of sites. It doesn't explain what information is included in the listing (e.g., site IDs, names, statuses) or how to handle the output. For a list operation with no structured output documentation, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'server_id' documented as 'The ID of the SpinupWP server'. The description adds no additional meaning beyond this, such as where to find server IDs or valid ranges. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('WordPress sites on a specific SpinupWP server'), making the purpose immediately understandable. It distinguishes from siblings like 'list_servers' by specifying sites rather than servers, though it doesn't explicitly contrast with 'get_site' (which likely retrieves a single site).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'list_sites' over 'get_site' (for single sites) or 'list_servers' (for servers), nor does it specify prerequisites like needing a valid server ID. Usage context is implied but not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits such as whether this requires admin permissions, if it's destructive to cached data, potential performance impact, rate limits, or what happens on success/failure, leaving significant gaps 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words, front-loading the core action and resource. It efficiently communicates the essential purpose without unnecessary elaboration, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It lacks critical context like permissions needed, side effects (e.g., temporary site slowdown), error conditions, or what 'purge' entails (e.g., all cache vs. selective), leaving the agent under-informed for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a clear description for 'site_id', so the description adds no additional parameter details beyond implying the site is WordPress-specific. This meets the baseline for high schema coverage, but doesn't enhance understanding of the parameter's role in the operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Purge') and resource ('page cache for a specific WordPress site'), making the tool's purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'restart_service' or 'run_site_git_deployment' that might also affect site performance, so it misses the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing site access), exclusions (e.g., not for non-cache issues), or related tools like 'restart_service' for broader fixes, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('reboot') but doesn't clarify critical details like whether this requires admin permissions, causes server downtime, is reversible, or has side effects on running services. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words, making it highly concise and front-loaded. It efficiently communicates the core purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a server reboot operation (a mutation with potential downtime), the lack of annotations and output schema means the description should provide more context. It fails to cover behavioral aspects, usage guidelines, or output expectations, making it incomplete for safe and effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't add any parameter-specific information beyond what the schema provides. However, with 100% schema description coverage (the 'server_id' parameter is fully documented in the schema), the baseline score is 3, as the schema adequately handles parameter semantics without needing extra description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('reboot') and target resource ('a specific SpinupWP server'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'restart_service' or 'create_server', which would require more specificity about what distinguishes a server reboot from other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'restart_service' or 'create_server'. The description lacks context about prerequisites, appropriate scenarios, or warnings about potential downtime, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('Restart') which implies a mutation operation, but doesn't disclose important behavioral traits like whether this requires admin permissions, if it causes service downtime, what happens to active connections, error handling, or typical response patterns. The description is minimal and 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the essential purpose without any wasted words. It's appropriately sized for a simple tool with two parameters and clear scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what happens during the restart (downtime implications), what the expected response looks like, error conditions, or operational considerations. Given the complexity of restarting services and the lack of structured behavioral information, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters well-documented in the schema (server_id and service with enum values). The description adds no additional parameter semantics beyond what's already in the structured schema. The baseline of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Restart') and resource ('a specific service on a SpinupWP server'), with examples of services provided. It distinguishes from siblings like 'reboot_server' by focusing on individual services rather than the entire server. However, it doesn't explicitly contrast with 'reboot_server' in the description text itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'reboot_server' (which restarts the entire server) or other service-related operations. It doesn't mention prerequisites, timing considerations, or error conditions that might affect usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While 'Run a git deployment' implies a write/mutation operation, it doesn't disclose critical behavioral traits: whether this triggers a production deployment, what happens to existing site content, if it requires specific permissions, potential downtime, or what the tool returns. For a deployment tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a deployment operation (potentially destructive), no annotations, no output schema, and incomplete behavioral disclosure, the description is insufficient. It doesn't explain what 'git deployment' entails, the expected outcome, error conditions, or how it fits with sibling tools like cache purging or permission correction.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage (site_id is fully documented in the schema), so the baseline is 3. The description doesn't add any parameter-specific meaning beyond what's in the schema—it mentions 'specific WordPress site' which aligns with site_id but provides no additional context about valid IDs or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run a git deployment') and the target resource ('for a specific WordPress site'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from potential sibling deployment tools (none are listed in the provided siblings, but the description doesn't explicitly differentiate from general site operations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing git configured on the site), when-not-to-use scenarios, or how it relates to other deployment methods. With siblings like 'purge_site_cache' and 'correct_site_file_permissions', some context about workflow ordering would be helpful but is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe any behavioral traits such as pagination, rate limits, authentication requirements, or what format the output takes. For a list operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently communicates the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, no annotations), the description is adequate as a basic statement of function. However, it lacks details about output format, pagination, or error handling that would be helpful for an AI agent. It meets the minimum viable standard but doesn't provide complete contextual information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100%, so there's no need for parameter documentation in the description. The description appropriately doesn't mention parameters, which is correct for this case. A baseline of 4 is assigned since no parameters exist to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('SSH keys configured in SpinupWP'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate this tool from sibling tools like 'list_servers' or 'list_sites' beyond the resource type, which keeps it from 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are no explicit instructions on prerequisites, timing, or comparisons with sibling tools like 'add_ssh_key' or other list operations. It's a basic statement of function without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'List recent SpinupWP events' but doesn't specify what 'recent' means (e.g., time range, pagination), whether it's read-only (implied but not stated), or any rate limits or authentication requirements. This leaves significant gaps for a tool that likely involves data retrieval, making it inadequate for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('List recent SpinupWP events') and includes essential details (optional filtering) without any redundant or verbose language. Every word earns its place, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (list operation with optional filters), no annotations, and no output schema, the description is partially complete. It covers the basic action and parameters but lacks details on behavioral aspects like response format, pagination, or error handling. This is adequate as a minimum viable description but has clear gaps that could hinder effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (server_id and site_id) clearly documented in the schema as filters. The description adds minimal value by mentioning these parameters as optional filters but doesn't provide additional context beyond what the schema already states (e.g., how filtering works, default behavior without filters). This meets the baseline of 3 since the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('SpinupWP events'), making the purpose immediately understandable. It specifies the scope ('recent') and mentions optional filtering parameters. However, it doesn't explicitly differentiate from sibling tools like 'get_event' or 'list_servers/list_sites', which would require more specific distinction to earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning optional filtering by server_id or site_id, suggesting this tool is for retrieving events with potential scoping. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'get_event' (for a single event) or when not to use it (e.g., for non-event data). No misleading information is present, but the guidance is limited to implied filtering scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'List' implies a read-only operation, it doesn't specify whether this requires authentication, what format the list returns (pagination, sorting), rate limits, or error conditions. The description adds minimal behavioral context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core functionality without any wasted words. It's front-loaded with the main purpose and includes helpful additional detail about what information is returned. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with no parameters and no output schema, the description provides adequate but minimal context. It explains what the tool does but lacks details about the return format, authentication requirements, or potential limitations. Given the tool's simplicity, this is acceptable but leaves gaps an agent would need to discover through trial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't discuss parameters since none exist, maintaining focus on the tool's purpose and output. This meets the baseline expectation for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('SpinupWP servers') with additional detail about what information is included ('hardware/update status'). It distinguishes itself from other list operations like 'list_sites' and 'list_ssh_keys' by specifying servers, but doesn't explicitly differentiate from 'get_server' which retrieves a single server.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'List all SpinupWP servers' - suggesting this is for getting a complete overview rather than retrieving specific servers. However, it doesn't provide explicit guidance on when to use this versus 'get_server' (for single server details) or mention any prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/farukgaric/spinupwp-mcp'

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