This server lets AI clients manage and deploy static sites on the Shiplo platform through MCP.
Account & site management: Check account status/plan/usage, list sites, create a site, and delete a site.
Project inspection: Auto-detect build configuration for a local project.
Static deployment: Build and deploy a project directory to Shiplo, with custom build commands, output directory detection, hashing/upload manifest, retries, resumable deployments, and live URL verification.
Media optimization: Shrink oversized local images (via sharp) or videos (via ffmpeg) to fit plan byte caps.
Deployment tracking: Query deployment status and retrieve deployment events.
Safety and convenience: Stores reusable config in .shiplo/project.json, excludes local secrets/uploads, removes API token from build commands, and supports structured content, progress updates, and cancellation.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@shiplohq/mcp deploy this project to Shiplo and give me the live URL"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for the Shiplo deploy platform. It lets AI clients (Claude Code, Claude Desktop, Codex CLI, Cursor, ...) deploy static sites and manage sites on your Shiplo account through the Model Context Protocol.
Tool | What it does |
| Get account status, plan, and usage information |
| List your sites |
| Create a new site with a platform hostname |
| Inspect a local project to detect build configuration |
| Build and deploy a project directory as a static site |
| Shrink an oversized image/video to fit a byte cap (images via sharp; video needs ffmpeg on PATH) |
| Get the status of a deployment |
| Delete a site |
platform_deploy_static runs the optional build_command, scans output_dir
(or auto-detects dist, out, build, or a project-root index.html), creates
a SHA-256 manifest, uploads every file, finalizes the release, and activates it.
Uploads run concurrently with bounded retry and can resume an interrupted
deployment with resume_deployment_id; server-side hashes and an idempotent
upload ledger prevent retries from double-counting bytes. Pass either site_id
or the more convenient site_slug. Oversized files require an explicit
oversized policy: optimize, skip, or error. Deploy-time optimization
uses an isolated temporary artifact and never rewrites the project source.
It then polls the public URL until the edge stops serving the unprovisioned-host
placeholder (live: true, up to ~75 seconds) and only then returns JSON with
deployment_id, release_id, status, url, and live. If the wait times
out, live is false with a live_note — the deploy itself is already active,
and the URL typically works a few seconds later. Set PLATFORM_LIVE_WAIT_TIMEOUT_MS=0
to skip the wait. Project-root deployments exclude .env*, .npmrc, .git, and
node_modules, plus common credential files such as .mcp.json, private keys,
and cloud CLI credential directories, so local secrets are not uploaded. The
Shiplo API token is removed from the environment of any requested build command.
On the first deployment, Shiplo detects the project settings and writes a
version-controllable .shiplo/project.json containing the project name, Shiplo site ID,
subdomain, build command, and output directory. It never stores the API token.
Later deployments reuse this file, so a normal "deploy this project" request
does not need the same setup questions again. Existing projects without the file
remain compatible: their next deployment creates it automatically. If a first
upload fails after Shiplo creates the site, the config is still saved so a retry
reuses that site instead of creating an orphan duplicate.
Tool responses expose native MCP structuredContent for clients that support
it while retaining the JSON text response for older clients. Progress-aware
clients receive build, scan, optimize, upload, finalize, activate, and live-wait
updates, and cancellation stops retries and URL polling promptly.
Related MCP server: StaticX MCP Server
npm install -g @shiplohq/mcp@0.1.6Or run once with:
npx @shiplohq/mcp@0.1.6Requires Node.js >= 24.
The server reads two environment variables:
Variable | Required | Description |
| Yes | Shiplo API token ( |
| No | Defaults to |
claude mcp add platform-mcp --env PLATFORM_API_TOKEN=shp_your_token -- npx -y @shiplohq/mcp@0.1.6claude_desktop_config.json{
"mcpServers": {
"platform-mcp": {
"command": "npx",
"args": ["-y", "@shiplohq/mcp@0.1.6"],
"env": {
"PLATFORM_API_TOKEN": "shp_your_token"
}
}
}
}~/.codex/config.toml[mcp_servers.platform-mcp]
command = "npx"
args = ["-y", "@shiplohq/mcp@0.1.6"]
env = { PLATFORM_API_TOKEN = "shp_your_token" }.cursor/mcp.json (project) or ~/.cursor/mcp.json (global){
"mcpServers": {
"platform-mcp": {
"command": "npx",
"args": ["-y", "@shiplohq/mcp@0.1.6"],
"env": {
"PLATFORM_API_TOKEN": "shp_your_token"
}
}
}
}Command: npx -y @shiplohq/mcp@0.1.6
Transport: stdio
Env: PLATFORM_API_TOKEN (required), PLATFORM_API_BASE_URL (optional)
Pin an exact package version so the deploy implementation stays reproducible across sessions. To upgrade, deliberately change the pin after reviewing the new release, then restart the MCP server or IDE once.
Some Windows clients use hardened process spawning and cannot resolve the
npx.cmd shim directly. Use cmd /c:
{
"mcpServers": {
"platform-mcp": {
"command": "cmd",
"args": ["/c", "npx", "-y", "@shiplohq/mcp@0.1.6"],
"env": { "PLATFORM_API_TOKEN": "shp_your_token" }
}
}
}For Codex on Windows, use the equivalent TOML:
[mcp_servers.platform-mcp]
command = "cmd"
args = ["/c", "npx", "-y", "@shiplohq/mcp@0.1.6"]
env = { PLATFORM_API_TOKEN = "shp_your_token" }Images are re-encoded in-process through sharp — no system dependencies needed.
Video optimization requires an ffmpeg binary: resolved from ffmpeg-static (when installed alongside) or from PATH. When neither is available, the tool reports skip as the only option.
Until the optional full package is published, install ffmpeg on PATH when
video optimization is needed. The standard package still optimizes images.
MIT
Get account status, plan, and usage information
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description bears the full transparency burden. It only says 'Get', implying a read but never stating access requirements, whether usage is aggregated, or what the response will contain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to identifying the resource and the type of information returned.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only call, the description names the three information categories returned. Without an output schema, a bit more detail on the response shape would improve completeness, but the core usage is captured.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing for the description to clarify. The baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a clear resource scope: account status, plan, and usage. This is distinct from the sibling site-focused tools, which all center on site operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The account-level wording provides implied context that this tool is for billing/plan overview rather than site management, but there is no explicit when-to-use guidance or mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new static site with a platform hostname
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Site name | |
| routing_mode | No | Routing mode (default: static) | |
| preferred_subdomain | No | Preferred subdomain (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden, but it only reports the core creation action. It does not mention whether creation is reversible, what side effects occur, naming constraints, or what happens if the site already exists, so an agent gets no safety or lifecycle context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler; it states the action and the key result immediately and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the parameter schema is fully documented, and the 'platform hostname' phrase gives a hint of the result. However, there is no output schema and no description of the response format or post-creation behavior, leaving a meaningful gap for a write operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all three parameters with 100% coverage, so the description need not repeat them. It adds only the general 'platform hostname' outcome and does not clarify parameter relationships beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Create') and a specific resource ('a new static site'), and it adds a distinctive outcome ('with a platform hostname') that separates it from sibling tools like platform_deploy_static or platform_delete_site.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use this tool when creating a site. However, it never states when not to use it or names alternatives, such as platform_deploy_static for deploying to an existing site, so the agent must infer the boundary from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a site
| Name | Required | Description | Default |
|---|---|---|---|
| site_id | Yes | Site ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavioral traits. It correctly signals a destructive action, but it does not state whether deletion is irreversible, what side effects occur, or whether special permissions are required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely terse and front-loads the core action with no wasted words. However, it is arguably too sparse for a destructive operation, lacking any cautionary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one well-documented parameter, so the description is minimally adequate. Still, for a delete operation with no annotations and no output schema, some mention of consequences or expected behavior would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the site_id parameter is already described as 'Site ID'. The tool description adds no extra semantic value beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Delete') and resource ('site'), making the operation unmistakable and clearly distinct from siblings like platform_create_site and platform_list_sites.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this tool versus alternatives, and there are no exclusions or prerequisites. The description simply states what the tool does without situating it among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get events for a deployment
| Name | Required | Description | Default |
|---|---|---|---|
| deployment_id | Yes | Deployment ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'Get events' and does not mention event ordering, pagination, return shape, empty-list behavior, or whether this is a safe read-only operation beyond the verb's implication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler. The operation and target resource are front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter, this is minimally adequate. However, with no output schema and no annotation support, it does not describe what the returned events look like or clarify when to choose this tool over platform_deployment_status.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single deployment_id parameter, so the baseline of 3 applies. The description adds no parameter-level detail, but none is needed given the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('events for a deployment'), making the tool's basic purpose clear. However, it does not explicitly distinguish this from the sibling tool platform_deployment_status, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives like platform_deployment_status. No usage context, exclusions, or selection criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the status of a deployment
| Name | Required | Description | Default |
|---|---|---|---|
| deployment_id | Yes | Deployment ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description itself must carry behavioral disclosure. 'Get' conveys a read-only retrieval with no side effects, which is appropriate for a status check, but the description does not disclose what statuses can be returned or whether there are any auth/error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It is appropriately concise, though it is too sparse to earn a 5 for fully informative structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple—one required parameter and no output schema—so the description plus schema covers the minimum needed to make the call, but it leaves gaps around the shape of the response and when to prefer this tool over sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the deployment_id parameter is already documented as 'Deployment ID'. The description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies the resource ('deployment') and the aspect being retrieved ('status'), making the core purpose clear. It does not explicitly contrast with the closely related sibling platform_deployment_events, so it falls short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Get the status of a deployment' implies that the tool is appropriate whenever a deployment's status is needed, but it offers no explicit usage guidance and no comparison with alternatives such as platform_deployment_events or platform_inspect_project.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deploy the current project as a static site. On first use, detects settings and writes .shiplo/project.json; later calls reuse it. Runs build_command first when configured. Honors plan upload limits (per-file size cap and account-wide file cap — call platform_account_status first to get them); oversized images/videos trigger an interactive optimize-or-skip choice for the user.
| Name | Required | Description | Default |
|---|---|---|---|
| site_id | No | Site ID override (optional; uses .shiplo config or creates a site on first deploy) | |
| output_dir | No | Output directory (optional, will auto-detect) | |
| build_command | No | Custom build command (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It discloses first-use side effects (.shiplo/project.json is written and reused), build_command execution, plan upload limits, and an interactive optimize-or-skip prompt for oversized files. This is substantial beyond what the schema conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three information-dense sentences with no filler. The main action is front-loaded, followed by config persistence, build execution, and upload-limit behavior. Every sentence adds necessary operational details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers prerequisites, side effects, limits, and interactive behavior well. However, it does not mention what happens after invocation—such as whether the deploy is synchronous, returns a deployment ID, or should be followed up via platform_deployment_status. Given the tool complexity and no output schema, this is a meaningful gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining that build_command runs first when configured and that later calls reuse persisted .shiplo/project.json settings, which clarifies how the parameters interact with the deploy lifecycle.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Deploy the current project as a static site.' This clearly distinguishes deploying from the sibling status/list/site-management tools, and the additional details about first-use config creation reinforce what the tool is for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit prerequisite guidance: 'call platform_account_status first to get them' for upload limits. It does not explicitly contrast this tool with alternatives like platform_deployment_status or platform_create_site, but the usage context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect the current project to detect build configuration
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. The word 'Inspect' suggests a non-destructive read operation, which is a useful signal, but the description does not mention permissions, side effects, return structure, or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the verb and resource, followed by the purpose. Every word contributes meaning, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter introspection tool, the description is minimally sufficient: the agent knows what to invoke and why. However, there is no output schema, no mention of what the returned build configuration looks like, and no guidance on the project context beyond 'current project'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema covers all invocation needs. The description adds no parameter-specific meaning, but none is required; per rubric, zero parameters warrant a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Inspect') with a clear resource ('the current project') and an explicit goal ('detect build configuration'). This clearly separates it from sibling tools focused on accounts, sites, deployment, or media optimization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when build configuration needs to be understood, but it does not state when to use this tool over alternatives or mention any predecessor/successor tools. There is no explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all sites for the authenticated account
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'List' implies a read-only operation and 'authenticated account' indicates auth context, but the description does not mention pagination, response shape, or absence of side effects beyond the lexical implication of 'list'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler, front-loaded with the action verb and immediately stating the resource and scope. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list operation, the description is nearly complete: it names the action, scope, and authentication context. The lack of an output schema means return details are not specified, but this is unlikely to block correct selection or invocation of such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description adds useful scope context by specifying the authenticated account, which is the only meaningful input dimension here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('List') and resource ('all sites for the authenticated account'), which clearly identifies the operation's scope. It does not explicitly contrast with siblings like platform_create_site or platform_delete_site, but the list-all scope is sufficiently distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The implied usage is to retrieve all sites for the authenticated account, which is clear enough for a simple listing tool. However, it does not explicitly state when to prefer this over related tools such as platform_inspect_project or platform_account_status, nor does it mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shrink an oversized local image or video file to fit a byte cap, in place (images re-encode via sharp; videos via ffmpeg — available in the full MCP build or when ffmpeg is on PATH). Call this after the user chose "optimize" over "skip" for a file exceeding plan.max_file_size_bytes.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path of the media file to optimize | |
| max_bytes | Yes | Target size cap in bytes (use plan.max_file_size_bytes) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses in-place mutation, the re-encoding engines (sharp for images, ffmpeg for videos), and the ffmpeg availability requirement. It could additionally note whether the original file is overwritten or replaced, but 'in place' strongly implies it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences carry substantial information with no filler. The core action and precondition are front-loaded, and implementation details are compactly parenthesized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the key context: target files, preconditions, in-place behavior, and encoding dependencies. It does not describe return values or failure modes, but since this is a side-effecting local operation without an output schema, the provided context is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description reinforces that max_bytes is a byte cap and refers to plan.max_file_size_bytes, but adds little meaning beyond what the schema already provides for either parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Shrink') with a clear resource ('oversized local image or video file') and a concrete goal ('fit a byte cap'). It also states the mutation is in-place, which clearly distinguishes this from other platform tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to invoke this tool: after the user chose 'optimize' over 'skip' for a file exceeding plan.max_file_size_bytes. This is a precise precondition and implies when not to use it, giving clear operational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.4platform_account_statusplatform_create_siteplatform_delete_siteplatform_deploy_staticplatform_deployment_eventsplatform_deployment_statusplatform_inspect_projectplatform_list_sitesplatform_optimize_mediaScored across 9 tools
Each tool targets a distinct resource and action: account, sites, project inspection, deployment, media optimization, and deployment status/events. There is no meaningful overlap even between deployment_status and deployment_events, as one reports overall status while the other provides event details.
Most tools follow a clear platform_ + verb_noun pattern (list_sites, create_site, delete_site, deploy_static), but a few use noun phrases (account_status, deployment_status, deployment_events) rather than verbs. The shared platform_ prefix keeps the set feeling coherent despite minor stylistic variation.
Nine tools is well within the ideal range for a deployment-focused server. Each tool covers a meaningful part of the workflow without unnecessary duplication or surface bloat.
The server covers the core lifecycle well: account awareness, site creation/deletion, project inspection, deployment, media optimization, and deployment monitoring. Minor gaps exist around updating site configuration or listing past deployments, but agents can accomplish the primary static-site deployment workflow without dead ends.
Deploy your project to a live HTTPS URL from your AI tool; read logs, set variables, resize apps.
Deploy and manage Jade Hosting projects from AI clients. Jade account and OAuth required.
Hosted MCP for creating, checking, deploying, and hosting static sites for AI agents.
Deploy static websites from AI agents. Free at mcp.shipstatic.com — no install, no signup.
