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

With no annotations, the description carries the full behavioral burden. It discloses that the tool only checks installation/login/identity and does not perform the login itself (the user must execute the command), which is valuable. It stops short of explicitly stating the tool has no side effects or describing the exact response shape, but it covers the principal behavioral trait.

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

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

Three sentences with no filler: the first states what is checked, the second states when to invoke it, and the third states the follow-up action. Every sentence earns its place and the key purpose is front-loaded.

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

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

For a parameterless diagnostic tool with no output schema, the description is complete: it specifies the checked state, the triggering error condition, and the guided next step. Nothing essential is missing for an agent to decide to call it and act on 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 tool has zero parameters and 100% schema coverage, so there is nothing for the description to add about parameter meaning. The baseline of 4 applies because no parameter documentation is needed.

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 names exact resources: whether lark-cli is installed, current login status, and available identity (user/bot). This clearly distinguishes the tool from sibling read/write tools for docs, sheets, and bases, which perform data operations rather than auth diagnostics.

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 an explicit trigger condition: when read/write operations report permission errors, call this tool first to troubleshoot. It also tells the agent what to do if not logged in (follow returned guidance and have the user run login on the deployment machine), leaving no ambiguity about when and how to use it.

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 present, so the description carries the full behavioral disclosure burden. It characterizes the tool as a listing/inspection operation ('列出', '查看'), which implies read-only behavior, and it documents accepted input forms. However, it does not explicitly state that it makes no modifications, mention auth prerequisites, or describe rate limits, errors, or pagination.

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

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

Two purposeful sentences: the first states the action and output, the second states accepted input formats. Every sentence earns its place, with no filler or redundant detail.

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 one required parameter, full schema coverage, no output schema, and no annotations, the description gives a clear enough output picture (table_id, field names, types, options) and the supported input variants. It falls short of 5 only because it does not explicitly describe the return structure or state that the operation is read-only.

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 explanation of base_token formats ('多维表格 URL、wiki 知识库 URL 或裸 token') largely mirrors the schema's '/base/、/wiki/ 链接' wording and adds only marginal explicitness about bare tokens.

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 specific action ('列出'), the resource ('飞书多维表格（bitable）'), and the deliverable ('所有数据表及每张表的字段 schema'), far beyond a tautology. It also implicitly distinguishes itself from siblings like read_feishu_base_records by focusing on schema discovery rather than record read/write.

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

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

The description explicitly says this tool is for use '读写记录前' to discover table_id, field names, and field type conventions, which is a clear trigger condition. It does not explicitly rule out alternatives or name sibling tools, but the bitable-vs-doc/sheet distinction is strong enough to guide 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 burden. It discloses return shape (object array with record_id and field values), filtering operators, sorting, projection, pagination, and token formats. However, it doesn't mention rate limits, error behavior, or whether this is a read-only operation (though the name implies it).

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

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

The description is compact and front-loaded with the core purpose, then lists capabilities and prerequisites in a logical order. It packs substantial information into two sentences without redundancy, though the operator list is long and could be considered dense.

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

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

For a read tool with 9 parameters and no output schema, the description covers the return format, filtering, sorting, projection, pagination, and token handling. It lacks explicit mention of pagination limits beyond the schema's limit parameter, but the schema covers that. The prerequisite reference to describe_feishu_base completes the usage context.

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

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

Schema description coverage is 100%, so the schema already documents all 9 parameters. The description adds context about base_token URL formats and the prerequisite for table_id/field names, but most parameter semantics are already in the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool reads Feishu bitable records and returns an object array with record_id and field values. It distinguishes itself from siblings by naming describe_feishu_base as a prerequisite and by listing filtering/sorting/projection/pagination capabilities, which separates it from read_feishu_doc and read_feishu_sheet.

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

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

The description explicitly instructs to first use describe_feishu_base to obtain table_id and field names, and explains base_token accepts URL, wiki URL, or bare token. This gives clear when-to-use guidance and a prerequisite step, though it doesn't explicitly name alternatives for exclusion.

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 automatic routing between docx and wiki links, the return format (Markdown), and the JSON structure with document_id/revision_id/content. It also explains the effect of different scope values (outline, section, keyword) and detail levels. It doesn't mention rate limits, auth requirements, or error behavior, but for a read tool the disclosed behavior is quite thorough.

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

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

The description is compact and front-loaded with the core purpose, then lists capabilities in a dense but organized way. It packs a lot of information into a few sentences without redundancy. Minor deduction because the parameter interaction details (e.g., keyword with 'a|b') could be seen as schema territory, but overall it's 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?

For a read tool with 8 parameters and no output schema, the description covers the main usage patterns, return format, and routing behavior. It doesn't explain error cases, pagination, or auth prerequisites, but the sibling check_feishu_auth exists for auth. The description is complete enough for an agent to select and invoke the tool correctly for common scenarios.

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

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

Schema description coverage is 100%, so the schema already documents all 8 parameters. The description adds value by explaining the workflow: scope=outline for structure first, section needs start_block_id, keyword supports 'a|b' branches, and detail=with-ids is needed for later partial updates. This goes beyond the schema's field-level descriptions and helps an agent understand how parameters interact.

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

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

The description states a specific verb ('读取' / read), a clear resource (飞书云文档), and explicitly distinguishes between document links (/docx/) and wiki links (/wiki/) with automatic routing. It also names the return format (Markdown) and the JSON structure, making it immediately clear what this tool does and how it differs from siblings like read_feishu_sheet or read_feishu_base_records.

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 guidance: it recommends using scope=outline first to see the structure, explains when to use section (needs block id), and mentions keyword positioning. It also implies when to use this tool vs alternatives by focusing on document content reading, while siblings handle sheets and base records. The routing note for /docx/ vs /wiki/ links is a clear when-to-use signal.

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 that it returns CSV text by default, that detail=cells exposes formulas/styles/comments, that omitting sheet params yields a sheet list, and that large tables may be truncated (the truncation note is in the schema but the description reinforces it). The read-only nature is implied by '读取'. This level of behavioral detail exceeds what a typical tool description provides.

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 core purpose and then quickly covers the key behavioral branches. There is no redundant wording; every clause adds information. The structure is efficient and scannable.

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 six parameters, no output schema, and no annotations, the description is remarkably complete. It covers the main use cases, the two modes, the detail option, and the truncation caveat. It does not explicitly mention authentication or error handling, but those are typically implied for read tools and not essential for correct invocation. For a read tool, this description provides all the context an agent needs 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?

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the interplay between sheet_name/sheet_id and the list mode, and by stating the default behavior of range and detail. While some of this is also in the schema (e.g., '都不传时返回子表清单'), the description synthesizes the parameter logic into a coherent flow, which helps an agent understand how the parameters interact rather than just their individual meanings.

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 a Feishu spreadsheet (电子表格), explicitly distinguishing it from multidimensional tables (不是多维表格). It also differentiates from sibling tools by specifying the two operational modes: returning a sheet list when no sheet is given, or reading a region when a sheet is provided. The verb '读取' (read) plus the resource '电子表格' makes 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 gives explicit conditional guidance: '不传 sheet_name/sheet_id 时返回工作簿的子表清单；传入子表后按区域读取' (without sheet params, return the sheet list; with a sheet, read by region). It also clarifies the detail parameter options and the default CSV output. While it doesn't explicitly name alternative tools like read_feishu_base_records, it clearly delimits its scope by stating it is not for multidimensional tables, which effectively routes agents to the correct sibling. This is strong usage guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the return fields (title, type, URL, update time) and the permission scope. It does not explicitly state that it is read-only (though implied by being a search), nor does it describe pagination behavior or rate limits. It is adequate but not exhaustive.

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, efficient sentence that front-loads the core purpose, mentions the return fields, and provides a hint about follow-up tools. There is no fluff or redundancy, and every part earns its place.

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

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

Given the tool's complexity (8 parameters, 1 required) and absence of an output schema, the description provides essential context: the scope of search, return fields, keyword length, and a pointer to related tools. It does not explain pagination or advanced syntax, but these are covered in the schema, so the description is sufficiently complete for an agent to use it correctly.

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

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

Schema description coverage is 100%, so all parameters have descriptions in the schema. The description adds minimal parameter-specific value beyond what the schema already provides (e.g., it mentions the 30-character limit, which is also in the schema). It does not clarify parameter semantics beyond the schema, so a baseline of 3 is appropriate.

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

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

The description clearly states the tool's purpose: searching Feishu cloud objects (documents, sheets, bitables, wiki pages, etc.) by keyword, returning title, type, URL, and update time. It explicitly names the sibling tool read_feishu_doc for further read/write operations, distinguishing itself as a discovery tool.

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 this tool (to find objects) versus siblings (to read/write them after obtaining URL/token). It mentions the keyword length limit and permission scope. However, it does not explicitly state when NOT to use it or provide alternative search methods, but the context is clear enough for an agent.

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 behavioral disclosure burden. It covers batch limit, mode-specific record structure, and field value type conventions, which are essential for correct invocation. However, it does not disclose partial-failure handling, idempotency, or overwrite semantics—traits an agent would need for a side-effectful write 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 compact and well-structured: purpose, batch limit, mode semantics, value conventions, and prerequisite advice are delivered in three sentences. Every sentence contributes non-redundant information with no 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 batch write tool with four parameters and no output schema, the description covers all essential invocation details: mode, records shape, value types, and a prerequisite check. Missing error/response behavior is a gap, but it is not fatal for constructing a correct request.

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

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

While the schema has 100% coverage, the description adds a crucial mapping of Feishu field types (text, select, date, boolean, number) to JSON value conventions, which is absent from the schema. It also clarifies that update mode requires each item to contain both record_id and fields, a conditional requirement not enforced by the static 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 tool batch adds or updates records in Feishu bitable, naming both the operation and the resource. It distinguishes itself from siblings like read_feishu_base_records and describe_feishu_base by focusing on writing records, and the sibling list confirms write_feishu_doc/write_feishu_sheet target different resources.

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 advises using describe_feishu_base to confirm writable fields, which is a clear prerequisite. It also implies usage scope by focusing on bitable records, but does not explicitly exclude other write tools. The mode guidance helps select between create/update parameters, but no alternative tools are named for exclusion.

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 the destructive nature of replace (discards original content) and clarifies that replace_text requires exact text matching. It also states the create return value. It doesn't cover auth, rate limits, or error cases, but the key side effects are 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 a single paragraph that front-loads the core purpose and efficiently lists all modes with their constraints. Every sentence contributes useful behavioral or semantic information; there is no redundancy or filler.

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

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

The description explains create's return value but is silent about append/replace/replace_text return values or error behavior. With no output schema and no annotations, this leaves some ambiguity for an agent. However, the mode semantics and destructive warnings cover the most critical operational aspects.

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 provides 100% parameter coverage, so the baseline is 3. The description adds substantial meaning beyond the schema by explaining the mode enum values in detail, noting that content is Markdown, and emphasizing that pattern must match exactly. This goes beyond the bare schema 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 identifies the tool's purpose: writing Markdown content to Feishu cloud documents (docx/wiki). It enumerates four distinct modes (create, append, replace, replace_text), each with a specific verb and resource, and the modes naturally distinguish it from sibling read/search/sheet tools.

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

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

The description provides explicit guidance on when to use each mode, including a caution for replace ('慎用') and a recommendation for replace_text for small changes. It does not explicitly name alternative sibling tools or conditions to avoid this tool, but the mode-level guidance is strong enough to route correct 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?

With no annotations, the description carries the full burden of behavioral disclosure. It explains what each mode does (pastes CSV, appends with header, writes values/formulas) and gives a concrete cells example, which is helpful. However, it omits important side effects such as overwrite behavior (allow_overwrite parameter), what happens to existing data, authentication requirements (check_feishu_auth exists as a sibling), or rate limits. For a write operation, this level of disclosure is insufficient for full 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 dense sentence but packs in all essential mode information without fluff. It is front-loaded with the purpose and then enumerates modes. While a bulleted list might improve readability, the current structure is efficient and every clause earns its place. Slightly verbose but not bloated.

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 (10 parameters, 3 modes, no output schema, no annotations), the description covers the core usage scenarios well: it explains all three modes, which parameters are required for each, and provides a concrete example. It lacks guidance on parameter conflicts (e.g., both url and spreadsheet_token provided) and the effect of allow_overwrite, but those are covered in schema descriptions. The description is adequate for an agent to invoke the tool correctly in most cases.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds significant value by linking parameters to modes: csv for overwrite/append, cells and range for set_cell, start_cell for overwrite, and clarifying that append treats the first row as a header. It also provides a detailed example of the cells format. This goes beyond the schema's individual descriptions and aids correct invocation.

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

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

The description clearly states the verb '写入' (write) and the resource '飞书电子表格' (Feishu spreadsheet), and further breaks down into three distinct modes with concrete behaviors. This distinguishes it from siblings like read_feishu_sheet (read) and write_feishu_doc (doc vs sheet), leaving no ambiguity about what the tool does.

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

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

The description provides explicit mode-specific instructions (overwrite, append, set_cell) that act as usage guidance within the tool, including what each mode expects (CSV, anchor cell, sheet last row, cells array). However, it does not mention when to choose this tool over alternatives like read_feishu_sheet or write_feishu_doc, relying on the name for that distinction. This is a minor gap given the tool's name is self-explanatory.

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