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

The description states that the tool returns account info and lists the specific fields. It does not explicitly mention side effects, but the annotations indicate readOnlyHint and idempotentHint, which are consistent with a read operation. The behavior is generally transparent.

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

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

The description is concise, consisting of two sentences that convey the purpose and usage. It is focused and free of unnecessary detail, making it easy to read and understand.

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

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

Given that there is no output schema, the description adequately explains what the tool returns (accountId, apiUrl, downloadUrl). It also provides context on how authorization is handled. There is no missing essential information for an agent to use this tool correctly.

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

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

The input schema is empty ({}), so there are no parameters to describe. The description does not add any parameter information, but since there are none, this is fully appropriate. Schema coverage is 100% with no gaps.

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: authorize with B2 and return account info including accountId, apiUrl, and downloadUrl. It specifies the action and the output, leaving no ambiguity about what the tool does.

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

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

The description provides guidance on when to use the tool: it notes that the server handles authorization automatically, but the tool is useful for verifying credentials and retrieving account details. It doesn't explicitly mention alternatives, but the context is clear enough.

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

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

Beyond the annotations, the description adds important behavioral context: bucket names are globally unique, duplicate-name requests fail with an error instead of returning the existing bucket, and the existing bucket may only be reused if it belongs to the caller's own account. It also discloses the required writeBuckets permission and the persistent nature of the created bucket. 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 front-loaded with the core purpose and then routes to alternatives. It is somewhat longer than necessary because the bucket-name character rules partly repeat the schema's bucketName description, but the duplicate-name behavior and reuse guidance justify the third sentence. Overall it is economical and well-structured.

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

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

For a complex 7-parameter creation tool with nested objects and no output schema, the description covers the key operational concerns: when to use it, required permission, alternatives, naming constraints, and duplicate-name behavior. It does not describe the success response format, but the rich schema compensates for most gaps.

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

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

Schema description coverage is 100%, so the schema already documents parameters in detail. The description adds value by explaining global uniqueness, duplicate-name failure semantics, and permission requirements beyond the schema. It does not deeply explain every optional parameter, but the schema covers those, so this is more than the baseline.

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 starts with a specific verb and resource: 'Create a persistent B2 bucket', and enumerates the optional capabilities (metadata, CORS, lifecycle, encryption, Object Lock). It also distinguishes itself from siblings by naming b2_update_bucket for later changes and s3_head_bucket for S3 reachability, so an agent can tell them apart.

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

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

The description explicitly states when to use this tool: 'initial provisioning with a key that has writeBuckets'. It also names the alternatives and their conditions: b2_update_bucket for later settings changes and s3_head_bucket for S3 reachability. It even gives conditional guidance for duplicate-name scenarios, which is actionable and complete.

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

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

Beyond the annotations (destructiveHint, openWorldHint), the description discloses critical runtime behavior: secret handling differs by mode. It explains that file sink mode writes the one-time application key secret out-of-band and returns only redacted metadata plus a secretSink pointer, while inline mode returns the secret with an explicit warning. This is valuable, non-obvious behavior that annotations alone do not convey.

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

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

The description is compact and front-loaded with the primary action, then efficiently explains the two secret-handling modes. Every sentence adds necessary information, and there is no filler or repetition of schema fields.

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 essential outcome, the secret-handling modes, and the response shape despite lacking an output schema. It leaves minor details such as failure behavior and billing implications unstated, but the schema and annotations fill most remaining gaps. Overall it is complete enough 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?

Schema description coverage is 100%, so the input schema already documents all parameters including adminAccountId, groupId, memberEmail, idempotencyKey, region, and confirm. The description adds context about the generated one-time application key but does not add parameter-level meaning beyond 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: 'Create a Backblaze account for a new Partner group member.' This clearly identifies the operation and distinguishes it from sibling tools like b2_eject_group_member or b2_reserve_trial_create_account. The account creation intent 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 gives clear context for when the tool applies: when a new Partner group member account must be created. It does not explicitly name alternatives or exclusions, but the context is specific enough that an agent can route to this tool for group-member creation versus other create/eject 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 mark the tool as destructive and non-idempotent, but the description adds substantial context: the one-time secret handling, file-sink versus inline output modes, idempotency requirements, destructive confirmation by policy, and environment-override restrictions. This goes well beyond the structured 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 earns its place: purpose, usage routing, output behavior, and policy constraints. The main action is front-loaded, and there is no redundant restatement of the tool name or schema fields.

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

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

For an 8-parameter, side-effectful creation tool with no output schema, the description covers the critical non-obvious behavior: secret sink routing, redacted metadata versus inline secret, and policy-driven refusals. Combined with the fully documented input schema, an agent has enough to call the tool correctly in most scenarios.

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 detailed per-parameter descriptions, so the baseline is 3. The description adds value by highlighting idempotencyKey as a requirement, the policy refusal of key-management/unscoped grants, and the B2_MAX_KEY_DURATION_SECONDS constraint that affects validDurationInSeconds and omission semantics.

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

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

The description states a precise verb and resource: 'Create a B2 application key' and adds the specific behavior of routing the one-time secret through a secret sink. It is clearly distinguishable from sibling tools like b2_list_keys and b2_delete_key by naming them as complementary operations.

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 to use this tool for least-privilege scoped credentials and names the sibling tools for inspecting and revoking keys. It also gives policy-based constraints on when grants are refused, giving an agent clear routing and precondition guidance.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds the key behavioral constraint that the bucket must be empty before deletion, which is not encoded in the annotations or schema. It does not discuss irreversibility in prose, but the schema's confirm parameter already covers that aspect.

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 short sentences with no filler. The core action and the essential precondition are stated directly and upfront, making it easy for an agent to parse.

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

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

For a simple destructive tool with full schema coverage and destructive annotations, the description includes the one non-obvious operational requirement: the bucket must be empty. It does not describe the failure mode for a non-empty bucket, but that is reasonably inferable from the stated precondition.

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

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

Schema description coverage is 100%, so the schema already documents both bucketId and confirm thoroughly. The description adds no parameter-level meaning beyond the empty-bucket precondition, which is an operation-level constraint rather than a parameter detail.

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: 'Delete a B2 bucket.' It also adds the critical prerequisite about emptiness, which helps an agent understand the operation's scope and distinguishes it from siblings like b2_update_bucket or b2_delete_key.

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

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

The description clearly states when the tool is usable: only when the bucket is empty, and it explicitly says files and file versions must be deleted first. It does not name alternative tools or say when to prefer them, but the precondition provides meaningful 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?

Annotations already indicate destructiveHint and readOnlyHint=false, and the description adds valuable behavioral context: the key secret cannot be recovered, dependent systems lose access immediately, and deleteKeys permission plus destructive confirmation are required. This goes beyond the structured hints and informs the agent of irreversible external impact.

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

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

Three sentences with no filler: the first states the action, the second provides the prerequisite workflow and alternatives, and the third explains consequences and requirements. Every sentence earns its place and the most important warning 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?

For a destructive delete operation with no output schema, the description is complete enough: it covers prerequisites, permission requirements, the irreversible nature of the action, and immediate impact on dependents. Combined with the detailed parameter schemas and annotations, an agent has everything needed to invoke this tool safely.

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 descriptive parameter entries for applicationKeyId and confirm. The description reinforces the source of applicationKeyId via b2_list_keys and clarifies the confirm parameter's role under destructive policy, adding workflow context beyond the raw schema.

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

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

The first sentence states a specific verb and resource: 'Permanently delete a B2 application key.' This clearly distinguishes the tool from sibling operations like b2_delete_bucket or s3_delete_object by naming the exact resource type and the destructive nature of the action.

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 workflow guidance: use b2_list_keys first to verify the applicationKeyId and dependencies, and use b2_create_key before deletion when rotating credentials. It also states the permission requirement and policy confirmation, so an agent knows both prerequisites and recommended 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 already marking the call destructive, the description reveals meaningful consequences: the account is not deleted, the member resets their password at next login, and the change is irreversible through the API. The 'cannot be re-added via API' warning is exactly the kind of behavioral context annotations cannot convey.

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

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

Three short sentences front-load the core action and then add high-value caveats: no account deletion, password reset, optional email change, and API re-add restriction. There is no filler or repetition of schema content.

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 operation with no output schema, the description covers what the agent most needs to know: outcome scope, side effects, optional behavior, and irreversibility. Combined with comprehensive parameter schemas and annotations, nothing critical is missing 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?

Schema description coverage is 100%, so the input schema already documents every parameter, including the meaning and constraints for email, confirm, groupId, adminAccountId, and memberAccountId. The description adds only the small clarification that email change is optional on eject, which does not lift it above the baseline.

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, 'Eject a member from a Group,' and immediately clarifies the scope by stating the account is NOT deleted, only removed. This distinguishes the operation from general account deletion and from the sibling create/list group member 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 makes the usage context clear: use this to remove a group member, with the caveat that the saved account remains and the member must reset their password. It also warns that re-adding via API is impossible, giving an implicit when-not-to-use signal, though it does not explicitly name alternatives such as b2_create_group_member.

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, idempotentHint, and destructiveHint, but the description adds valuable behavioral context beyond them: required permissions (readBucketNotifications or writeBucketNotifications), explicit 'no side effects', and redaction of sensitive webhook fields in the MCP response. This is meaningful transparency not available from structured fields alone.

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

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

Three sentences, front-loaded with the core purpose, and every sentence adds value: usage context, authorization, side effects, and response redaction. There is no redundant or filler wording.

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

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

Given the tool's low complexity (one parameter, no output schema), the description covers everything an agent needs: what it does, when to use it, required permissions, safety profile, and sensitive data redaction behavior. Nothing essential is missing.

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

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

Schema description coverage is 100% and the single bucketId parameter is already well documented ('Exact bucket ID whose notification rules should be read'). The description does not need to add parameter detail, so the 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 states a specific verb ('Read'), a specific resource ('B2 event-notification webhook rules for a bucket'), and explicitly distinguishes this tool from its sibling b2_set_bucket_notification_rules. An agent can immediately understand what the tool does and which sibling it complements.

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 to use this tool before b2_set_bucket_notification_rules to diff or preserve existing rules, because the set operation replaces the complete rule set. This gives clear when-to-use guidance and names the natural alternative, earning full credit.

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

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

The annotations already provide readOnlyHint and openWorldHint, indicating a safe, non-destructive operation. The description adds valuable behavioral details beyond the annotations: it explicitly states that requests are automatically narrowed to authorized bucket IDs when bucket-scoped, that results are truncated if exceeding the limit, and it describes the return fields (ID, name, type, CORS rules, lifecycle rules). This enhances transparency beyond what the annotations alone convey, though it does not fully describe edge cases like error handling.

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 moderately concise, but it is well-structured with two main sentences: one stating the core action and filters, another explaining the cap and truncation. It front-loads the primary purpose and includes necessary details without excessive verbosity. It could be slightly tightened (e.g., merging repeated 'filter' mentions), but it remains clear and efficient.

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

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

Given that there is no output schema, the description compensates by explicitly listing the returned fields (ID, name, type, CORS rules, lifecycle rules). It also covers important context such as the automatic authorization narrowing and the truncation behavior, which are essential for a user to understand the tool's behavior in a real-world B2 account scenario. The description is complete for the complexity of a simple list operation.

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 descriptions for all four parameters with 100% coverage, including default values and enums for bucketTypes. The description reinforces these by explaining the purpose of the limit (to keep response small) and the consequence of exceeding it (truncation with a note). This adds semantic value, particularly around the limit parameter, going slightly beyond the schema's own descriptions.

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

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

The description clearly states the tool lists B2 buckets for the authorized account, using a specific verb ('List') and resource ('B2 buckets'). It distinguishes itself from other list tools by mentioning optional filters (by bucket ID, name, or type) and the automatic narrowing to authorized bucket IDs when bucket-scoped. This makes its purpose unambiguous and distinct from 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 context on when to use the tool: it is the primary listing operation, and it explains that the response is capped and how to handle truncation (raise the limit or add filters). While it does not explicitly mention alternative tools (e.g., b2_list_keys or s3_list_objects_v2), the context is clear enough for typical usage. It falls just short of explicit 'when-not-to-use' guidance, hence a 4.

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, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds value by disclosing pagination limits (up to 1,000 per call), the use of nextEmail for continuation, and that storage stats per member are included. These details go beyond annotations and help the agent understand response volume and pagination flow. 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 two sentences with no filler. The core purpose is front-loaded, followed by essential behavioral details (pagination limit and response content). Every word earns its place; it is compact and well-structured.

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

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

For a read-only list operation with no output schema, the description provides sufficient context: it defines the resource scope, pagination mechanism, and return content (members with storage stats). It does not enumerate member fields, but that is not essential for invocation. Combined with annotations covering safety, the description is complete enough for correct use.

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% (all 4 parameters have descriptions). The description does not add new semantic meaning beyond the schema—it restates pagination and the 1,000 limit, which are already in parameter descriptions (maxMemberCount maximum and startEmail as cursor). With high schema coverage, baseline 3 is appropriate; no additional parameter context is provided.

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 specific verb ('List'), resource ('Group members'), and scope ('for a specific Group'). It also specifies the active (ACCEPTED) state, distinguishing it from siblings like b2_list_groups (lists groups) and b2_create_group_member (adds a member). The tool's purpose is unambiguous and clearly differentiated.

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

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

The description implies usage context by stating it lists accepted members for a specific group, and mentions pagination behavior. However, it does not explicitly name alternatives or state when not to use this tool versus others like b2_list_groups. There is no explicit when/when-not guidance, though the purpose is clear enough for basic selection.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral detail beyond that: it specifies a 100-group limit, pagination via nextGroupId, and the authorization requirement. These are not in the annotations and help the agent understand expected behavior.

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

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

Two sentences with zero wasted words. The main action is front-loaded, and the critical details (limit, pagination, authorization) are included without redundancy. It is a model of efficient writing.

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

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

For a simple list operation with no output schema, the description covers the key points: the scope ('active Groups'), the cap and pagination mechanism, and a prerequisite (authorization). It does not describe the response shape, but that is a minor gap given the tool's simplicity and the presence of a pagination hint.

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 all four parameters are already documented. The description's mention of 'Returns up to 100 groups' and 'use nextGroupId for pagination' loosely relates to maxGroupCount and startGroupId but does not add new semantic meaning beyond the schema. Per the rubric, a baseline of 3 is appropriate when the schema carries the full burden.

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

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

The description uses a specific verb ('List') and a clear resource ('active Groups'), and adds the qualifier 'administered by a Group admin account,' which distinguishes it from sibling tools like b2_list_group_members (which lists members) and b2_list_buckets. It is unambiguous and immediately conveys the tool's core 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?

The description states the required context (Group admin account, Partner API authorization) and implies the tool is for listing groups, but it does not explicitly name alternatives or state when not to use it. The distinction from b2_list_group_members is inferable but not spelled out, so guidance is present but not exhaustive.

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 establish read-only, idempotent, and non-destructive behavior. The description adds valuable behavioral context by explicitly stating that key secrets are not returned and exactly which fields are included (IDs, names, capabilities, restrictions). This goes beyond the schema and informs the agent about data sensitivity.

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

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

Two concise sentences with zero redundancy. The primary purpose is front-loaded, and the important caveat about key secrets is placed immediately after, giving the agent the most decision-relevant information efficiently.

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 straightforward list tool with no required parameters, the description covers the key details: what is listed, what is returned, and what is deliberately excluded. Pagination mechanics are handled by the schema's parameter descriptions, so nothing critical is missing.

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

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

Schema description coverage is 100%, with both maxKeyCount and startApplicationKeyId fully described in the schema itself. The description adds no additional parameter-level detail, but the schema already provides sufficient semantics for correct invocation.

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 ('application keys associated with the B2 account'), making the tool's function immediately clear. It also distinguishes itself from sibling tools like b2_create_key and b2_delete_key by focusing on listing rather than mutation.

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

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

The description clearly identifies this as a listing operation for application keys, which gives the agent enough context to select it over creation or deletion siblings. It does not explicitly state 'use this instead of X', but the read-only listing intent and the security-focused caveat provide clear situational 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 already mark the tool as read-only and idempotent. The description adds non-obvious behavior beyond that: the scan is bounded by max_scan and a time budget, results may come back as truncated=true, and the tool returns only name/size/upload time, never contents. This is excellent disclosure of live-listing behavior.

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

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

Four sentences with a clear progression: purpose, intended queries, caveat and workaround, return contract. Every sentence adds useful information and there is no filler or restatement of the tool name.

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

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

For a read-only listing tool with fully documented parameters and annotations covering safety, the description supplies the missing output details (name, size, upload time, never contents) and the truncation caveat. An agent has everything needed 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?

Schema coverage is 100%, so the baseline is 3. The description adds meaning by noting bucket accepts a name or bucketId, explaining that prefix can focus on a subtree for a complete ranking, and tying max_scan to the truncation behavior. Only the limit parameter is left entirely to 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 opens with a specific verb and resource: 'List a bucket's largest objects by size'. It also gives natural-language triggers ('largest files', 'what's taking up space') and closes with a clear boundary ('never contents'), so an agent can distinguish this from listing buckets or fetching object content.

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 contexts for use, including quoted user intents, and provides a prefix-based strategy for large buckets. It does not explicitly name a sibling alternative or state when not to use it, but no close sibling exists for this capability, so the guidance is strong.

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 readOnly/idempotent annotations, the description adds meaningful behavioral context: it relies on daily usage reports, defaults to month-to-date, returns shares of total egress, scopes to the caller's key, and explicitly requires Usage Reports to be enabled. This is exactly the kind of operational detail an agent needs.

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

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

The description is compact and front-loaded with the core action and resource, then delivers use cases, output semantics, scoping, and a prerequisite. Every sentence contributes useful information with no filler or redundancy.

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

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

For a simple read-only ranking tool with no required parameters and no output schema, the description covers the source data, default window, result content, scope, and prerequisite. It could be slightly stronger by describing the exact response fields or ordering, but nothing essential is missing for a 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?

Schema description coverage is 100%, so the schema already fully documents by, days, and limit. The description mostly restates what the schema says, such as ranking by account or bucket and month-to-date defaults, and does not add substantial parameter-level meaning 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 uses a specific verb-resource pairing: rank top egress leaders by account or bucket over a period. It also describes the exact use cases ('who's downloading the most', 'where is egress concentrated'), which makes it easy to distinguish from sibling reporting tools like b2_report_usage_growth.

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

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

The description provides clear context for when to use the tool through intended questions and prerequisites like needing Usage Reports enabled. It does not explicitly name an alternative or when-not-to-use condition, but the use cases are specific enough that an agent can select it appropriately among the 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?

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial behavior beyond that: it fetches only the two compared snapshots for speed, returns the two dates plus per-account start/current GB and % growth, flags new accounts, scopes by the caller's key, and requires Usage Reports enabled. Nothing contradicts 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?

Five dense sentences, front-loaded with the core purpose; each sentence earns its place (purpose, use-cases, mechanism/efficiency, output shape, scope+precondition). No filler and no repetition of what the schema already states.

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

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

With no output schema, the description supplies the needed return-shape info (dates compared, per-account start vs current GB, % growth, new-account flag). It also covers the prerequisite, scope, data source, and performance behavior, so an agent can select and invoke the tool correctly with no gaps.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns a 4 by giving the period/days parameters operational meaning — the comparison against 'one month/quarter/year earlier' using end-of-day stored_gb snapshots and the 'fetches only those two days' performance rationale — context the schema's per-parameter descriptions don't provide.

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

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

States a specific verb+resource ('Rank accounts by how much STORED data grew or shrank between two points in time') and names its data source (daily B2 usage reports, stored_gb end-of-day snapshot). The example queries ('which customers grew the most/least', 'who's moving data off') make its niche unmistakable, and it is clearly distinguished from sibling b2_rank_egress_leaders, which ranks by egress rather than stored-data growth.

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

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

Gives explicit use-case phrasing ('For "which customers grew the most/least", "who's moving data off"'), a hard precondition ('Needs Usage Reports enabled'), and scope semantics ('Scope follows the caller's key'). However, it never names an alternative tool or states a when-not condition, so it stops just short of a 5.

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

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

Annotations already flag destructive=true and idempotent=false, but the description adds crucial context: the operation is billable, irreversible, gated by the destructive-operation confirmation, has no provider-side recovery path in file-sink mode, and the minted key is shown only once. It also explains that idempotencyKey will not prevent duplicate accounts, which directly elaborates on the idempotentHint=false 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?

Five focused sentences, each carrying essential operational or routing information. Critical caveats are front-loaded: purpose, return value, prerequisites, irreversibility, secret-sink constraint, retry behavior, and alternative tool. No filler or repetition.

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

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

For a complex, destructive, no-output-schema tool, the description covers prerequisites, side effects, retry semantics, secret handling, and the alternative pathway. It also names the return value (durable application key). Combined with 100% schema parameter coverage, an agent has enough context to invoke this tool correctly and avoid dangerous duplicate provisioning.

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 of 3 applies. The description reinforces the idempotencyKey caveat already documented in the schema, but it does not add new meaning to email, term, storage, region, or confirm beyond what the property descriptions already provide.

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

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

States a specific verb ('Reserve and create') plus the exact resource ('B2 Reserve trial account through the Partner API') and the key output (a durable application key). The final sentence also distinguishes it from b2_create_group_member, so an agent can tell this tool apart from its closest sibling.

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 this tool (standalone trial provisioning) and names the alternative (b2_create_group_member) for adding an account to an existing Partner group. It also gives prerequisites (Partner-entitled master key), operational constraints (inline secret-sink mode only), and retry guidance (verify before retrying), leaving little to inference.

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

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

Beyond the annotations (destructiveHint=true, readOnlyHint=false), the description adds meaningful behavioral context: confirmation is enforced by policy, webhook URLs are validated for public HTTPS reachability, and echoed URL details, HMAC secrets, and custom-header values are redacted from the response. These behaviors are not derivable from annotations and materially shape agent expectations. The description is consistent with all annotations, so no 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?

Three sentences, each earning its place: the first states the core action, the second gives the read-first workflow and the patch/append warning, and the third discloses permissions, confirmation, URL validation, and response redaction. Critical information is front-loaded and there is zero 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 write tool with no output schema, the description covers everything an agent needs to invoke it correctly: full-replace semantics, the prerequisite read call, permission and confirmation requirements, URL validation, and response redaction behavior. The schema fully documents all three parameters, so no material gap remains.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by reinforcing the semantics of eventNotificationRules as a complete desired set ('submit the full desired rule set; this is not a patch or append API'), which tells the agent that omitting a rule deletes it and that a read-first call is required to assemble the payload. The URL-publicity and redaction notes also echo and reinforce the schema's url and secret parameter descriptions.

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

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

The description opens with a specific verb and resource: 'Replace the complete B2 event-notification webhook rule set for a bucket.' It clearly differentiates from the read sibling b2_get_bucket_notification_rules by emphasizing this is a full replacement, not a patch or append API, so an agent can select it correctly without opening the schema.

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

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

It explicitly prescribes the workflow ('Use b2_get_bucket_notification_rules first and submit the full desired rule set') and names the exclusion condition ('this is not a patch or append API'), so the agent knows partial edits are out of scope. It also states the required permission (writeBucketNotifications) and the destructive-confirmation precondition, leaving no ambiguity about when this tool applies.

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 readOnly, idempotent, and non-destructive behavior, so the baseline burden is lower. The description adds meaningful behavior beyond annotations: it is a live listing bounded by max_uploads and an internal time budget, may truncate results on bloated buckets, and wasted_gb may be a lower bound. It also discloses that the tool recommends a lifecycle rule.

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

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

Three sentences with no filler: use case, return metrics, invocation, and truncation caveat are each given distinct content. The most important scoping 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?

Even without an output schema, the description tells the agent what will be returned: count, oldest upload age, and wasted bytes. It also covers the key failure mode and mitigation recommendation. Combined with rich annotations, this is complete enough for correct invocation and result interpretation.

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

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

Schema description coverage is 100%, so the schema already documents all parameters little parameter-level meaning beyond restating that the bucket can be given by name or bucketId, which duplicates the schema. 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 states a specific verb and resource: 'Find abandoned multipart uploads that silently consume storage in a bucket.' It also includes use-case keywords like 'bucket bloat' and 'wasted storage', which help distinguish it from generic listing tools such as s3_list_multipart_uploads and from size-focused siblings like b2_largest_files.

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

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

The description gives clear invocation contexts: 'bucket bloat', 'stuck/incomplete uploads', and 'wasted storage'. It does not explicitly name alternative tools or state when not to use this tool, so it stops short of full exclusionary guidance.

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

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

Annotations already carry readOnlyHint=false and destructiveHint=true; the description adds value beyond them by naming the required capability (writeBuckets), enumerating the confirmation-gated cases (bucketType allPublic, fileLockEnabled false, defaultRetention.mode null, lifecycleRules with daysFromHidingToDeleting, replicationConfiguration updates), and flagging that delete-rule lifecycle updates are destructive in effect. No contradiction with 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?

A single dense paragraph, front-loaded with purpose, followed by capability, precondition, alternative routing, and gated cases. Every clause carries distinct information, and nothing in the description repeats what the schema already documents.

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

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

For an 11-parameter, confirmation-gated, destructive mutation tool with no output schema, the description covers capability requirements, precondition workflow, gated cases, and sibling differentiation — most of what an agent needs before invoking. The remaining gap is the response shape on success (e.g., updated bucket object and changed revision value), which would strengthen ifRevisionIs retry logic.

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 of 3 applies and the schema does the heavy lifting. The description adds only light operational context for two parameters (bucketId must be the exact ID, ifRevisionIs enables safer retries), which is useful but not new semantic meaning 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 opens with a specific verb and resource — 'Update persistent settings on an existing B2 bucket' — and enumerates the scope (visibility, metadata, CORS, lifecycle, default encryption, replication, Object Lock, default retention). This cleanly distinguishes it from siblings like b2_create_bucket, b2_delete_bucket, and s3_put_bucket_lifecycle without requiring schema inspection.

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 an explicit precondition ('Use b2_list_buckets first to inspect the current bucketId/revision'), a safer retry pattern via ifRevisionIs, and a named alternative with a selection condition ('use s3_put_bucket_lifecycle only when you specifically need the S3 lifecycle API shape'). When-to-use, when-not-to-use, and alternatives are all spelled out.

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

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

Beyond the annotations, which already flag this as destructive, the description adds meaningful behavior: active legal hold overrides retention-based deletion protections, and the operation requires a specific application-key capability. It accurately describes setting and clearing without contradicting the destructiveHint or idempotentHint annotations.

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

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

Three sentences, each earning its place: the first states the action, the second the behavioral consequence, and the third the authorization prerequisite. There is no redundancy or filler.

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

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

The description plus the rich schema covers the operation, its effect, the required capability, and the confirm fallback for destructive policy. It does not explain return values, but there is no output schema, and the main remaining gap is that it does not explicitly name b2_update_file_retention as the alternative when retention, rather than legal hold, is the goal.

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 even though the main description does not add parameter-level details. The description's 'regardless of retention settings' provides functional context for the legalHold parameter, but it does not need to explain syntax because the schema already documents the enum and the bare-string requirement.

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 and resource: 'Set or clear a legal hold on a specific file version in B2.' It also explains the practical effect—'the file cannot be deleted regardless of retention settings'—which distinguishes it from retention-focused sibling tools like b2_update_file_retention.

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

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

The description gives clear context for when this tool is relevant: managing legal holds that prevent deletion, and it names the required capability 'writeFileLegalHolds.' It does not explicitly name alternatives or exclusions, but the contrast with 'retention settings' implies when the retention tool would be the different choice.

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, readOnlyHint=false, and idempotentHint=true. The description adds meaningful behavioral context beyond annotations: the capability requirement, the compliance-mode extension-only rule, and the condition that clearing only works in governance mode with bypassGovernance. This gives the agent a clearer safety/behavior model 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 is three purposeful sentences: the primary action, the supported modes, and the critical constraint plus capability requirement. It is front-loaded and contains no filler or redundant restatement of the tool name.

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 nested fileRetention object, the confirm flag, and no output schema, the description plus schema covers what an agent needs to invoke this correctly: required parameters, mode semantics, capability requirements, and destructive implications. A return-shape note would be nice but is not essential for a mutating update tool.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters, including the nested fileRetention object. The tool description itself adds little parameter-level detail beyond naming the modes and capability. Baseline 3 is appropriate because the schema carries the parameter semantic burden.

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

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

The description opens with a specific verb and resource: 'Set or modify the retention policy on a specific file version in B2.' It names the two retention modes and clearly differentiates this from the sibling b2_update_file_legal_hold, whose subject is legal hold rather than retention.

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 operational constraints: governance vs compliance modes, compliance retention can only be extended, clearing requires governance mode, and the writeFileRetentions capability is required. It does not explicitly name alternatives or say 'use X instead,' but the context is sufficient for an agent to decide when this tool applies.

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 destructiveHint=true and readOnlyHint=false, so the description's core safety profile is covered. The phrase 'release all associated storage' adds a useful consequence, but the description does not elaborate on irreversibility or the idempotent behavior 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?

A single sentence that is direct, front-loaded with the verb and object, and contains no filler or redundant phrasing. It conveys the essential information efficiently.

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 annotations and full schema coverage, the description is largely complete for a destructive operation. It states the primary effect and the annotations cover safety semantics. It does not mention the confirm parameter's fallback behavior, but the schema already describes it, so the description need not repeat it.

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 does not add any parameter-specific meaning beyond what the schema already documents for bucket, key, and uploadId.

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 ('Abort'), the specific resource ('in-progress S3-compatible multipart upload'), and the consequence ('release all associated storage'). It distinguishes this tool from sibling tools like s3_complete_multipart_upload and s3_create_multipart_upload without ambiguity.

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

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

The description implies this tool is for canceling an in-progress upload rather than completing it, but it does not explicitly name alternatives or state when not to use it. The context is clear enough for an agent to infer the primary use case, but explicit routing guidance is missing.

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

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

Beyond the annotations, the description adds meaningful behavioral context: the writeFiles permission requirement, the qualified idempotency condition ('idempotent only when B2 already committed the exact same part list'), and the recovery path if the response is lost. It refines the idempotentHint 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?

Three dense sentences front-load the core purpose and sequential constraints, then cover verification, permission, and failure recovery. Every sentence carries essential operational guidance without 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 complex multipart finalization flow with no output schema, the description covers prerequisites, ordering, verification, permissions, idempotency caveats, and retry reconciliation. This is sufficient for an agent to 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 description coverage is 100%, so the input schema already thoroughly documents bucket, key, uploadId, and parts. The description adds orchestration context around the part manifest but does not need to repeat parameter details; 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 states a specific verb ('Finalize') and resource ('S3-compatible multipart upload in B2'), clarifying it assembles uploaded parts into the final object. It is clearly distinguished from sibling operations like s3_abort_multipart_upload, s3_create_multipart_upload, and s3_list_parts.

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 only after s3_create_multipart_upload and s3_get_presigned_upload_part_url (or s3_upload_part_copy) have produced every required part,' and instructs the agent to verify with s3_list_parts before retrying. It also names reconciliation alternatives (s3_head_object, s3_list_object_versions) for lost responses, leaving little to inference.

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

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

The description adds useful behavioral context beyond the annotations: the acl parameter is called out as a no-op S3 compatibility hint, and B2 access is tied to the destination bucket policy. This helps the agent understand side effects and authorization behavior that the annotations do not convey. There is 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 two sentences with no filler. It front-loads the core operation and scope, then places the important acl caveat and access-policy note. Every sentence earns its place and the structure is easy for an agent 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?

For a 9-parameter tool with full schema coverage and useful annotations, the description is reasonably complete: it clarifies bucket scope and the acl no-op. It does not describe the return value or error behavior, but the absence of an output schema and the schema's thorough parameter documentation keeps this from being a major gap.

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

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

Schema description coverage is 100%, so the schema already documents all parameter meanings. The description repeats the acl no-op behavior that the schema already states, adding no new param-level insight. Baseline 3 is appropriate because the schema does the heavy lifting and the description does not need to compensate.

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 operation: 'Copy an object within B2 or between B2 buckets via B2's S3-compatible CopyObject API.' It names a specific verb, resource, and scope, and the phrase 'CopyObject API' distinguishes it from sibling upload/part-copy tools without requiring schema inspection.

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

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

The description gives clear context for the operation and its cross-bucket scope, but it never explicitly tells the agent when to choose this over alternatives like s3_put_object or s3_upload_part_copy. Usage is implied by the semantics of 'copy' rather than stated with exclusions or sibling comparisons.

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

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

Annotations already indicate a mutating, non-idempotent operation, and the description adds meaningful behavioral context: it requires the writeFiles capability, accrues storage for uploaded parts, does not reserve or lock the destination key, and explains the consequences of not finalizing or aborting. This goes well beyond the structured 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 earns its place: purpose, lifecycle, concurrency caveat, alternative routing, orchestration flow, and part-number limits are all present. The most important identifying information is front-loaded in the first sentence.

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

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

This is a complex stateful operation with significant side effects, and the description covers prerequisites, follow-up steps, alternatives, concurrency implications, and size constraints. The absence of an output schema is mitigated by explicitly stating that the tool returns an UploadId, and the full lifecycle is 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%, so the schema fully documents all six parameters, meeting the baseline. The description does not add field-level parameter meaning beyond the schema, though it does provide useful context about part size constraints that informs how the multipart flow should be used.

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: 'Initiate an S3-compatible multipart upload for a large object in B2 and return an UploadId.' It clearly distinguishes this tool from siblings by naming the complete/abort counterparts and contrasting it with s3_put_object and presigned URLs.

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: use s3_put_object only for tiny ≤1 MiB payloads, prefer presigned PUT for most transfers, and use multipart for parallel-part uploads or copies. It also lays out the full orchestration flow with sibling tools, leaving no ambiguity about how this step fits.

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

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

Annotations already indicate destructiveHint=true, but the description adds crucial behavioral nuance: omitting versionId can create a delete marker in versioned buckets, while providing versionId permanently removes that version after a native B2 binding check. It also discloses permission requirements beyond the annotation flags, which is highly valuable for a destructive operation.

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 earns its place: core action first, then alternative routing, then permissions, then versioning semantics. It is front-loaded and contains no filler or repetition of schema fields.

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 single-object delete with no output schema, this description is complete: it covers the operation, the aliasing through S3-compatible API, versioning consequences, permission requirements, and the key sibling alternatives. An agent has everything needed to invoke the tool correctly and safely.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema by explaining the behavioral consequences of omitting versus providing versionId, and by tying versionId usage to an additional readFiles permission. This goes beyond simply restating parameter names.

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

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

States a specific verb ('Delete'), a specific resource ('one B2 object'), and the exact interface ('S3-compatible API'). It also distinguishes itself from the sibling tools s3_delete_objects and s3_list_object_versions, so an agent can tell them apart immediately.

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 tells the agent when to use s3_list_object_versions first (targeting a specific version or delete marker) and when to use s3_delete_objects (batches up to 1000). It also states the permission prerequisites for the base operation and for versionId targeting, leaving no ambiguity about invocation 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?

The annotations already mark this as destructive (destructiveHint: true), but the description does not elaborate on permanence, potential failures (e.g., governance restrictions), or the need for confirmation. The bypassGovernance parameter is not mentioned in the description, leaving the agent unaware of conditions that may affect the operation.

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 concise sentence, directly stating the purpose without fluff. It includes the key constraint ('up to 1000 objects') efficiently. No unnecessary words.

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

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

Given the absence of an output schema, the description does not explain return formats, but it adequately covers the tool's core purpose and key operational bound. It does not mention error handling or prerequisites, but these are not critical for the agent's initial selection. The description is sufficiently complete for a simple deletion operation.

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 description covers 100% of parameters, so the baseline is 3. The description adds no additional semantic detail about parameters; it only restates the action. No extra value is provided 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 action: 'Delete multiple objects from a B2 bucket' with a specific bound ('up to 1000 objects'). It distinguishes itself from singular deletion (s3_delete_object) by emphasizing multiple objects and the concurrency bound.

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

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

The description implies usage for bulk deletion ('multiple objects'), but does not explicitly state when to choose this tool over alternatives like s3_delete_object or when not to use it (e.g., for single-object deletion). The concurrency bound is mentioned but not framed as a selection criterion.

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 the tool read-only, idempotent, and non-destructive, lowering the disclosure burden. The description adds useful context about the S3-compatible API and its verification purpose, but does not describe the return payload or failure behavior. This is adequate but not rich.

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

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

Two sentences, front-loaded with the operation and resource, and every clause adds value. The parenthetical and dash clause pack in API family and purpose without any 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 one-parameter, read-only, idempotent tool with complete schema coverage and rich annotations, the description covers the essential context: API family, purpose, and lack of native alternative. It does not explicitly state the return value, but the operation name and purpose make it mostly inferable.

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 a single required bucket parameter, so the schema fully documents the input. The description mentions 'B2 bucket' and 'location constraint' but adds no parameter-level meaning beyond what the schema already provides.

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 opens with a specific verb ('Get') and resource ('region (location constraint) of a B2 bucket'), and distinguishes itself from b2_* siblings by explicitly stating there is no native equivalent. This makes it clearly identifiable among the many S3 and B2 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 a clear use case ('verify region/endpoint pairing') and notes that no native b2_* equivalent exists, guiding the agent away from the b2_* family. It does not explicitly name alternatives like s3_head_bucket, so the guidance is useful but not exhaustive.

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 meaningful behavioral detail beyond the annotations: inline returns base64, saveToPath creates parent directories, partial files are removed on stream failure, and no remote B2 mutation occurs. This is especially valuable because readOnlyHint=false could otherwise leave an agent uncertain about side effects.

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

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

Three dense, purposeful sentences with no filler. The core usage choice is front-loaded, followed by side-effect disclaimers and the alternative routing. 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?

The tool has no output schema, but the description explains the return format for inline reads and the local-path behavior for saveToPath. Combined with full schema coverage for parameters, an agent has everything needed to invoke it correctly, including edge-case cleanup and the alternative for large real data.

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 covers all 5 parameters at 100%, so the baseline is already strong. The description goes further by explaining the practical semantics of saveToPath (local write, parent directory creation, cleanup) and the inline/base64 return behavior, which the schema alone does not convey.

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 and resource: 'Read a SMALL object inline' or stream to a local path, with named use cases (manifests, sidecars, configs). It also distinguishes itself from s3_get_presigned_url, so a selecting agent can tell them apart immediately.

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 inline reads (small objects ≤1 MiB to inspect), when to use saveToPath (any size), and when to use the alternative s3_get_presigned_url for real object data. This gives clear selection criteria without relying on inference.

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

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

Beyond the annotations, the description adds valuable behavioral context: URLs are sensitive bearer capabilities, the response contains expiresIn/expiresAt, the client must capture ETags from PUT responses, and part size constraints apply. This clarifies that the tool itself only mints URLs while the upload happens externally, consistent with openWorldHint=true.

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?

Every sentence earns its place: purpose, alternative routing, security caveat, workflow sequence, and size constraints. The most important scoping information is front-loaded, and the flow is compact but complete.

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

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

The description fully equips an agent to use the tool correctly within the multipart lifecycle: prerequisite create call, direct PUT usage, ETag capture, subsequent complete call, part size limits, and expiry behavior. No output schema exists, but the key response fields are stated.

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 covers all parameters with detailed descriptions (100% coverage), so the baseline is 3. The description adds useful flow context around uploadId and partNumbers, but it does not substantially explain parameter formats 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 opens with a specific verb and resource: 'Generate short-lived presigned PUT URL bearer capabilities for parts of an S3-compatible multipart upload.' It clearly distinguishes itself from s3_get_presigned_url, which is for single-object transfers, so an agent can immediately tell which tool to use.

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: 'Prefer this over s3_get_presigned_url for multipart uploads; use s3_get_presigned_url for single-object PUT/GET transfers.' It also gives the full sequence with related sibling tools and states resumability by minting only missing part numbers.

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?

Even though annotations already mark destructiveHint=true and readOnlyHint=false, the description adds substantial behavioral context: the URL is a sensitive 'bearer capability' to treat as secret until expiry, the response shape (URL, operation, expiresIn, expiresAt), and the crucial data-flow fact that bytes bypass the MCP server entirely. It also discloses the B2 platform limitation on presigned POST, which an agent could not infer from the schema or 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?

Five sentences with no filler; the core purpose is front-loaded in the first phrase, followed by usage routing, response/security details, and a constraint note. It is denser than the minimal two-sentence ideal, but each sentence earns its place given the security implications and missing output schema.

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

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

Given no output schema, the description compensates by enumerating the response fields. With 7 parameters, the 100% schema coverage handles parameter semantics while the description addresses what an agent cannot infer elsewhere: security handling, expiry behavior, data-path architecture, multipart alternative routing, and a platform-specific limitation. Nothing critical is missing.

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

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

Schema description coverage is 100%, so the baseline of 3 applies — every parameter already carries its own description. The tool description adds modest framing value by tying expiresIn to the 'short-lived' concept and clarifying that operation selects download vs upload capability, but it does not meaningfully elaborate on versionId, contentType, or confirm 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 opens with a specific verb and resource: 'Generate a short-lived presigned URL bearer capability for one B2 object', and immediately disambiguates the two modes (GetObject download vs PutObject upload). It differentiates from sibling tools by framing this as URL-based transfer rather than server-mediated access, which separates it from s3_get_object, s3_put_object, and the multipart family.

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 routing is provided: 'Prefer this for single-object transfers; use s3_create_multipart_upload and s3_get_presigned_upload_part_url for multipart uploads.' It also states this is 'the preferred path for moving real object data' and gives a hard exclusion (presigned POST unsupported by B2, use PutObject URL instead). An agent receives clear when-to-use and when-not-to-use guidance with named 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, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable behavioral context: it operates on the S3-compatible endpoint, checks both existence and reachability, and depends on current credentials. This goes beyond what the annotations convey, though it could mention explicit error/status outcomes.

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 tight sentences with no filler. The primary purpose is first, followed by a precise usage directive. Every phrase earns its place and nothing needs to be trimmed.

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

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

For a simple one-parameter, read-only tool with full annotations and complete schema coverage, this description supplies all necessary context: what it checks, what credentials it uses, and when to prefer it over a sibling. No missing information blocks an agent from selecting or invoking 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?

Schema description coverage is 100% and the only parameter, 'bucket', is already described as 'The bucket name to check.' The description reinforces this by referencing the bucket but does not add new semantic details such as name format or restrictions. Baseline 3 is appropriate given full 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?

States a specific verb ('Check whether') and resource ('B2 bucket') with the precise scope: exists and is reachable on the S3-compatible endpoint with current credentials. It also distinguishes itself from b2_list_buckets, removing any ambiguity with 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?

Explicitly gives the use case: 'Use this to validate S3-surface reachability' and directly names the alternative (b2_list_buckets) that does not cover S3 reachability. This tells an agent exactly when to choose this tool over a similar sibling.

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, idempotentHint=true, and destructiveHint=false, so the read-only safety profile is established. The description adds value beyond those by disclosing that the operation returns metadata only and by listing the response fields (content type, size, last modified, ETag, custom metadata), which is genuinely useful given there is no output schema.

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

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

Two sentences with zero filler: the core purpose and differentiator are front-loaded in the first sentence, and the response summary follows directly. Every clause 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 simple metadata-retrieval tool with rich annotations and fully documented parameters, the description is nearly complete, and it partially compensates for the missing output schema by enumerating the returned metadata fields. Minor gaps remain around failure behavior (e.g., 404 for a missing object) and versionId semantics, but these are not blocking 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?

Schema description coverage is 100% — bucket, key, and versionId each already carry descriptive entries, so the baseline 3 applies. The description adds no parameter-specific detail, but none is required given that 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?

States a specific verb and resource ('Get metadata for a B2 object') and the key differentiator 'without downloading it', which distinguishes it from s3_get_object and s3_head_bucket. The second sentence enumerates the response contents, making the tool's scope 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 phrase 'without downloading it' provides clear context for when to choose this tool over the object-download sibling: when only metadata is needed and the body is not. However, no alternative is named explicitly and no exclusionary conditions are stated, so it stops short of the strongest routing guidance.

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

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

Annotations already mark this as readOnly, idempotent, and non-destructive; the description adds useful behavioral context beyond that: the required listFiles permission, pagination semantics with maxUploads limits and markers, and the commonPrefixes behavior for delimiters. No contradiction with annotations.

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

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

Three dense sentences with no filler: purpose first, then usage guidance and alternative, then permission and pagination details. Every clause earns its place and the most decision-relevant 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?

For a six-parameter listing tool with no output schema, the description covers permissions, pagination, default/range values, and delimiter behavior. It does not enumerate the full response shape, but the S3 semantics are standard and the key operational details are present.

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 each parameter is already documented in the schema. The description reinforces pagination and delimiter behavior but does not add substantial new meaning beyond what the schema provides, so the 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 states a specific action ('List in-progress S3-compatible multipart uploads') on a specific resource ('B2 bucket'), and differentiates itself from b2_unfinished_uploads by naming the exact use cases. An agent can clearly tell what this tool does and how it differs from nearby siblings.

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 when to use this tool ('resume or audit unfinished uploads'), names the downstream operations it precedes, and gives a concrete alternative (b2_unfinished_uploads) with the condition for choosing it ('storage-cost analysis across bounded listings'). It also states the required permission, listFiles.

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 cover the read-only, idempotent, non-destructive behavior, so the description does not need to repeat safety traits. It adds useful functional detail about filtering, delimiter folder views, and pagination, but it does not disclose truncation behavior or the need to follow continuation tokens.

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?

One well-structured sentence that front-loads the primary action and resource, then lists the key capabilities. Every clause adds information, and there is no redundant or filler content.

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, combined with rich annotations and a well-documented schema, gives an agent enough to invoke the tool correctly. It covers filtering, folder-style listing, and pagination; the only notable gap is not explicitly explaining that results can be truncated and require a continuation token, though the word 'pagination' hints at this.

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 high at 83%, providing a solid baseline. The description goes further by giving semantic meaning to key parameters: 'prefix filtering' maps to prefix, 'delimiter-based folder listings' maps to delimiter, and 'pagination' maps to continuationToken. Only maxKeys lacks prose explanation, though the schema defines its bounds.

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?

Begins with the specific verb-object pair 'List objects in a B2 bucket' and names the exact S3-compatible ListObjectsV2 API. This clearly identifies the operation and distinguishes it from siblings like s3_list_object_versions and s3_list_parts.

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

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

The description implies use cases by mentioning prefix filtering, delimiter-based folder listings, and pagination, but it never states when to choose this tool over alternatives such as s3_list_object_versions or s3_list_parts. There is no explicit when-to-use or when-not-to-use guidance.

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

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

Annotations already provide readOnly, openWorld, idempotent, and non-destructive hints. The description adds useful behavioral context beyond that: pagination behavior with maxKeys default/max of 1000, paired key/version markers, and the listFiles permission requirement. No contradiction with annotations.

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

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

Three dense sentences with no filler. It front-loads the action and resource, then gives usage guidance and pagination details, earning every sentence's 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 read-only listing tool with rich schema coverage and annotations, the description is complete: it covers purpose, when to use versus alternatives, required permission, and key pagination behavior. No output schema is present, but the description sufficiently conveys what the call returns.

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 reinforces maxKeys limits and the paired keyMarker/versionIdMarker pagination scheme, but these details are already fully documented in the schema, so it adds limited new semantic value.

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

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

The description states a specific verb and resource: listing object versions and delete markers in a B2 bucket via the S3-compatible API. It also distinguishes itself from s3_list_objects_v2 by name, so an agent can tell them apart immediately.

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 says when to use this tool: before version-targeted s3_get_object, s3_head_object, s3_copy_object, or s3_delete_object calls. It also names the alternative s3_list_objects_v2 for when current live objects are sufficient, and states the required listFiles permission.

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, idempotentHint, and destructiveHint false, so the description does not need to restate safety. It adds the useful context that the upload must be in-progress, but it does not disclose pagination behavior, response shape, or any error conditions, so it stays at the baseline.

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

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

A single, front-loaded sentence communicates the operation, resource, and required state with no redundant wording. Every word contributes to the agent's understanding.

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

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

For a simple read-only list operation, the description plus schema annotations cover the essential invocation details: the operation, the target resource, and the in-progress state. It does not describe the return object, but a list operation of this kind is still sufficiently callable without that 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 schema covers 80% of parameters, documentating bucket, key, uploadId, and partNumberMarker, leaving only maxParts without a description. The description does not add meaning to any parameter beyond the schema, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('List'), a clear resource ('parts'), and a scoping condition ('an in-progress S3-compatible multipart upload'). This clearly distinguishes it from sibling tools like s3_list_multipart_uploads, which list uploads rather than parts, and from s3_upload_part_copy.

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 phrase 'in-progress' provides clear context that this tool is for active multipart uploads, implying it is not for completed uploads. It does not explicitly name alternatives or exclusions, but the intended use case is clear enough without additional guidance.

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

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

Annotations already mark the tool as destructive and idempotent, so no contradiction exists. The description adds valuable behavioral context by explaining that passing an empty rules array clears the S3 lifecycle configuration and by listing which lifecycle actions are supported versus unsupported. It does not explicitly state whether non-empty rules replace or merge with existing rules, but the clear/set framing largely covers this.

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 with no filler. The primary action and clear-behavior caveat are front-loaded, followed by supported rule types and the B2-specific limitation. 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?

The description covers the operation's core semantics, the clearing mechanism, supported rule types, and a B2-specific limitation. There is no output schema, but return-value details are typically minor for this kind of set operation. The confirm parameter's purpose is documented in the schema, so the description does not need to repeat it. A minor gap is lack of explicit statement about whether setting new rules replaces all existing rules.

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

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

The input schema has 100% description coverage, including the bucket name, the rules array with '[] clears the configuration', and the confirm fallback behavior. The tool description adds extra semantic meaning by clarifying which rule types are valid on B2 and that Transition/storage-class rules are not supported, giving the agent additional constraints not fully spelled out in 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 states a specific action ('Set S3 lifecycle rules on a B2 bucket') with a clear resource and purpose. It also distinguishes itself by explaining the supported lifecycle actions and explicitly noting B2 does not support Transition/storage-class rules, which separates it from any lifecycle-related 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 gives explicit usage context: use it to set lifecycle rules, pass rules: [] to clear the configuration, and do not use Transition/storage-class rules because B2 does not support them. It does not explicitly name alternative sibling tools, but the constraints and clear-vs-set guidance are sufficient for tool selection.

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

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

Annotations already cover read-only status, idempotency, and destructiveness. The description adds useful behavioral context beyond annotations: the 1 MiB size limit, the inline nature of the upload, and the fact that presigned URLs keep bytes from passing through the server. It does not detail overwrite/versioning behavior, but the annotations lower the burden here.

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 compact sentences with no filler. The purpose and size constraint are front-loaded, followed by parameter options and routing to alternatives. 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 high schema coverage, present annotations, and no output schema, the description covers the core decision space well: size threshold, inline vs. presigned, and multipart alternative. It could be slightly more explicit that content or filePath must actually be supplied despite only bucket and key being marked required in the schema, but the imperative 'Provide base64-encoded content or a local file path' substantially mitigates that gap.

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

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

Schema description coverage is 100%, so the schema already documents all nine parameters. The description adds marginal value by clarifying that content is base64-encoded and that either base64 content or a local file path can be provided, but it does not need to compensate for missing schema documentation.

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

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

The description states a specific verb ('Upload'), a specific resource ('a SMALL object inline (≤1 MiB) to a B2 bucket'), and the intended use cases ('manifests, sidecars, and tiny configs'). It distinguishes this tool from s3_get_presigned_url and multipart upload tools, so an agent can tell them apart without opening schemas.

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

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

The description explicitly states when to use this tool (SMALL inline objects ≤1 MiB) and when not to ('For real object data, generate a PutObject URL... or use the multipart tools for large objects'). It names the specific alternative tools and the condition that selects between them, leaving little to inference.

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

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

Beyond the annotations, the description discloses permission requirements, same-account/region constraints, part-size limits, failure conditions for missing/inaccessible sources or invalid ranges, and the returned ETag. This is substantial behavioral context that annotations do not 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 dense but every sentence earns its place: purpose, permissions, constraints, alternatives, failure modes, and return value. It is front-loaded with the core action and avoids redundant filler.

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

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

With no output schema, the description still explains the return value (part ETag) and its downstream use. It also covers prerequisites, constraints, failure behavior, and alternatives, so an agent has everything needed to 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?

Schema coverage is 100%, so the schema already documents every parameter. The description adds helpful constraints around part size and source behavior, but most of that is also reflected in the schema. It meets the baseline for a fully covered schema without significantly enhancing parameter-level meaning.

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 ('copy a byte range') and names the exact resource ('a part of an in-progress S3-compatible multipart upload'). It also differentiates this tool from s3_get_presigned_upload_part_url and s3_copy_object by scope, making the purpose unmistakable.

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

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

It explicitly states when to use this tool ('assemble large objects from data already in B2') and names the alternative for new bytes ('s3_get_presigned_upload_part_url'). It also gives exclusions, such as cross-account sources not being copyable, so an agent can route correctly.

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