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?

Beyond the annotations (which only flag destructive/one-shot semantics), the description discloses the token's one-time nature, that claiming a live drop extends it to the 30-day free-account lifetime, that an expired drop can be claimed but stays expired until restored on Pro, and that the claim requires an sp_ API key. This is exactly the behavioral context an agent cannot infer from the schema or hints, and it is consistent with destructiveHint=true and idempotentHint=false.

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 core action is front-loaded in the first clause, followed by token provenance, lifetime effects, and the auth prerequisite in a tight progression. Every sentence carries decision-relevant information; there is no restatement of the name 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?

With only two parameters, full schema coverage, an output schema, and annotations covering safety, the description supplies the remaining essentials: prerequisite API key, token source, lifetime consequences, and post-claim capabilities. Nothing needed to invoke it correctly or interpret a success 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 both parameters are already documented as slug and one-time spc_ token, giving a baseline of 3. The description adds meaning beyond the schema by stating where the token comes from ('returned once by deploy_html/deploy_files') and by emphasizing that it is one-time, which matters operationally if a call fails and the agent considers retrying.

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 ('Attach an anonymously deployed drop to the authenticated account') and names the one-time claim token as the mechanism. It also names the sibling tools that produce the token (deploy_html/deploy_files), so an agent can place it precisely in the deploy-then-claim flow rather than confusing it with list_drops or delete_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?

It clearly implies the usage context: this is the step after an anonymous deploy, and it requires an sp_ API key plus the one-time spc_ token from deploy time. It also spells out downstream consequences (listable, deletable, redeployable on paid plans) that help an agent decide whether to claim. It stops short of explicitly naming a case where another sibling should be used instead (e.g., restore_drop for expired drops), which keeps it from a 5.

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?

The annotations already declare destructiveHint=true, openWorldHint=true, and idempotentHint=false. The description adds meaningful operational context beyond those annotations: anonymous file limits, 7-day expiry, 30-day signed-in retention, paid-tier max files and TTL behavior, and named drops. It does not fully explain overwrite or purge semantics for named redeploys, but it substantially improves transparency.

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 compact, front-loaded paragraph that leads with the core action and then layers on constraints and tier information. The parenthetical tier details are dense but relevant. There is little wasted text, though the sentence could be split for easier scanning.

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 complex, with six parameters, nested file objects, annotations, and an output schema. The description covers the essential payload requirement, tier limits, expiry behavior, and named drops, while the output schema handles return values. It leaves some sibling-routing and redeploy-overwrite details implicit, but is otherwise complete enough to invoke 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?

Schema description coverage is 100%, so the schema already documents ttl, name, agent, email, files, and password in detail. The description reinforces tier limits and the index.html requirement, which adds some framing beyond the schema. Because most parameter-level meaning is already in the schema, 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 and resource: deploy a map of path -> content as a multi-file site. It also gives a key structural constraint that index.html must be included to serve at the root. It is clearly distinct from a generic deploy, though it does not explicitly contrast itself with sibling deploy_html or append_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 description implies usage through file-count and TTL tiers, and the index.html requirement tells the agent when a payload is valid. However, it does not explicitly say when to choose this over deploy_html for single-file HTML or append_files for incremental changes. Usage guidance is therefore present but inferred rather than stated.

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?

Goes well beyond the annotations by disclosing a 10 deploys/min per-IP rate limit, a 10MB body cap, and a 7-day anonymous expiry, and by explaining that the URL is unguessable but public with Pro-only custom TTL and named drops. It never addresses what the destructiveHint implies (publication is irreversible; expiry/purge behavior) or what recovery looks like, so a small gap remains.

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 the outcome and URL shape front-loaded, then limits and tier gating in a compact clause. No filler, no restatement of the title.

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 not be explained, and the description covers plan gating, expiry, and rate limits for a six-parameter publish tool. What is missing is the irreversibility/publicity contract implied by destructiveHint=true and the role of the sibling claim_drop in the anonymous flow.

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 earns an extra point by tying plan tiers to specific parameters (custom or no TTL maps to ttl, "named drops" maps to name), which clarifies why those fields are plan-gated rather than merely optional.

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?

Names a specific verb and resource ("Deploy one HTML document") plus the concrete outcome (a live, unguessable https://<slug>.ship.place/ URL). "One HTML document" implicitly separates it from the sibling deploy_files, so an agent can pick between them without opening either 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?

Usage context is implied through the anonymous vs Pro tier breakdown, which tells an agent what it can do unauthenticated, but there is no explicit when-to-use/when-not guidance and no sibling tool (deploy_files, append_files, claim_drop) is ever named. The agent must infer routing from parameter 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?

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?

Adds substantial context beyond the annotations: an sp_ API key on a paid plan is required, the restored drop persists without expiry while on Pro, and free accounts receive a 402 subscription_required with an upgrade_url. It does not explain the non-idempotent behavior flagged in annotations (e.g., what happens if the drop is already active or the slug is wrong), which is the main remaining gap.

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 tightly written sentences, front-loaded with the action and scope, followed by auth requirements and error semantics. No filler or restatement of the title.

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 the key operational facts an agent needs: plan/API-key requirements, persistence after restore, and the 402 failure mode. It could be complete with a note on failure when the drop is not expired or is not owned by the account.

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?

With a single parameter at 100% schema coverage, the schema already defines 'slug' as the subdomain part of the drop URL. The description adds no further meaning about the identifier, 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?

States a specific verb and resource ('Bring back an expired drop') plus the ownership scope ('owned by the authenticated account'). This clearly separates it from siblings like claim_drop, list_drops, and delete_drop without needing to open any 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 usage context — restoring an expired drop regardless of how long ago it expired — and implies the preconditions (expired state, ownership, paid plan). It does not explicitly name an alternative such as claim_drop or say what to do when the drop is not expired, so it stops short of full routing 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.