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

With readOnlyHint=false, the description adds the meaningful outcome that the anonymous upload becomes attached to the API key, which is beyond just stating it's a write operation. It does not mention reversibility or auth requirements, but the added context is useful.

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 that conveys the essential purpose and required inputs without any filler or redundant 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?

The tool has no output schema and one annotation. The description explains the workflow context (after upload) and the parameters, making it sufficient for proper selection. It doesn't cover error cases or postconditions, but the simplicity of the tool doesn't require more.

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 all three parameters already described in detail. The description merely references fileId and claimToken from the upload response, adding no additional semantic meaning beyond what the schema 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?

The description clearly states the action ('Attach'), the object ('anonymous upload'), and the destination ('your API key'), distinguishing it from sibling tools like beecargo_upload or beecargo_delete_file. The verb 'Attach' is specific and not a tautology.

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 references 'from upload response,' indicating the tool should be used after an upload to claim the anonymous file. It doesn't explicitly exclude alternatives or state when not to use it, but the workflow context is clear.

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

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

Beyond the readOnlyHint=false annotation, the description reveals key behavioral nuances: default logic (trial if eligible else weekly), guest sessions always weekly, no API key required for guest, and a caution not to send session bc_* for guest. It also outlines the post-checkout workflow, giving a complete picture of 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?

The description is appropriately sized for the complexity. Every sentence adds value, from the core purpose to the detailed plan logic and follow-up action. It is front-loaded with the main purpose and progressively details nuances, with no redundancy or fluff.

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

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

Given the one optional parameter, no output schema, and minimal annotations, the description provides comprehensive context: it covers what the tool does, how to choose parameters, special cases (guest vs signed-in), security notes, and the required next steps. The tool is fully usable based on the description alone.

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

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

While the schema already describes the `plan` parameter with enum values and default, the description adds crucial meaning: the logic behind 'recommended' (trial if eligible else weekly), the condition 'only if the human asks' for non-recommended plans, and guest-specific behavior. This significantly enriches the parameter understanding.

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

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

The description explicitly states the tool's function: 'Mint a Stripe Checkout URL for a human to subscribe to Premium.' The verb 'mint' is specific and the resource (Stripe Checkout URL for Premium) is clear, distinguishing it from sibling tools focused on file management.

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

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

Provides explicit usage guidance: 'Prefer recommended; use weekly/monthly/annual only if the human asks' and clarifies guest vs signed-in behavior. It also explains when trial is applicable, giving a clear decision tree for plan selection. No alternative tool is mentioned, but this tool is unique among siblings.

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

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

The annotation readOnlyHint=false already signals a mutation, and the description confirms this by saying 'Create.' The description adds the authenticated key scope but does not disclose return behavior, parentId-related effects, or error conditions, which would be useful given the lack of an 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?

The description is a single sentence of about 9 words, front-loaded with the key verb and resource. There is no filler or redundant information; every word contributes to the meaning.

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 create operation with minimal annotations and no output schema, the description covers the core action. However, it omits important behavioral context such as what the tool returns, how parentId affects the creation location, and any prerequisites beyond authentication, leaving moderate 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 0%, so the description should compensate by explaining both parameters. The name parameter is implied by 'Create a folder,' but parentId semantics (e.g., whether null means root) are not addressed, leaving the agent to infer.

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 'Create' and resource 'folder', clearly distinguishing it from sibling tools like beecargo_create_checkout and beecargo_upload. It also adds scope with 'under the authenticated API key,' making the tool's purpose unambiguous.

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

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

It provides clear context that this tool creates a folder scoped to the authenticated API key, which is distinct from uploading files or creating checkouts. However, it does not explicitly state when not to use this tool or mention alternatives, so it falls short of a perfect score.

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 substantial behavioral context beyond the readOnlyHint=false annotation. It reveals the storage backend (R2), the short-lived nature of the delegation, the required API key tier, and the exact sequence of operations (PUT then POST). This goes far beyond what annotations or schema 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 three concise sentences that cover the purpose, the protocol, and a key constraint. Every sentence is meaningful, with no fluff or repetition.

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

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

Given the tool's complexity (11 parameters, no output schema), the description covers the core workflow but omits details about parameter meanings, return format, and edge cases. It is minimally viable but incomplete for a tool with this parameter count and sparse schema.

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 only 9%, and the description does not explain any of the 11 input parameters. While it mentions uploadUrl and completeUrl, these are response fields, not request parameters. The description fails to compensate for the sparse schema, leaving the meaning of most parameters undocumented.

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 'Mint' and clearly identifies the resource as a 'short-lived direct-to-R2 upload'. It also outlines the two-step protocol (PUT to uploadUrl, POST to completeUrl) and explicitly states 'No anonymous delegation', distinguishing it from potential anonymous upload variants.

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 by specifying the requirement for an 'owned/bootstrap/Pro API key' and states 'No anonymous delegation', which helps narrow when to use the tool. However, it does not explicitly name alternative tools like 'beecargo_upload' or mention when not to use this tool beyond the anonymous case.

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 destructiveHint annotation already signals the operation is destructive. The description adds value by revealing authentication requirements (API key vs deletionToken), which is not covered by annotations. It doesn't detail permanent effects, but the annotation covers the core risk.

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

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

Two concise sentences front-load the action and identifier, with no wasted words. Each clause earns its place, making it easy to scan.

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

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

The description is adequate for a destructive tool: it covers the core deletion action and auth variants. It omits the force requirement, but that is documented in the schema. No output schema is present, so no return-value explanation is needed.

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

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

Schema description coverage is 75%, leaving deletionToken undocumented. The description clarifies deletionToken's purpose ('for anonymous uploads'), adding meaning beyond the schema. Other parameters (force, idempotencyKey) are well-described in the schema, so the description compensates for the gap.

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'), the resource ('fileId'), and the method of identification, distinguishing it from sibling tools like upload or list. It is specific and unambiguous, not merely repeating the title.

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 practical auth context: 'Use API key for owned files, or deletionToken for anonymous uploads.' However, it doesn't explicitly say when to use this tool vs alternatives, nor mention the force parameter requirement for immutable files, which is only in the schema.

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

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

Annotations already declare readOnlyHint=true, and the description adds a useful behavioral detail: the result set includes an unlockRequired field that must be checked prior to download. This goes beyond the structured data and provides contextual behavior, though it doesn't describe full return shape or pagination.

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 tightly written sentences: the first states the core function and scope, the second provides a critical dependency hint. Every word earns its place, and the description is front-loaded with the primary purpose.

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

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

Given the tool's simplicity (one parameter), no output schema, and readOnly annotation, the description covers the essential context: batch operation, metadata lookup, and a prerequisite check. It could list more metadata fields, but for this complexity level it is sufficient.

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%: the single parameter fileCodes is fully described in the schema ('Comma-separated short codes, e.g. abc12,xyz99'). The description repeats the same info without adding new semantic depth, so it meets the baseline but does not exceed it.

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 a specific verb ('lookup') and resource ('metadata by short codes'), and the batch scope distinguishes it from siblings like beecargo_list_files (which lists all files) and beecargo_get_download_url (which retrieves a URL). The purpose is unambiguous.

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

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

The description gives an explicit usage directive: check unlockRequired on each result before calling beecargo_get_download_url. This provides clear context and a workflow hint, though it doesn't explicitly exclude other alternatives or mention when not to use the tool. Still, the guidance is actionable.

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 readOnlyHint annotation already indicates a safe read operation. The description adds value beyond the annotation by disclosing the conditional requirement for unlockCode/unlockToken/handoffToken, which is a behavioral trait not captured anywhere else. No contradiction with the annotation.

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

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

The description is two sentences, front-loaded with the main action, and every sentence contributes meaning. There is no fluff or repetition of schema details.

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

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

Given the tool's simplicity, the schema covers all parameters, and the readOnly annotation covers the safety profile, the description is sufficient. It explains the core function and the important unlock condition. No output schema exists, but the return value (a signed URL) is clear from the action.

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

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

The input schema already provides 100% descriptive coverage for all four parameters. The description adds extra meaning by explaining that the three unlock-related parameters are alternatives and must be passed conditionally when unlockRequired is reported, which is not fully explicit in the individual 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 uses a specific verb 'Get' and identifies the resource ('a signed download URL for a file by fileId'). It clearly distinguishes the tool from siblings like beecargo_file_info (which would give info) and beecargo_upload (which uploads). The scope is well-defined.

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 condition for when to pass unlock codes/tokens (if unlockRequired is reported), which is helpful usage guidance. However, it does not explicitly name alternative tools or state when not to use this tool, so it stops short of a perfect score.

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 readOnlyHint annotation already declares this as a safe read operation. The description adds context about API key scoping and the includeFolders behavior. However, it states 'Set includeFolders true to also return sibling folders' while the schema has a default of true, creating a minor inconsistency. It does not disclose pagination or other behaviors beyond annotations.

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

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

The description is concise and front-loaded, with the core purpose in the first sentence. The second sentence adds parameter information, but it is slightly misleading given the schema default, which prevents a perfect score. Overall, it is well-structured and avoids waste.

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

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

Despite having no output schema and four optional parameters, the description only covers the main purpose and one parameter. It fails to explain pagination (page, limit), filtering by folderId, or any details about the returned file list. This is insufficient for an agent to fully understand the tool's behavior without additional inference.

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

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

With 0% schema description coverage, the description must compensate for the four parameters. It only explains includeFolders, leaving page, limit, and folderId without any added meaning. The partial explanation of one parameter is insufficient for a low-coverage 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?

Description clearly states the action ('List files') and the resource scope ('for the authenticated API key'), distinguishing it from sibling tools like beecargo_list_folders. The title 'List owned files' reinforces the purpose. It is specific and unambiguous.

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

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

The description provides clear context: it lists files for the authenticated API key, implying its use for file listing tasks. It does not explicitly mention alternatives or exclusions, but the scope is obvious given sibling tools like beecargo_list_folders and beecargo_file_info. No misleading guidance is present.

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 no behavioral details beyond the readOnlyHint annotation. It only mentions that listing is for the authenticated API key, which is standard. There is no disclosure of pagination behavior, whether only top-level folders are listed, or how access is scoped.

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 sentence with no fluff, which is concise. However, it is under-specified and does not convey the necessary details about parameters or usage, making it less useful than it could be while remaining 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 the tool has four optional parameters and no output schema, the description is far from complete. It does not explain return values, filtering capabilities, or pagination behavior. The context from sibling tools is not leveraged to clarify what makes this tool unique. A more detailed description is needed for safe and correct invocation.

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

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

The schema has 0% description coverage, and the description does not explain any of the four parameters (page, limit, search, parentId). Since the description entirely fails to clarify what these parameters do or how they affect results, it cannot compensate for the schema's lack of information.

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

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

The description clearly states the action (list) and resource (folders), and scopes it to the authenticated API key. It distinguishes from sibling tools like beecargo_list_files by focusing on folders rather than 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?

No guidance is provided on when to use this tool versus alternatives. It does not mention related tools like beecargo_create_folder or beecargo_list_files, nor does it describe scenarios or exclusions. The only implied usage is the basic purpose of listing folders.

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

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

The annotation only sets readOnlyHint=false, but the description adds substantial behavioral context: no API key required, rate-limited per IP, and that the MCP session adopts the key after success. These are significant operational details not present in the annotation, and there is no contradiction with the mutation hint.

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

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

The description is compact yet information-dense: it covers purpose, constraints, production alternative, and post-condition in four short sentences. Every sentence provides essential value with no redundancy.

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

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

Given the tool's simplicity (one optional parameter, no output schema, minimal annotations), the description is remarkably complete. It explains the key scope, implicit prerequisites, rate limits, post-success behavior, and when to use an alternative, answering likely agent questions.

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 covers 100% of the single optional 'label' parameter, including its own description. The tool description does not add any extra meaning about the label parameter beyond what the schema already provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states a specific action and resource: 'Create a bootstrap bc_* machine key' with purpose 'files_write, free-tier quotas'. It also distinguishes itself from production API key creation by referencing the Pro dashboard alternative, making it unique among 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 explicitly says when to use this tool (bootstrapping, no API key required) and when not to use it, providing an explicit alternative: 'For production agents with 500GB included concurrent storage/1000rpm, mint via Pro dashboard POST /api-keys/agent.' This is clear and actionable.

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

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

The annotation readOnlyHint: true already indicates a safe read operation. The description adds the scope 'on your account' and the grouping by runId, which is useful context. However, it does not disclose pagination behavior or return format, leaving some transparency gaps.

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, coherent sentence that front-loads the verb and object. It contains no extraneous information and is easy 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?

Given the tool's simplicity and the readOnlyHint annotation, the description is minimally adequate. It does not mention the limit parameter or what the response will contain, but the absence of an output schema and the straightforward nature of the operation keep this from being a critical 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 0%, so the description must compensate. It explains the meaning of runId ('the same runId') but provides no additional detail about the limit parameter, which the schema only defines with default/max/min. This is partial compensation.

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

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

The description clearly states the tool's function with a specific verb (List) and resource (files), scoped by runId. This distinguishes it from sibling tools like beecargo_list_files, which likely list files without run filtering.

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 when you need to retrieve files associated with a specific runId, but it does not explicitly mention when to use it versus other listing tools or provide exclusion criteria. The context is clear but not fully elaborated.

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

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

The annotation readOnlyHint=true already covers the safe read-only nature. The description adds no additional behavioral context such as result format, query behavior, or limits, providing no value beyond the annotation.

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

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

The description is a single clear sentence that conveys the core purpose without unnecessary words. It efficiently 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?

As a simple search tool with two parameters and no output schema, the description gives a basic understanding but omits return value details, pagination behavior, and result ordering. It is adequate but has 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 0% with no parameter descriptions. The description hints that 'query' is the search term but does not explain the 'limit' parameter, defaults, or their interaction, failing to compensate for schema 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 states 'Keyword search over available Beecargo tools' which clearly identifies the action and resource. It differentiates itself from sibling tools by positioning as a meta-search utility rather than a domain operation.

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

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

The description provides minimal usage guidance, only mentioning similarity to lomi_search_tools. It implies usage for finding tools but does not explicitly state when to use this vs alternatives or provide exclusions.

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

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

Beyond the minimal annotations (readOnlyHint: false), the description discloses that an API key is required, explains the Pro default of keeping files while subscribed, and specifies that expiresAt must be a future ISO date within 90 days for automatic deletion. These are non-obvious behavioral details that help the agent anticipate 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?

The description is two sentences, front-loaded with the core action and then adding essential caveats. No filler or repetition; every clause adds information (owned file, API key, Pro default, 90-day expiry).

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 update tool with no output schema, the description gives the essential context: what can be changed, the ownership requirement, auth need, and the retention default/expiry behavior. Missing interactions (e.g., protect vs direct) are partially covered by schema descriptions, so the description is adequately complete for agent selection and initial invocation, though not exhaustive.

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

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

The schema description coverage is 64%, and the description adds meaning to at least one parameter (expiresAt: future ISO date within 90 days) and reiterates visibility and direct download. However, many parameters (protect, extendTtl, immutable, idempotencyKey) are not elaborated in the description, leaving most of the burden on the schema. It adds some value but does not fully compensate for the moderate coverage gap.

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 'change' and names the exact resources/settings: visibility, direct download, and retention. It clearly distinguishes from sibling tools by specifying 'owned file' and the update intent, leaving no ambiguity about what this 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?

Provides clear context: only for owned files, requires API key, and notes Pro defaults and the 90-day expiry behavior. While explicit alternatives to other tools are not named, the 'owned file' constraint and the focus on share settings define when to use it and implicitly when not to.

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

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

Beyond the readOnlyHint=false annotation, the description adds meaningful context: anonymous use, free/Pro limits, background job support, and the return of a share link and fileId. It doesn't mention auth prerequisites or default retention, but it still extends beyond the sparse annotations.

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

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

The description is concise and front-loaded with the core modes, but 'Anonymous, free, and Pro limits match the API' is vague and adds less value than a concrete expiration or size limit would. Overall it's efficient with minimal waste.

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 22 parameters, no output schema, and minimal annotations, this short description is not enough to guide advanced usage like folderId, maxDownloads, retention, or visibility. It covers common upload cases but leaves substantial configuration behavior undocumented.

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 only 36%, and the description only explains url, contentBase64, and path, leaving fields like ttl, retention, visibility, once, protect, maxDownloads, and grace unexplained. This does not compensate for the low parameter coverage.

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

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

The description clearly identifies a single upload tool with a specific verb and resource: 'Upload a file', detailing three input modes (public URL, contentBase64, stdio path). It distinguishes itself from siblings like beecargo_upload_status and beecargo_get_download_url.

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 each mode based on file source/size: public URL (sync or background), small contentBase64, and stdio path with auto multipart. It doesn't compare with sibling alternatives, but the 'One upload tool' framing plus the background polling hint gives adequate usage 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 readOnlyHint annotation already declares the operation safe, and the description adds meaningful context: it returns sharePath when completed, clarifying the async nature and expected outcome. It does not detail intermediate states or errors, but this additional context goes beyond what annotations provide.

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

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

The description is two short sentences, front-loaded with the action and key return value. Every word earns its place, with no redundancy or filler.

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

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

The description covers purpose and return condition but omits behavior for incomplete jobs, optional parameter usage, and how the required jobId is obtained. For a simple poll tool with no output schema, these gaps affect completeness.

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 only 33%, with jobId and waitSeconds lacking any description. The description does not explain these parameters, nor does it mention waitSeconds semantics or how to obtain jobId, failing to compensate for the low schema coverage.

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

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

The description clearly states the tool polls an async URL upload job from beecargo_upload with background: true, identifying the specific verb, resource, and condition. It distinguishes itself from sibling tools like beecargo_upload by referencing the companion and the returned sharePath.

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 after beecargo_upload with background: true, giving clear context for when to use this poll tool. It does not explicitly list exclusions or alternatives, but the reference to the sibling tool provides adequate guidance.

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