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

With no annotations, the description carries the transparency burden. It discloses that results are filtered by the current user's permission to add content, which is useful. However, it does not mention pagination behavior (e.g., cursor handling) or the exact structure of returned data, which might be relevant for a list 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 two sentences long, front-loading the main purpose and then adding a usage condition. There is no wasted wording, and every sentence contributes 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?

For a simple list tool with two optional parameters and no output schema, the description is largely sufficient. It specifies what the list contains (knowledge bases with add-permission) and when to use it. However, it does not explicitly describe the return format, which the absence of an output schema makes slightly incomplete.

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

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

The schema covers 100% of parameters (limit and cursor), both with clear descriptions. The tool description adds no extra parameter-specific meaning, so the 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 the tool's function: getting a list of knowledge bases the current user has permission to add content to. It uses a specific verb (获取) and resource (知识库列表), and distinguishes itself from sibling tools like get_knowledge_base by adding the permission and 'add content' scope.

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

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

The description provides an explicit usage condition: '仅在未指定目标知识库时使用' (only use when a target knowledge base is not specified). This tells the agent when to use the tool, though it does not explicitly name alternative sibling 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 the batch size limit (1-20) and indicates typical content (description, recommended questions), but does not mention error behavior, handling of invalid IDs, or response format.

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

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

The description is two concise sentences with no filler. It front-loads the main purpose and immediately provides the batch-size constraint, making it efficient and 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?

The tool has low complexity (one parameter, no output schema). The description covers the main purpose and batch limit, but without an output schema, it could provide a bit more detail on return structure. Still, it is adequate for a straightforward details-by-ID tool.

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

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

The schema already fully describes the 'ids' parameter with minItems, maxItems, and a clear description. The tool description adds no additional parameter semantics beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description clearly states the tool retrieves knowledge base details, with a specific verb ('获取') and resource ('知识库详情'). It also specifies batch capability (1-20), which distinguishes it from siblings like search_knowledge_base or get_knowledge_list.

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

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

The description implies use when you know knowledge base IDs and need details for up to 20 at once, but it does not explicitly state when to use this tool versus alternatives like search_knowledge_base. No exclusions or prerequisites 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, the description carries the transparency burden. It discloses pagination behavior, return contents (files and subfolders), and root directory handling. It does not cover authorization, error handling, or sorting, but for a read-only list tool this is reasonably transparent.

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

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

The description is brief, front-loaded, and free of fluff. It packs the essential behavior, pagination, and folder_id guidance into a single clear 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?

Given the lack of annotations and output schema, the description offers a decent overview of the list behavior, pagination, and folder handling. It does not describe the exact return structure or error cases, but the schema covers parameter details, so it is reasonably complete for a list tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds behavioral nuance by explaining the optional folder_id usage (omit for root) and reinforces the folder_ prefix rule, which is not fully explicit in that a user might not know when to omit the parameter.

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

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

The description clearly states the tool's purpose: '浏览知识库内容列表' (browse knowledge base content list) with root or specified folder, paginated returns of files and subfolders. This distinguishes it from sibling tools like search_knowledge_base (search) and get_knowledge_base (single base).

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 usage context: when operating on root, omit folder_id; folder_id must start with folder_ prefix. It does not explicitly mention alternatives or exclusions, but the root vs. folder guidance is practical.

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 takes on full disclosure responsibility. It reveals type-dependent outputs: '对微信文章/网页/文件类，返回可访问 URL；对笔记类（media_id 以 note_ 开头），会自动拉取并返回笔记正文' (for WeChat/web/file returns accessible URL; for notes starting with note_ automatically fetches and returns note_content). It also names the field note_content and states plain text. It doesn't mention authorization or error handling, but the behavioral core is transparent.

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

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

Two sentences deliver the purpose, source of the parameter, and type-specific behavior with no redundancy. The main verb and resource appear first, and conditional behavior is compactly described.

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

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

For a one-parameter tool with no output schema, the description covers the essential return distinctions (URL vs note_content) and the provenance of the ID. It is sufficiently complete for invocation, though it might have been strengthened by noting the absence of download links for note types or potential errors, but these are minor 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?

The schema only defines media_id as '媒体条目 ID', but the description adds crucial context: it explains the media_id originates from get_knowledge_list or search_knowledge, and that the note_ prefix changes the tool's behavior. This meaningfully extends the bare schema definition.

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

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

The description opens with a clear verb-object phrase '获取知识库条目的原文内容或下载链接' (get original content or download link of knowledge base entry), specifying both action and resource. It distinguishes from siblings by detailing type-specific behaviors (URL for articles/web/files vs note_content for notes), which differentiates it from get_note_content and get_knowledge_list.

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

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

The description instructs to pass media_id obtained from get_knowledge_list or search_knowledge, establishing a clear prerequisite. It explains type-based branching (note_ prefix vs others), giving contextual guidance on what to expect. However, it doesn't explicitly contrast with the sibling get_note_content or state when not to use this tool, so it misses explicit exclusions.

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

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

No annotations are provided, so the description carries the transparency burden. It discloses that the output is plain text and clarifies the ID's provenance, but it does not mention potential errors, authentication requirements, or what happens for invalid IDs. This is a simple read operation, so the description is adequate but not rich.

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

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

The description is two sentences and front-loaded with the main action. The second sentence adds context about being dedicated to IMA notes, which is somewhat redundant but not wasteful. It remains concise and readable.

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 getter with two parameters and no output schema, the description covers the essential purpose, how to obtain the ID, and the return format (plain text). It does not describe edge cases or length limits, but these are not critical for the tool's basic use.

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

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

Schema coverage is 100%, so the schema already explains both parameters. The description adds value by elaborating on note_id's origin (get_media_info's notebook_id or search's doc_id), which helps the agent correctly populate the parameter. This goes beyond the schema's brief '笔记数字 ID'.

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 note content as plain text, using a specific verb ('读取') and resource ('笔记正文'). It also distinguishes itself as the dedicated interface for reading original IMA note text, setting it apart from sibling tools like get_media_info which likely handles metadata.

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

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

The description gives clear context for when to use this tool: when you need the raw text of a note. It explains the source of the required note_id (from get_media_info or search interfaces), but does not explicitly mention when not to use it or name alternatives.

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

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

No annotations are provided, so the description carries the burden. It adds useful context about accepted URL types (webpage/WeChat) and the folder omission rule, but does not disclose side effects, permissions, or return behavior beyond the obvious 'add' mutation. The count limit and optional folder_id are already present in the schema, so these add minimal new behavioral insight.

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 covers the core action and key constraint without redundancy or unnecessary detail. It earns its place with zero 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?

For a simple import tool with no output schema and no annotations, the description provides the basic purpose and parameter rule, but omits return values, duplicate handling, or any post-import behavior. While the tool is straightforward, the lack of return/error information leaves some contextual gaps.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's statement about omitting folder_id for root directory and the 1-10 URL limit merely repeats what the schema already documents. It adds no new semantic meaning beyond the structured fields.

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: adding webpage or WeChat article URLs to a knowledge base, with a specific verb and resource. It also includes a constraint (1-10 URLs) that distinguishes it from search/read 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?

Provides clear usage context by specifying that folder_id should be omitted when adding to the root directory. While it doesn't explicitly mention alternatives, the tool's write nature and the sibling tools' read nature make the intended use 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 provided, the description carries the burden of behavioral disclosure. It reveals that the tool returns titles and summary snippets and covers both files and folders. However, it does not mention pagination behavior (despite a cursor parameter), potential limitations, or whether it is strictly read-only, 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 concise and front-loaded, stating the action and result in the first sentence. The second sentence adds value by confirming its role as the core interface. No unnecessary words.

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

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

For a simple search tool with schema-covered parameters and no output schema, the description is largely complete: it explains what it does and what it returns. It lacks details about pagination or usage limits, but these are not critical for basic invocation. The absence of an output schema is not a significant issue given the return description.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add extra meaning beyond the schema; it only mentions keyword search, which is already implied by the 'query' parameter. No further parameter context is provided.

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

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

The description clearly states the tool's function: searching content by keyword in a specified knowledge base, including files and folders, and returning matched titles and summary snippets. It uses a specific verb and resource, but does not explicitly differentiate from the sibling tool 'search_knowledge_base', 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?

The description provides clear usage context by calling this the 'core interface for knowledge base content retrieval', implying it is the primary tool for this task. However, it does not mention explicit exclusions or alternative tools, so it lacks full when/when-not 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 the full burden. It discloses that an empty query returns all visible knowledge bases (self-built and subscribed), which is useful behavioral context. However, it does not explicitly state the read-only nature, pagination behavior beyond schema, or any permissions/rate limits, leaving some 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 two concise sentences, front-loaded with the core purpose ('搜索知识库列表') and then adding the empty-query behavior and use case. Every word adds value with no fluff.

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

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

For a simple list-search tool with fully described parameters, the description covers the key behavior and use case. It does not describe the response structure, but there is no output schema and the tool is straightforward enough that this is not 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 coverage is 100%, so baseline is 3. The description reinforces the query parameter semantics ('query 传空字符串时返回所有') and adds practical meaning ('知道知识库名称'), going slightly beyond the schema's '知识库名称关键词' to clarify the intended usage pattern.

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 a list of knowledge bases, with a specific use case ('用此接口' when name is known but ID is not). This distinguishes it from siblings like get_knowledge_base (which likely fetches by ID) and get_addable_knowledge_base_list.

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

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

The description provides explicit usage context: use this when you know the knowledge base name but not the ID. However, it does not explicitly state when not to use it (e.g., when you have the ID, use get_knowledge_base). The guidance is clear but not fully exhaustive.

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