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

With no annotations, the description carries the full burden. It does disclose that the tool returns a boolean and message, which is a behavioral trait. However, it does not mention whether it makes a network call, has side effects, or requires authentication. For a simple check tool, the stated behavior is adequate but minimal.

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, with one sentence covering purpose and return value. It is front-loaded and contains 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?

Given the tool's simplicity (no parameters, no output schema), the description sufficiently covers the essential functionality: checking login status and returning state plus message. It does not explain edge cases like session expiration, but for a basic check tool, this is fairly complete.

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

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

The tool has zero parameters, and the schema shows no properties. The baseline for 0 params is 4, and the description adds no parameter semantics because none are 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 clearly states the verb 'check' and the resource 'login status', and specifies the return value: whether logged in and a message. This distinguishes it from the sibling tool 'login', which performs an action rather than checking state.

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 that this is used to verify login status, but does not explicitly state when to use it relative to 'login' or other operations. There is no mention of alternatives or exclusions, so usage context is implied but not spelled out.

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 full responsibility for behavioral disclosure. It specifies the local save path, automatic compression, inclusion of carousel images, and a critical access requirement (xsec_token). While it doesn't touch on authentication or error handling, the '重要' warning adds valuable context beyond what the schema alone offers.

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

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

The description is concise and well-structured: it states the primary action first, then the scope, compression, and an important prerequisite. Each sentence contributes necessary detail without redundancy or fluff, making it easy to parse quickly.

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

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

Given the absence of an output schema and annotations, the description covers the return value (file path list), side effects (local save, compression), and critical input constraints. It lacks edge-case behaviors such as failure modes or authentication requirements, but for a straightforward download tool, it provides sufficient contextual coverage.

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

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

The schema provides complete descriptions for all four parameters, giving 100% coverage, so the baseline is 3. The description's only parameter-related remark—the need for xsec_token—mirrors the schema's own noteUrl description, adding no new information beyond what is already structured.

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 downloads all images of a note, saves them to a specific local directory, and returns a list of file paths. This is a specific verb+resource+outcome that distinguishes it from sibling tools which handle searches, favorites, and content retrieval. The additional note about including carousel images further clarifies the exact scope.

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

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

The description provides a clear prerequisite: noteUrl must be a full URL with an xsec_token parameter sourced from get_favorites_list or search_notes_by_keyword. This tells the agent when and how the tool should be used, though it does not explicitly mention when not to use it or name alternative tools.

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

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

With no annotations, the description carries the burden. It discloses automatic calls to sibling tools and that all URLs include xsec_token. It does not mention failure handling, rate limits, or that it is a read-only operation, but the provided context adds meaningful value beyond what schema gives.

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, front-loaded with the main purpose, followed by the internal mechanism and a usage note. Every sentence earns its place; no redundancy or filler.

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

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

For a composite tool with 2 params and no output schema, the description explains its internal calls and token handling, which is essential. It lacks detail on result structure or partial failure behavior, but overall it is reasonably complete given the tool's 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 covers both parameters with descriptions (100% coverage), so the description adds little new param info. The note about avoiding timeouts is already in the schema's limit description. The description's mention of xsec_token is behavioral, not param-specific.

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 batches full note content (text and images) from the current user's favorites. It distinguishes itself from sibling tools by explicitly mentioning it internally calls get_favorites_list and get_note_content, making its composite nature 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?

Provides a clear use case ('适用于批量分析收藏的笔记') and explicitly describes the internal workflow. It does not explicitly state when NOT to use it or how it compares to using the sibling tools directly, but the context is sufficient for most agents.

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 adds auth context ('当前登录用户') and return limitations ('不包含详细内容和图片'), which are useful behavioral disclosures. It does not mention rate limits or error handling, but for a simple read tool these are not critical.

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

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

The description is two sentences, front-loads the main purpose, and includes key limitations without unnecessary detail. Every sentence earns its place, making it appropriately concise and well-structured.

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 one-parameter list tool, the description covers purpose, scope, and return content exclusions. It does not explain pagination or error behavior, but these are not essential given the tool's low complexity and the presence of sibling tools for more specific needs.

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 100% (single parameter limit with description, default, min, max). The tool description adds nothing beyond the schema, but per the baseline rule for high schema coverage, a score of 3 is appropriate.

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

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

The description clearly states it retrieves the note list from the current logged-in user's favorites, with a specific verb ('获取') and resource ('收藏夹'). It distinguishes from sibling tools like get_batch_notes_from_favorites and download_note_images by specifying the scope and return content.

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

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

The description provides clear context for when to use the tool (getting a list of favorites) and explicitly states it does not include detailed content or images, which implies other tools should be used for those needs. However, it does not name the alternatives explicitly.

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 and does disclose important behaviors: the vlm mode relies on external VLM APIs and lists supported providers and priority order, and it warns about potential failure without proper URL tokens. It also reveals image compression behavior. It does not mention rate limits or authentication requirements, but for the given information it is reasonably transparent.

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

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

The description is compact and front-loads the main purpose in the first sentence. It efficiently packs essential usage caveats (URL token requirement, image modes, API key options) into two dense sentences without unnecessary filler. Every clause contributes valuable information.

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 7 parameters, no output schema, and no annotations, the description covers the critical prerequisites (URL token), mode-specific behavior (original vs vlm), and mentions return formats (Base64, text description). It does not describe the full return structure or error conditions, but given the complexity, it provides enough context to invoke the tool safely and effectively.

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

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

The input schema already has 100% coverage with descriptions for all 7 parameters, giving a baseline of 3. The description adds extra value by explaining the difference between original and vlm modes, the API key priority, and the critical noteUrl requirement. This goes beyond the schema's per-parameter descriptions and enhances the agent's understanding of how to use the parameters effectively.

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

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

The description opens with a clear verb+resource: '获取笔记的完整内容' (get the full content of a note), which precisely states the tool's function. It differentiates from sibling tools like download_note_images and get_batch_notes_from_favorites by focusing on single-note content retrieval with optional components.

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

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

Usage context is well explained: it mandates using URLs with xsec_token from get_favorites_list or search_notes_by_keyword, explicitly warning that otherwise access may fail. It also clarifies when to choose 'original' vs 'vlm' image modes. However, it does not explicitly contrast with sibling tools (e.g., when to use get_batch_notes_from_favorites instead), though the purpose distinction is fairly clear.

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

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

No annotations are provided, so the description carries the burden. It discloses key behaviors: opening a browser, guiding user interaction, and automatically saving cookies. It does not cover failure modes or implications of repeated logins, but the disclosed traits are informative and accurate.

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

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

The description is two sentences, front-loaded with the explicit purpose, and every clause adds value (interaction method, cookie persistence). No unnecessary words or repetition.

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

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

For a simple login tool with one parameter and no output schema, the description covers the core flow and side effect (cookie saving). It could mention what happens if already logged in or how to verify success, but the provided information is sufficient for basic use.

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

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

Schema description coverage is 100% for the single parameter (timeout) with a detailed description in the schema. The tool description adds no extra parameter context, but the schema already fully explains the parameter, reaching the baseline of 3.

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 (login) and the resource (小红书/Xiaohongshu), and further specifies the interaction mode (browser window, QR/password) and outcome (saving cookies). This differentiates it from siblings like check_login_status, which only checks state.

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

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

The description implies this is a prerequisite for other tools by mentioning cookies for later use, but it does not explicitly state when to use it or contrast it with check_login_status. The usage context is implied 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?

No annotations are provided, so the description must disclose behavioral traits like authentication needs or side effects. It only mentions the return format, without stating whether login is required, the read-only nature, or any rate limits. The description carries the full burden and falls short.

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

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

The description is a single sentence that states the purpose and output, with no unnecessary words. It is front-loaded 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?

With no output schema, the description explains the return list fields, which is necessary. However, it lacks contextual details such as authentication requirements or behavior when no results are found. It is minimally complete but could be more helpful.

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

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

Schema coverage is 100% with descriptions for all parameters, so the baseline is 3. The description does not add any additional meaning beyond what the schema already provides; it only repeats 'search by keyword'.

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 'Search Xiaohongshu notes by keyword' with a specific verb and resource. It also lists the return fields, distinguishing it from sibling tools like get_favorites_list or download_note_images.

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

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

Usage is implied by the name and description: use it when you need to search notes by keyword. However, it does not explicitly mention alternatives or when not to use it, nor does it provide context that search results can lead to further actions like get_note_content.

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