Dropyour

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

Builds on destructiveHint annotation by clarifying 'immediate and final' and that URL not reassigned. Also adds auth context. No contradictions.

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, front-loaded with core action, no unnecessary words.

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?

Covers action, outcome, and auth condition. Lacks parameter format details and explicit return value (no output schema). Adequate but not exhaustive.

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?

Adds meaning for managementToken (when needed). But schema coverage is 0%; dropId format not described beyond regex pattern in schema. Description partially compensates but not fully.

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?

Clearly states 'Permanently delete a drop' with specific verb and resource. Emphasizes permanence and that URL is never reassigned, distinguishing from any other tool.

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 context for when managementToken is needed vs not, implying when to use with account token. However, does not explicitly compare with sibling tools (e.g., replace).

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 readOnlyHint=true, but the description adds value by detailing how the list differs based on authentication state and mentioning that management tokens are not stored server-side.

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, each conveying essential information without redundancy. It is front-loaded with the main action and efficiently expands on context.

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 simple tool (no parameters, readOnlyHint), the description fully covers the two key usage scenarios and a privacy note. No output schema exists, but the listing behavior is sufficiently described.

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 schema has zero parameters, so the description cannot add parameter meaning. Baseline score of 4 is appropriate as it fully covers the simple input interface.

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 'List your drops', specifying the resource (drops) and the context (account vs anonymous). It distinguishes from sibling tools like publish or delete by focusing on listing.

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 explains when to use the tool (to list drops) and provides context about account token vs anonymous sessions. While it doesn't explicitly name alternative tools, the behavioral distinction is 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?

Discloses key behaviors: returns stable URL and token, token shown once, required for management, free/anonymous, size and expiration limits, privacy by default. With no annotations, the description carries full burden and does so well, though could mention rate limits if any.

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?

Description is thorough but slightly verbose; front-loads the main action, then adds details. Could be tightened but remains clear and well-organized.

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 no output schema, the description fully explains return values (URL, managementToken) and their implications. Covers constraints, management requirements, and privacy. No obvious gaps.

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?

Since schema coverage is 100%, the description adds meaningful context: clarifies html as 'complete self-contained HTML (inline CSS/JS, max 5 MB)' and explains expiresInSeconds options and default tier behavior, exceeding bare schema info.

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 explicitly states it publishes a self-contained HTML file to Dropyour, distinguishing it from 'dropyour_publish_site' (likely for multiple files). It specifies the output (stable public URL, managementToken) and the file type constraint.

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 for when to use (publishing a single HTML file), mentions constraints (5 MB, default expiration), and stresses keeping the token. Does not explicitly exclude alternatives but implies differentiation via 'self-contained'.

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?

Despite no annotations, description discloses important behavioral traits: requires Pro token, size and file count limits, permanent URL, assets served under the drop. It does not describe error handling or return value but covers key 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?

Two sentences, front-loaded with key action, no wasted words. All information is essential and well-structured.

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?

While it covers purpose and constraints, it lacks any description of return value or response format (no output schema). Given the complexity (multi-file site), the description would benefit from mentioning what is returned (e.g., URL or status).

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 description adds meaning: zipBase64 is a .zip with index.html+assets, expiresInSeconds defaults to 30 days based on tier. This goes beyond the schema's enum list and description.

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 clearly states 'Publish a MULTI-FILE site from a .zip' and specifies expected contents (index.html + css/js/images), which distinguishes it from sibling tools like dropyour_publish (likely single-file).

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?

Description specifies requirement of 'Pro account token' and mentions limitations (25 MB, 50 files). It implies use for multi-file sites, but does not explicitly state when not to use or name alternatives like dropyour_publish.

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 only provide idempotentHint=true. The description adds valuable behavioral context: URL never changes (origin contract), visitors' browser data survives the update, and management token requirements. This enriches understanding beyond 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 sentences, front-loaded with the core action. Every sentence adds value: the action, the URL stability guarantee, and the token requirement. No wasted words.

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 content replacement tool with no output schema, the description covers key aspects: what it replaces, URL persistence, authentication context. Could mention success/error returns, but sufficient for agent understanding.

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 67% (2 of 3 parameters have descriptions). The description does not add meaning beyond the schema for parameters, though it provides context for managementToken. With moderate coverage, the baseline 3 is appropriate as the description adds little extra semantics.

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 'Replace the HTML content of an existing drop.' It uses specific verb (replace) and resource (drop), distinguishing it from siblings like dropyour_publish (creates new) and dropyour_update_settings (updates settings).

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 for updating content of an existing drop and mentions that the URL never changes. However, it does not explicitly state when to use this tool versus alternatives like dropyour_update_settings, nor does it provide when-not-to-use 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 declare readOnlyHint=true, so the description's additional note about account token usage adds value but is limited. It does not disclose error handling, rate limits, or other behavioral traits beyond the basic read-only nature.

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 concise with two sentences. It front-loads the primary purpose and key attributes, then adds a secondary auth note. No superfluous 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?

Given the tool's low complexity (two parameters, no output schema, read-only), the description covers the main response fields and auth nuance. It lacks details on potential errors or optional fields, but is largely adequate for an agent to understand and use the tool.

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 0% parameter description coverage, and the description does not explain the dropId parameter format or purpose beyond the tool's name. It mentions managementToken in context, providing some semantic value, but overall it fails to add significant meaning beyond what the schema alone offers.

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 tool retrieves a drop's status and lists specific attributes (URL, visibility, expiration, size, approximate view count). However, it does not explicitly differentiate from sibling tools like dropyour_list or dropyour_delete, leaving the distinction implied rather than explicit.

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 provides some context about authentication (account token vs managementToken), but lacks explicit guidance on when to use this tool versus alternatives. It does not state conditions for using dropyour_status over dropyour_list for viewing drops, or when to avoid 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?

Annotations provide idempotentHint only. The description adds significant behavioral detail: the re-scan on public transition, token requirements, and that owned drops need no managementToken. 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 covering all key actions without redundancy. Front-loaded with main purpose. Each sentence serves a distinct purpose (what, consequences, auth). No wasted words.

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?

Covers visibility, expiration, badge, and re-scan risk. Missing: return value or success indication (no output schema), and behavior when managementToken is omitted for non-owned drops. Adequate but not fully comprehensive for a 5-parameter tool.

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 low (20%). The description adds meaning for visibility (private vs public semantics), expiration, and badge removal. It clarifies managementToken's role indirectly. However, dropId and managementToken details are not fully explained.

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 it changes a drop's visibility, expiration, and badge settings. It uses specific verbs ('Change', 'remove') and resources ('drop's visibility', 'badge'), making the purpose unambiguous. It implicitly distinguishes from siblings like dropyour_delete (delete) and dropyour_publish (publish).

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 includes context about when an account token is needed and that switching to public may be rejected, but it does not explicitly guide when to use this tool versus alternatives (e.g., dropyour_replace for replacing content). Usage is implied but not contrasted with 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?

The description adds significant behavioral context beyond the readOnlyHint annotation: it specifies what is checked (tier, limits) and the silent degradation behavior of invalid tokens. No contradictions 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 concise sentences: first states purpose, second provides usage guideline. No unnecessary words, front-loaded with key 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 read-only tool with no parameters, the description fully covers the tool's behavior and usage context. No output schema needed given the straightforward nature.

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?

No parameters exist (schema coverage 100%, 0 params). The description adds no parameter info, but baseline for 0 params is 4, and no further elaboration is needed.

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 tool's purpose: to check session authentication tier (anonymous/free/pro) and limits. It distinguishes itself from sibling tools, which are all about actions on resources (delete, list, publish, etc.).

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?

Explicitly instructs when to call: after configuring an account token to confirm recognition. Also warns about invalid token silently degrading to anonymous, providing critical usage context.

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