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 mentions the read-first prerequisite and the uniqueness constraint, but omits that this is an in-place mutation, the existence of a stale-read guard (only hinted by `force` schema), or the behavior of multiple edits. Partial 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?

Two short sentences packed with essential information: the primary action, the prerequisite, and the key constraint. No fluff, front-loaded with the core purpose.

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

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

For a tool with no annotations or output schema and low schema coverage, the description covers the main workflow (read first, unique old) but omits details like the stale-read guard, the array nature of edits, and potential failure modes. It's adequate but not fully complete for an agent needing robust calling context.

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

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

Schema description coverage is only 33%, so the description must compensate. It clarifies `old` must be unique and `replace_all` handles multiple matches, adding value beyond the schema. However, it doesn't explain the `file` or `edits` structure (though `edits` is intuitively an array of edit objects) or the `force` flag, leaving gaps.

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

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

The description states a clear verb ('做精確替換' - perform precise replacement) and resource ('既有檔案' - existing files), making it obvious this tool edits file content. It distinguishes from creation by specifying existing files, though it doesn't explicitly compare with fs_write or other siblings.

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

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

Provides explicit when-to-use guidance: '須先 fs_read' (must read first) and the uniqueness condition for `old` with the alternative `replace_all` for multiple matches. This gives solid operational context, though it doesn't mention when NOT to use (e.g., for new files).

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. It discloses key behaviors: it skips .git and node_modules, and does not search file contents. This is valuable safety and scope information. It does not explicitly state read-only behavior, but 'search' implies no side effects, and there are no contradictory hints. Minor gaps like symlink handling or sort order exist, but coverage is good for a search 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, compact sentence. It front-loads the core function ('glob path fuzzy search') and adds essential exclusions immediately. No filler or redundancy.

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

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

For a simple search tool with 3 parameters and no output schema, the description adequately covers the tool's scope and constraints. It does not mention return format (likely a list of paths) or edge cases, but those are implied and not critical for a basic glob search. The exclusions and content-search limitation add completeness beyond the bare minimum.

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 low (only glob has a description, root and limit have none). The description does not compensate by explaining root or limit. It only implicitly explains glob through the tool's purpose. For a low-coverage schema, the description should clarify all parameters, but it stays silent on root and limit, leaving agents to guess their meaning and defaults.

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 performs a glob-based path search, with exclusions (skips .git/node_modules) and explicitly notes it does not search file content. This differentiates it from fs_grep (content search) and fs_ls (directory listing), making the purpose unambiguous.

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

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

The description implies when to use it (for path pattern matching) but does not explicitly compare with siblings or state when to avoid it. The note about not searching content hints at fs_grep as an alternative, but this is not made explicit. Lacks clear 'use this instead of X' 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 provided, the description carries the full behavioral burden, and it delivers substantial context: skip rules for specific directories and large files, and a nuanced fallback (degrade to literal matching, return literal_fallback warning when there are hits, report INVALID_REGEX only on zero hits). This exceeds what the schema provides. Minor gaps remain (return format, case sensitivity), keeping it just below a 5.

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 compact, single-sentence block with no wasted words — every clause (search method, skip rules, fallback behavior, error reporting) earns its place and the core purpose is front-loaded. It is slightly dense as one run-on sentence, but efficient overall.

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 core search mechanics, skip rules, and fallback/error behavior are well covered, which is the heart of this tool. However, with no annotations and no output schema, an agent is left without the return format, the meaning of limit, and root usage details. For a 3-parameter tool these are notable gaps, making the description adequate but not 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 33% (only query has a description). The description's regex-fallback detail adds genuine meaning for the query parameter. However, root and limit semantics remain unexplained in both schema and description — what limit counts (matches per file vs total) and root's traversal scope are unclear, so the description only partially compensates for the low coverage.

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

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

The description states a specific verb+resource: '正則逐行搜尋檔案內容' (regex line-by-line search of file content). The skip rules (.git, node_modules, >1MB) further characterize behavior, clearly distinguishing it from sibling fs_find (filename-based search) and fs_read (file read). An agent can tell it apart from the filesystem siblings without opening other schemas.

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

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

The intended use case (searching text inside files by regex) is implied by the description's mechanism, making selection from filesystem siblings reasonably inferable. However, there is no explicit when-to-use guidance, no named alternative (like fs_find vs fs_grep), and no stated exclusions or preconditions. The usage context is clear but not articulated.

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 key behavior: it lists direct members, does not recurse, and does not read content. However, it omits other behavioral details such as the return format (names, paths, metadata), handling of hidden files, error behavior for nonexistent directories, or sorting order. This is minimal but not misleading.

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, front-loaded with the main action and immediately followed by the two key constraints. It is appropriately sized for a simple listing tool and avoids unnecessary words. It could add a bit more detail without becoming verbose, but it is well-structured and efficient.

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

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

The tool is simple (1 param, no output schema, no annotations) but the description leaves out essential information about the output. An agent calling fs_ls will receive a list of directory members but is not told whether it gets filenames, full paths, file types, or metadata. There is no output schema to fall back on, so the description itself should clarify the return format. It also doesn't mention error conditions or edge cases (e.g., empty directory, permissions). This is a significant gap for an agent to correctly process 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 defines a single 'dir' parameter with a default of '.', but has 0% description coverage. The tool description does not mention the parameter at all, leaving its semantics to be inferred from the property name. While 'dir' is intuitive, for a tool with zero schema coverage, the description should explicitly explain the parameter's meaning, format, and usage. It does not.

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

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

The description states a specific verb ('列出' = list) and resource ('目錄' = directory) with an explicit scope ('直屬成員' = direct members). It further clarifies what it does not do: '不遞迴' (not recursive) and '不讀內容' (does not read content). This clearly distinguishes it from siblings like fs_read (content reading) and fs_find (search).

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 constraints by stating it is non-recursive and does not read content, which tells the agent when NOT to use it (e.g., when recursion or file content is needed). However, it does not explicitly name alternatives (like fs_find or fs_read) or provide conditional guidance on when to select this tool over siblings. The guidance is implicit rather than 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 carries the full burden. It discloses key behaviors: PDFs return page PNG images, a default limit of 20 pages, total page count and continuation position are included, and it establishes observation state for fs_edit. It does not cover error handling, file encoding, or behavior on missing files, but the core behavioral traits are clearly communicated.

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, dense sentence that front-loads the purpose, then covers file-type differences, limits, return information, and the fs_edit prerequisite. No wasted words; every clause earns its place and the structure is logical.

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

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

Given 4 parameters, no output schema, and no annotations, the description covers the main usage but leaves gaps: it does not specify the return format for text files, the precise meaning of offsetLine and maxLines beyond 'line range', error handling, or the exact nature of the 'observation state'. It is reasonably complete for a read tool but not fully self-sufficient.

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

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

Schema coverage is only 25% (only 'pages' has a description). The description adds context by tying line range to text files, which maps to maxLines/offsetLine, but it does not explain those parameters individually. It gives examples for pages but does not compensate for the undocumented 'file', 'maxLines', or 'offsetLine' parameters beyond the implied line-range concept. Some value is added, but it is insufficient for the low coverage.

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

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

The description clearly states the tool reads files, distinguishes between text files (line range) and PDFs (pages parameter returning PNG images), and ties it to a specific prerequisite for fs_edit. It is unambiguous and distinct from sibling tools like fs_ls (listing) or fs_find/fs_grep (searching).

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

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

It explicitly states when to use the tool: before fs_edit to establish observation state. It also provides guidance on parameter selection based on file type (text vs PDF). However, it does not explicitly mention when NOT to use it (e.g., use fs_ls for listing) or name all alternative tools, so it earns a 4 rather than a 5.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It reveals two key behaviors: automatic parent directory creation and that it does not perform partial merges. This is helpful, though it could mention side effects like permanent deletion of existing content or permission requirements, but the current disclosure is adequate for a simple write 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 extremely concise—two short clauses. It front-loads the core purpose and key behavior (auto-create parents) and includes a critical exclusion (no partial merge). Every word earns its place, with no filler or redundant phrasing.

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 two-parameter write tool with no output schema, the description covers the essential operational behaviors: create/overwrite, parent directory creation, and the no-partial-merge restriction. Missing details like error handling or return values are not critical given the tool's simplicity, but a mention of whether the operation is atomic or what happens on missing directories would make it more 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%, so the description must compensate for missing parameter meaning. The description only mentions 'file' and 'content' implicitly through 'create new file' and 'overwrite', but does not elaborate on path format, content encoding, or how the two parameters interact. Since the schema provides only types and no descriptions, the tool relies on the parameter names being self-explanatory, which is insufficient for an agent to understand edge cases or expected formats.

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 action (create or overwrite), the resource (file), and explicitly contrasts with partial merging, which distinguishes it from siblings like fs_edit. The 'complete overwrite' and 'does not do partial merging' clauses make the purpose unambiguous.

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

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

The description defines when to use the tool (creating new files or fully overwriting) and when not to (when partial merging is needed). However, it does not explicitly name the alternative tool (fs_edit) as the HIGH calibration example did, leaving the alternative selection slightly implicit.

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. It explicitly states the write action to 'vitals', which implies mutation. But it does not disclose whether it overwrites or appends, any rate limits, or what happens on failure. It also doesn't describe the return format. For a simple side-effect tool, this is acceptable but incomplete.

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, concise sentence that leads with the core action and lists all collected data and the target. No extraneous information. Perfectly structured for agent consumption.

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

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

Given the tool's low complexity (no parameters, no output schema), the description covers the essential facets: what it triggers, what it gathers, and where it writes. It lacks explicit return behavior, but since vitals are observable via sibling tools, this is a minor gap. Reasonably complete for its scope.

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 zero parameters, so schema description coverage is trivially 100%. The description adds no parameter-specific meaning because there are none to document. Per the baseline rule for 0 parameters, a score of 4 is appropriate as there is nothing to explain.

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

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

The description states a specific action ('execute a heartbeat immediately') and lists the exact data collected (foreground window, idle seconds, clipboard changes, todo count) and the destination ('write to vitals'). It clearly distinguishes from sibling tools like screen_capture or list_windows by naming the aggregated write operation.

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

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

The description implies it is for triggering a heartbeat on demand ('immediately execute'), but does not explicitly state when to use it versus alternatives like vitals_latest (which reads vitals) or todo_list. No guidance on when not to use it or preconditions. However, the intent to force an update is discernible.

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 mentions '輕量' (lightweight) which hints at low resource cost, and the verb '列出' implies a read-only operation, but it does not explicitly state that it never modifies state, how it handles errors (e.g., no windows), or performance characteristics. Since the actual behavior is limited to listing, this is a minor gap, but the description is too skeletal to fully convey behavior.

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

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

The description is two sentences long, front-loading the core action ('列出前景視窗與所有有標題的視窗') and then providing a purpose ('輕量了解使用者正在做什麼'). Every word contributes to agent understanding; there is no fluff or redundancy.

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

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

Given the tool is a simple parameterless list operation with no output schema, the description provides the essential info: what is listed (foreground window and titled windows) and the format (process name + title). It does not describe the exact return structure (e.g., array vs object) or edge cases (e.g., empty list), but these are minor gaps. The tool is adequately specified for its simplicity, though a bit more detail on the return format would improve 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, and the schema coverage is trivially 100% since the schema is empty. Per the guidelines, a baseline of 4 is appropriate for tools with no parameters. The description adds no parameter documentation because none is needed; the tool is parameterless.

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 '列出' (list) and the resource '視窗' (windows), specifying exactly what is listed: the foreground window and all titled windows, with process name and title. This distinguishes it from sibling tools like screen_capture (visual capture) and read_clipboard (clipboard content), making the purpose unambiguous.

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

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

The description implies usage context by saying '輕量了解使用者正在做什麼' (lightly understand what the user is doing), which suggests it is for monitoring/understanding user activity without heavy overhead. However, it does not explicitly contrast with alternatives like screen_capture or web_fetch, so while context is clear, exclusions are missing.

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

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

With no annotations provided, the description fully bears the burden. It discloses that the tool mutates memory ('新增或更新') and implies upsert via name uniqueness, but it does not mention side effects, permissions, error behavior, or response format. This is a significant gap for a write 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 concise sentences with no wasted words. The core purpose is front-loaded, and the additional constraints (uniqueness, keyword purpose, content norms) are presented efficiently in a structured order.

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 write tool without an output schema, the description covers the essential purpose and basic usage. However, it omits any mention of return value, error conditions, or explicit upsert behavior (though name uniqueness implies it). It is adequate but leaves some gaps for an agent to infer.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds context for 'keywords' ('供日後檢索觸發') and gives content quality norms, but these are minor additions beyond what the schema already states. It does not explain name or content format beyond minimal requirements.

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

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

The description clearly states the verb and resource: '新增或更新長期記憶' (add or update long-term memory). It also specifies the name uniqueness constraint. However, it does not explicitly distinguish from sibling tools like memory_search or memory_forget, though the write nature makes it obvious.

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 when to use it (for writing memory) and gives content style guidance, but it does not explicitly contrast with alternatives or state when not to use it. No mention of 'use memory_search to retrieve' or 'use memory_forget to delete' is present.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals the destructive nature implicitly via 'delete' but does not state that deletion is irreversible, what happens when a memory with the given name doesn't exist, or whether any confirmation is required. For a mutation tool with zero annotation coverage, this is a significant gap.

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, front-loaded sentence with no waste. However, its brevity borders on under-specification rather than efficiency—for a destructive operation, more behavioral context would legitimately earn its place.

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

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

Although the tool is simple (1 parameter, no output schema), it is a destructive mutation with no annotations. The description fails to disclose key operational details like irreversibility and missing-name behavior, so an agent calling it correctly cannot fully anticipate the outcome.

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. The phrase 'by name' adds some meaning by indicating the name parameter identifies which memory to delete. However, it doesn't clarify valid name formats, uniqueness, or case sensitivity, leaving only minimal compensation for the uncovered 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 states a specific verb (delete/刪除), resource (memory/記憶), and method (by name/依名稱). This clearly distinguishes it from siblings memory_add, memory_search, and memory_list. The purpose is unambiguous even though the sentence is brief.

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. It doesn't name sibling tools like memory_add or memory_list, state when deletion is appropriate, or note any exclusions or prerequisites. Usage context is entirely absent.

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?

注解未提供任何安全或只读提示，因此描述需承担全部行为披露责任。描述仅说明'列出全部長期記憶'，没有说明操作是只读的、无副作用，也没有提及性能、分页、排序或错误处理。对于简单的列表工具，行为透明度严重不足。

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?

描述仅一句话，无冗余信息，目的明确且高效。虽然简短但信息密度高，没有浪费字节，符合简洁性要求。

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?

工具无参数、无输出模式，复杂度低。但描述仅简单声明列出全部长期记忆，未提及返回格式、内存条目的结构、是否分页等。考虑到兄弟姐妹工具的存在，输出可能类似，但描述未明确说明。对于简单工具，缺少数个关键上下文细节，但整体仍可用，故评分3。

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?

工具无参数，因此基线为4。描述没有重复参数信息（也没有参数可描述），且无必要添加额外语义。输入模式覆盖100%，无需补偿，符合基线标准。

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?

描述包含具体动词'列出'和资源'長期記憶'，明确表示这是列出所有长期记忆的操作。结合工具名和兄弟工具（memory_search、memory_add），可以清楚区分这是列表操作而非搜索或添加，虽然没有详细说明返回结构，但目的明确。扣除1分是因为描述简短，未涉及任何范围限定或返回值细节，但基本符合清晰标准。

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?

描述没有提供任何使用时机或替代方案说明。没有提及何时用memory_list而不是memory_search，也没有说明是否适合查看全部记忆或需要过滤场景。隐含的使用场景是'列出全部'，但未明确表达，也没有排除条件。

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 states it searches memory, without mentioning whether it is read-only, any side effects, rate limits, or what the return format looks like. This is a significant gap for a tool with zero annotation coverage.

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 unnecessary words. It front-loads the core functionality clearly and efficiently.

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

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

Given the tool's simplicity (1 parameter, no output schema) but the presence of many sibling memory tools, the description is incomplete. It does not clarify what results are returned, how results are ordered or filtered, or how it differs from memory_list. An agent would have significant uncertainty about expected behavior.

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 for the single 'query' parameter has 0% description coverage, but the description adds meaning by specifying that the query can be a keyword, name, or content. This goes beyond the parameter name alone, partially compensating for the missing schema documentation.

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

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

The description clearly states the tool searches memory by keyword/name/content, using a specific verb and resource. However, it does not explicitly distinguish itself from siblings like memory_list, so while the purpose is clear, differentiation is weak.

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 such as memory_list or memory_forget. There is no mention of contexts, exclusions, or alternative tools, leaving the agent to infer usage.

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

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It mentions the character limit but omits other relevant behaviors such as return format (does it return the raw text? empty string on no text?), error conditions (e.g., permission denied, inaccessible clipboard), or side effects (presumably none, but not stated). For a tool with zero annotation support, 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, front-loaded sentence that states the action, resource, and limit without any fluff. It is concise and perfectly structured for quick comprehension.

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 no-parameter read tool, the description is minimally adequate. It tells the agent what it does and the size cap, but it leaves out edge-case behavior (empty clipboard, non-text content) and return details. Given the lack of annotations and output schema, more clarity would improve completeness, though the tool's simplicity makes this a moderate 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?

The tool has zero parameters, and the schema confirms this with an empty properties object. The baseline for 0 parameters is 4, and the description adds no parameter information because none exists. The schema fully covers this aspect, so no additional description is 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 clearly states the action ('read'), the resource ('clipboard'), and adds a specific constraint (character limit of 20,000). It is unambiguous and distinct from all sibling tools, none of which mention clipboard functionality.

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 are no sibling clipboard tools, so no alternative routing is needed. The description implicitly conveys its use case (reading clipboard text) but does not specify when to use it over other tools, nor does it describe typical scenarios or exclusions (e.g., non-text clipboard content). Some guidance would be useful but is not critical given the lack of competing 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?

Since no annotations are provided, the description carries the full burden. It discloses the core behavior (captures full screen), the return type (PNG), and the ability for multimodal clients to directly view the image. This is above the minimum viable, though it does not mention permissions or potential capture of sensitive content, which would be ideal.

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 exceptionally concise: two sentences, front-loaded with the primary action, followed by the return format and a usage guideline. Every sentence serves a purpose with no waste. Ideal structure for a simple 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?

The description is largely complete for a parameterless tool: it states what it does and returns. However, it leaves minor ambiguity about whether 'full-screen' includes multiple monitors or just the primary display. It also omits any note on error conditions, though this is not critical for such a simple action.

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

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

With zero parameters, the baseline is 4. The description does not need to add parameter semantics, and it does not attempt to. It correctly leaves an empty schema; the description's mention of full-screen capture aligns with the no-parameter design.

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 (capture) and resource (local full-screen), and specifies the output format (PNG image). It is distinct from sibling tools like list_windows and read_clipboard, and the scope ('full-screen') differentiates it from per-window operations. No tautology or ambiguity.

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

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

The description provides a usage rule: 'call only when explicitly needed' (僅在明確需要時呼叫). This is a conditional guideline, but it does not compare with alternatives (e.g., list_windows for window titles or read_clipboard for text). It implies careful usage but lacks explicit when-to-use-vs-other 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 of behavioral disclosure. It does state that tasks are created in open status and that duplicate open tasks with the same name are rejected, which is useful. However, it omits details like return value, error handling, or whether the operation is idempotent. It provides some but not comprehensive 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, focused sentence that immediately communicates the core action and two key behavioral constraints. There is no redundant phrasing or filler. It is perfectly sized for the information it covers, making it highly efficient.

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

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

Given three parameters, no output schema, and no annotations, the description is insufficient. It fails to explain what 'weight' and 'content' represent or how they affect the todo creation. It also doesn't describe expected outcomes (e.g., success/failure messages) or additional constraints. The duplicate-rejection behavior is mentioned but not elaborated. Overall, it leaves significant gaps 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%, so the description must compensate for the lack of parameter meaning. It does not mention any of the three parameters (name, weight, content) or explain their semantics beyond the schema's type/default information. The description adds no value to parameter understanding, leaving the agent to infer meanings from the schema alone.

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

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

The description clearly states the action: '新增待辦任務' (add a new todo task) with a specific resource. It also mentions the open status and duplicate rejection, which adds specificity beyond just the verb. However, it does not explicitly differentiate this tool from sibling tools like todo_update or todo_list, though the action is distinct.

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. There is no mention of context, prerequisites, or exclusions. It doesn't indicate when to prefer this over todo_update (which likely modifies todos) or how it relates to todo_list. Usage is implied by the name but not explicitly communicated.

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 must carry the full burden. It states the tool lists todos but does not disclose whether it is read-only, what the response format looks like, or any side effects. Since 'list' implies a read operation, the agent can infer safety, but explicit behavioral disclosure is missing.

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

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

The description is extremely concise, containing only two short clauses. The core action ('列待辦') is front-loaded, and the parameter guidance is efficiently packed. There is no wasted text.

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

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

Given the tool's simplicity (one optional parameter, no nested objects, no output schema), the description covers the essential functional aspects: listing with optional filtering. It does not mention return format or pagination, but for a basic list tool this is acceptable. The description is sufficient for an agent to call it correctly.

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

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

The description adds meaning beyond the schema by explaining the default behavior when status is omitted ('省略則全部'). It clarifies that status accepts 'open' or 'done' and specifies the all-case. This is a meaningful addition to the bare enum definition, despite being brief.

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 todos ('列待辦'), which is a specific verb+resource. It is distinct from sibling tools like todo_add and todo_update, though it does not explicitly contrast with them. The purpose is immediately understandable.

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 explains the optional status parameter and that omitting it returns all todos. However, it does not provide guidance on when to choose this tool over alternatives such as todo_add or todo_update. Usage is somewhat implied by the listing action, but there are no explicit when-to-use or when-not-to-use instructions.

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 must disclose behavioral traits, but it only lists the three actions without explaining side effects (e.g., whether 'remove' is permanent, whether 'done' affects lists, reversibility, or permission requirements). The description is minimal and does not convey any consequences or safety implications of the mutations.

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

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

The description is extremely concise—a single sentence with the essential actions and id flexibility. It's well-structured and front-loaded, but it could include slightly more context without becoming verbose. The brevity is appropriate for a simple 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 tool with only two parameters and no output schema, the description covers the actions and id flexibility but omits behavioral details like return value, side effects, and error conditions. It's adequate for a simple operation but leaves gaps that the agent might need to know, especially regarding mutating actions.

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 compensate. It does add value by stating that 'id' accepts either an id or a name, which goes beyond the schema's generic string type. However, the 'action' parameter is only covered by the enum, which is self-explanatory; the description doesn't clarify any nuances about the actions beyond their labels.

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 supported actions (done, reopen, remove) and implies the target resource (a todo item via 'id'). It distinguishes itself from sibling tools like todo_add and todo_list by showing it mutates an existing todo. However, it doesn't explicitly name the resource as a 'todo' in the description, relying on the title, and doesn't explicitly contrast with siblings.

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

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

No guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing an existing todo id, or scenarios where todo_add would be more appropriate. The only usage hint is the id flexibility ('accepts id or name'), which is parameter-oriented rather than usage-oriented.

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 bears the full burden of behavioral disclosure. It reveals only that history is returned, but says nothing about ordering, what each record contains, units, pagination/truncation behavior, failure conditions, or the shape of the response. For a read tool, this is thin and leaves significant unknowns.

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 no wasted words, but this is under-specification rather than genuine conciseness. It omits essential behavioral and parameter details that a 1-2 sentence description could easily and cheaply contain to earn its 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?

While the tool is simple (one optional parameter, no annotations, no output schema), the absence of any output schema or annotation coverage raises the burden on the description. An agent cannot tell from this text what the response format contains, which a history-retrieval tool should specify. The lack of return-format guidance makes it incomplete 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%, so the description must compensate for the undocumented `n` parameter. The phrase '最近 N 筆' weakly implies `n` is a count of records, but it does not state the default of 20, the min/max bounds, or that `n` is optional. The description barely adds meaning beyond the schema and fails to fully compensate for the zero coverage gap.

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

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

The description states the tool returns the most recent N heart rate history records ('最近 N 筆心跳歷史'), which is a specific verb+resource that conveys historical data. It distinguishes itself from heartbeat_now and vitals_latest by implying a historical series rather than a live reading, though it never names those siblings or clarifies the exact boundary.

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 exists on when to use this tool versus alternatives like vitals_latest or heartbeat_now. There is no mention of use cases, exclusions, or conditions that would route an agent to this tool over its siblings, leaving the selection decision entirely to inference.

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

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

With no annotations provided, the description carries the full burden. It only states 'most recent heartbeat snapshot' without disclosing what a snapshot contains, whether it can fail, or any side effects. Minimal behavioral disclosure.

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 no redundant words. It is efficient, though it could include a bit more detail 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?

Given no output schema, no annotations, and a simple resource, the description should at least indicate what the snapshot contains or any relevant conditions. It does not differentiate from siblings or explain return format, leaving the agent with significant 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 tool has zero parameters, so the schema coverage is trivially 100%. The baseline for 0 params is 4. The description adds nothing about parameters because there are none, 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 identifies the specific resource (heartbeat snapshot) and scope (most recent). The noun phrase implies a retrieval action and is distinct from sibling tools like heartbeat_now (current) and vitals_history (history). Clear enough, though the verb is implicit.

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 on when to use this tool versus the siblings. It doesn't mention alternatives or conditions for selection. The agent must infer from the 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?

無 annotations，描述承擔行為揭露責任。它披露了拒絕本機/私網地址這項安全相關行為，並提及分頁限制，但未說明輸出格式、速率限制或潛在副作用。行為揭露不夠完整。

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

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

描述精簡，一句話即涵蓋核心功能、模式、分頁及安全限制。資訊密度高，但分號分隔的句子讀來略顯緊湊，仍有提升空間。

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?

工具簡單，無輸出 schema，描述已覆蓋主要面向：URL 類型、模式、分頁、限制。雖未提及返回格式，但對於此類讀取工具，資訊已足夠。

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 描述覆蓋率為 0%，描述必須補償。它清楚解釋了 mode 的兩種取值（readable=抽正文、source=原文），並提及 offset/limit 的有界分頁，為參數提供了重要語義。但未詳細描述 limit/offset 的具體效果，略有不足。

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?

描述明確指出工具讀取公開 HTTP(S) URL，並區分兩種模式（readable/source）及分頁行為。與兄弟工具（如 web_search）功能不同，能清楚分辨用途。

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?

描述說明了工具用途（讀取網頁）及限制（拒絕本機/私網），但未明確說明何時不應使用或建議替代方案。使用情境隱含，但沒有明確的排除條件或對比。

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 must fully disclose behavioral traits. It does mention two important limitations (no JS, no reading result page bodies) and that it returns summaries, which is useful. However, it omits other potentially relevant behaviors such as rate limits, auth requirements, or whether results are cached. Given it is a read-only search, some of these may be less critical, but the disclosure is incomplete.

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, compact sentence that front-loads the core purpose ('DuckDuckGo 公開網頁搜尋') before stating the return format and limitations. Every clause adds value, with no filler or repetition. It is appropriately sized for the tool's simplicity.

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, and the description covers the essential return format (title/URL/summary) and key limitations. With no output schema, this suffices for an agent to understand what it will receive. It does not specify the exact JSON structure of the results, but that may be inferred. For a search tool with a straightforward result set, the description is nearly 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 schema description coverage is 0%, meaning the description provides no additional meaning for the 'query' and 'limit' parameters. The description does not explain that 'query' is the search terms or that 'limit' caps the number of results. Since the schema itself only provides type and constraints (and 'limit' has a default), the description fails to compensate for the low coverage, leaving parameters only partially understood.

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

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

The description states a specific verb ('搜尋' = search), a specific provider (DuckDuckGo), and what it returns (titles/URLs/summaries). It also explicitly states what it does NOT do (no JS execution, no reading of page bodies), which clearly differentiates it from tools like web_fetch. This unambiguously distinguishes it from siblings.

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

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

The description implies usage for web searches but does not explicitly state when to prefer it over alternatives like web_fetch (which would retrieve full content). It states limitations (no JS, no page body) that hint at when NOT to use it for full-page retrieval, but no explicit guidance or exclusions are given. The context is clear but not proactively stated.

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