list_dropsList drops owned by the authenticated account (requires an sp_ API key; anonymous drops are not listable). Returns slug, url, name, file counts, expiry and password_protected, newest first.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max drops to return (1-500, default 100). | |
| offset | No | Number of drops to skip (default 0). |
| Name | Required | Description | Default |
|---|---|---|---|
| drops | Yes | ||
| total | Yes |
Changes observed during successful MCP inspections.
Output schema / properties / drops / items / properties / password_protectedAdded value: +{
+ "type": "boolean"
+}Output schema / properties / drops / items / requiredPrevious value: -[
- "slug",
- "url"
-]New value: +[
+ "slug",
+ "url",
+ "password_protected"
+]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.
Add one secure layer between your agents and this server.