ship.page

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

Goes well beyond the annotations by disclosing a hard cap (10,000 files per drop), the destructive behavior specifically ('existing paths are overwritten'), auth/subscription requirements, and the non-obvious fact that expiry and password protection are preserved. This is exactly the extra context annotations cannot convey.

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 dense sentence whose every clause (auth requirement, file cap, overwrite behavior, preserved settings) carries information an agent needs. No filler and the operation 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?

With an output schema present, return values need not be described, and the definition covers side effects, limits, and auth needs adequately. The only gap is routing guidance relative to sibling deployment tools, which is more a usage-guideline concern.

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 baseline is 3; the description adds real meaning by clarifying that re-used path keys overwrite existing files and by bounding the total file count, which the schema does not express.

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?

States a specific verb and resource ('Add files to a drop') plus scope ('owned by the authenticated account'), and the clause 'existing paths are overwritten' implies an existing drop, distinguishing it from deploy_files/deploy_html without needing the schemas opened.

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?

Gives a prerequisite ('requires an sp_ API key and an active subscription') which is real usage guidance, but never states when to prefer this over deploy_files or deploy_html, nor any exclusions. Usage context is implied rather than declared.

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 a mutating, non-idempotent, destructive operation, and the description adds meaningful context: the token is one-time, claiming extends the drop lifetime, can revive an offline drop during its recovery window, and grants new capabilities. It also notes the sp_ API key requirement, which is beyond what annotations provide. 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?

Three sentences pack the core action, lifecycle consequences, and auth requirement without wasted words. The key action and token mechanism are front-loaded, and the later sentences add useful context without bloating the description.

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 two-parameter tool with an output schema and annotations, the description covers the purpose, the token source, the effects of claiming, and the required API key. It does not detail error cases or explicitly warn about irreversibility, but the one-time token wording and the lifecycle information make the tool's behavior sufficiently clear for correct invocation.

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 both slug and claim_token are clearly described in the schema. The description reiterates the spc_... token format but adds no 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 states a specific verb ('Attach') and a specific resource ('anonymously deployed drop') with a precise mechanism (one-time claim token), making the tool's purpose immediately clear. It also distinguishes itself from siblings by referencing deploy_html/deploy_files as the source of the token and noting claimed drops become listable/deletable/redeployable, which separates it from delete_drop and restore_drop.

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 this tool: when claiming an anonymously deployed drop with its one-time token, including lifecycle effects like extending lifetime to 90 days and reviving offline drops. It does not explicitly state when not to use it or name alternatives, but the unique claim-token mechanism makes the intended use unambiguous.

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 mark destructiveHint as true, but the description adds meaningful behavioral specifics: deletion is permanent, the URL stops serving immediately, and recovery is impossible. It also discloses the credential 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 short sentences with no filler. The core destructive action is front-loaded, followed by the key consequences and auth requirement. 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?

For a single-parameter destructive tool with a complete input schema and an output schema present, the description covers the action, ownership requirement, auth requirement, and immediate irreversible effects. Nothing essential 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%, and the schema already explains slug as the subdomain part of the drop's URL. The tool description adds no parameter-specific detail, 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?

States a specific action ('Permanently delete') on a specific resource ('a drop owned by the authenticated account') and emphasizes irreversibility. This clearly distinguishes it from non-destructive siblings such as remove_drop_password or restore_drop.

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?

Provides clear context: the drop must be owned by the authenticated account and an sp_ API key is required. It does not explicitly name alternatives or give a when-not-to-use condition, but the permanent and unrecoverable nature strongly implies when this tool should be avoided.

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 declare destructiveHint=true, non-idempotent, open world. The description adds useful behavioral context: tier limits (100/10,000 files), TTL expiry (30/90/custom days), and anonymous vs signed-in differences. With annotations present the bar is lower, and this clears it by explaining the operational constraints.

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 three clauses, front-loaded on the core action and immediately followed by the tier constraints. 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?

For a multi-file deploy tool with annotations, full schema coverage, and an output schema, the description covers the essential scope (file map, required index.html, tier limits). It could mention what happens on redeploy or how the return relates to claim tokens, but the output schema carries that.

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 baseline is 3. The description implies ttl tier behavior and named drops match the schema docs, but it adds no syntax or format detail beyond what the schema already provides for name, ttl, password, and 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?

States a specific verb and resource: deploy a map of path -> content as a multi-file site. The index.html root-serving constraint sharpens the purpose and distinguishes it from the sibling deploy_html, which handles single 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?

The tier table clearly explains when each tier applies (anonymous, signed-in, Pro) and the file/expiry limits. It doesn't explicitly say when to choose this tool over deploy_html or append_files, leaving that comparison to be inferred from names.

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 declare the write, destructive, non-idempotent, open-world profile, so the bar is lower. The description adds genuinely useful operational context the annotations lack: a 10 deploys/min per IP rate limit, a 10MB body cap, and the 30-day anonymous expiry.

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 with zero waste: the core action and return value come first, followed by the tier/limit facts. Nothing is padded or redundant.

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?

An output schema exists, so return values need no narration, and the description plus rich parameter docs cover the essentials. It is close to complete; a brief pointer to the claim/restore lifecycle for anonymous drops would close the remaining 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 schema already documents ttl, name, password, email, and agent with their constraints. The description's tier/expiry remarks echo rather than extend the schema, so baseline 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?

The description states a specific verb (Deploy) and resource (one HTML document) and describes the output (a live, unguessable URL). It implicitly separates itself from deploy_files by stressing a single document, but never names that sibling explicitly to remove all doubt.

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?

It conveys tier-based capabilities (Anonymous limits vs Pro custom/no TTL and named drops), which gives context on what's possible, but never states when to choose this over deploy_files or how the deploy/claim/restore lifecycle relates. Usage is implied rather than directed.

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?

Annotations provide no hints (all false), so the description carries the burden. It discloses the auth requirement, that anonymous drops are excluded, the exact returned fields, and newest-first ordering — meaningful behavior beyond the 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 sentences with no filler. Purpose and auth constraint are front-loaded, followed by return fields and ordering. Every element 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?

Complete for a simple list tool: output schema covers return values, pagination lives in the documented schema, and auth requirements and return composition are described. Slightly richer tie-in to how ordering interacts with offset could push it higher, but nothing essential 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% for both limit and offset, so the schema fully documents the parameters. The description adds nothing substantive about parameters beyond the schema, but it needn't — baseline 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?

States a specific verb (list) + resource (drops) + scope (owned by the authenticated account), immediately distinguishing it from get_account and get_limits. The mention of returned fields makes the operation unmistakable.

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?

Gives clear operational context: requires an sp_ API key, anonymous drops are not listable. While it doesn't name a specific sibling alternative, none of the siblings compete for this operation, so the context is sufficient for an agent to know when to call it.

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 goes beyond the annotations by disclosing the destructive consequence (password removed and drop becomes publicly readable), the authentication requirement, and the surprising behavior of remaining functional after subscription lapse. No contradiction with destructiveHint or readOnlyHint exists.

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 concise sentences with the core action front-loaded and no unnecessary detail. Every clause adds useful decision-making 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 one-parameter mutation with an output schema, the description covers prerequisites, side effects, authentication, and an edge-case licensing condition. Nothing essential is missing for an agent to select and invoke this tool correctly.

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 single parameter `slug` is already fully described in the input schema as the drop slug subdomain part. The description adds no additional parameter-level detail, so the schema carries the semantic burden.

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 clearly states the action ('Remove password protection'), the resource ('a drop you own'), and the outcome ('making it readable by anyone with its URL'). This unambiguously distinguishes it from sibling tools like set_drop_password.

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?

It specifies key usage context: the drop must be owned, an sp_ API key is required, and the action works even after subscription lapse. It does not explicitly name set_drop_password as the alternative, but the conditions for when to use this tool are clear.

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 mark this as a non-read-only, non-idempotent, non-destructive write. The description adds genuinely useful behavior beyond that: the auth requirement (sp_ key), the 90-day retention window, and the plan-dependent outcome where paid-plan drops never expire again after restore. It stops short of describing failure modes when files are no longer retained.

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?

Front-loads the action, then the eligibility constraints and the plan-dependent outcome in three compact clauses. Dense but every clause carries information; only the parenthetical auth note slightly interrupts flow.

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?

An output schema exists, so return values need no explanation. The description covers the eligibility window, auth requirement, and post-restore lifetime semantics, which is most of what an agent needs; it omits error behavior for drops past retention or already-restored drops.

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?

Single parameter with 100% schema description coverage, so the schema already explains the slug. The description adds no format, example, or validation detail beyond what the schema provides, which is the baseline case.

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?

Specific verb+resource ('Bring back an expired drop') scoped to the authenticated account, which cleanly separates it from siblings like claim_drop (new claim) and delete_drop (removal). An agent can identify the operation without opening the schema.

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?

Gives clear preconditions: the drop must be expired, its files still retained, within 90 days past expiry, and an sp_ API key is required. It does not explicitly contrast with claim_drop or state what to do if the retention window has lapsed, so it stops short of full 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.

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

Annotations already indicate a destructive, non-read-only, non-idempotent write operation. The description adds valuable behavioral context beyond that: billing failures error out instead of exposing a public drop, visitors unlock in their browser, and the password must not be placed in a URL. This meaningfully supplements the structured hints without contradicting them.

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 compact, front-loaded with the core action, and every sentence earns its place: the operation, prerequisites, failure behavior, visitor experience, and a security warning. No redundant phrases or filler are present.

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 write operation with annotations, a fully documented schema, and an output schema, the description covers the essential context: authentication needs, billing prerequisite, failure mode, security constraints, and the end-user effect. Nothing critical for selecting or calling 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 description coverage is 100%, so the schema already fully documents both slug and password, including length limits, UTF-8 byte constraints, and redeploy behavior. The description adds minimal parameter-specific semantics beyond reinforcing that the password is shared and should be kept out of URLs, so the baseline score 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?

The description opens with a specific verb and resource: 'Set or rotate the shared password on a drop you own.' This clearly defines the operation and naturally distinguishes it from the sibling remove_drop_password tool, which removes rather than sets or rotates.

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 is usable: it requires an sp_ API key and active paid Pro/Team, and it warns that unavailable billing returns an error rather than falling back to a public drop. It does not explicitly mention alternatives or when to prefer remove_drop_password, but the usage context is strong.

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