ship.page

Append files to an existing drop

append_files

Destructive

Add files to a drop owned by the authenticated account (requires an sp_ API key and an active subscription): up to 900 files per call, 10,000 per drop total, and existing paths are overwritten. The drop keeps its current expiry.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`slug`	Yes	The drop slug (the subdomain part of its shipped.run URL).
`files`	Yes	Map of relative paths (e.g. 'index.html', 'css/app.css') to either a string, or { encoding: 'base64', content } for binary files.

Output Schema

TableJSON Schema

Name	Required	Description
`url`	Yes
`plan`	No
`slug`	Yes
`files`	Yes	Paths added by this call
`expires_at`	Yes	ISO timestamp, or null when the drop never expires
`total_files`	Yes	Total files on the drop after the append

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed1 schema field changedAug 31, 2026

changedInput schema / properties / slug / description

Previous value: -"The drop slug (the subdomain part of its shipped.page URL)."New value: +"The drop slug (the subdomain part of its shipped.run URL)."

AddedAug 23, 2026

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds substantial behavioral disclosure beyond the annotations: per-call and per-drop file limits (900/10,000), overwrite behavior for existing paths (consistent with destructiveHint=true), and the fact that the drop's current expiry is preserved. It also states the auth requirement (sp_ API key, active subscription). No contradiction with annotations.

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?

A single well-structured sentence that front-loads the action and ownership, then packs prerequisites, limits, overwrite behavior, and expiry semantics without waste. Every clause earns its place.

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 the rich schema (100% param coverage), output schema, and annotations, the description covers the remaining gaps that matter: auth requirements, rate/resource limits, destructive overwrite semantics, and expiry behavior. Nothing essential for correct invocation is missing.

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 coverage is 100% with solid descriptions of both slug and files, so the baseline is 3. The description adds value beyond the schema by imposing a per-call constraint on the files parameter (up to 900 files), which is not stated in the schema, and by clarifying that path collisions overwrite existing files.

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 states a specific verb+resource ('Add files to a drop') and scopes it precisely ('owned by the authenticated account'), which clearly differentiates it from siblings like deploy_html and delete_drop. The title and description together leave no ambiguity about what operation is performed.

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 establishes clear context for when the tool can be used: requires an sp_ API key, an active subscription, and ownership of the target drop. It does not explicitly name alternatives or state when not to use it, but the prerequisites and ownership constraint give an agent enough context to select it appropriately.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All ship.page tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0

Disambiguation5/5

Each tool targets a distinct resource or lifecycle action: deploy_html vs deploy_files separate single-file from multi-file deploys, append_files adds to an existing drop, and claim/restore/delete/list cover different drop states. There is no meaningful overlap between tool purposes.

Naming Consistency5/5

All nine tools follow a consistent snake_case verb_noun pattern, e.g. deploy_html, deploy_files, list_drops, restore_drop. The verbs clearly indicate the action and the nouns indicate the target resource.

Tool Count5/5

Nine tools is well-scoped for a deployment service covering deploy, file management, lifecycle, and account/limit information. Each tool earns its place without unnecessary redundancy or overwhelming surface area.

Completeness4/5

The core drop lifecycle is covered: deploy, append files, claim, list, delete, and restore, plus account and limits context. Minor gaps exist around per-file updates/overwrites and named-drop redeployment not being exposed as an explicit tool, but agents can accomplish the main workflows.

Resources

Need Help?