AI 客服国标合规知识库 (GB/T 47746—2026)

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 implies a simple read-by-identifier and lists the returned sections, but says nothing about failure behavior for an invalid/unknown slug, auth requirements, or whether content can be large. Adequate but shallow for a zero-annotation 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?

Two short, front-loaded lines: the purpose sentence comes first, then the argument note. Every clause earns its place and nothing is redundant.

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 a single required string param and an output schema present, the description does not need to document return values, and it still sketches them. Complete enough to invoke correctly; only error/permission behavior is left unstated, which is minor for a read 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?

Schema coverage is 0% (schema only labels the field 'Slug'), so the description must compensate: it explains slug is the Q&A identifier and, crucially, where to obtain it (list_questions or search_answers). That is real meaning beyond the schema, though no format example is given.

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+scope: fetch the complete content of ONE Q&A entry by slug, and even enumerates what 'complete' means (body, key points, standard-clause references, common follow-ups). The mention of list_questions/search_answers makes clear this is not the enumeration tool, distinguishing it from siblings.

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

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

Gives a clear prerequisite/workflow: obtain the slug first via list_questions or search_answers. That routes the agent correctly, but there is no explicit statement of when NOT to use this tool (e.g. browsing without a known slug).

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 behavioral burden. It does disclose that only titles are returned (not full question/answer content), which is useful, but says nothing about permissions, result limits, or ordering for what could be a large list.

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 short and front-loads the core purpose before the argument details. Every sentence carries information, though the Args block is formatted in a way that reads more like schema documentation than agent-facing prose.

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-value details are not required, and the one parameter is well explained. What remains missing is guidance on when to choose this tool over search_answers/get_answer, which matters given four plausible 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?

Schema description coverage is 0%, but the description compensates well for the single parameter by naming the allowed values and explaining them: ai-service-standard (AI客服国标) and enterprise-knowledge-base (企业知识库). This enum information is absent from the schema, so the description adds real meaning.

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 and resource ('列出全部合规问答的标题清单') and scopes it to the full set rather than a filtered search. It does not explicitly contrast itself with siblings like search_answers or get_answer, so it is clear but not sibling-differentiating.

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 guidance and no mention of alternatives such as search_answers or get_answer. The 'list all' framing only implicitly suggests a browse use case, leaving the agent to infer when this beats a 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 does disclose that results are keyword-scored and return a brief answer, which adds behavioral context beyond the schema. However, it omits ranking semantics, result format details, and pagination behavior — gaps that matter for an unannotated search tool.

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

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

Front-loads the core purpose in the first sentence and then documents parameters. The 'Args' style is structured, but the example for 'query' is somewhat specific and could be more generalizable.

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 the description needn't explain return values. However, without annotations, it should do more to describe safety, authorization requirements, or rate limits. The core purpose and parameters are covered, but behavioral completeness is still limited.

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

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

Schema description coverage is 0%, so the description must compensate. It provides an example for 'query' and the default for 'top_k', which adds meaning for both parameters. However, it doesn't clarify whether query supports natural language, boolean operators, or exact phrases — details that would help an agent invoke it correctly.

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 (检索/retrieve) and resource (合规问答/compliance Q&A), plus a scope hint (returns most relevant items with brief answers). Siblings include get_answer, list_questions, and standard_info, but the description doesn't explicitly differentiate from these — it's clear but not sibling-aware.

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

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

No guidance on when to use this search tool versus siblings like get_answer or list_questions. The description implies it's for keyword-based retrieval, but there's no explicit when-to-use or when-not-to-use context.

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 does disclose the return shape (61 items with id/clause/level/veto flag/requirement/remediation, plus a veto-item quick reference and an explainer field), implying a read-only, no-argument retrieval, but it says nothing about permissions, auth, or rate 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?

The purpose is front-loaded in the first sentence, followed by the return contents, with no filler. Markdown bolding is used to structure the output enumeration, though the second sentence is dense with detail that partially duplicates the output schema.

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 zero parameters and an output schema present, the description need not explain return values, yet it does so anyway, and the purpose is clear. It is essentially complete for a parameterless retrieval tool; only the lack of any routing guidance to siblings keeps it from a 5.

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 takes zero parameters, so the baseline is 4; there is no parameter syntax or meaning for the description to clarify, and the schema is empty.

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 (取/retrieve) and a precise resource (the GB/T 47746-2026 self-check list for AI customer service compliance), which is easily separable from the Q&A-oriented siblings like get_answer and search_answers. However, it never explicitly contrasts itself against standard_info or the answer tools, so it falls short of the top mark.

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 framing '企业对照检查自家 AI 客服是否达标', which suggests a compliance-checking scenario, but there is no explicit when-to-use, when-not-to-use, or named alternative (e.g. use standard_info for the standard text itself). Minimum-viable 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 full burden. '获取' implies a safe read, and it usefully enumerates what the metadata covers, but it says nothing about failure behavior if the standard is unavailable, permissions, or caching/freshness. An output schema exists, so return-format detail is legitimately omitted.

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 the identified standard and the payload contents; nothing extraneous, nothing missing.

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

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

For a parameterless, read-only metadata lookup with an output schema already defining the return shape, the description supplies everything an agent needs to select and call it.

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 takes zero parameters, so the baseline of 4 applies. The description correctly adds no parameter narrative, and the fields it lists describe output content rather than inputs.

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 ('GB/T 47746-2026 标准的元信息') and even enumerates the returned fields (发布/实施日期、归口、篇幅、核心要求). An agent immediately knows this returns metadata for one specific standard; the sibling tools are unrelated Q&A utilities, so no further 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?

No explicit when-to-use or when-not-to-use statement is given, but the tightly scoped single-resource description makes the intended usage self-evident (call it when you need facts about this standard). No alternatives are named, though none of the siblings compete with it.

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