中国 AI 客服国标 GB/T 47746—2026 合规问答库：必须自动转人工的场景、强制自查项、上线备案要求，答案标注条款依据。
Scored across 5 tools
Each tool targets a distinct need: get_answer (full content by slug), list_questions (browse titles), search_answers (keyword retrieval), self_check_list (checklist), and standard_info (metadata). list_questions and search_answers both surface Q&As, but the browse-vs-search and brief-vs-full distinctions are clear enough to prevent most misselection.
Three tools follow a clean verb_noun pattern (get_answer, list_questions, search_answers), but self_check_list and standard_info are noun-style names, creating mixed conventions. Still readable, though not fully predictable.
Five tools is well-scoped for a focused compliance knowledge base, covering retrieval, browsing, search, a checklist, and standard metadata without redundancy.
The surface covers the core lifecycle of a Q&A knowledge base plus a self-check tool and standard metadata, which is strong for this domain. A minor gap is the absence of a tool to browse or fetch a specific standard clause directly, though get_answer references clause basis.
按 slug 取一条问答的完整内容（正文 + 要点 + 标准条款依据 + 常见追问）。
Args:
slug: 问答标识，先用 list_questions 或 search_answers 取得
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
列出全部合规问答的标题清单。
Args:
cluster: 可选，按集群过滤。可选值 ai-service-standard(AI客服国标) / enterprise-knowledge-base(企业知识库)
| Name | Required | Description | Default |
|---|---|---|---|
| cluster | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
按关键词检索合规问答，返回最相关的若干条（含简要答案）。
Args:
query: 检索词，如「转人工」「备案 登记」「知识库 切分」
top_k: 返回条数，默认 5
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| top_k | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
取 GB/T 47746-2026 的自查清单：企业对照检查自家 AI 客服是否达标。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. '取' implies a non-destructive read and it discloses the content type (a checklist), but it says nothing about format, size, or any prerequisites. For a zero-parameter read tool the risk is low, so this is adequate rather than rich.
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 tight sentence, front-loaded with the action and the standard identifier, followed by the use case. Every clause earns its place with no redundancy.
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 simple (no params, output schema present), so the description need not explain return values. It covers what is fetched and why, leaving only minor gaps around how the checklist relates to the sibling tools.
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 there is nothing for the description to disambiguate; the baseline of 4 applies. The description correctly avoids inventing inputs and simply names the fixed standard being retrieved.
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 pairs a specific verb (取/get) with a specific resource (GB/T 47746-2026 自查清单), so an agent immediately knows this returns a self-assessment checklist for that standard. It does not explicitly contrast itself with siblings like standard_info, but the checklist deliverable is distinctive enough to differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the intended scenario — enterprises checking whether their own AI customer service meets the standard — which implies when to reach for it. However, it never says when to prefer this over standard_info or how it differs from the other question/answer tools, so routing guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取 GB/T 47746-2026 标准的元信息（发布/实施日期、归口、篇幅、核心要求）。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_answerlist_questionssearch_answersself_check_liststandard_infoKorea AI Basic Act compliance MCP — in force 22 Jan 2026. High-impact AI + GenAI labelling + MSIT
Governance maturity assessment, compliance gap analysis, and evidence-linked briefs for AI agents.
Multi-jurisdictional AI compliance readiness scoring with sourced penalty math.
Provenance-backed EU and UK legislation for AI agents, addressable to the individual provision.
