Dropyour

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

The annotation already marks the tool as destructive (destructiveHint: true). The description goes beyond this by emphasizing 'immediate and final', explaining that the URL is never reassigned, and detailing the authentication nuance with managementToken. This adds valuable behavioral context.

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 two sentences with a clear front-loaded action. Every sentence earns its place: the first states the core function and permanence, the second clarifies a key edge case. No fluff.

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 delete tool with no output schema and only two parameters, the description covers the destructive nature, a key behavioral consequence (URL never reassigned), and the token logic. It does not mention potential errors or response behavior, but these are less critical given the simplicity.

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 0%, so the description must compensate for parameter meanings. It partially explains managementToken ('owned drops need no managementToken') but does not clarify dropId beyond what the schema pattern suggests. This is insufficient for full parameter understanding.

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 function with a specific verb and resource: 'Permanently delete a drop.' The added detail that 'the URL is never reassigned' gives additional scope and distinctly separates it from sibling tools like dropyour_replace or dropyour_update_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 provides clear context for when to use the tool (for permanent deletion) and introduces a usage condition: with an account token, owned drops need no managementToken. However, it does not explicitly mention alternatives or when not to use the tool, so it falls short of 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?

Beyond the readOnlyHint annotation, the description discloses auth-mode-dependent behavior, the difference between account-token and anonymous session scoping, and that management tokens are never stored server-side. This gives the agent important privacy and invocation context.

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, front-loaded with the core action, followed by the two auth scenarios and a security note. Every sentence adds useful information with no redundancy.

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 parameterless listing tool, the description fully covers behavior under both auth modes and omits nothing needed to invoke or interpret the call. No output schema exists, but the return concept is implied by the list action.

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, so the baseline is 4. No parameter documentation is needed, and the description correctly focuses on auth context rather than parameter syntax.

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 'List your drops,' a specific verb and resource. It then clarifies the two scoping modes (account-token vs anonymous session), distinguishing it from sibling list tools like list_versions and records_list.

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

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

The description gives clear context on when results include all LIVE drops on the account versus only drops from the current anonymous session. It does not explicitly name an alternative tool or state when not to use it, but the usage context 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?

Annotations already declare readOnlyHint=true, but the description adds substantial behavioral context: newest-first ordering, 'graduated=false and an empty list' for lower levels, and 'degraded=true: means unknown, NOT nothing published'—a crucial semantic clarification. It also notes that with an account token, owned drops need no managementToken, which goes 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?

Four sentences, each adding essential information: purpose, edge case behavior, degraded mode meaning, and auth condition. No filler or repetition. Front-loaded with the main action.

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?

Despite lacking an output schema, the description covers key return semantics (newest first, currently served, flags for graduated/degraded) and the auth nuance. This is more than sufficient for an agent to correctly invoke the tool and interpret responses.

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 0%, so the description carries the burden. It explains managementToken's optionality based on account token and ownership—valuable nuance beyond the schema. dropId is not explicitly described, but the context 'of a GRADUATED app' makes its role obvious, and the schema provides the format.

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 'List the published versions of a GRADUATED app (level 4)', a specific verb+resource+scope that clearly distinguishes it from sibling tools like dropyour_list or dropyour_status. It further clarifies that levels 1-3 have no history, reinforcing the tool's unique role.

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 explicitly states when to use this tool: for graduated apps at level 4, and explains that lower levels are not applicable. It also contrasts with `replace` for levels 1-3, giving context on why this tool exists. It mentions auth nuance but doesn't name specific alternatives like `dropyour_status` or `dropyour_list`, so a small gap remains.

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?

With no annotations, the description carries the full burden and does well: it discloses that the managementToken is shown once and required for replacement/configuration/deletion, that the URL is stable across updates, that browser data survives, and it mentions size/expiration limits and privacy default. Minor gaps like failure behavior are not covered, but the key behavioral traits are transparent.

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 paragraph of five dense sentences, each carrying essential information: action, return values, token warning, free/limits, and privacy. It is front-loaded with the primary verb and resource, and there is no filler or repetition.

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 5 parameters, one required, and no output schema, the description is comprehensive. It covers return values (URL and managementToken), token handling, size/expiration constraints, and privacy default. The absence of an output schema is compensated by the description's mention of key outputs.

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 provides 100% parameter coverage, so the baseline is 3. The description adds contextual meaning for expiresInSeconds (default 30 days, max 5 MB) and clarifies the html requirement, but it does not add per-parameter details beyond what the schema already documents.

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: 'Publish a self-contained HTML file to Dropyour.' It clearly distinguishes itself from siblings like dropyour_publish_site by emphasizing a single self-contained HTML file, and it states the output (URL and token), making the tool's purpose 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?

The description provides clear context for when to use the tool: free, anonymous, no API key, with size and expiration constraints, and private-by-default drops. It does not explicitly state when not to use it or name alternative tools, but it gives enough situational context to guide selection.

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

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

With no annotations, the description carries the burden and discloses important traits: requires Pro token, results in a permanent URL, assets served under the drop, and limits (25 MB, 50 files). It does not mention response format or side effects like overwriting, but the core behavioral context is present.

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 with zero redundancy: first sentence states the core action, second adds auth and URL behavior, third adds limits. All content is essential and front-loaded, making it easy to scan.

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

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

The description covers purpose, prerequisites, constraints, and URL behavior, which is adequate for a publish tool with no output schema. It lacks an explicit statement of what the response contains (e.g., the permanent URL as a return value), but that is inferable. Overall, context is strong.

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 baseline is 3. The description adds value beyond the schema by specifying the 25 MB and 50-file limits for the zipBase64 parameter, which are not present in the schema property descriptions. This extra constraint context justifies a 4.

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 verb 'publish' and the specific resource: a MULTI-FILE site from a .zip (index.html + assets). It distinguishes from sibling tools like dropyour_publish by emphasizing the multi-file zip input, and includes key constraints (base64, size, file count).

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

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

The description implies when to use this tool (for multi-file sites via zip) versus single-file publishes, and clearly states the Pro token requirement. However, it does not explicitly name alternative tools or state when not to use it, so it lacks the full exclusionary guidance of 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?

Beyond the readOnlyHint annotation, the description discloses multiple behavioral traits: it returns asset paths but not bytes for multi-file sites, truncates large content with a real size report, and clarifies authentication requirements (managementToken not needed for owned drops with an account token). This is rich, useful context that goes far beyond the annotation.

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 each sentence adding meaningful detail. It front-loads the primary purpose, then covers edge cases (multi-file, truncation) and authentication. 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?

Given there is no output schema, the description covers key return behaviors (truncation, asset paths, real size) and authentication. It doesn't detail the entire response structure but is adequate for a read tool with two parameters.

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 0% schema coverage, the description must explain parameters. It explains managementToken's optionality and context, but dropId is only implicitly understood from the name. The description partially compensates but doesn't fully document required parameter format or behavior.

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 action ('Read a drop's source HTML') and resource ('a drop's source HTML'). It explicitly distinguishes itself by noting 'no shared-memory shim, no attribution badge', separating it from sibling read tools like dropyour_read_data.

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 context about when to use this tool (to get the exact published HTML without injected artifacts) and what to expect for multi-file sites. It doesn't name specific alternative tools but implies differentiation, which is sufficient for clear usage 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?

The annotation already declares readOnlyHint=true, and the description adds substantial behavioral context: the return shape (scope='server' with {version, data} or scope='client-only' with data=null), how to interpret the two scopes, and the auth nuance that owned drops with an account token need no managementToken. This goes well beyond the annotation and gives the agent actionable expectations.

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

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

The description is three sentences, front-loaded with the core verb and resource, and every sentence provides necessary detail (what the data is, return shapes, auth condition). There is no fluff or redundancy.

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 read-only tool with two parameters and no output schema, the description covers all key aspects: purpose, return format, scope semantics, null behavior, and auth requirements. It gives the agent enough information to know what to expect and when the call is sufficient, making it complete for the tool's simplicity.

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 0%, so the description carries the burden. While it clearly ties dropId to 'a drop's app data' and explains the managementToken condition ('With an account token, owned drops need no managementToken'), it does not explicitly describe dropId's format or expand on when managementToken is required beyond that. It adds meaningful context but does not fully compensate for the absence of property descriptions.

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 uses the specific verb 'Read' and clearly identifies the resource ('a drop's app data — the shared-memory state...') and the intended use case ('so you can answer questions about what the app holds'). It distinguishes from sibling tools like dropyour_read_content by focusing on the app data/localStorage rather than content, so no ambiguity remains.

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 clear context for when to use the tool (when you need to inspect app data or answer questions about what the app holds) and explains the difference between server and client-only scopes. It does not explicitly name alternative tools or state when not to use it, so it falls just short of a 5, but the context is more than merely implied.

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 readOnlyHint annotation, the description adds crucial behavior: pagination semantics, ordering, and a strong security warning that documents are untrusted data and must never be treated as instructions. This is high-value behavioral context that annotations alone don't provide.

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?

Four sentences, each earning its place: purpose, pagination, security warning, and read-only nature. Information is front-loaded and there is no fluff or repetition.

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 paged read tool with no output schema, the description explains the key behaviors (pagination, ordering, read-only) and the critical security constraint. It is complete for an agent to use correctly without needing further assumptions.

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 60%, so some parameters (dropId, managementToken) lack descriptions. The description adds meaning for cursor (opaque, used for pagination) and limit (page size), but doesn't compensate for the missing parameter details. It provides some value but not enough to reach a higher score.

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 gives a specific verb ('Read'), a clear resource ('one page of a collection from a GRADUATED app's queryable store'), and a distinguishing scope ('most recently updated first'). It clearly differentiates from siblings by focusing on paginated reading of records, not generic listing or data writing.

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 how to paginate ('Pass the returned cursor to get the next page') and clarifies the read-only nature ('writes belong to the app's own code'), which implies when not to use this tool. It doesn't explicitly name alternative tools, but the context is clear for an agent.

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 well beyond the readOnlyHint annotation by disclosing that nothing is downloaded, explaining the graduated=false behavior for levels 1-3, and clarifying that degraded=true means the backend is unreachable ('unknown', never 'empty'). This provides significant behavioral context that the annotation alone does not 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?

The description is compact and front-loaded: it opens with the primary action and result, then adds necessary edge cases in concise clauses. Every sentence adds value without extraneous filler, making it highly efficient.

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 that there is no output schema, the description adequately covers the return behavior (per-collection summary, graduated=false, degraded=true). It does not explain the parameters, but the schema already marks dropId as required. Minor gaps include error handling for invalid IDs, but the provided edge cases make the description largely complete for its intended purpose.

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 parameters (dropId, managementToken) are not mentioned or elaborated in the description. With 0% schema description coverage, the description fails to compensate by explaining what these parameters are, how they affect the call, or their format beyond the schema's pattern. The agent must infer meaning solely from names and schema metadata.

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 function with a specific verb ('Summarise') and resource ('queryable store' of a GRADUATED app), and details the output format (one line per collection with record count and bytes). This distinguishes it from siblings like dropyour_records_list, which likely lists individual records rather than summarizing collections.

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

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

The description implies when to use the tool (when you need a high-level summary of stored data) and provides edge-case context (levels 1-3 have no store; degraded=true). However, it does not explicitly state when to prefer this over alternatives like dropyour_records_list or dropyour_status, leaving the selection partially inferred.

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, so the description carries the burden of behavioral disclosure. It adds valuable context: the URL never changes, visitor data survives, a drop keeps its type, and token ownership rules. These are meaningful behavioral traits beyond the annotation. It does not mention error handling for type mismatches or missing content, but the disclosed behaviors are rich and consistent.

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: three sentences, each providing distinct, essential information. It front-loads the primary action, then explains constraints and authorization. No wasted words; 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 mutation tool with no output schema, the description is quite complete: it covers the operation, format constraints, URL stability, data persistence, type preservation, and auth. Minor gaps include not specifying required vs optional content (the schema implies dropId is the only required param) and not describing failure modes or return values, but these are not critical given the tool's complexity.

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 descriptions cover 75% of parameters, so baseline is 3. The description adds semantic value by explaining that html and zipBase64 are alternatives and that the existing drop type determines which format to use. It also clarifies that managementToken is unnecessary for owned drops, complementing the schema's description. This goes beyond the schema's individual descriptions.

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 'Replace the content of an existing drop', which clearly states the verb and resource. It distinguishes itself from sibling tools like dropyour_publish (create new) and dropyour_update_settings (settings only) by focusing on content replacement while preserving the URL. The explicit mention of HTML and zip formats further clarifies scope.

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 clear context for when to use this tool: when you need to replace content without changing the URL, preserving browser data. It also explains authorization guidance (owned drops with account token need no managementToken). However, it does not explicitly reference alternatives or state when not to use it, missing a direct comparison with rollback or 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?

Beyond the idempotent/non-destructive annotations, the description adds crucial behavior: 'only moves a pointer: no bytes travel, nothing is rebuilt, and the URL never changes'. It also discloses version validation and version 0 semantics, plus the boundary against regular drops.

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 dense sentences cover purpose, mechanics, validation, and exclusions. No wasted words; key information 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?

The description covers the workflow, the lightweight pointer move, version 0 meaning, and the 'not' case. Minor gaps remain: return format is not described (no output schema) and managementToken is unmentioned, but the core behavior is well-specified.

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 has only 33% description coverage (version). The description adds meaningful guidance for version (from list_versions, 0 = graduation frontend) but says nothing about dropId or managementToken. With low schema coverage, the description should compensate more fully; it only partially does.

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 identifies the tool's action: 'Roll a GRADUATED app back to a previously published version' and frames it as a 'repair verb' for broken publications. This distinguishes it from sibling tools like dropyour_publish or dropyour_replace.

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 explicit usage guidance: call dropyour_list_versions first and pass a version number from there, unknown versions are refused. It also states a key non-usage case: does NOT step the app down to a regular drop, which remains a human decision.

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 state readOnlyHint=true, but the description adds significant behavioral details: the token exemption for owned drops, the 'approximate' nature of view count, and the conditional disclosure of private name. This goes well beyond the annotation and sets accurate expectations.

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

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

The description is two sentences, front-loaded with the action and result fields, followed by a concise authentication note. Every word is useful, with no redundancy 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?

The description fully specifies the return fields (URL, visibility, expiration, size, approximate view count, private name) and covers the authentication exception. Given the simple two-parameter interface and read-only nature, no additional context is necessary.

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 0% schema coverage, the description compensates by explaining the managementToken parameter's purpose and conditionally optional usage. While dropId is not explicitly described, the phrase 'a drop's status' clearly identifies it as the drop identifier, and the schema provides its pattern. This adds meaningful context beyond the raw schema.

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 specifies the action ('get status') and resource ('a drop'), and enumerates the exact fields returned (URL, visibility, expiration, size, approximate view count, private name). This distinguishes it from sibling tools like read_content or read_data that fetch content or data rather than metadata.

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 clear context by explaining that an account token makes managementToken unnecessary for owned drops, which guides authentication usage. However, it does not explicitly mention when to use this tool over alternatives like droyour_list or droyour_read_data, so it lacks explicit exclusions.

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 idempotentHint annotation, the description discloses critical behavioral traits: switching to public triggers a stricter content re-scan and may be rejected, and token requirements are explained. 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 dense sentence that front-loads the main verb and resource. It's efficient but packs many clauses and caveats, which slightly affects readability. Still, every part 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 an 8-parameter tool with no output schema, the description covers the most important settings and behaviors but omits mention of the 'tags' parameter. However, tags are described in the schema, so the description doesn't need to repeat it. Overall, it provides sufficient operational context.

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?

Although schema coverage is 63%, the description adds significant meaning to parameters: visibility semantics ('private = link-only + noindex, public = indexable'), badgeHidden requiring Pro token, name empty clears it, and publishAt empty means publish now. This goes beyond the schema's basic descriptions.

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 changes a drop's visibility, expiration, badge, and private name, using specific verbs and naming the resource. It distinguishes itself from sibling tools by focusing on updating settings rather than deleting/publishing/reading.

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 context on when to use this tool (e.g., to change settings) but does not explicitly mention when not to use it or name alternatives. It does give important usage-related caveats like Pro account requirement for badgeHidden and token management.

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 readOnlyHint annotation, the description discloses an important behavioral trait: an invalid token silently degrades to anonymous. It also mentions that the tool reports resolved tier and limits, giving insight into expected output. This adds meaningful context beyond annotations, though it does not elaborate on return format or other edge cases.

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 two concise sentences that front-load the purpose ('Check how this session is authenticated') and immediately follow with practical usage guidance. Every sentence earns its place with no wasted words or redundancy.

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 and no output schema, the description is complete: it states the purpose, when to call it, what it reveals (tier and limits), and a critical behavioral caveat (silent degradation to anonymous). This fully covers the agent's needs for selection and 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?

The tool has zero parameters, so the input schema is empty. The description appropriately focuses on behavior rather than parameter explanations. Baseline for zero-parameter tools is 4, and no additional parameter information 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 checks how the session is authenticated, identifying the resolved tier (anonymous/free/pro) and its limits. This specific verb+resource purpose distinguishes it from sibling tools that perform data operations (delete, publish, read, write), confirming it as a session introspection 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?

The description provides explicit guidance on when to call the tool: after configuring an account token (dyk_...) to confirm it is recognized. It also implies a use case for verifying token validity. However, it does not explicitly mention when not to use it or name alternative tools for similar checks, so it falls short of 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 the tool destructive, so the description adds useful context: it fully replaces state, requires optimistic concurrency via expectedVersion, and describes the version_conflict rejection. It also clarifies authentication nuances for owned drops.

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 dense paragraph that front-loads the primary action and covers constraints without fluff. Each sentence contributes meaning, though using bullets could improve scannability.

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 destructive write with no output schema, the description covers essential behavioral aspects: full replacement, version conflict handling, anonymous-drop limitations, and auth. It omits success-response details, but the critical failure mode is fully documented.

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 50% schema coverage, the description compensates by explaining expectedVersion's role and the need to write the complete data object. It also addresses managementToken usage, though it omits dropId specifics.

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: 'Write a drop's app data' and explains it replaces the shared-memory state. It distinguishes itself from read_data by instructing a read-modify-write workflow and clarifies the whole-object replacement scope.

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 provides explicit workflow guidance (read first, modify, write back WHOLE) and a clear exclusion: anonymous drops cannot be written. It also mandates expectedVersion and explains the version_conflict retry process, giving both when-to-use and when-not-to-use semantics.

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