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

No annotations are provided, so the description carries the full behavioral burden, and it discloses little. It implies a read-only fetch and that the returned item is a 摘要 (summary, possibly not the full document), but it says nothing about what happens with an invalid or stale id, whether the result is complete or truncated, or any auth/rate constraints.

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

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

A single short sentence with the action front-loaded and the parenthetical id provenance immediately after. Nothing is wasted and nothing about a one-parameter lookup is left buried.

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 no output schema, the description covers the essential idea (fetch one doc entry by id) and hints that the result is a 摘要. It is missing behavior on missing or invalid ids, which matters for a lookup tool, so it is adequate rather than complete.

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

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

Schema description coverage is 0%, so the schema only says `id` is a required string. The description partially compensates by naming the provenance of the value (it comes from dev_docs_search), which is genuinely useful semantics that the schema lacks, but it gives no format detail beyond that.

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 specifies a concrete verb-resource pair (按 id 读取一条文档摘要) and names the sibling dev_docs_search as the source of the id, so the agent can separate the fetch-by-id tool from the search tool. It stops short of stating the difference between this tool and that sibling explicitly, so it earns a 4 rather than 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?

By stating 「id 来自 dev_docs_search」, the description implies the correct two-step flow: search first to obtain an id, then call this tool to fetch that entry. It gives no exclusion cases or error conditions, but for a one-parameter lookup the usage context is 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 supplied, so the description carries the full load. It does usefully disclose two traits: the index is offline (no network dependency) and each result includes an official doc link, which tells the agent what it gets back. It says nothing about coverage limits, result caps, or failure behavior when a term is absent.

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

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

A single front-loaded sentence with no filler; the scope (offline, four libraries) and the return shape (summary plus official link) both land immediately.

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 three-parameter read tool with no annotations and no output schema, the description covers intent and return content adequately. Gaps remain around the default/maximum result count and what happens when a query matches nothing, which matter for correct invocation.

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

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

Schema coverage is only 33%: query has an example-rich description and lib is a self-evident enum, but limit has no description and its default is never stated. The description's enumeration of the four libraries reinforces the lib enum and adds framing, but it does not compensate for the undocumented limit parameter.

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

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

States a specific verb (离线检索) and resource (常用 API 要点摘要) restricted to four named frontend libraries, which lets an agent tell it apart from a generic doc fetcher. However, it never names the sibling dev_docs_get, so the split between summary search and doc retrieval has to be inferred.

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 when-to-use guidance, no prerequisites, and no mention of alternatives. With siblings like dev_docs_get present, an agent gets no explicit signal about which tool to pick for a given lookup.

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 were provided, the description must carry the full burden of behavioral disclosure. The explicit mention of '内置国务院办公厅 2025、2026 年放假通知' provides critical behavioral context regarding the data source and scope limitations (2027 data is unavailable). This is a valuable piece of meta-information about the tool's operational boundary.

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 definition is highly concise and efficient. It packs the function, the scope of data coverage, and the nature of the tool (classification) into a single, powerful sentence.

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

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

Given the single-parameter nature of the tool and the absence of complex output schemas, the description provides all necessary contextual completeness. It informs the agent about the domain, the data sources used for the classification, and its limitations.

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 baseline is a 3. The description does not add further semantic meaning to the 'date' parameter beyond what is already implied by its function and the schema's type definition. It doesn't elaborate on date format nuances beyond the general intent.

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 clear verb ('查询' - query) and precisely defines the resource it classifies: whether a day is a holiday, adjusted workday, weekend, or regular workday. It is distinct from date manipulation tools like workday_count or holiday_year.

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 clearly defines the tool's function as a classifier for a specific date, which inherently establishes its proper usage. It is not a calculator, making its purpose unambiguous in the agent's decision-making process.

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 whole burden. It does add genuinely useful behavioral detail beyond the title — that results include both 调休上班日 (make-up workdays) and the 官方通知来源 (provenance) — which an agent could not assume. It does not disclose what happens for a year whose arrangement has not yet been announced by the State Council, nor the jurisdictional scope (presumably mainland China), which are the main behavioral unknowns for this tool.

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

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

One sentence, front-loaded with the verb and the resource, with the provenance clause trailing. Nothing is redundant and nothing is padded.

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

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

For a one-parameter read-only lookup with no output schema and no annotations, the description covers scope (whole year), content (holiday ranges plus make-up workdays), and provenance (official notice). The remaining gap — unannounced future years — is marginal for a tool of this simplicity.

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?

Single parameter with 100% schema description coverage (年份，如 2026), so the schema already conveys meaning and the baseline of 3 applies. The description adds nothing about the valid year range or how the year should be interpreted relative to the returned arrangement.

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?

States a specific verb (列出) and a clearly bounded resource: the full-year set of statutory holiday ranges plus make-up workdays, with the official notice as source. This implicitly separates it from the single-date sibling holiday_check, but it never names that sibling explicitly, so the differentiation is left to inference.

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 word 全年 (whole year) hints that this is the bulk/yearly view rather than a point lookup, but there is no explicit statement of when to prefer it over holiday_check, nor any prerequisite (e.g. whether the year's arrangement must already be officially published). Usage 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, the description carries the full burden. It usefully narrows the schema's absurd year range (±9 quadrillion) down to 1900–2100, which is real behavioral value, but it says nothing about how invalid dates or out-of-range years are reported, nor what form the returned Gregorian date takes.

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?

Extremely compact: purpose, worked example and valid range in a single phrase, with nothing wasted. The brevity is close to under-specification, which keeps it from a 5.

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?

score 3. A simple four-parameter converter with no output schema needs little, and the example plus year range covers the essentials. Missing edge-case behavior (invalid lunar dates, leap-month handling) keeps it from being fully complete.

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

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

Schema coverage is only 25% (only isLeapMonth is documented), so the description must compensate. The example clarifies that year/month/day are lunar year (1–12), lunar month and day-of-month, and the range note constrains year, but it doesn't explain leap-month numbering or how isLeapMonth interacts with month.

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 (conversion) and resource (lunar → Gregorian date) and gives a concrete example, so the direction of conversion is unambiguous. This inherently distinguishes it from solar_to_lunar, though it never names that 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?

Usage is only implied by the conversion direction and example; there is no explicit 'use this when' or any mention that solar_to_lunar is the inverse operation for the opposite direction. For a straightforward conversion tool this is adequate but leaves routing to inference.

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

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

With no annotations, the description carries the full burden. It does add genuine behavioral signal beyond the schema — automatic handling of common polyphonic characters (多音字) — but says nothing about how non-Chinese or mixed input is treated, whether it errors or passes through, or any limits.

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

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

A single compact sentence with the resource conversion front-loaded and the output modes trailing as qualifiers. Zero filler and nothing repeated.

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 small 3-parameter pure function this covers purpose and output variants adequately, and no output schema is needed to explain a string result. The main residual gap is the return shape — whether pinyin comes back as one joined string or per-character segments — which is left for the agent to discover.

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 67% and both enum parameters (mode, tone) already document themselves in the schema, including the 'symbol' default. The description restates those same options in prose and adds no new meaning; the required 'text' parameter remains undescribed in both places (e.g. accepted length or mixed-language behavior).

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 precise verb+resource (把中文转换为拼音) and enumerates the actual output variants (带声调/数字声调/无声调/首字母), plus the polyphonic-character handling. No sibling tool overlaps this function, and an agent can tell exactly what it produces without opening the schema.

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 self-evident for a pure conversion utility and the listed output modes tell the agent which variant to pick. There are no overlapping siblings to disambiguate against, but the description never states exclusions or edge-case conditions (non-Chinese characters, empty strings), so it stops short of a 5.

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

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

With no annotations, the description carries the full burden. It does valuable work by disclosing dataset scope (31 provincial regions, HK/Macau/Taiwan excluded, three levels) and data provenance, which tells the agent when a lookup will legitimately return nothing. However, it never says whether name matching is exact or substring, whether `limit` applies to name queries, or how results are ordered/truncated.

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

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

Two sentences, front-loaded with the query mechanism and formats, followed by coverage and provenance. Every clause is informative; the source attribution is slightly beyond minimal need but earns its place by explaining data authority and staleness.

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 2-parameter lookup tool with no output schema, the description covers input format and data scope but says nothing about the return shape — whether a query yields the code/name pair, the full parent hierarchy, or just a level. Combined with the unexplained `limit`, an agent knows what to send but not confidently what it gets back.

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 50%: `query` is documented in the schema, but the description adds real value by spelling out the accepted code formats (2/4/6 digits, 12-digit prefix rule). The `limit` parameter is undocumented in both schema and description — its role (result capping, max 100) and which query type it affects are left to inference, so the description only partially compensates.

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?

States a specific verb (查询) and resource (省/市/县行政区划) plus the accepted query forms (2/4/6-digit codes, 12-digit truncated to 6, or names). No sibling could be confused with this — pinyin, lunar conversion and the validator tools are all different domains — so no sibling differentiation is needed.

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

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

The description gives clear context for how to invoke it: pass either a code (with explicit digit-length rules) or a name. It never states exclusions or prerequisites beyond the coverage note, and gives no guidance on choosing between code and name input, but the intended use is unambiguous.

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

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

With no annotations, the description carries the full burden; it does disclose the supported year range (1900–2100) and the returned fields (干支/生肖/节气/节日), which is real behavioral value. It does not say what happens for out-of-range or malformed dates, nor state that the call is a pure read-only computation.

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 short sentence, front-loaded with the conversion direction, then the return contents and the supported range. 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 one-parameter deterministic conversion with a fully documented schema, the description covers direction, outputs, and range — enough to call it correctly. Only the out-of-range/invalid-date behavior is left unspecified.

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% and the single 'date' parameter already documents the YYYY-MM-DD format. The description adds nothing about the parameter beyond what the schema provides, so baseline 3 applies.

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 conversion direction (Gregorian → lunar) plus the returned components, which is enough to distinguish it from the sibling lunar_to_solar even without naming it. It stops short of an explicit sibling call-out, so a 4 rather than 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?

There is no explicit when-to-use/when-not or named alternative such as lunar_to_solar or holiday_check; the conversion direction only implies the use case. Usage is inferable but not guided.

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 and does so well: it discloses that the operation is a read-only format check, that it also validates birth-date plausibility and the checksum digit, and that it explicitly does NOT perform real-identity lookup. The one gap is that it doesn't state what a failed validation returns.

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 compact clauses: the first front-loads what is checked and parsed, the second immediately scopes the tool with a negation. No filler; every phrase 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?

No output schema exists, and the description compensates by enumerating the parsed fields (birth date, gender, region), so an agent knows roughly what comes back. It could be slightly more complete by describing the success/failure signal shape, but nothing essential is missing for correct invocation.

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

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

There is a single parameter with 100% schema description coverage ('15 或 18 位身份证号'), so the schema already carries the parameter semantics. The description adds only indirect context by implying both 15- and 18-digit formats are accepted; baseline 3 applies.

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?

Names a specific verb+resource (校验身份证号格式) and enumerates exactly what is checked — format, birth date, checksum — plus what is parsed (birth date, gender, region). This clearly distinguishes it from siblings like validate_uscc and validate_mobile.

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 closing clause '仅做格式校验，不查询、不核验真实身份' sets a clear boundary on when the tool is appropriate and what it must not be used for. It does not name an alternative tool for actual identity verification, so the routing guidance 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 present, so the description carries the full behavioral burden. It discloses accepted input formats and that the tool infers the carrier segment, which is genuine context, but it does not say whether the check is purely local/read-only, what happens on invalid input, or whether a carrier string or just a boolean is produced.

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 dense sentence that front-loads the core validation scope and appends the accepted input variants and carrier inference. Nothing is redundant or padded.

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 single-parameter validator this is nearly sufficient, but with no output schema the description should state the return shape (boolean validity, normalized number, inferred carrier). It hints at a carrier result without defining it, leaving a real gap for correct interpretation.

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

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

Schema description coverage is 0% and the single 'phone' parameter has no type detail beyond string in the schema. The description compensates well by specifying the 11-digit mainland format with optional +86 prefix, spaces, and hyphens, which is exactly the syntax an agent needs before calling.

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 definition states a specific action (validate) applied to a specific resource (mainland China 11-digit mobile number) and adds the accepted format variants (+86, spaces, hyphens) plus a carrier-inference side effect. It is clearly distinct from sibling validators such as validate_id_card and validate_uscc.

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 verb 'validate' and the stated format scope, so an agent can infer this is a format-check tool. However, no explicit when-to-use, when-not-to-use, or alternative (for example, distinguishing it from validate_id_card on identity-related input) is given.

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, and it does disclose the important behavioral trait that this is a purely local format-and-checksum validation with no registry lookup or network call. It is silent on what happens for an invalid code (error vs. valid=false), on idempotency, and — with no output schema — on the shape of the returned parse result.

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 dense sentence leads with the verb and resource, then adds which checks and parses are performed, followed by a short exclusion. Every clause carries information and nothing is repeated.

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

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

For a one-parameter, no-output-schema validator, the description covers purpose, checks performed, fields extracted, and the key non-behavior (no business lookup). The gap is the invalid-input behavior and the exact parse fields returned, which matter because there's no output schema to lean on.

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

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

Schema coverage is 0% for the single `code` parameter, so the description must compensate, and it does: 18 位统一社会信用代码 plus the GB 32100-2015 reference tells the agent the expected length, character set, and standard, which is the essential constraint. It does not discuss formats beyond that (for example, whether hyphens or spaces are tolerated).

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 specific verb (校验) and resource (18 位统一社会信用代码), then goes further to say which checks are applied (字符集与校验位, GB 32100-2015) and which fields are parsed (登记管理部门、机构类别、地区). The closing phrase 不查询工商信息 pre-empts the most likely confusion with a company-registry lookup, so an agent can distinguish this from the other validate_* siblings.

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

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

The description gives a clear use context (validating and decoding an 18-character USCC) and an explicit exclusion (不查询工商信息), which tells the agent when not to reach for it. However, it does not name an alternative tool for the excluded use case or state prerequisites, so it stops short of a full when/when-not/alternatives statement.

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 burden. It usefully discloses that negative n moves backwards, but leaves open a critical question for a workday calculator: which calendar defines a workday (weekends only, or national holidays via holiday_check?), plus timezone and out-of-range/invalid-date behavior.

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

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

A single front-loaded sentence that defines the operation, the negative-n case, and a motivating example — no filler. It could be marginally tighter, but nothing is wasted.

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

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

For a simple two-parameter tool with a fully described schema, little is required, and no output schema is needed to explain a date result. However, the workday definition (weekend-only vs. statutory holidays) is exactly the detail an agent needs to call this correctly, and it is absent.

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 documented (n as an integer that may be negative, date as YYYY-MM-DD). The description's note that negative n means 'before' echoes the schema rather than adding new meaning, so the baseline 3 applies.

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?

States a specific verb (计算) and resource (第 n 个工作日) with scope: after a date, or before it when n is negative. That directionality cleanly separates it from the sibling workday_count, which counts workdays rather than offsetting by n.

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 '3 个工作日内发货' example implies a deadline-calculation use case, which is helpful context. But it never states when to prefer workday_count over workday_add, nor any exclusions or prerequisites, so alternatives must be inferred.

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

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

With no annotations provided, the description must carry the behavioral burden. It usefully discloses that holidays and 调休 (adjusted workdays) are factored in, which is real behavioral information beyond the schema. However, it doesn't state which region's holiday calendar applies, what data range is covered, or anything about the response shape.

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

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

A single compact sentence with no filler, and the key behavioral fact (holiday/调休 awareness) is front-loaded alongside the core verb. Nothing repeats the title or wastes space.

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

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

For a simple two-date read-only counting tool with a fully documented schema and no output schema, the description covers inclusive range, both counts returned, and holiday logic. The main remaining gap is calendar scope — which country/year holiday data is applied — which matters given the 调休 reference.

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 earns an extra point by clarifying that both endpoints are inclusive (含首尾), a semantic detail the schema does not express and one that directly affects how an agent sets start and end.

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?

States a specific verb+resource: count working days and rest days between two dates, inclusive. This is clearly distinct from siblings like workday_add (which shifts a date) and holiday_check (which inspects a single date), though no sibling is named explicitly. Purpose is unambiguous without opening the schema.

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 only implied by the description's scope — you call it when you need a range-level count. There is no explicit 'use this when…' statement, no mention of workday_add or holiday_check as alternatives, and no preconditions such as supported year ranges.

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