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

Beyond the annotations (openWorldHint false, destructiveHint false), the description discloses critical behavioral details: the token is single-use, the action joins and switches the active workspace, and it returns the joined workspace. It also notes that a team-scoped credential authenticated as the invited email is required, which is important operational context not available in the 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 tightly written in two sentences. It front-loads the primary purpose, then packs in parameter selection, prerequisites, side effects, and return value without wasted words. Every clause adds value.

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 complexity—two mutually exclusive parameters, a required credential, side effects, and a return value—the description covers all essential aspects. It ties into sibling tools (dropthis_invitations) and provides sufficient context for an agent to invoke it correctly. The presence of an output schema and good annotations further reduces the need for more detail.

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?

While the schema already describes the two parameters, the description adds crucial semantics: it clarifies that token is a raw single-use token from the invite email, invitation_id comes from dropthis_invitations, that at least one is required, and that token takes precedence when both are provided. This goes well beyond the schema descriptions and gives the agent a clear decision rule.

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 begins with a specific verb and resource: 'Accept a team-workspace invitation and join.' It clearly distinguishes this from sibling tools by labeling it 'the teammate's join path,' contrasting it with inviter-side tools like dropthis_invite_member. The purpose is unambiguous.

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 when-to-use guidance: it is the join path for teammates. It explains exactly how to choose parameters, noting that token is from the invite email, invitation_id is the agent path from dropthis_invitations, and that at least one is required with token winning if both are given. It also states the credential requirement (members:write) and the side effect, giving clear context for use.

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 readOnlyHint=true and openWorldHint=false, annotations already establish the read-only safety profile. The description adds meaningful behavioral context by detailing the returned capability matrix, numeric limits, and active workspace, and how this supports pre-checking feature gates and confirming publish 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?

The description is information-dense but each clause adds value: profile fields, entitlements, limits, workspace, and usage rationale. It is front-loaded with the primary resource and avoids filler, though the first sentence is somewhat long and parenthetical.

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 zero parameters, a readOnly annotation, and the presence of an output schema, the description fully covers the tool's purpose, content, and when to invoke it. It explains both the account profile and workspace aspects, leaving no significant gaps for an AI agent.

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 zero parameters and schema coverage is 100%, so the description need not explain parameters. Per the rubric, 0 params yields a baseline of 4; the description focuses on output semantics, which 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 clearly specifies the resource (authenticated account profile) and the exact contents returned: profile fields, entitlements, numeric limits, and active workspace. It distinguishes from sibling tools by emphasizing the combined payload for feature gating and pre-publish workspace confirmation, something no single sibling provides.

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 explicit usage context: call before a multi-team publish to confirm workspace, and for feature gate pre-checks to avoid separate lookups. It does not name alternative tools like dropthis_workspaces, but the 'no separate lookup' phrasing implies when not to use other tools.

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, disclosing that counts are 'best-effort — captured fire-and-forget at the edge, so treat them as an approximate signal, not exact human visits.' It also details plan-gated responses (feature_not_in_plan, views+truncated, byCountry/byReferer/daily), which is crucial 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 dense but well-structured: purpose first, then capability tiers, accuracy caveat, parameter prerequisite, and usage trigger. Every sentence contributes unique information, with no filler or restatement. Length is justified by the tool's complexity.

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 usage scenario, plan-based return variations, accuracy limitations, and the prerequisite resolve step. With an output schema present, it does not need to list return fields, and it adequately handles error cases (feature_not_in_plan). Complete for a read-only analytics 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 covers the only parameter (drop_id) fully, including the id-only requirement and the resolve alternative. The description essentially repeats this, adding no new semantic information beyond the schema. Baseline 3 applies due to high schema coverage.

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: 'Approximate view analytics for one drop, by its `drop_…` id.' It uses a specific verb ('get' from title, but more precisely 'read analytics') and resource ('view analytics for a drop'), and distinguishes from siblings by specifying id-only usage and pointing to dropthis_resolve for URL/slug inputs.

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?

Explicit guidance is provided: 'Use when the user asks how many views / how much traffic a drop got.' It also tells the agent to call dropthis_resolve first for public URLs/slugs, and explains capability-based limitations (Free vs Keep vs Pro+) that affect when the tool is usable.

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 valuable behavioral context beyond the sparse annotations: return value (id and slug), the fact that switching active workspace is a separate action, and the subtle creatorCanReach failure mode with its security implication (denied on next write, re-auth needed). This goes far beyond what openWorldHint/destructiveHint 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 a dense but well-structured paragraph. Each sentence serves a distinct purpose: action+ownership, auth prerequisite, return+separation concern, comparison to sibling, and failure-mode warning. No filler; sentence order is logical.

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 creation tool with auth requirements and a non-obvious failure mode, this description covers all essential aspects: what it does, prerequisites, output, related operations, and a warning about allowlist reachability. With an output schema present, the description need not elaborate further on return structure.

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% with clear descriptions for both name and slug, so the baseline is 3. The description does not add parameter-level detail beyond the schema (e.g., no mention of validation rules beyond the schema's 409 clash note), but it also does not need to.

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+resource ('Create a new team workspace') and immediately clarifies ownership ('you become its owner'), distinguishing it from sibling tools like dropthis_workspaces (list) and dropthis_use_workspace (switch active). This clearly identifies 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?

Explicitly states when to use it (requires team-scoped credential with workspaces:write), when not to (publish-only key cannot create teams), and points to alternatives (dropthis_workspaces to list existing, dropthis_use_workspace to switch). This is textbook 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 description goes beyond the destructiveHint annotation by specifying that both the drop and its public URL are removed, the operation is irreversible, and a confirmation flag is mandatory. This is critical behavioral context for an agent evaluating the consequences of invoking the tool.

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, well-structured sentence that front-loads the core action and packs in the identifier constraint, destructiveness, and confirmation requirement without any 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 two-parameter destructive tool with an output schema, the description covers the essential aspects: the action, the identifier specificity, the irreversibility, and the required confirmation. No critical information is missing for an agent to decide on and execute the 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?

Schema description coverage is 100%, and the schema already thoroughly documents both parameters, including the drop_id format and the confirm constraint. The main description reiterates these points but does not add new parameter-level meaning beyond the schema, so a baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: to permanently delete a drop and its public URL using a drop_id. It specifies the exact identifier type ('drop_…' id, not slug or URL), distinguishing it from workspace deletion and other sibling tools.

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: use this tool for permanent deletion of a drop, emphasizing that it is destructive and irreversible and requires confirm=true. It does not explicitly list alternatives or when-not-to-use scenarios, but the context is unambiguous.

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

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

The description discloses that deletion is destructive, irreversible, and cascades to 'drops and members'. It also states the owner-only permission and credential requirement (ADR-0068). This significantly augments the destructiveHint annotation with specific consequences and prerequisites.

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 four crisp sentences that front-load the core purpose and then add necessary caveats (destructive, confirm, owner, credential) and a pointer for obtaining the workspace id. No 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?

For a destructive, two-parameter tool with an output schema, the description covers the action, consequences, permissions, confirmation requirement, and how to obtain required input. It leaves little ambiguity for an agent.

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% with clear descriptions for both `workspace` and `confirm`. The description reiterates `confirm: true` and references dropthis_workspaces for the workspace id, but adds little beyond the schema for the parameters themselves.

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 'Permanently delete a team workspace by its id', specifying the verb (delete), resource (team workspace), and method (by id). This distinguishes it from sibling tools like dropthis_delete or workspace management tools.

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 guidance: 'Owner only' establishes who may use it, 'requires `confirm: true`' is a prerequisite, and 'Use dropthis_workspaces to find the workspace id' points to a supporting tool. However, it doesn't explicitly contrast with other deletion tools, so slightly less than full alternative specification.

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 idempotent and non-destructive, but the description adds key behavioral traits: mode immutability ('delete and reconnect to change'), the DNS loop and verification process, and the side effect that the first live path domain becomes the default publish target. 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 dense but every sentence adds value: purpose, response structure, workflow steps, mode semantics, and idempotency. It is front-loaded with the core action and flows logically. Length is justified by the tool's complexity; no filler or redundant phrases.

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 having an output schema, the description still explains the key response elements (CNAME record and `next` hints) and the full verification loop. It covers prerequisites (DNS provider tooling), mode differences, default publish behavior, and idempotency. For a multi-step domain connection tool, this is complete and well-rounded.

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% for both parameters, with detailed explanations of `mode` and `hostname`. The description adds some workflow context (e.g., response carries CNAME, first live path domain becomes default), but this info is largely already present in the schema. Baseline 3 is appropriate since the schema does the heavy lifting.

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 ('Connect'), identifies the exact resource ('custom domain... to the dropthis account'), and scopes the action ('start the DNS loop'). It clearly distinguishes from sibling tools like dropthis_domains_verify or dropthis_domains_list by focusing on the initial connection step.

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 when-to-use and next-step guidance: if DNS provider tooling is available, create the CNAME yourself then call dropthis_domains_verify; otherwise show the user. It also advises re-calling verify until live and then publishing with `domain` set. This goes beyond basic usage to a full workflow with alternatives.

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 flag destructiveHint=true, but the description adds substantial behavioral context: the confirm requirement, drops not deleted, the dangling-CNAME security warning, and the fallback to the shared pool if the domain was the publish default. This goes well beyond what annotations 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?

The description is well-structured and front-loaded with the core action. Every sentence adds a distinct consequence or instruction—effect, destructive confirmation, DNS warning, and default-publish fallback—with 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 destructive domain-disconnection tool, the description covers all critical outcomes: impact on drops and routes, security warning about DNS, and fallback behavior for the publish default. The presence of an output schema means return values need not be 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?

Schema description coverage is 100%, with both parameters fully described ('dom_…' id or hostname, confirm must be true). The description adds no additional parameter-level syntax or format details beyond the schema, so baseline 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 opens with a specific verb+resource ('Disconnect a custom domain') and explains the concrete effect (hostname stops serving drops, routes removed). This clearly differentiates it from sibling tools like connect, verify, update, and 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 a clear context for use (disconnecting a domain) and explicitly notes what this tool does NOT do ('the drops themselves are NOT deleted'), providing a when-not signal. It does not name alternative tools, but the guidance 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 read-only and idempotent hints, and the description adds the critical behavioral context that it 'does NOT run a live DNS check' and only reads what dropthis last recorded. This is valuable beyond the 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 concise and well-structured: it states what is returned, clarifies a key limitation, gives use cases, and points to a sibling for list queries. Every sentence earns its place with no 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?

Given the tool's complexity and the presence of an output schema, this description is complete: it covers return fields (status, mode, DNS record, etc.), the stored-state behavior, and next-step guidance. It fully addresses the context needed for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'domain' is fully described in the schema as 'The `dom_…` id or the hostname'. The description repeats this same information without adding extra semantic detail, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool 'Fetch one custom domain's STORED state' by ID or hostname, and clearly distinguishes it from dropthis_domains_verify and dropthis_domains_list. The verb+resource+scope are specific and unambiguous.

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 when-to-use scenarios ('re-read the CNAME instructions', 'check a domain's state on a read-only connection') and names alternatives for other needs (verify, list). This is clear guidance versus 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 provides rich detail beyond the readOnlyHint annotation, including the full set of output fields, possible statuses (pending_dns/verifying/live/failed), and the distinction between path and dedicated domains. This gives the agent a clear picture of what information is retrievable and how to interpret results.

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 but the first is long and dense with field details. It is efficient and avoids unnecessary fluff, though a slight restructuring could improve scanability. Still, every sentence earns its place by conveying essential output and usage 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 simplicity (0 params, output schema present), the description fully covers the tool's purpose, output contents, and typical usage scenarios. It also cross-references related tools (dropthis_publish, dropthis_list) to help the agent navigate the tool family.

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 0 parameters, so the schema covers everything. The description adds no parameter-specific detail because none are needed; it focuses on the output and usage. This is appropriate for a no-parameter list operation.

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 'List the account's custom domains' and enumerates the specific fields returned (dom_ id, hostname, mode, status, default flag, mounted drop id). It clearly distinguishes this tool from siblings like dropthis_domains_get, connect, verify, update, and delete by focusing on the list behavior.

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 gives explicit use cases: 'check which domain publish lands on by default' and 'find a hostname to pass as domain to dropthis_publish.' It also tells the user to pass a hostname to dropthis_list to see mounted drops, providing clear guidance on when to use this tool and how it relates to alternatives.

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 annotations (idempotent, non-destructive), the description adds critical behavioral context: 'Changes ROUTING only' clarifies it doesn't modify content, and 'Mode is immutable' discloses a permanent characteristic. This fully discloses the tool's behavior and limitations without contradicting 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 packs multiple pieces of information (purpose, domain types, parameter conditions, alternatives, immutability) into a compact yet readable structure. Each sentence earns its place and the most important distinction (routing vs content) 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?

Given the tool's two modes and the existence of an output schema, the description covers all essential context: what changes (routing), what doesn't (content), the mode immutability constraint, and valid input formats. It also differentiates from siblings, making it complete for an agent to correctly select and invoke 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?

Schema coverage is 100%, so baseline is 3. The description adds semantic value by explaining that `drop_id` is for dedicated domains and `default` is for path domains, and that `domain` accepts either the `dom_…` id or hostname. This goes beyond the schema descriptions by clarifying the domain-type-specific usage.

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 dual purpose: repointing dedicated domains via `drop_id` and setting/clearing path domains as default via `default`. It uses specific verbs ('Repoint', 'set/clear') and distinguishes from sibling tools by noting that `dropthis_update_content` handles content changes.

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 when-to-use guidance: use for routing only, not for content changes. It explicitly names the alternative (`dropthis_update_content`) and adds a constraint ('Mode is immutable: delete and reconnect to change it'), giving clear direction on when and how to use the tool.

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 and destructiveHint annotations, the description discloses key behavioral details: the non-blocking behavior, the 'retry_after' mechanism, diagnostics showing expected vs observed DNS values, and what happens once status is 'live' (publishing with domain set). This adds significant context about the tool's runtime behavior and recovery semantics.

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 information-dense and well-structured: purpose first, then behavior, re-call guidance, recovery path, post-live outcome, and parameter detail. Every sentence contributes necessary context, though it is slightly longer than strictly needed.

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 nuanced behavior (status advancement, retry logic, recovery), the description covers all critical aspects: purpose, usage, behavioral nuances, and the meaning of the parameter. The presence of an output schema reduces the need to explain return values, and the description is complete for the given 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 coverage is 100%, so the baseline is 3. The description adds value by specifying acceptable input forms ('the `dom_…` id or the hostname'), which helps the agent understand what 'domain' can be even though the schema describes it as a string.

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: 'Check a custom domain's DNS and TLS provisioning and advance its status (pending_dns → verifying → live).' This is a specific verb+resource+state transition, and it distinguishes the verify operation from sibling domain tools like connect, list, get, update, and delete.

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 strong context for when to use the tool: it explains the non-blocking nature, instructs to re-call after 'retry_after' seconds if status is 'verifying' or 'pending_dns', and explicitly identifies it as the recovery path after a 'failed' status. It does not explicitly name alternative tools, but the re-call and recovery guidance effectively communicates usage scenarios.

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 useful behavioral details: the tool is id-only (rejects URL/slug), returns a specific set of fields, and explicitly does not return content bytes. This adds meaningful context about what the tool actually does and its boundaries, enhancing trust and correct usage.

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 well-structured and front-loaded with the core purpose. It is somewhat long but every sentence earns its place: purpose, usage context, return fields, id-only constraint, and sibling differentiation. There is no wasted 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?

Given the simple single-parameter tool, the description covers all necessary context: what it returns, how to get the id, and what it does not cover. The presence of an output schema complements the return-field list, making the tool fully understood without missing pieces.

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 already fully describes drop_id (including the id-only restriction and the dropthis_resolve pointer) with 100% coverage. The description repeats this information but adds no new parameter-level semantics, so it continues to rely on the schema. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Read back an EXISTING drop's settings and metadata'. It clearly distinguishes itself from siblings by explicitly naming dropthis_get_content (served content) and dropthis_resolve (URL/slug to id conversion), leaving no ambiguity about its 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 explicit when-to-use and when-not-to-use guidance: it positions the tool within a read-modify-write cycle ('read current settings here, change them, then write with dropthis_update_settings'), instructs to use dropthis_resolve for public URLs/slugs, and directs to dropthis_get_content for served bytes. This fully orients the agent among alternatives.

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, and the description doubles down by saying 'this tool only reads' and 'never edit a partial window.' It further discloses default manifest output, historical deployment reads, 80,000-character windows with truncated flags and next_start_char, and binary byte-count summaries—rich behavior not visible in 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 text is long but front-loaded and tightly packed; each clause adds operational detail (default manifest, historical reads, windowing, exclusions). It is dense but free of filler, and the structure using dashes and semicolons keeps related ideas together.

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 complexity and 4 parameters, the description covers prerequisites, default vs. historical vs. file-specific behavior, output format, pagination, binary handling, workflow integration, and exclusions. It fully prepares an agent to select and invoke the tool correctly in 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?

Schema descriptions already cover all four parameters 100%, so the baseline is 3. The description adds meaningful workflow semantics: drop_id is id-only requiring prior resolution, deployment_id comes from dropthis_list_deployments, path must match manifest entries, and start_char is for paging with a warning not to edit partial windows.

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 'Read back the content an EXISTING drop is serving' and explicitly casts it as the read half of a read-modify-write loop, naming dropthis_update_content as the write counterpart. It also contrasts with sibling dropthis_get (settings/metadata) and dropthis_resolve, making the tool's unique role 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?

Provides explicit usage guidance: 'Use when the user wants to read, view, inspect, diff, or edit what a drop currently serves.' It names exclusions—'NOT for fetching arbitrary web pages' (publish with source_url) and directs metadata needs to dropthis_get—plus a prerequisite (call dropthis_resolve for URL/slug).

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, and the description reinforces this with 'List'. It adds behavioral context beyond annotations: the specific return fields (invitation id, workspace, role, status, expiry) and the required auth scope (ADR-0068: members:read). 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 sentences: the first states purpose and return fields, the second covers auth requirement and references the accept action. Each clause adds value with no redundancy, and the description is front-loaded with the core purpose.

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 zero-parameter read-only tool with an output schema present, the description covers purpose, scope, auth, and related next action. It is complete for its 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?

The tool has zero parameters, so schema coverage is inherently 100%. The description does not need to explain parameter semantics and does not attempt to. Baseline 4 applies for zero-parameter tools.

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 a specific verb 'List' and resource 'workspaces you have been invited to', clarifying it lists pending invitations. It further scopes to 'your own pending invitations', distinguishing it from siblings like dropthis_members and dropthis_accept_invitation.

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 (list pending invitations) and a prerequisite (team-scoped credential with members:read). Names the alternative tool dropthis_accept_invitation for acting on an invitation. However, it does not explicitly state when not to use this tool compared to other list tools, though the 'your own pending invitations' scoping reduces ambiguity.

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 only openWorldHint=false and destructiveHint=false, so the description carries the burden of explaining behavior. It adds valuable context: requires a team-scoped credential, role defaults to member, owner is transferred never invited, and returns a pending invitation that the invitee must accept. This goes beyond the annotations and clarifies key side effects 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 extremely concise—three sentences that front-load the main purpose, then add necessary context (token requirement, role default, acceptance flow, workspace lookup). No wasted words, and all information is relevant.

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 moderate complexity, the presence of an output schema, and minimal annotations, the description covers the essential context: prerequisites, default role, owner restriction, pending invitation outcome, and next step. It doesn't mention edge cases like duplicate invites, but that's not required for a well-rounded description. The only slight gap is not stating what happens if the email is already invited or a member.

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 already provides clear descriptions for all three parameters (100% coverage), including the role enum with the default mention. The description adds minimal extra value by referencing dropthis_workspaces for the workspace parameter, but the schema alone is sufficient. Baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Invite an email to a team workspace as admin or member'. It also differentiates from sibling tools by clarifying that owners are never invited, and that acceptance is handled by a different tool (dropthis_accept_invitation). The verb 'invite' and resources (email, workspace) are specific.

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 use this tool: it points to dropthis_workspaces to find the workspace id, and explains the acceptance flow via dropthis_accept_invitation. It also mentions the required credential and role default. While it doesn't explicitly state when not to use it, the inclusion of the owner restriction and the accept flow makes the usage context 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 pagination, ordering, field set, and the distinction between drop_ id and slug/URL. Also reveals authorization caveat for workspace ('delegated credentials only') and the recovery use-case for domain. These go well beyond the readOnlyHint 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?

Concise yet packed with value: opens with the core function, then usage, then crucial ID semantics, then parameter-specific guidance. Every sentence earns its place without 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 list tool, it covers ordering, pagination, return fields, parameter meanings, and related tool references. With an output schema present, the description fully supports 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?

Even with 100% schema coverage, the description enriches each parameter: limit/cursor are implied, domain is explained as a recovery path, and workspace is detailed with id/slug format, delegated credentials, and as the read-side twin of publish's workspace.

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 states a clear verb and resource: 'List the account's drops' with specifics on ordering (newest first), pagination, and returned fields. It distinguishes from siblings by explaining the drop_ id relationship to mutating tools and referencing domain/workspace list tools.

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 states when to use: 'Use when the user wants to list / show my drops / see what they have published.' Provides parameter usage context (domain, workspace) and references related tools, but does not explicitly mention when not to use or name alternative tools for similar operations.

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, and the description adds that results are newest first and requires the drop_… id, not the slug/URL. This is useful behavioral context beyond the annotations, though it doesn't mention pagination (but cursor is in 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?

The description is two sentences, front-loaded with the purpose and ends with a required-id note. 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?

Given the readOnly annotation, the output schema, and full parameter schema coverage, the description is sufficiently complete. It covers ordering, when to use, and the id format requirement.

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 100% coverage with detailed descriptions for all three parameters, so the description adds no new parameter semantics. It reinforces the drop_id format, but that's already in the schema, so it's redundant.

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 lists a drop's deployments/content history, using the verb 'list' and specifying the resource (deployments/versions). It also says 'newest first' and distinguishes it from restore (implicitly) by being a list operation.

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 says 'Use when the user asks for the content history, previous versions, or revisions of a drop,' which is clear when-to-use guidance. It does not provide when-not-to-use or alternative tools, but the context is sufficient for choosing this over siblings like restore.

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 readOnlyHint=true already indicating a safe read operation, the description adds valuable context: the required members:read permission, the semantic meaning of returned fields (including isYou and joined date), and the fact that the returned accountId is the input for other tools. This goes beyond what annotations alone would 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 two succinct sentences with no filler. It front-loads the action and resource, then packs field details, authorization, and cross-references into a compact, readable 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?

For a single-parameter read-only list tool with an output schema, the description covers purpose, output contents, required permissions, and related tools. There are no obvious gaps given 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?

The input schema already fully describes the single 'workspace' parameter as an id and even references dropthis_workspaces. The description's mention of 'by its id' and using dropthis_workspaces to find the id is redundant with the schema. Since schema coverage is 100%, the description adds no meaningful new semantics for the parameter.

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 with a specific verb ('List') and resource ('a team workspace's members by its id'), and enumerates the output fields. It also distinguishes itself from sibling tools by naming dropthis_workspaces, dropthis_update_member_role, and dropthis_remove_member, making its role in the workflow 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 gives clear usage context: it requires a team-scoped credential (ADR-0068: members:read) and directs users to dropthis_workspaces to find the workspace id. It also explains how the returned accountId is consumed by related membership tools. It stops short of explicitly stating when not to use this tool, but the guidance is solid.

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 richly discloses behaviors beyond the annotations: every call creates a NEW drop (duplicate risk), routing falls back to the shared pool if no live domain, image optimization transforms are disclosed in warnings[], and raw_url is null for HTML drops. This adds substantial context beyond the openWorldHint/destructiveHint flags.

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?

Although long, every sentence earns its place for a 19-parameter, three-mode publishing tool. It is front-loaded with the core purpose and explicitly enumerates content input options before diving into routing, optimization, and return-value nuances.

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 is complete for this complex tool: it covers all input modes, the multi-file structure, domain and slug routing, image optimization behavior, returned URLs (url vs raw_url), and even plan restrictions (password feature). An output schema exists, but the description provides the operational context the schema cannot.

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%, but the description adds meaning far beyond the field names: it explains the five mutually exclusive content input modes, the 200-file limit, when to use source_url vs content_base64, slug validation and auto-suffixing, and domain routing behavior. This is genuinely additive semantic guidance.

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+resource: 'Publish content to a NEW permanent public URL and get back its drop_… id.' It clearly distinguishes this creation tool from the update siblings (dropthis_update_content/dropthis_update_settings) and explains what makes it unique (always creates a new 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?

Explicit when-to-use guidance is present: 'Use when the user wants to publish, share, post, put online, make public, or get a shareable link.' It also gives strong when-not-to-use instructions: never call to change existing content, and if you only have a URL/slug, call dropthis_resolve instead of publishing again to avoid duplicates.

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 destructiveHint annotation, the description discloses the need for `confirm: true` and details the specific credential scopes (members:admin vs members:write). This adds significant behavioral context about permissions and necessary precautions, exceeding what annotations alone 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?

The description is two sentences and directly front-loads the action. It packs essential details (destructive nature, confirm requirement, credentials, dual use case) without redundancy or verbosity.

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 both possible use cases, the destructive nature, the mandatory confirmation, and the credential prerequisites. Given the tool's complexity and the existence of an output schema, this is complete for guiding correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already documents all parameters (100% coverage), but the description adds meaningful semantics: it explains that account_id can refer to either another member or yourself for leaving the workspace, and it clarifies the purpose of the confirm flag. This goes beyond the schema's literal field 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 action: 'Remove a member from a team workspace by the workspace id and the member's accountId' and explicitly covers the alternative use case of leaving the workspace by passing your own accountId. This distinguishes it from sibling tools like dropthis_update_member_role or dropthis_invite_member.

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: it says when to use this tool (to remove a member or leave the workspace) and gives prerequisites (credential requirements for each scenario). It doesn't explicitly name alternative tools for the 'when not to use' case, but the distinction between the two allowed actions is strong enough guide.

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 idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable context beyond annotations: permission requirements (team-scoped credential with specific scope), the need for an existing workspace id, and the condition that at least one of name/slug must be provided. It does not mention potential side effects like URL changes from slug modification, but the presence of annotations lowers the bar. This is solid, though not exhaustive.

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 long, front-loaded with the core purpose, and then provides essential operational details. Every sentence earns its place: purpose, credential requirement, parameter constraint, and sibling tool reference. 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?

Given the tool's complexity (3 parameters, 1 required), presence of output schema, and annotations, the description is complete. It covers purpose, how to find the workspace id, the required credential, and the parameter constraint. Error cases (slug clash) are already documented in the schema. The description provides all necessary context for an agent to select and invoke the 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?

With 100% schema coverage, each parameter already has a description. The description adds meaningful semantic content beyond the schema: it specifies that `name` and `slug` are mutually optional but at least one is required, which is not captured by the schema's required field (workspace). This relationship constraint adds value, so the score is above the baseline 3.

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: 'Rename a team workspace or change its slug, by its workspace id.' It specifies the verb (rename/change), resource (team workspace), and method (by workspace id), distinguishing it from siblings like dropthis_update_settings or dropthis_delete_workspace.

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 usage context: requires a team-scoped credential (with explicit permission ADR-0068: workspaces:write; owner/admin), and instructs to use dropthis_workspaces to find the workspace id. It also clarifies that at least one of `name` or `slug` is required. However, it does not explicitly list when not to use this tool or differentiate from alternative tools like dropthis_update_settings, so it stops 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 key behaviors: owner-scoping, pass-through of drop_… ids, and the conceptual distinction between locators and identifiers with drift risk. These go well beyond annotations and provide actionable behavioral context without contradiction.

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 front-loaded with the core purpose and organized into distinct, non-redundant segments: purpose, scoping, usage, input variants, and best practice. Every sentence earns its place, and the structure makes 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?

Given the single parameter, existing annotations, and output schema, the description covers all essential aspects: input forms, scope, output contents, related tools, and error behavior ('returns no match'). It leaves no important behavior unexplained.

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?

Even though the schema already covers the parameter, the description adds meaningful context by explaining that URLs/slugs are locators that can drift while the id is stable, and that the tool accepts a drop_… id and passes it straight through. This enriches the raw schema definition.

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 a specific verb ('resolve') and resource ('a drop's public URL or slug') and explicitly states the output ('the drop itself, including its drop_… id'). It also distinguishes itself from siblings by framing the tool as the required first step for editing tools that need the id.

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 explicit usage instructions: 'resolve here, then call dropthis_update_content / dropthis_update_settings / dropthis_delete with the returned id.' It also clarifies owner-scoping and that unknown or foreign URLs return no match, effectively telling users when not to expect a result.

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?

It discloses key behaviors beyond the annotations: it mints a NEW deployment rather than mutating the old one, URL/settings are unchanged, restoring the current deployment is a no-op, and below Pro it returns a 403 with upgrade_url. The return value (updated parent drop with bumped revision) is also specified, providing a complete behavioral picture.

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 well-organized and front-loaded: it opens with the core action, then explains the mechanism, key caveats, usage preference, requirements, and return value. Despite a moderate length, every sentence contributes meaningful information without repetition or 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?

Given the tool's complexity (version-history rollback, Pro gating, no-op behavior, and reliance on other tools for input resolution), the description covers everything needed for correct invocation: purpose, exact behavior, prerequisites, error handling, and return information. The presence of an output schema further reduces the need to describe return values in detail.

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 already provides detailed descriptions for both parameters (100% coverage), so the baseline is 3. The description adds extra value by tying deployment_id to dropthis_list_deployments, stressing that drop_id must be id-only and referencing dropthis_resolve for URL/slug resolution, which enriches the semantic understanding beyond the 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 states the tool's function: rolling a drop back to a prior deployment's content. It distinguishes itself from siblings by explicitly naming the alternative (reading an old version with dropthis_get_content and re-publishing) and positioning itself as the first-class rollback path, making its unique purpose unambiguous.

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 usage guidance: use this for version-history rollback, prefer it over the manual alternative, and note the prerequisites (Pro plan, drop_id must be id-only, deployment_id from dropthis_list_deployments). It also mentions the error below Pro, which signals when the tool cannot be used.

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?

Annotation contradiction: the annotations declare destructiveHint:false, but the description explicitly says mode:'replace' makes the files you send become the whole drop and 'everything else is dropped' — clearly destructive to existing content. The description otherwise provides rich behavioral context (patch-by-default, delete_paths, idempotency, image optimization), but per scoring rules the contradiction forces a score of 1.

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 long but front-loaded with the most critical information (purpose, patch default, alternatives) and is well-structured. Some repetition exists (the files[] schema description repeats the patch/replace semantics) but the density of novel guidance justifies the length.

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 complex tool with 14 parameters, the description covers all key operational aspects: purpose, when to use, mode semantics, deletion, idempotency, image optimization, and sibling tool routing. It also addresses dependencies (drop_id resolution) and exclusions (doesn't change settings). Since an output schema exists, return-value documentation is not needed.

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, but the description adds substantial param semantics beyond the schema: exactly one of content/files/file/paths/source_url must be provided, drop_id is id-only requiring dropthis_resolve, delete_paths is patch-only and invalid in replace mode, optimize is on by default with warnings disclosure, and idempotency_key prevents duplicate deploys. These enrich parameter understanding significantly.

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+resource: 'Update the content of an EXISTING drop, keeping its current URL (ships a new deployment).' It also distinguishes from siblings by explicitly saying 'for title/visibility/password/expiry/metadata use dropthis_update_settings, and to create a brand-new drop use dropthis_publish.' This fully differentiates the 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?

It gives precise usage context: 'Use when the user edited, changed, regenerated, or wants to update the page and the URL should stay the same.' It also states exclusions and alternatives, including pointing to dropthis_publish and dropthis_update_settings, and the requirement to resolve a URL/slug via dropthis_resolve first. The mode guidance (patch default vs replace) further clarifies when to use each variant.

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 annotations by disclosing the high-impact side effect: setting role=owner transfers ownership of the workspace, requiring confirm=true. It also mentions the credential requirement and server-side enforcement, adding valuable behavioral context not present in the 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 well-structured and front-loaded with the primary action. It uses three informative sentences without redundancy. It could be slightly more compact, but each sentence adds necessary detail for a high-impact operation.

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 4 parameters, an output schema, and sensitive ownership-transfer behavior, the description covers all critical aspects: purpose, required permissions, ownership transfer semantics, and confirm requirement. It is complete enough for an agent to select and invoke the 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?

Although the schema already covers all parameters (100% coverage), the description enriches meaning by explaining that role=owner is an ownership transfer and that confirm must be true for that case. It also clarifies the source/context for workspace and account_id, improving understanding beyond the schema descriptions alone.

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 'Change' with a specific resource 'a workspace member's role' and enumerates the allowed values (owner, admin, member). It also specifies the key identifiers (workspace id and accountId), distinguishing it from sibling tools like remove/invite member.

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 the tool is appropriate by stating the required team-scoped credential (members:admin) and the server-side rule that only an owner may modify an owner. While it doesn't explicitly contrast with alternatives, the constraints and the clear purpose imply correct usage.

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 idempotentHint=true and destructiveHint=false, and the description reinforces this with 'Idempotent — applying the same values again is a no-op.' It adds useful behavioral context beyond the annotations: the operation 'does not touch the content at the URL' and requires a `drop_…` id, both of which help avoid misuse.

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 yet information-dense: four sentences cover purpose, scope, sibling differentiation, prerequisites, and idempotency. Every sentence earns its place and the most important 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?

Given the tool's complexity (9 parameters, nested metadata object, output schema), the description is complete: it explains what is updated, what is not touched, how to get the required id, and how it differs from related tools. The output schema exists, so return-value details are not needed in the description.

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 lists the fields and mentions routing (custom domain/shared pool, slug rename), but does not add substantial meaning beyond the already-detailed schema descriptions of each parameter.

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 'Change an EXISTING drop's settings' — a specific verb, resource, and scope — and enumerates exactly which settings (title, visibility, password, noindex, expiry, metadata, routing). It also distinguishes itself from siblings by explicitly naming dropthis_update_content for content replacement and dropthis_publish for creation.

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 explicit when-to-use guidance: it is for updating settings, not content, and points to dropthis_update_content and dropthis_publish as alternatives. It also tells users to call dropthis_resolve first when they only have a public URL or slug, which is clear prerequisite context.

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 include idempotentHint and destructiveHint, but the description adds valuable behavioral context: the switch persists server-side across reconnects and affects subsequent publish operations. This goes beyond the structured hints.

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 purpose, then consequences and guidance. Zero filler; 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 one-parameter tool with an output schema, the description covers purpose, side effects, persistence, and pre-requisite listing. Complete for an agent 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?

The single parameter 'workspace' is fully described in the schema (slug or id). The description adds a hint to list workspaces first, but doesn't add new parameter-level details; baseline 3 due to high schema coverage.

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 ('Switch') and resource ('active team/workspace'), clearly distinguishing it from sibling tools like dropthis_workspaces (list) or dropthis_create_workspace. It unambiguously states the tool's function.

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 to list workspaces first via dropthis_workspaces, and explains when switching matters ('Subsequent publishes land in it'). This provides clear context for when to use this tool versus alternatives.

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 does not need to restate that. It adds useful context by explaining that only workspaces the connection can act in are listed and that the active one is flagged. It also hints at the session-scoped nature of the active workspace, which goes beyond the bare annotation without contradicting it.

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 serving a distinct purpose: stating the core function, pointing to an alternative, and offering usage guidance. It is slightly dense in the final sentence but contains 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?

Given the tool's simplicity (no parameters, one output schema with the isActive flag), the description is remarkably complete. It not only explains what the tool does, but also integrates it into the broader workflow of switching workspaces and publishing, which is more than sufficient for an agent to use it 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 tool has zero parameters, and the schema is trivially 100% covered. Per the rubric, the baseline for 0 params is 4, and there is nothing for the description to clarify about parameters. The description does not add parameter-specific detail, but none 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 opens with a specific verb 'List' and a clear resource 'workspaces (teams)', and it adds the distinctive behavior of flagging the active workspace via `isActive`. This clearly distinguishes it from siblings like dropthis_account and dropthis_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?

It explicitly names dropthis_account as an alternative for viewing the active workspace on the current session, and provides conditional guidance for publishing into non-active workspaces using dropthis_use_workspace or passing a workspace to dropthis_publish. This gives the agent concrete when-to-use and when-to-use-another-tool directives.

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