Baidu Netdisk Knowledge MCP

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

With no annotations, the description carries the full burden of disclosing behavior. It describes the output content but fails to state whether the operation is read-only, whether selectionId must come from a prior selection step, how chunkSize affects processing, or any side effects and permission requirements. Operational behavior remains opaque.

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 that front-loads the verb 'Summarize' and packs the output aspects into a compact list. There is no wasted wording or redundant repetition 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?

With no output schema and no annotations, the description should explain the tool's integration with other selection tools, the origin of selectionId, and the meaning of chunkSize. It states the purpose but omits these critical contextual details, leaving an agent uncertain about how to safely invoke the tool in a workflow.

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, but it does not explain either parameter. 'Selected files' loosely implies selectionId identifies a prior selection, but chunkSize's meaning, constraints, and effect are entirely absent. No parameter-level detail 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?

The description uses the specific verb 'Summarize' and clearly identifies the resource as 'selected files', enumerating the output dimensions (key points, actions, tags, value judgment, suggested classification). This makes the tool's function clear, though it does not explicitly distinguish itself from sibling tools like baidu_read_selection or baidu_plan_organize_selection.

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 the user needs a summary of selected files—but provides no explicit guidance on when to prefer this tool over alternatives, nor any exclusions or prerequisites. It does not mention that a prior selection must exist or reference related selection tools.

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

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

With no annotations, the description must convey behavior. It only states the exchange but omits crucial behavioral details: the code is single-use, possible failure modes, whether tokens are returned in the response, and whether any upstream API calls are made. This leaves the 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?

The description is a single, direct sentence with no filler. It states the action and the outcome 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?

The description is minimal and lacks critical context: it doesn't explicitly state the response structure, error conditions, or that the authorization code becomes invalid after use. There is no output schema or annotations to fill this gap, so the agent may not know how to handle the result.

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 provides no description for the 'code' parameter, and the description merely references 'authorization code' without explicitly mapping it to the parameter. However, the parameter name and the tool's action make the semantics clear enough. The description adds some context but doesn't elaborate on code format, length, or origin.

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

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

The description uses the specific verb 'exchange' with the resource 'Baidu OAuth authorization code' and explicitly names the outputs (access and refresh tokens). This clearly distinguishes it from sibling tools like baidu_auth_url and baidu_auth_refresh.

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 by naming the input (authorization code) but doesn't explicitly state when in the OAuth flow this should be called or mention alternatives like baidu_auth_refresh. The context is clear enough to infer, but there's no explicit 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?

With no annotations, the description carries the full burden. It indicates the tool constructs outputs (URL, terminal QR, PNG data URL) rather than performing side effects, but it does not disclose prerequisites, potential network calls, or the nature of the terminal QR format. Minimal but non-contradictory transparency.

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, front-loaded sentence that immediately communicates the core function without filler. Every word adds value.

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

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

No output schema or annotations exist, and the description is too terse to fully specify behavior. It does not describe the return structure (how the URL, terminal QR, and PNG data URL are returned) or how parameters affect the output, making it incomplete for an agent.

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

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

Schema description coverage is 0%, and the description does not mention the parameters `state` or `deviceId`. The agent receives no explanation of their purpose or format, leaving the invocation ambiguous.

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 the specific verb 'Build' and identifies the resource: a QR-code Baidu OAuth URL, plus terminal QR and PNG data URL. This distinguishes it from sibling tools like baidu_auth_qrcode_url, which likely only returns a 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?

No usage guidance is provided. The description does not explain when to use this tool over alternatives like baidu_auth_url or baidu_auth_qrcode_url, nor does it mention its place in the OAuth flow.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only states that a URL is built. It does not mention authentication requirements, side effects, return format, or how the state and deviceId parameters affect the URL, leaving the agent without critical behavioral context.

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

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

The description is a single clear sentence with no wasted words. It could still be expanded with parameter hints or usage notes without becoming bloated, but as written it is concise and front-loaded.

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

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

Given the lack of annotations, no output schema, and 0% parameter description coverage, the description is incomplete. It doesn't say what the tool returns, how parameters affect the URL, or how it differs from the similarly named sibling baidu_auth_qrcode.

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%, and the description adds no explanation of 'state' or 'deviceId'. An agent must guess their roles from OAuth conventions, which is unreliable. The description provides no value beyond what the parameter names weakly imply.

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 ('Build') and resource ('Baidu OAuth URL'), and the qualifier 'optimized for QR-code login' distinguishes it from the sibling baidu_auth_url. However, 'optimized' is vague—it doesn't clarify what makes the URL QR-specific compared to the standard auth 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?

No when-to-use or alternative guidance is provided. The phrase 'optimized for QR-code login' implies a use case, but the description never names baidu_auth_url or baidu_auth_qrcode as alternatives or explains when to choose this tool over them.

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

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

With no annotations, the description carries the full burden. It adds useful context: the refresh token is single-use and the new one is persisted. However, it does not disclose failure modes, prerequisites, or effects on other auth credentials, leaving 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, direct sentence that front-loads the action and object. Every word adds value, 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?

For a zero-parameter auth action, the description covers the core behavior (refresh and persist). However, it omits details such as return values or success/failure indicators, and since there is no output schema, these would be helpful for full 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?

The tool has zero parameters, so the schema provides no extra information and the baseline is 4. The description does not need to clarify parameters, and no additional semantics are required.

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

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

The description uses the specific verb 'Refresh' and clearly identifies the resource (stored Baidu access token) and the side effect (persist a new single-use refresh token). This distinguishes it from sibling tools like baidu_auth_exchange_code and baidu_auth_status.

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. The description does not mention token expiry, the need for a valid refresh token, or that this tool should be used after initial authentication rather than exchanging a code again.

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

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

With no annotations, the description carries the burden of disclosing behavior. It states the check action and implies a boolean result, but it does not explicitly clarify whether the token is merely locally present or validated against the server, nor does it describe potential errors or side effects. More detail would improve transparency.

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, straightforward sentence with no filler. It directly states the tool's purpose and is appropriately sized for a simple status-check tool.

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

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

For a zero-parameter tool with no output schema, the description is mostly complete: it clearly conveys the function and implies a boolean return. A minor gap is that it does not explicitly state what the tool returns (e.g., 'true if token exists, false otherwise'), but this is easily inferable from the wording.

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

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

The tool has zero parameters and the schema is empty, so the description does not need to explain any parameters. The baseline for zero parameters is 4, and the description meets this easily by being clear about the tool's purpose.

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 'check' and clearly identifies the resource (MCP server's Baidu Netdisk access token). It distinguishes itself from sibling auth tools (e.g., baidu_auth_url, baidu_auth_refresh) by focusing on status verification rather than obtaining or refreshing tokens.

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 verifying authentication state, but it does not provide explicit guidance on when to use this tool versus alternatives. It lacks context such as 'check before performing authenticated operations' or 'if the token is missing, use baidu_auth_qrcode to initiate authentication'.

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

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

With no annotations provided, the description carries full burden. It accurately states the action (building a URL) but provides no detail on side effects, prerequisites, or behavior like whether it returns the URL as a string or performs network calls. It is not misleading, but lacks depth.

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 that is directly to the point. It contains no wasted words and is well-structured for quick parsing.

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 is simple, but with 4 undocumented optional parameters, no output schema, and no annotation, the description alone is insufficient. It lacks information on how the returned URL is used, the meaning of parameters, and how this tool fits into the auth flow.

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% and the description does not explain any of the four optional parameters (state, qrcode, display, deviceId). The phrase 'basic,netdisk access' gives scope but no parameter-level meaning, so the agent has no semantic help.

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

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

The description uses the specific verb 'Build' and clearly identifies the resource as a 'Baidu OAuth authorization URL' with the scope 'basic,netdisk access'. It communicates the core function effectively, but does not explicitly distinguish it from the sibling tool baidu_auth_qrcode_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?

There is no guidance on when to use this tool versus alternatives like baidu_auth_qrcode_url or baidu_auth_exchange_code. No prerequisites, exclusions, or alternative conditions are mentioned.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It merely says 'copy' without explaining key behaviors such as handling of existing destinations (ondup), asynchronous execution, dry-run mode, or the effect of newname. This leaves the agent without critical operational details.

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, front-loaded sentence with no wasted words. It is concise, though the extreme brevity comes at the cost of substance, so it does not reach a perfect 5.

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 six parameters, no output schema, and no annotations, yet the description provides only the most basic purpose. Missing details about parameter semantics, conflict behavior, asynchronous options, and return values make this description inadequate for reliable tool 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 0%, so the description must compensate for the six parameters, but it mentions none of them. The schema shows enums like ondup and async, but the description adds no meaning to these or to path, dest, dryRun, or newname.

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 'copy' and the resource 'Baidu Netdisk file or folder', which is specific and understandable. However, it does not distinguish itself from sibling tools such as move or rename by noting that the original remains intact, so it falls short of a 5.

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?

There is no guidance on when to use this tool versus alternatives like baidu_move_file or baidu_rename_file. The description only states what it does, leaving the agent to infer appropriate usage from the tool name alone.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely states a folder is created, but does not disclose whether the operation is idempotent, what happens if the path already exists, whether special permissions are required, or what the response contains. This is significantly lacking for a mutation tool.

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

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

The description is a single, front-loaded sentence with no filler words. It is efficient and easy to parse, though it could be slightly longer to cover parameter details without becoming verbose.

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 three parameters, no annotations, no output schema, and zero schema parameter descriptions, the tool definition is incomplete. The description does not explain error behavior, return values, the effect of dryRun, or the meaning of rtype, leaving an agent without enough guidance for successful 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 0%, so the description must compensate. It hints at the path semantics ('under /apps/<appName>') but does not explain the rtype parameter, the dryRun flag, or the exact path format. Only minimal value is added beyond the raw schema.

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

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

The description clearly states the action ('Create') and the resource ('folder'), with a specific location ('under /apps/<appName> in Baidu Netdisk'). This distinguishes it from file-centric siblings like baidu_upload_file and baidu_delete_file.

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

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

The description provides clear context about where the folder is created ('under /apps/<appName>'), which implies when this tool should be used. It does not explicitly name alternatives or exclusions, but its unique purpose among siblings makes the intended usage reasonably 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?

With no annotations, the description carries full behavioral disclosure burden. It only states the destructive nature and the confirmation requirement. It does not disclose whether deletion is permanent, what happens to parent folders, or how async/dryRun affect 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 very short and front-loaded. The first sentence largely repeats the title, but the second adds the critical confirmation requirement. It earns its place overall, though slightly redundant.

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 annotations and no output schema, the description is incomplete. It fails to explain the paths format, async behavior, dryRun semantics, or irreversible consequences.

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

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

Schema coverage is 0%, so the description must explain parameters. It only clarifies confirm (which the schema already constrains to DELETE). The paths, async, and dryRun parameters are left 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 clearly states the tool deletes Baidu Netdisk files, using a specific verb and resource. It is unambiguous and distinct from sibling tools like copy, move, or rename.

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 mentions the requirement to pass confirm: DELETE, which is a usage condition. However, it does not provide guidance on when to prefer this tool over alternatives or any 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the download action and destination, omitting overwrite semantics, authentication requirements, filesystem side effects, and return value.

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, front-loaded sentence with no filler. Every word contributes meaning, making it appropriately concise for the core action it describes.

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?

There is no output schema and no annotations, yet the description is too sparse. It fails to explain localPath semantics, overwrite behavior, prerequisites, or what the tool returns, leaving critical gaps 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 0%, so the description must compensate. It explains fsId as the file identifier but does not clarify the relationship between localPath and the 'configured local root,' nor does it mention the overwrite parameter.

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

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

The description uses a specific verb 'Download' plus the resource 'Baidu Netdisk file by fs_id' and the destination 'configured local root.' This clearly distinguishes it from sibling upload, delete, and list tools.

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

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

The description clearly implies when to use this tool: when you need to download a Baidu file by its fs_id to the local root. It provides no explicit exclusions or alternatives, but the context is clear enough for selection.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Get metadata' without revealing whether this is a read-only operation, what metadata fields are returned, how missing/invalid fs_ids are handled, or any rate limits or auth requirements. This is inadequate for an 8-parameter tool.

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

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

The description is a single, concise sentence with no redundancy. It effectively communicates the core purpose without wasted words, making it appropriately sized for a tool with minimal context.

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

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

Despite the tool having 8 parameters, no output schema, and no annotations, the description provides only a single sentence. It omits essential details such as parameter semantics, return format, behavior for batch requests, and any constraints. This is severely incomplete for a tool of this complexity.

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

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

Schema description coverage is 0%, and the description does not explain any of the 7 optional parameters (path, dlink, extra, thumb, detail, deviceId, needmedia) or even the required 'fsids' parameter beyond mentioning 'fs_id values'. The description fails to compensate for the lack of 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 clearly states the action ('Get metadata') and the resource ('Baidu Netdisk fs_id values'), which distinguishes it from file listing or search tools. However, it does not explicitly distinguish from siblings like baidu_list_files or baidu_search_files, so it lacks explicit differentiation.

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 no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, use cases, or exclusions, leaving the agent without context 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?

No annotations exist, so the description carries the full burden of behavioral disclosure. It only mentions optional recursion, but fails to disclose pagination, output format, cost implications of recursion, or authentication requirements.

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 single sentence is concise but under-specified for a tool with 10 parameters. It lacks structure that would group or explain the optional filters, and the brevity results in missing critical usage 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?

With no output schema, the description should at least indicate what the returned list contains, but it does not. Given the complexity of the schema (10 params) and absence of annotations, the description is far from complete.

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%, and the description does not compensate. None of the 10 parameters (e.g., web, ctime, order, deviceId) are explained beyond their raw names and types, leaving the agent unable to correctly construct calls.

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 files below a Baidu Netdisk path, with an explicit optional recursion flag. The title 'Recursively list Baidu files' and name 'baidu_list_all_files' differentiate it from the sibling 'baidu_list_files', which likely lists non-recursively.

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?

Usage is implied: use this to list files at a given path, optionally recursively. However, no explicit guidance is provided on when to prefer this over baidu_list_files, baidu_search_files, or other siblings, nor any 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the listing function and does not mention pagination, sorting, recursion, authentication, or any side effects. The read-only nature is implied but not explicit.

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 with no filler, which is efficient. However, given the tool's eight parameters, the extreme brevity omits essential structure and context, making it under-specified even though it is not verbose.

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 eight parameters, no schema descriptions, no annotations, and no output schema, the description must supply comprehensive context. It only states the basic function, leaving the agent without enough information to select or invoke the tool correctly, especially given many similar sibling tools.

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%, and the description does not explain any of the eight parameters (e.g., 'dir', 'limit', 'order', 'folder'). The agent is left to infer meaning solely from parameter names, which is insufficient for correct usage.

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

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

The description uses a clear verb ('List') and specifies the resource ('files in a Baidu Netdisk directory'), making the core action evident. However, it does not distinguish this tool from sibling tools like baidu_list_all_files or baidu_search_files, so it lacks differentiation.

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 no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It simply states what it does without contextualizing its place among the many sibling listing/search tools.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses the numbered-list output and selection-expression usage, but does not disclose authentication needs, default directory behavior, sorting, pagination, rate limits, or side effects. This is a significant gap for a tool with no other structured behavioral context.

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

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

The description is a single, front-loaded sentence with no wasted words. It is concise and immediately states the core function, though it could be longer to cover necessary parameter and usage context.

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

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

Given five optional parameters, no annotations, no output schema, and no sibling differentiation, the description is too sparse. It does not explain parameter semantics, return format beyond 'numbered list', or how this tool fits into the selection workflow. The tool is functional but incomplete for an agent to use confidently.

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 5 parameters with 0% description coverage, and the description does not explain any of them (dir, limit, category, fileTypes, recursive). The description only talks about output and selection expressions, adding no meaning to the parameters themselves.

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

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

The description clearly states a specific verb and resource: 'List files and return a numbered list that can be selected with expressions like 1,3,5-9.' This distinguishes it from plain listing tools like baidu_list_files by emphasizing the selectable numbered output.

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 the tool is used when a numbered, selectable list is needed for selection expressions, but it does not explicitly state when to use it versus siblings like baidu_search_selectable_files or baidu_list_files. There is no exclusion or alternative mention, so usage context is only implied.

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

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

With no annotations provided, the description carries the full burden. The verb 'List' implies a read-only operation, and the description adds the Markdown/YAML scoping, but it does not disclose return format, authentication requirements, or any 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 a single, information-dense sentence with no redundancy. Every word contributes 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 parameter-less list tool with no output schema, the description clearly captures its purpose and scope. It could optionally mention what fields are returned per skill, but the core functionality is sufficiently complete.

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

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

The tool has zero parameters, so the schema already fully covers the input. The description adds nothing about parameters, and none are needed, aligning with the baseline of 4 for 0-param tools.

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

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

The description uses a specific verb 'List' and clearly identifies the resource as 'built-in and user-defined Markdown/YAML knowledge processing skills', which distinguishes it from sibling tools such as baidu_list_files. The scope qualifiers add precision.

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 discovering available skills, but it does not explicitly state when to use it versus alternatives like baidu_run_skill or baidu_analyze_selection. No exclusions or conditional use cases are provided.

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

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

With no annotations, the description carries full responsibility for behavioral disclosure. It only states 'move,' implying mutation, but gives no details about overwrite behavior (ondup), async execution, dry-run simulation, or that it removes the source after copying. This is insufficient for a mutation tool.

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

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

The description is a single, grammatically complete sentence with no redundant wording. It is as concise as possible while conveying the core purpose.

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

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

For a tool with 6 parameters, 2 enums, no annotations, and no output schema, a one-sentence description is severely incomplete. It fails to explain behavior on conflicts, return values, or any operational nuances, making safe invocation the agent must rely on external knowledge.

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 for parameters, so the description must compensate. It mentions nothing about 'path,' 'dest,' 'async,' 'ondup,' 'dryRun,' or 'newname,' leaving the agent to infer meaning solely from parameter names. This is a significant 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 ('Move') and the resource ('a Baidu Netdisk file or folder'). This distinguishes it from sibling tools like copy, rename, and delete, which have different verbs and semantics.

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 no guidance on when to use this tool versus alternatives. It does not mention exclusions, such as not using it for copying, nor does it indicate prerequisites like permissions or file availability.

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

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

With no annotations, the description carries full responsibility. The verb 'read' indicates a non-mutating, safe operation, which is helpful. However, it does not disclose whether authentication is required, the format of audit records, or the meaning of 'local' and 'recent', leaving behavioral ambiguity.

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 that front-loads the primary action and resource. No unnecessary words 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 lack of annotations and output schema, the description leaves important gaps: it doesn't explain what the audit records contain, how 'recent' is defined, whether authentication is needed, or what the response format looks like. The tool is simple but the description is too sparse for full contextual 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?

The single parameter `limit` has no description in the schema (0% coverage) and the tool description does not mention it at all. The description fails to compensate for the lack of parameter documentation, so the agent must rely solely on the parameter name and schema constraints.

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 reads audit records for executed write operations. It uses a specific verb ('read') and resource ('local audit records for executed Baidu Netdisk write operations'), distinguishing it from siblings that perform operations rather than inspect logs.

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 auditing recent write operations, but it does not explicitly state when to use this tool versus alternatives or mention any prerequisites or exclusions. It lacks clear 'when 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?

With no annotations, the description carries full burden. It discloses the key behavioral trait that no files are moved, which is critical for a tool that might otherwise be assumed to be destructive. The term 'dry-run' reinforces that this is a non-mutating planning operation. It could add more detail about whether the plan is returned or saved, but for a planning tool, the core safety behavior is clearly disclosed.

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 that deliver essential information without waste. The key qualifier 'dry-run' is front-loaded, and the safety note 'It does not move files' is a valuable addition in the second 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?

The tool is relatively simple, but the absence of an output schema and the lack of parameter explanations means the agent must infer what the plan contains and how to set 'skill' and 'targetRoot.' The description provides enough to understand the tool's role, but leaves gaps in parameter interpretation and expected return value, so it is adequate but not fully complete.

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%, and the description does not explain any of the three parameters. It references 'selected files,' which implicitly maps to the required selectionId, but provides no meaning for 'skill' or 'targetRoot.' The description does not compensate for the lack of schema property descriptions.

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

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

The description clearly states the verb 'Create' and the resource 'a dry-run folder organization plan for selected files,' which is specific and distinct from sibling tools like baidu_move_file or baidu_create_folder. The explicit statement 'It does not move files' further differentiates its purpose from adjacent file-operation 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 clear context about when to use this tool—when you want to organize files without actually moving them, indicated by 'dry-run' and 'does not move files.' However, it does not explicitly name alternatives like baidu_move_file or state 'use this instead of move_file when you want a preview,' so there is no direct exclusion 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?

No annotations are provided, so the description carries full burden. It states the operation is a 'Get' (read-only) and discloses the return values (total, used, free, expiring capacity). While it does not mention auth requirements or error cases, for a simple read-only quota check this is adequate and does not contradict any structured data.

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 immediately conveys the action and result. Every word adds value, 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 low complexity (no params, no output schema, no annotations), the description fully covers the tool's purpose and return contents. It is complete enough for an agent to understand what the tool does and what to expect.

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

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

The tool has zero parameters, and schema coverage is 100% (empty properties). Per the rubric, 0 params baseline is 4. The description adds no parameter-specific details because none exist, which is appropriate.

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

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

The description uses the specific verb 'Get' and identifies the resource as 'Baidu Netdisk' with precise attributes: total, used, free, and expiring capacity. It clearly distinguishes this from sibling tools by focusing on storage quota, which no other tool addresses.

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 implies when to use this tool: to retrieve storage capacity information. With no alternative quota tools among siblings and zero parameters, explicit exclusions are unnecessary. It provides sufficient context for selecting this tool over file operations or auth tools.

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

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

No annotations are provided, so the description carries the full burden. It discloses a local cache side effect, parsing of supported formats, and the return of chunked text, which is useful. However, it omits important behaviors such as auth requirements, what happens with unsupported file types, error behavior, and whether the cache persists or is cleaned.

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, front-loaded sentence that efficiently communicates the core purpose and output. Every word adds value, 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 absence of an output schema and annotations, the description provides a basic understanding but lacks completeness. It does not specify the format of the chunked text, the list of supported document formats, prerequisites (e.g., that a selection must exist), or error conditions. For a read tool, this is minimal but not wholly inadequate.

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 does not explain `selectionId` (beyond the vague 'selected files') or `chunkSize` (only hints at chunking via 'chunked text'). This is insufficient for an agent to understand how to set parameters correctly.

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 (`Download selected files to local cache, parse supported document formats, and return chunked text`) with a specific resource (`selected files`) and distinguishes itself from siblings like `baidu_download_file` (raw download) and `baidu_analyze_selection` (analysis) by explicitly focusing on parsing and returning text chunks.

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 no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives like `baidu_download_file` or `baidu_analyze_selection`. Usage is only implied by the phrase 'selected files', which suggests it should be used after a selection exists, but this is not explicit.

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

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

With no annotations, the description provides minimal behavioral information. It does not disclose async or dry-run capabilities, nor does it describe side effects, permissions, or error behavior. The agent cannot anticipate whether the operation is immediate, reversible, or requires special conditions.

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, direct sentence conveys the tool's purpose with zero filler words. It is front-loaded and easy to parse, appropriate for a simple rename operation.

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

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

The tool has 4 parameters, no annotations, and no output schema, yet the description provides only the basic action. It lacks details on async behavior, dry-run, error handling, and return values, making it incomplete for an agent to invoke confidently.

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%, and the description adds no parameter information. The parameters path, newname, async, and dryRun are entirely undocumented, and the description's generic phrasing 'file or folder' does not explain their meanings or usage.

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

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

The description uses a specific verb 'Rename' and explicitly names the resource 'Baidu Netdisk file or folder,' clearly distinguishing it from sibling tools like delete, copy, move, upload. It states exactly what the tool does 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?

No guidance is provided on when to use this tool versus alternatives. The description does not mention scenarios, prerequisites, or when a different operation would be more appropriate, leaving the agent to infer 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?

With no annotations, the description must fully disclose behavioral traits, but it only says 'Run...' without mentioning whether the operation is synchronous, requires prior configuration, has side effects, or returns a result. No behavioral context is added beyond the most surface-level action.

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, focused sentence with no redundancy or filler. It is front-loaded and easily scannable, though its brevity contributes to the incompleteness penalized elsewhere.

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 lack of annotations, output schema, and any parameter documentation, this description is not self-sufficient. It leaves out essential context such as how to obtain a valid skill, whether the selection must already exist, and what the return value or side effects are. Only the core intent is conveyed.

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 clarifies that selectionId is the target selection and skill is a 'configured knowledge processing skill', but it says nothing about chunkSize, nor does it explain the relationship or expected format of skill values. The compensation is minimal.

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 ('Run') and the resource ('configured knowledge processing skill') against a 'selectionId'. This is more specific than a mere restatement of the title, though it doesn't explicitly contrast with siblings like baidu_analyze_selection, so it isn't a 5.

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?

There is no guidance on when to use this tool versus alternatives such as baidu_list_skills, baidu_analyze_selection, or baidu_plan_organize_selection. The description implies a generic execution action but provides no prerequisites, exclusions, or selection criteria.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only restates the search action. It does not mention pagination behavior (page/num), what happens when recursion is enabled, result format, auth requirements, or any default limitations.

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 that is front-loaded with the key action and target. It has no wasted words, though it is minimal to the point of under-specification.

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 (8 parameters, no output schema, no annotations), this one-sentence description is grossly inadequate. It does not clarify pagination, recursion behavior, category filtering, or the distinction from the selectable-file search sibling, so an agent cannot invoke it confidently.

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 8 parameters with 0% description coverage, and the description only adds meaning for 'key' via the phrase 'by keyword'. No explanation is given for 'dir', 'recursion', 'category', 'web', 'deviceId', 'page', or 'num', leaving their semantics unclear.

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: 'Search Baidu Netdisk files by keyword.' It clearly communicates this is a search operation, distinguishing it from list/delete/upload siblings. However, it does not differentiate from the similarly named 'baidu_search_selectable_files' sibling, so it lacks full sibling differentiation.

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 no guidance on when to use this tool versus alternatives like 'baidu_list_files' or 'baidu_search_selectable_files'. It does not state any prerequisites, exclusions, or context for choosing this search tool.

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

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

With no annotations, the description carries the transparency burden. It does disclose the numbered-list selection behavior, which is beyond the schema, but it omits auth requirements, read-only guarantees, and any rate limits or result size constraints.

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

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

A single, front-loaded sentence that communicates the core behavior and selection syntax without 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 five-parameter search tool with no output schema and no annotations, the description is under-specified: it lacks parameter semantics, result scope, and interaction context. The selection-format detail is helpful but not sufficient for reliable 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 0% and the description does not explain any of the five parameters. Even the required 'key' is not mentioned as the search term; 'dir', 'web', 'category', and 'recursion' receive no semantic clarification.

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 searches files and returns a numbered selectable list, with example selection syntax. This distinguishes it from sibling tools like baidu_search_files and baidu_list_files by adding the selectable numbered-list aspect.

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 when a search must produce ordered selectable results, but it provides no explicit guidance on when to prefer this over baidu_search_files or baidu_list_selectable_files, and no 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?

There are no annotations, so the description must carry the full burden of behavioral disclosure. It explains the creation of a selectionId but does not mention side effects, authentication requirements, persistence, or whether the operation is read-only. For a tool that likely mutates state, this is insufficient.

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 short sentence with a useful example. It is front-loaded, contains no fluff, and every word earns its place. This makes it easy to parse and quickly understand the core action.

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

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

With no output schema, no annotations, and 4 undocumented parameters, the description only covers the core concept. Missing information includes parameter semantics, return format, and usage workflow. Given the tool's moderate complexity, this is not enough for reliable 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 0%, and the description only explains resultId and select (via the expression example). fsids and paths are entirely undocumented, leaving the agent unable to determine how these parameters are used or when they are needed. The description partially compensates but not enough.

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: creates a reusable selectionId from a resultId and an expression. It uses a specific verb ('Create') and resource ('selectionId'), and includes an example expression '1,3,5-9'. This distinguishes it from sibling tools like baidu_read_selection and baidu_analyze_selection.

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 explicit guidance is provided on when to use this tool versus alternatives. The description implies a workflow involving resultId but does not mention prerequisites, exclusions, or sibling tools such as baidu_list_selectable_files. This leaves the agent without clear context for 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the official multipart upload flow, but does not disclose that this creates/mutates remote state, whether authentication is required, what happens on conflicts, or how the multipart process behaves. This is insufficient for an upload tool.

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

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

The description is a single, well-formed sentence that is front-loaded with the action and resource. Every word earns its place, 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?

Given the absence of annotations and output schema, the description alone is not enough for an agent to use the tool correctly. It omits authentication requirements, upload behavior, return values, and the meaning of rtype. The multipart upload mention provides some context but leaves major 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%, and the description does not explain the parameters. While localPath and remotePath are self-explanatory by name, rtype is an unexplained enum (0-3). The description adds no meaning beyond the schema, leaving rtype ambiguous.

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 uploads a local file to Baidu Netdisk using the official multipart upload flow, with a specific verb and resource. It distinguishes itself from sibling tools like baidu_download_file and baidu_delete_file.

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

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

The description implies use when uploading a local file to Baidu Netdisk, but it provides no explicit when-to-use versus alternatives, no prerequisites such as authentication, and no exclusions. The context is clear enough for a basic upload action, but guidance is minimal.

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