SiteBay MCP Server

Official

by sitebay

Overview Schema Related Servers Score Discussions(1)

TypeScript

Hybrid

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes targeting specific SiteBay resources like sites, backups, teams, and proxies. However, the three proxy tools (posthog_proxy, shopify_proxy, wordpress_proxy) have overlapping functionality patterns that could cause confusion about which to use for different API integrations.
Naming Consistency5/5
All tools follow a consistent sitebay_ prefix with snake_case naming and clear verb_noun patterns (e.g., create_site, delete_site, list_sites, get_site). The naming convention is predictable and well-structured throughout the entire tool set.
Tool Count4/5
16 tools is reasonable for a comprehensive WordPress hosting platform covering site management, backups, billing, and integrations. The count feels slightly high but appropriate for the domain scope, with each tool serving a distinct operational need.
Completeness5/5
The tool set provides complete lifecycle coverage for WordPress site management including create, read, update, delete operations, plus backups, billing, team management, and file/command execution. No obvious gaps exist for the core SiteBay platform functionality.
Average 3.2/5 across 16 of 16 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 is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is an edit operation but doesn't mention permissions required, whether edits are reversible, if there are rate limits, or what happens if the file doesn't exist. The description lacks critical behavioral 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, args, returns) and uses minimal sentences. Each sentence serves a purpose, though the parameter discrepancy slightly reduces efficiency. The front-loaded purpose statement is effective.
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 3 parameters with 0% schema coverage and no annotations, the description provides basic purpose and parameter explanations but has a critical parameter name mismatch. The output schema exists, so return values don't need explanation. However, for a file editing mutation tool, more behavioral context would be expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains fqdn, file_path, and content parameters, but the input schema shows a different third parameter named 'file_edit_using_search_replace_blocks' instead of 'content'. This creates confusion and incomplete parameter documentation.
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 ('Edit a file') and resource ('in the site's wp-content directory'), providing specific context about the target location. It distinguishes from siblings like site creation or backup tools by focusing on file editing, though it doesn't explicitly differentiate from other file-related operations that might exist.
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 mentions of prerequisites, limitations, or comparison to sibling tools like sitebay_site_shell_command which might also manipulate files. Usage context is implied but not explicitly stated.
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 creating a checkout session but fails to detail critical aspects like authentication requirements, rate limits, error handling, or whether the session is immediately usable. This leaves significant gaps for an agent to understand operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for purpose, arguments, and returns, and it is front-loaded with the main action. It avoids unnecessary verbosity, though the 'Args' and 'Returns' labels could be more integrated for optimal flow.
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 complexity of a billing tool with 3 parameters, no annotations, and an output schema (which covers return values), the description is moderately complete. It explains the purpose and parameters but misses behavioral context and usage guidelines, making it adequate but with clear gaps for effective agent 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 description includes an 'Args' section that lists parameters with brief explanations, adding meaning beyond the input schema (which has 0% description coverage). However, it lacks details on constraints (e.g., valid plan_name/interval values beyond examples), defaults, or the implications of optional team_id, leaving some semantic gaps.
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 a Stripe checkout session') and the resource ('for team billing'), making the purpose specific and understandable. However, it does not explicitly differentiate this tool from its siblings (e.g., other billing or account-related tools), 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, such as other billing methods or tools for managing teams. It lacks context on prerequisites, exclusions, or comparisons to sibling tools, offering only basic functional 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. It states the tool lists backups but doesn't disclose behavioral traits like whether it requires authentication, has rate limits, returns paginated results, or what happens if no backups exist. The description is minimal and misses key operational details for a tool with potential data implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the purpose clearly. The 'Args' and 'Returns' sections are structured but slightly redundant with the schema. Every sentence adds value, though it could be more concise by integrating parameter details into the main text.
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 (2 parameters, no annotations, but has an output schema), the description is partially complete. The output schema exists, so return values needn't be explained, but the description lacks context on authentication, error handling, or sibling tool relationships. It meets a basic threshold but has clear gaps in operational guidance.
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 0%, so the description must compensate. It adds basic semantics: 'fqdn' is explained as 'The site domain' and 'number_to_fetch' as 'Number of backup entries to fetch (default: 1)'. This clarifies parameter purposes but doesn't provide format details (e.g., domain structure) or constraints. With 0% coverage, it partially compensates but remains incomplete.
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: 'List available backup commits for point-in-time restore.' It specifies the verb ('List') and resource ('backup commits') with a clear objective ('for point-in-time restore'). However, it doesn't explicitly differentiate from sibling tools like 'sitebay_backup_restore', which might be a related but distinct operation.
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, such as needing an existing site or backup, or compare it to siblings like 'sitebay_backup_restore' for restore operations. Usage is implied by the purpose but lacks explicit context or exclusions.
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 'Proxy POST requests' and returns 'PostHog API response,' but lacks details on authentication needs, rate limits, error handling, or side effects. For a proxy tool with zero annotation coverage, this leaves significant gaps in understanding its operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the purpose in the first sentence. The 'Args' and 'Returns' sections are structured clearly, with no redundant information. However, the mention of 'POST requests' in the purpose might be slightly misleading given the 'method' parameter supports multiple HTTP methods, indicating a minor inefficiency.
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 complexity (a proxy with 3 parameters), no annotations, and an output schema exists (implied by 'Returns'), the description is moderately complete. It covers basic purpose and parameters but lacks behavioral context and usage guidelines. The output schema reduces the need to explain return values, but overall completeness is adequate with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists parameters in the 'Args' section with brief explanations (e.g., 'PostHog API path'), adding some meaning beyond the schema. However, it doesn't fully detail parameter formats, constraints, or examples, leaving gaps for the 3 parameters, especially 'query_params_json' and 'method' with its default 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 tool's purpose: 'Proxy POST requests to PostHog analytics API.' It specifies the verb ('proxy'), resource ('PostHog analytics API'), and method ('POST requests'), which is specific and actionable. However, it doesn't differentiate from its sibling 'sitebay_shopify_proxy' or 'sitebay_wordpress_proxy', which are also proxy tools, 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.
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 any specific scenarios, prerequisites, or exclusions, nor does it reference sibling tools like other proxies or analytics-related tools. Usage is implied only by the purpose statement, with no explicit context for selection.
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 that the tool proxies requests and returns a Shopify API response, but it lacks critical details: it doesn't specify authentication requirements, rate limits, error handling, or whether it's read-only or destructive. For a proxy tool with no annotations, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for purpose, arguments, and returns. It uses bullet-like formatting under 'Args' and 'Returns', making it easy to scan. The sentences are direct and avoid unnecessary words, though it could be more front-loaded by emphasizing key constraints earlier.
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 complexity as a proxy with 4 parameters, no annotations, and an output schema, the description is moderately complete. It covers the basic purpose and parameters but lacks behavioral context like authentication or error handling. The presence of an output schema means it doesn't need to explain return values, but overall, it's adequate with clear gaps for a tool of this nature.
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 includes an 'Args' section that lists and briefly describes each parameter, adding meaning beyond the input schema, which has 0% description coverage. For example, it explains 'path' as 'Shopify API path' with an example, and 'query_params_json' as 'Optional JSON string for payload or query params'. However, it doesn't provide detailed semantics like format constraints or usage examples for all parameters, so it partially compensates for the low 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: 'Proxy requests to a Shopify Admin API.' It specifies the verb ('proxy') and resource ('Shopify Admin API'), which is specific and actionable. However, it doesn't explicitly differentiate from its sibling 'sitebay_posthog_proxy' or 'sitebay_wordpress_proxy', which are also proxy tools but for different APIs, 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.
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 any prerequisites, such as authentication or setup requirements, nor does it compare it to other Shopify-related tools or general API tools. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns a list with descriptions, which is helpful, but lacks critical details such as whether this is a read-only operation, if it requires authentication, any rate limits, pagination behavior, or error handling. For a tool with no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with the first sentence clearly stating the purpose and the second providing return value information. Both sentences earn their place by adding value beyond the tool name. However, it could be slightly more structured by explicitly separating purpose from returns, but overall it's efficient with zero waste.
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 (0 parameters, no annotations, but with an output schema), the description is somewhat complete. It explains what the tool does and what it returns, but lacks behavioral context like safety or performance details. The output schema likely covers return values, so the description doesn't need to detail those, but it should address usage guidelines and transparency more thoroughly for a tool with no annotations.
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 input schema has 0 parameters with 100% coverage, so no parameter information is needed. The description doesn't add any parameter details, which is appropriate here. Since there are no parameters, the baseline score is 4, as the description doesn't need to compensate for any gaps in schema documentation.
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: 'List available ready-made sites for quick launches.' This specifies the verb ('List'), resource ('ready-made sites'), and context ('for quick launches'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'sitebay_list_sites', which might list all sites rather than just ready-made ones.
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 mentions 'for quick launches', which hints at a use case, but doesn't specify when to choose this over 'sitebay_list_sites' or 'sitebay_create_site', nor does it outline any prerequisites or exclusions. This leaves the agent without clear 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?
No annotations are provided, so the description carries full burden. It mentions 'authenticated user' (implying auth needs) and describes the return format, but lacks critical behavioral details: whether it's paginated, rate-limited, or has side effects. For a list operation with zero annotation coverage, this is insufficient transparency about 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. It front-loads the core purpose in the first sentence, then uses clear sections for Args and Returns. Every sentence adds value without redundancy. Minor deduction because the 'Returns' section could be more concise by referencing the output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter) and the presence of an output schema (which handles return values), the description is mostly adequate. However, it lacks context about authentication requirements, pagination, or error handling, which are important for a list operation. With no annotations, these gaps prevent a higher score.
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 description adds meaningful context for the single parameter: 'team_id: Optional team ID (UUID4) to filter sites by team.' This clarifies its purpose (filtering) and format (UUID4), which compensates for the 0% schema description coverage. Since there's only one parameter and the description fully explains it, this earns a high score.
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: 'List all WordPress sites for the authenticated user.' It specifies the verb ('List'), resource ('WordPress sites'), and scope ('for the authenticated user'). However, it doesn't explicitly differentiate from sibling tools like 'sitebay_get_site' (single site) or 'sitebay_list_ready_made_sites' (different resource type), 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. It doesn't mention sibling tools like 'sitebay_get_site' for retrieving a single site or 'sitebay_list_teams' for listing teams first. There's also no information about prerequisites (e.g., authentication requirements) or exclusions, 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?
No annotations are provided, so the description carries the full burden. It mentions the return type ('List of users'), but lacks details on behavioral traits such as authentication requirements, rate limits, pagination, error handling, or whether it's read-only (implied by 'Get' but not confirmed). This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured: two sentences that front-load the purpose ('Get affiliate referral information') and follow with return details. Every sentence adds value without waste, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 (0 parameters, output schema exists), the description is adequate but incomplete. It covers the purpose and return type, but lacks behavioral context (e.g., auth needs) that isn't provided by annotations or schema. With an output schema, return values are documented elsewhere, so the description doesn't need to explain them, but overall completeness is moderate due to missing operational details.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately adds no parameter details, focusing on the tool's purpose and output. Baseline is 4 for zero parameters, as it avoids unnecessary repetition.
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 'Get affiliate referral information' (verb+resource) and elaborates with 'Returns: List of users who signed up using your affiliate links'. It distinguishes from siblings like sitebay_list_sites or sitebay_list_teams by focusing on affiliate data, but doesn't explicitly differentiate from all siblings (e.g., sitebay_account_create_checkout).
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 affiliate account), exclusions, or comparisons to other tools like sitebay_list_sites for general user data. Usage is implied by the purpose but not explicitly stated.
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 indicates this is a read operation ('Get detailed information'), which is clear, but it lacks details on permissions, rate limits, error handling, or response format. For a 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 well-structured and concise, with a clear purpose statement followed by sections for 'Args' and 'Returns'. Each sentence earns its place by providing essential information without redundancy, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter) and the presence of an output schema, the description is reasonably complete. It explains the purpose, parameter, and return value at a high level. However, it could benefit from more behavioral details, especially since no annotations are provided to cover aspects like safety or performance.
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 0%, so the description must compensate. It adds meaning by explaining the 'fqdn' parameter as 'The fully qualified domain name of the site (e.g., "www.example.com")', which clarifies the input beyond the schema's basic string type. However, it doesn't cover all potential nuances, such as format constraints or examples for edge cases.
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: 'Get detailed information about a specific WordPress site.' It specifies the verb ('Get') and resource ('WordPress site'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'sitebay_list_sites' (which likely lists multiple sites), leaving room for improvement.
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 sibling tools such as 'sitebay_list_sites' for listing multiple sites or 'sitebay_update_site' for modifications, nor does it specify prerequisites or exclusions. This lack of context could lead to confusion in tool selection.
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 tool proxies requests but lacks critical details: authentication requirements, rate limits, error handling, or whether it's read-only or destructive. The mention of HTTP methods like 'post' and 'delete' implies potential mutations, but this is not explicitly clarified, leaving 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core purpose. The 'Args' and 'Returns' sections are structured for clarity, though the 'Returns' section is minimal. Every sentence adds value, with no redundant information, making it efficient 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 complexity (4 parameters, no annotations, but with an output schema), the description is partially complete. It covers the basic purpose and parameters but lacks usage guidelines and behavioral details like authentication or error handling. The output schema exists, so the description need not explain return values, but overall, it leaves significant gaps for a proxy tool with potential mutations.
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 0%, so the description must compensate. It adds meaning by explaining each parameter's purpose (e.g., 'fqdn: The site domain', 'path: WordPress API path') and provides an example for 'path'. However, it does not fully document all parameters, such as the format for 'query_params_json' or valid values for 'method', leaving some ambiguity beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('proxy requests') and resources ('WordPress site's REST API'). It distinguishes itself from sibling tools like sitebay_posthog_proxy and sitebay_shopify_proxy by specifying the WordPress API target, making the scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, such as authentication or site ownership, nor does it differentiate from other proxy tools like sitebay_posthog_proxy or sitebay_shopify_proxy, 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.
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 lacks critical behavioral details. It mentions a 'dry run' option and default values for some parameters, but doesn't disclose whether this is a destructive operation (likely yes, given 'delete_extra_files'), permission requirements, rate limits, or what happens to current site data. The confirmation return is noted but without specifics on what that entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by parameter details and return info. Each sentence adds value, with no redundancy. It could be slightly more concise by integrating parameter explanations more tightly, but overall it's efficient and readable.
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 complexity (8 parameters, no annotations, but with output schema), the description is moderately complete. It covers parameters well but lacks behavioral context (e.g., destructiveness, side effects). The output schema existence means return values don't need explanation, but critical operational details are missing for a restoration tool, leaving gaps in understanding risks and outcomes.
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?
Schema description coverage is 0%, so the description must compensate—and it does by explaining all 8 parameters with clear semantics beyond schema titles. It adds value by specifying formats (ISO datetime), defaults, optionality ('or omit for latest'), and purposes (e.g., 'Simulate restore without applying changes' for is_dry_run). However, it doesn't fully explain interactions (e.g., how dolt_restore_hash relates to restore_point).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Restore a site to a previous point in time'), identifies the resource ('site'), and distinguishes it from siblings like sitebay_backup_list_commits (which lists backups) and sitebay_update_site (which updates current settings). The verb 'restore' is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. While the purpose is clear, there's no mention of prerequisites (e.g., needing existing backups), when not to use it (e.g., for minor changes), or how it relates to siblings like sitebay_backup_list_commits (which might help select a restore point). Usage 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 for behavioral disclosure. While it mentions the tool creates a site and returns success details, it doesn't disclose critical behavioral traits: whether this is a long-running operation, what permissions are required, whether the FQDN must be unique/available, what happens if creation fails, or any rate limits. The description is insufficient for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns) and efficiently organized. Each parameter explanation is concise yet informative. The only minor inefficiency is repeating 'Optional' for multiple parameters when a single note could suffice, but overall it's appropriately sized and front-loaded with the core purpose.
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 complexity (11 parameters, mutation operation) and the presence of an output schema (which handles return values), the description is moderately complete. It covers parameter semantics well but lacks behavioral context about the creation process. For a site creation tool with no annotations, it should provide more operational guidance about what the creation entails.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by providing clear semantic explanations for all 11 parameters. It explains what each parameter represents (e.g., 'Team UUID that owns the site', 'fully qualified domain name', 'Admin email address'), identifies which are optional, and provides formatting examples. This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Create a new WordPress site') and resource ('SiteLiveCreate schema'), distinguishing it from sibling tools like sitebay_get_site, sitebay_update_site, and sitebay_delete_site. It explicitly identifies this as a creation operation rather than retrieval, modification, or deletion.
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 sitebay_update_site or sitebay_list_sites. It doesn't mention prerequisites (e.g., needing a team_id from sitebay_list_teams) or constraints (e.g., domain availability). The only implicit guidance is that it's for creating new sites, not modifying existing 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 full burden but only mentions command types (WP-CLI, system commands) and return details. It omits critical behavioral traits like security implications, permission requirements, execution timeouts, or error handling, which are essential for a shell 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by structured Args and Returns sections. It avoids unnecessary fluff, but could be more concise by integrating parameter explanations into the main text rather than separate sections.
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 complexity (shell execution with 4 parameters), no annotations, and an output schema (which reduces need to explain returns), the description is incomplete. It covers basic purpose and some parameters but misses behavioral details and full parameter semantics, making it adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'fqdn' and 'command' with examples, but ignores 'cwd' and 'auto_track_dir' entirely. This partial coverage leaves half the parameters undocumented, meeting only the baseline for minimal value addition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Execute a shell command') and resource ('on a WordPress site'), with examples distinguishing it from siblings like sitebay_site_edit_file (file editing) or sitebay_wordpress_proxy (proxy operations). It directly addresses what the tool does without being tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for shell commands on WordPress sites, mentioning WP-CLI and system commands, but lacks explicit guidance on when to use this versus alternatives like sitebay_wordpress_proxy or sitebay_site_edit_file. No exclusions or prerequisites are stated, leaving usage context somewhat vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that it returns a 'formatted list of teams with their details and member information', which adds context about the output format. However, it lacks details on pagination, rate limits, or error handling, leaving gaps 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, with two sentences that directly state the purpose and return value without any wasted words. Every sentence earns its place by providing essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no annotations, but has an output schema), the description is reasonably complete. It explains what the tool does and what it returns, and the output schema should cover return details, reducing the need for more in the description. However, it could improve by adding usage context or behavioral traits.
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 input schema has 0 parameters with 100% coverage, so the schema fully documents the absence of parameters. The description does not add parameter information, which is unnecessary here. Baseline is 4 for zero parameters, as no additional semantic value is needed beyond the schema.
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 all teams') and the resource ('teams for the authenticated user'), making the purpose unambiguous. However, it does not explicitly differentiate this tool from sibling tools like 'sitebay_list_sites' or 'sitebay_list_ready_made_sites', which might list other resources, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, such as authentication requirements implied by 'authenticated user', nor does it compare to other list tools in the sibling set, 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Update' implies a mutation, the description lacks critical details: whether this requires specific permissions, if changes are reversible, potential side effects (e.g., downtime), rate limits, or error conditions. It mentions a return confirmation but doesn't describe format or success/failure indicators.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief purpose statement followed by categorized 'Args' and 'Returns' sections. Every sentence earns its place by explaining parameters or outcomes. It could be slightly more front-loaded with key behavioral details, but overall it's efficient and avoids redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, mutation tool) and lack of annotations, the description is partially complete. It excels in parameter semantics but lacks behavioral context (e.g., permissions, side effects). The presence of an output schema reduces the need to detail return values, but more guidance on usage and risks would improve completeness for a tool of this nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing clear, concise explanations for all 7 parameters. Each parameter is listed with its purpose (e.g., 'Change the site domain' for new_fqdn, 'Toggle free plan flag' for is_free), adding essential meaning beyond the bare schema. This is crucial given the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'existing SiteBay site configuration', making the purpose specific and unambiguous. It distinguishes this tool from siblings like 'sitebay_create_site' (creation) and 'sitebay_delete_site' (deletion), establishing its role in modifying existing sites rather than creating or removing them.
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 site), exclusions (e.g., not for new sites), or comparisons to siblings like 'sitebay_get_site' (for viewing) or 'sitebay_site_edit_file' (for file-level edits). Usage is implied but not explicitly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates the destructive, irreversible nature of the operation ('permanently', 'cannot be undone'), which is crucial for a deletion tool. However, it doesn't mention authentication requirements, rate limits, or error conditions that might be relevant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely well-structured and concise. It begins with the core action and critical warning, then provides organized sections for Args and Returns. Every sentence earns its place, with no redundant information, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a destructive operation with no annotations, the description provides excellent contextual completeness. It explains the irreversible nature, documents the single parameter thoroughly, mentions the return value format, and the existence of an output schema means the description doesn't need to detail return values. This is complete enough for safe tool invocation.
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 description explicitly documents the single parameter 'fqdn' with a clear explanation ('The fully qualified domain name of the site to delete'), adding meaningful context beyond the schema which has 0% description coverage. This fully compensates for the schema's lack of parameter descriptions, making the parameter's purpose and format clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Delete a WordPress site permanently') and distinguishes it from sibling tools like sitebay_get_site, sitebay_update_site, and sitebay_create_site by emphasizing the irreversible destructive nature. It provides a verb+resource combination that is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('Delete a WordPress site permanently') and includes a critical warning ('This action cannot be undone'), which helps differentiate it from less destructive alternatives. However, it doesn't explicitly name specific sibling tools as alternatives or provide when-not-to-use guidance beyond the permanence warning.
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:

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

Score Badge

Copy to your README.md:

[![sitebay-mcp MCP server](https://glama.ai/mcp/servers/sitebay/sitebay-mcp/badges/score.svg)](https://glama.ai/mcp/servers/sitebay/sitebay-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/sitebay/sitebay-mcp'

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