ship.page

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.

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.

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.

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.

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.

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.

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

Annotations already signal mutability (readOnlyHint=false) and destructive potential (destructiveHint=true). The description adds valuable behavioral context beyond those annotations: the token is one-time, claiming extends lifetime to 90 days, revives offline drops in a 30-day recovery window, and enables listing/deletion/redeployment. It does not fully explain destructive consequences, but the one-time token warning is critical and informative.

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 three sentences and every sentence adds a distinct piece of information: action + token source, effects, and prerequisites/options. It is front-loaded with the core purpose. It is slightly dense but not bloated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the two required parameters, full schema coverage, and presence of an output schema, the description covers the essential context: when to use, what claiming does, the one-time nature of the token, the lifetime extension, and the API key requirement. Nothing critical for correctly invoking the tool is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds extra meaning to the claim_token parameter by stating its exact format (spc_...), that it is one-time, and that it comes from deploy_html/deploy_files endpoints. This helps an agent know where to find the token, which the schema alone does not provide.

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 ('Attach') and a clear resource ('anonymously deployed drop to the authenticated account'), and differentiates the tool from siblings like deploy_html/deploy_files by focusing on the claim token. It also explains the concrete outcome (lifetime extension, reviving offline drops), so an agent can tell what this tool uniquely does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context for when to use claim_drop: after deploying anonymously and when the drop needs to be attached to the account. It mentions prerequisites (sp_ API key) and the one-time token source, but it does not explicitly say when NOT to use it or name alternative tools such as restore_drop for other recovery scenarios.

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

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

Annotations already flag destructive=true, and the description adds valuable behavioral context: deletion is permanent, the URL stops serving immediately, and recovery is impossible. This goes beyond the annotation flags and sets correct user expectations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences convey purpose, ownership, authentication, immediacy, and irreversibility. Every clause adds information, and the most important consequence ('Permanently delete') is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter deletion tool with rich annotations and an output schema, the description is fully sufficient. It covers the action, prerequisites, ownership scope, and the critical irreversibility effect without unnecessary detail.

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%, and the slug parameter is already well documented as the subdomain part of the shipped.run URL. The description does not add parameter-level detail, but the baseline of 3 is appropriate because the schema carries the semantic weight.

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 verb ('delete'), a specific resource ('drop'), and the key scope ('owned by the authenticated account'). It clearly distinguishes the tool from siblings like restore_drop by emphasizing permanence.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool: when you intend a permanent deletion of a drop you own, and it states the authentication requirement (sp_ API key). It does not explicitly list alternatives or exclusions, but the permanence warning effectively separates it from restore-minded siblings.

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

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

Annotations already indicate destructive/write behavior, so the description is not burdened with basic safety disclosure. It adds valuable context: file-count limits, expiry durations by auth tier, Pro custom TTL, output schema existence, and the index.html requirement. This goes beyond annotations and schema.

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 tight sentences deliver the core purpose plus the most important constraints and tier limits with no filler. The essential 'multi-file site' and 'index.html' requirement are front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description, combined with the output schema and annotations, covers the deployment action, constraints, limits, and tier behavior. The only minor gap is that it does not explicitly route to siblings like deploy_html or append_files for single-file or incremental workflows.

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%, and each parameter is already well documented. The description adds the high-level shape of files and the index.html rule, but it does not need to restate parameter details. This meets the baseline for full schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific action and resource: 'Deploy a map of path -> content as a multi-file site.' It adds a concrete requirement (must include index.html) and differentiates itself from deploy_html by emphasizing the multi-file nature. This is clear and distinguishes the tool from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context on when to use this tool: for multi-file sites, with explicit constraints and tier-based limits. It does not explicitly name alternatives like deploy_html for single files or append_files for updates, but the context is strong enough to guide basic selection.

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

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

Annotations already signal readOnly=false, destructive=true, and idempotent=false, and the description adds concrete operational context: unguessable URL, anonymous rate limit, body cap, and expiry policies. However, despite destructiveHint=true, it does not explain overwrite/replace semantics for redeploying a named drop, though this is a minor gap given the schema covers 'redeployable drop'.

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 sentences with no filler: the first front-loads the core action and result, the second packs the most important constraints and plan tiers into a compact clause. Every sentence 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 definition is largely complete for a moderate-complexity deploy tool: it covers the primary outcome, limits, expiry, and plan differences, while the rich input schema and output schema carry the remaining detail. It could be slightly stronger by explicitly pointing to deploy_files for multi-file deploys, but nothing critical is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and every parameter already has a rich description including defaults, constraints, and edge cases. The description summarizes ttl/name concepts but does not meaningfully add beyond what the input schema provides, 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 opens with a concrete verb and resource — 'Deploy one HTML document' — and states the expected outcome: a live, unguessable URL. It clearly distinguishes itself from sibling deploy_files by emphasizing 'one HTML page/document'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly implies the single-HTML-file use case, but it never explicitly names deploy_files as the alternative for multiple files or gives when-to-prefer conditions. It provides tier context (anonymous vs Pro) but leaves the routing decision to inference.

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

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

All annotation hints are false, so the description carries the burden of behavioral disclosure. It discloses an authentication requirement (sp_ API key) and characterizes the operation as 'Show', implying a read-only, non-destructive access. It does not explicitly state 'does not modify state', but given the tool name and description, this is sufficiently clear for an agent. 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence with no wasted words. The core purpose is front-loaded, followed by the auth requirement and the routing to an alternative, all in compact, scannable 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?

This is a low-complexity, zero-parameter tool with an output schema present. The description covers the tool's purpose, authentication requirement, and the alternative for anonymous callers. Nothing needed for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters and schema coverage is 100%, so there are no parameter semantics to document. The baseline of 4 applies because the description adds no unnecessary parameter commentary and there is nothing missing.

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 the resource ('the authenticated account') and a specific verb ('Show'), and enumerates the exact fields returned (plan, subscription status, usage). It also differentiates this tool from the sibling get_limits by explicitly stating the account-specific scope, leaving no ambiguity about what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly states a precondition ('requires an sp_ API key') and explicitly routes anonymous callers to the alternative tool get_limits. This is direct when-to-use versus when-not-to-use guidance, with the named sibling alternative.

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

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

The description adds meaningful behavior beyond annotations: it discloses the anonymous vs authenticated behavior and the public plan matrix. The word 'Show' implies a non-mutating operation, and while readOnlyHint is false, this is not an affirmative contradiction since false is not a positive claim of mutation.

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, information-dense sentence with principal content front-loaded and the conditional case stated second. No unnecessary words or repetition of the title or schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no parameters and an output schema, the description is complete: it specifies exactly what is shown in both the anonymous and API-key-present cases. Nothing an agent needs to decide whether to call it is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, so the description does not need to explain parameter meaning. The baseline for zero parameters is 4, and the description correctly avoids inventing parameter details while still clarifying the API key as an environmental condition.

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 action ('Show') and a specific resource (the ship.page plan matrix), and adds the conditional account/plan status. It is clear about what the tool does, though it does not explicitly differentiate itself from the overlapping 'get_account' sibling for account status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context for when the tool provides just the public matrix versus when it also shows the caller's status (when an sp_ API key is present). It does not mention alternatives or exclusions, but for a zero-parameter informational tool this is adequate.

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

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

Annotation Contradiction: readOnlyHint is false, yet the description says 'List drops' and 'Returns ...', which describes a non-mutating read operation. Even though the description is behaviorally honest about auth and output details, it directly conflicts with the structured readOnlyHint annotation, so it must score 1.

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 compact sentences front-load the core purpose, then pack auth, return fields, and ordering without redundancy. Every clause adds information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list operation with only optional pagination parameters and an output schema, the description covers scope, auth requirements, return content, and ordering. Nothing needed to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for both parameters, with ranges, defaults, and meaning already in the schema. The description mainly contributes ordering ('newest first'), but does not need to explain limit/offset further.

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 states a specific action ('List drops') with a precise scope ('owned by the authenticated account') and adds concrete distinguishing detail: requires sp_ API key and anonymous drops are not listable. This separates it from all sibling drop tools that mutate or deploy files.

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?

Clear context: use to list drops for an authenticated account, with an explicit precondition (sp_ API key) and an exclusion (anonymous drops cannot be listed). It does not explicitly name sibling alternatives, but no sibling offers the same list operation, so the guidance is adequate.

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

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description reveals meaningful post-call state changes: on free plans 'the drop comes back at the 90-day lifetime' and on paid plans 'the drop never expires again' — a significant, quasi-permanent consequence. It also discloses the auth-key requirement. 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two dense sentences with zero filler. The core action is front-loaded, the auth requirement is placed in a parenthetical, and the plan-dependent rules are compressed into parallel clauses. Every clause 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?

Given the tool's complexity — auth requirement, two plan tiers, differing expiry windows — the description covers all major decision factors. An output schema exists, so return values need no explanation. The only minor ambiguity is the exact meaning of 'the 90-day lifetime' (from what reference point), which is a small 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 coverage is 100% — the slug parameter is already documented in the input schema as 'the subdomain part of its shipped.run URL.' The description adds no param-specific detail beyond what the schema provides, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Uses a specific verb ('bring back') tied to a concrete resource ('an expired drop') with additional scoping constraints: 'owned by the authenticated account' and 'while its files are still retained.' This clearly differentiates it from siblings like delete_drop, list_drops, and claim_drop, and adds substantive detail beyond the title.

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?

Supplies concrete when-to-use conditions: an explicit auth prerequisite ('requires an sp_ API key') and eligibility windows ('Free accounts restore up to 30 days past expiry... paid plans restore up to 90 days past expiry'). It does not name sibling alternatives or explicitly state when not to use it, but the window and retention conditions effectively bound its applicability.

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