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

No annotations are provided, so the description carries the behavioral burden. It discloses that the search matches across title, abstract, and author fields, which is useful. However, it does not explain result ordering behavior, pagination, or any API-specific constraints beyond the schema.

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 the core action front-loaded. The audience clause '研究者获取最新学术动态' adds mild context but is not verbose or redundant enough to hurt the structure.

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 moderately complex with an output schema and fully documented parameters, so much of the operational context is covered elsewhere. The main gap is the lack of usage guidance relative to the many search-related sibling tools, making the description acceptable but incomplete.

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

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

Schema description coverage is 100%, so the schema already fully documents query, sort, and limit. The description's mention of title/abstract/author fields relates to search scope rather than the parameter syntax, adding little beyond the 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 opens with a specific verb and resource: '搜索 arXiv 论文' (search arXiv papers), and further clarifies the matching scope as title/abstract/author. This clearly distinguishes it from generic sibling tools like web_search and exa_search by naming a unique academic corpus.

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 no explicit guidance about when to use this tool versus alternatives such as web_search or exa_search. The phrase '研究者获取最新学术动态' implies a research-oriented use case, but there are no exclusions, prerequisites, or comparisons to sibling tools.

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

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

No annotations are provided, so the description carries the burden. It indicates a query operation ('查询') and states the interface is public ('公开接口'), implying read-only behavior and no authentication. However, it does not mention rate limits, failure modes, data freshness, or what happens with invalid codes, leaving some behavioral uncertainty.

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 conveys the core action, target, and data source with no redundant fluff. It is front-loaded with the main function, and the parenthetical source adds useful context without bloating the 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?

For a simple lookup tool, the description covers the essential purpose and source, while the output schema and fully described parameters fill in return and input details. The main missing piece is usage differentiation from similar cninfo sibling tools, but the tool's simplicity keeps this from being a major gap.

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

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

Schema description coverage is 100%, so the schema already documents both 'code' and 'market' parameters. The description adds no parameter-level detail, beyond confirming the general purpose. Baseline 3 is appropriate because the schema carries the semantic load.

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 specifies a verb ('查询') and resource ('A股公司基本信息'), and identifies the data source as the Eastmoney public interface. It is contextually distinct from sibling tools like cninfo_financial_analysis and cninfo_compare_companies, though it does not explicitly name those alternatives.

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 no guidance on when to use this tool versus alternatives such as cninfo_financial_analysis or cninfo_compare_companies. There is no mention of when not to use it, nor any exclusions or conditions. The agent must infer usage from the tool name and sibling list.

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, but it only states the action and says nothing about side effects, data source, delays, rate limits, or the read-only nature. An agent cannot tell from the description whether any side effects or limitations exist beyond the basic purpose.

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 entirety is a single 10-word sentence with no fluff. It is front-loaded with the main purpose and contains only essential information, making it highly concise.

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 both parameter and output schemas present, the description needs only to give essential context. It does state the market (A-share) and the comparison aspect, but it omits any caveats like the meaning of 'core indicators' or whether the tool is read-only, and it does not explain how years interacts with 'latest'. This suffices at a basic level but leaves gaps for an agent.

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

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

Schema description coverage is 100%, with both parameters (codes and years) already described. The description adds only 'latest fiscal year' language, which could conflict with the years parameter allowing multiple years, and does not elaborate on what 'core indicators' means, so it provides no additional value over the schema.

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

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

The description clearly states the action (compare), the resource (multiple A-share companies), and the specificity of data (core indicators of the latest fiscal year). This distinguishes it from single-company tools like cninfo_company_profile and US-focused sec_compare_companies.

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 implicitly suggests using it when comparing multiple A-share companies' latest financial metrics, but it does not explicitly state when to use it over alternatives, mention exclusions, or provide any routing guidance relative to sibling tools like cninfo_financial_analysis.

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 behavioral disclosure burden. The verb 查询 ('query') conveys a non-mutating read operation, and the listed indicators clarify expected content. But the description does not disclose whether results are annual snapshots, how missing indicators like R&D ratio are handled, or whether there are data-coverage caveats.

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 resource and then packs the key indicator examples into a parenthetical list. Every word earns its place; there is no repetition of the tool name or schema details.

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

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

For a two-parameter tool with a full output schema and 100% parameter documentation, the description is mostly complete: it names the exact metrics and the schema covers accepted inputs. The only meaningful gap is the absence of selection guidance among sibling cninfo tools, which is a moderate completeness shortfall.

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 code and years parameters are already fully documented in the schema. The description adds no parameter-specific meaning; the listed indicators are about the output, not the inputs, so it provides no additional parameter guidance beyond the schema's baseline.

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: query financial-analysis metrics for A-share companies, and it names the specific indicators returned (ROE, net margin, revenue growth, gross margin, R&D ratio). It does not explicitly differentiate it from sibling tools like cninfo_company_profile or cninfo_compare_companies, so it stops short of a 5.

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

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

Usage is implied: an agent can infer to use this tool when it needs financial-ratio indicators for an A-share company, based on the indicator list. However, there is no explicit guidance about when to choose this over the sibling cninfo tools or web_search, so the guidance is not complete.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that it is a semantic search, which suggests query style matters, but it does not disclose return format quirks, whether results include snippets, or rate limits. The description is minimal but not contradictory.

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

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

The description is a single, concise sentence that front-loads the main purpose and scope. No wasted words, but it could also mention when to use alternatives.

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 has two parameters, an output schema, and no annotations, the description covers the basic purpose but lacks usage guidance and behavioral details. It is adequate for a simple search tool but does not fully help an agent decide between this and overlapping siblings.

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 100% schema description coverage, the schema already documents the query parameter and num_results. The description adds only high-level guidance on query phrasing, which is already in the schema. It does not elaborate on the meaning of num_results or any other nuances, so value added is limited, but it reinforces the query style tip.

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 ('search') and resource ('Exa'), and specifies it's a semantic English search aimed at overseas tech trends, industry reports, and papers. However, it does not explicitly distinguish itself from siblings like 'web_search' or 'arxiv_search', which could overlap in purpose.

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 English semantic search but gives no explicit guidance on when to choose this over alternatives like 'web_search' or 'arxiv_search'. No exclusions or alternative tool names are provided, leaving the agent to infer.

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 behavioral burden. It clarifies it fetches current hot lists from named platforms)Skip. It does not mention failure modes, rate limits, live-source behavior, or output limitations, but for a simple fetch operation the core behavior is clear.

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?

One concise sentence front-loads the action and then lists supported platforms. No waste.

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

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

For a single-parameter tool with an output schema, the description adequately identifies the data source and platform set. It could mention expected use cases ('when user asks today's hot topics') or note live-source behavior, but it is largely 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 only documents 'platforms' as a list with a default of all platforms. The tool description adds the allowed platform values (知乎/B站/GitHub趋势/HN), giving meaning beyond the 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?

Description uses a specific verb ('获取') and resource ('主流平台当前热搜榜单'), and enumerates the platforms (知乎, B站, GitHub趋势, Hacker News). It clearly states what the tool does, though it does not explicitly contrast with sibling search/recommendation 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 implies when to use it (when hot topics from mainstream platforms are needed) and the schema adds default behavior (all platforms if not specified). However, it gives no explicit guidance on when to prefer this over siblings like web_search, juejin_recommended, or arxiv_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?

No annotations are provided, so the description carries the full burden. It discloses the key behavioral trait: it removes ads/navigation/sidebars and outputs clean Markdown, which is useful. However, it does not mention error handling, network requirements, or limitations (e.g., dynamic content). The description gives a reasonable overview but lacks depth for edge cases.

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

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

The description is a single, concise sentence that front-loads the primary action and output format. It includes the library name for specificity and contains no redundant words or filler. Every element 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?

The tool is relatively simple, with three well-documented parameters and an output schema present. The description covers the core behavior (fetch and clean) but omits important operational details such as how the tool handles unreachable pages, timeouts, or non-HTML content. Given the absence of annotations, this is a moderate gap in 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?

Schema coverage is 100% — every parameter has a description in the schema, so the baseline is 3. The description does not add any additional parameter-level meaning beyond what the schema already provides; it only restates the tool's overall behavior. No extra semantic value is contributed, so the score stays at the baseline.

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 (抓取网页正文), the resource (web page), and the output format (干净 Markdown), with a specific mention of the library used (trafilatura). It also distinguishes itself from siblings like web_search (searching) and fetch_hot_topics (lists) by focusing on fetching a single page and cleaning it.

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

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

The description implies the tool is for fetching a specific URL and cleaning it, but it does not explicitly state when to prefer it over alternatives like parse_pdf or web_search. There is no explicit 'when to use' or 'when not to use' guidance, so an agent must infer the appropriate context from the purpose alone.

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

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

No annotations are provided, so the description carries the full burden. It only says the tool compares current snapshot data; it does not disclose whether the operation is read-only, whether authentication is needed, whether rate limits apply, or what behavioral side effects or constraints exist. This is minimal for a tool with no annotation support.

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

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

The description is a single, direct sentence with no filler or redundant repetition of the title. It front-loads the core purpose and earns its place, though it is terse in other dimensions.

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 only one parameter and an output schema present, the structural complexity is low and return-value details are covered elsewhere. However, the lack of usage guidance and behavioral context means the description is only minimally adequate for an agent deciding when and how to invoke the tool.

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

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

The schema already documents the only parameter `repos` with an example, and schema description coverage is 100%. The description adds the context of comparing snapshots, but does not add meaning beyond the schema for the parameter itself, so the 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 states a specific action ('对比' / compare) and a specific resource ('多个 GitHub 仓库的当前快照数据' / current snapshot data of multiple GitHub repos). This distinguishes it from sibling github_search_repos, which is about searching repos rather than comparing existing repo snapshots.

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 given about when to use this tool versus alternatives such as github_search_repos. The agent must infer usage from the tool name and sibling list; there is no explicit when-to-use or when-not-to-use guidance.

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

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

No annotations are provided, so the description carries the burden. It discloses a behavioral trait: the tool focuses on quantitative metrics (stars/forks/activity) and trend analysis, which goes beyond a generic search. However, it doesn't mention rate limits, authentication, or return format, but given the output schema existshareholders, the core behavior is transparent enough.

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

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

The description is a single, concise sentence that front-loads the purpose (trend search) and outcomes (quantitative metrics). It's efficient with no filler, earning a high score for its brevity and clarity.

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 has an output schema (filling in return values), 3 well-documented parameters, and a straightforward search use case, the description suffices. It covers the core purpose and result orientation. Minor gaps like not mentioning comparison with siblings are offset by the existence of an output schema and simple parameter semantics.

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 documents all three parameters (query, sort, limit) with clear descriptions. The description adds a trend-oriented framing but doesn't add new parameter-level meaning beyond what's in the schema. Baseline 3 is appropriate since the schema carries the load.

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) and resource ('GitHub 仓库趋势' - GitHub repository trends), and clarifies it translates trends into metrics (stars/forks/activity). It distinguishes from siblings by focusing on trend metrics rather than generic search or comparison, though it doesn't name a sibling explicitly.

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 exploring trends and quantifying popularity, but doesn't explicitly state when to use it vs. alternatives like github_compare_repos (for comparison) or web_search (for general web results). The trend-focused angle gives some guidance, but no exclusions or alternative names are mentioned.

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

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

No annotations are provided, so the description carries the full disclosure burden. It only restates the browse action and does not mention sorting, result shape, pagination, rate limits, or empty/error behavior. This is minimal 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 efficient sentence with a parenthetical list of categories. It is front-loaded and contains no filler, so 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?

An output schema exists, so return values do not need explanation. The description plus the input schema is adequate for a simple two-parameter call, but it lacks behavioral context and sibling differentiation, which matters because no annotations are present.

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 value by listing valid category values (ai/frontend/backend/android/ios/freebie/article), which the schema does not enumerate. Limit semantics are already covered by the schema's default and maximum.

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 ('浏览'/browse) and resource ('掘金文章' Juejin articles), and it enumerates the supported categories. It does not explicitly distinguish itself from sibling tools like juejin_recommended, so it misses the top bar.

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 phrase '按分类浏览' implies category-based browsing, but there is no explicit guidance about when to use this tool versus alternatives such as juejin_recommended or fetch_hot_topics. Context is implied rather than stated.

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 bears the full burden of behavioral disclosure. It only states that the tool discovers recommended articles; it does not disclose pagination behavior via cursor, the hot/new sort semantics, the default/maximum limit, or whether any rate limits or authentication apply. There is no contradiction, but the behavioral information is 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 short and contains no waste, but it is under-specified to the point of reading as a tagline rather than a functional description. It lacks the context that could be added in a sentence or two without sacrificing conciseness.

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 input and output schemas cover the mechanics of the call, but the description does not explain how to choose this tool over juejin_by_category, nor does it describe the behavioral flow around pagination or sort modes. For a tool with a direct sibling on the same platform, this is insufficient contextual guidance.

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 provides complete descriptions for all three parameters (sort, limit, cursor), including defaults and constraints. The description adds no parameter-level detail, but with 100% schema coverage the 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 names a concrete resource ('掘金技术社区推荐流文章') and implies an action with '发现', but it is phrased as a noun phrase ('recommended feed article discovery') rather than a clear operational verb like 'List' or 'Fetch'. It does not explicitly differentiate from the sibling tool juejin_by_category, relying on '推荐流' to carry that distinction.

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

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

No usage guidance is provided. The description does not state when to use this tool over juejin_by_category, web_search, or other siblings, nor does it mention any exclusions or prerequisites. The agent is left to infer context entirely from the tool name and input schema.

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 of behavioral disclosure. It states the core function (parse to Markdown, preserve tables) but does not disclose potential issues like handling scanned PDFs, password protection, or error behavior. The presence of an output schema mitigates the lack of return-format details, but other behavioral traits remain undisclosed.

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

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

The description is a single sentence that is front-loaded with the core purpose and scope. Every word earns its place; there is no fluff or repetition.

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

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

The tool is relatively simple with four parameters, full schema coverage, and an output schema provided. The description covers the essential usage (local and URL, table preservation). Minor caveats like PDF size limits or authentication are not mentioned, but for typical use the description is 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 description coverage is 100%, so the schema fully documents all four parameters (url, file_path, max_pages, extract_tables). The description does not add any extra meaning beyond the schema, but it also does not need to. Baseline 3 is appropriate given full 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: parse PDF to Markdown, preserving tables, and explicitly supports both local files and URLs. It clearly distinguishes from siblings like fetch_page or web_search, which are for web content, not PDFs. The purpose is 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 context (local vs URL) but does not explicitly state when to use this tool over alternatives. It implies that for PDF files this is the tool, but no exclusions or alternative names are provided. 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 provided, the description carries the safety burden. '查询' clearly indicates a read-only retrieval, and '结构化数据' signals the output type. However, it does not disclose behavior around invalid identifiers, data freshness, rate limits, or the ticker-vs-cik requirement, leaving some behavioral uncertainty.

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 with no filler. It front-loads the source (SEC EDGAR), the action (query), and the output type (structured financial data), earning every word.

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 has an output schema, return values need not be described. However, the description lacks usage boundaries and sibling differentiation, and the all-optional parameters (ticker vs cik) are not explained at the description level. It is minimally adequate but leaves selection and invocation decisions partially unsupported.

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 parameters are already documented in the schema. The description adds examples ('营收/净利/研发支出') that map to the metrics parameter, but it does not add meaningful semantics beyond what the input schema already provides.

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?

Description clearly states the verb '查询' (query), the resource '美股公司财报（SEC EDGAR）', and the kind of data returned ('营收/净利/研发支出等结构化数据'). It is unambiguous about the tool's function, though it does not explicitly distinguish itself from the sibling sec_compare_companies.

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 such as sec_compare_companies, cninfo_company_profile, or web_search. There are no exclusions, prerequisites, or comparisons to siblings, so an agent must infer the appropriate context from the name and schema alone.

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

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

No annotations are provided, so the description carries the disclosure burden. It discloses the comparison scope and time alignment ('同一财年'), and the verb '对比' implies a read-only operation. However, it does not mention prerequisites, data source limitations, or behavior for invalid tickers, leaving some transparency gaps.

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

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

The description is a single, front-loaded sentence with no filler. Every phrase contributes essential information: multiple companies, US market, same fiscal year, and core indicator comparison.

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 moderate complexity, fully documented parameters, and existing output schema, the description is largely sufficient for invocation. It could mention alternative tools or limitations, but the combination of description and schema covers the essential invocation details.

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 meaningful context by specifying that companies are compared in the same fiscal year and by pointing to 'core indicators,' which aligns with the metrics default. This gives an agent more insight into how the parameters relate to each other.

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

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

The description clearly states a specific action: comparing core indicators of multiple US-listed companies within the same fiscal year. The '美股' qualifier distinguishes it from sibling tools like cninfo_compare_companies, and '多家' distinguishes it from singular lookups such as sec_company_facts.

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: use this tool when comparing multiple US listed companies on their core metrics for the same fiscal year. It does not name alternatives or exclusions explicitly, but the context is specific enough that an agent should be able to select it appropriately.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It usefully reveals that the tool depends on a local SearXNG instance and aggregates multiple engines, which is important operational context. It does not discuss failure behavior, latency, or result format, but the presence of an output schema reduces the need to describe return values.

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 and immediately follows with the key infrastructure dependency. Every element earns its place, though it is slightly sparse in terms of structured guidance.

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 three simple parameters, full schema coverage, and an output schema, the description is mostly adequate. It includes the critical local-service dependency and clarifies the search scope, but it leaves usage-vs-alternative guidance and potential failure conditions implicit.

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 parameters are already well documented in the schema. The description adds little beyond the schema's own parameter descriptions, only reinforcing the Chinese-language context, so the 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 performs Chinese web search and aggregates Baidu/Sogou/Bing CN, which distinguishes it from general-purpose search siblings like exa_search or domain-specific tools like arxiv_search. It uses a specific verb and resource, though it does not explicitly contrast itself with every sibling.

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 phrase '中文网页搜索' implies the tool is appropriate for Chinese-language web queries, and the explicit dependency on local SearXNG at localhost:8080 signals an important prerequisite. However, it does not mention when to prefer this over alternatives such as exa_search or when it should not be used.

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