checker_answerGiven a question id and the chosen option (its choice index), return the next question or the final verdict.
| Name | Required | Description | Default |
|---|---|---|---|
| choice | Yes | ||
| question | Yes |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
没有提供任何annotations，描述必须承担全部行为披露责任。描述只说明了输出类型（下一题或最终裁决），但'answer'语义暗示这是一个提交答案并推进状态的mutation操作，却未披露是否会修改状态、重复提交的行为、无效choice或未知question id的错误处理。对无注解覆盖的交互推进工具，这是显著的信息缺口。
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?
单一句话完整表达了输入条件和输出结果，前置条件、后置结果，零冗余信息。每个词都承载含义，且与工具标题精确对应，结构高效。
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?
对于只有2个参数且无输出schema的简单工具，描述覆盖了核心调用方式。但缺少边界行为（无效索引、未知question id）和流程上下文——这是一个状态机推进步骤（checker_start启动、checker_tree查看结构）。作为交互流程中的一环，信息刚好够调用，但不足以让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描述覆盖率为0%，描述成功补偿了关键语义：question被明确为question id（而非任意字符串），choice被解释为所选选项的索引，赋予了schema中仅有名字和类型的参数以业务含义。但未提供question id的具体格式或choice的取值上限，因此未到满分。
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?
描述使用具体动词'return'，明确说明输入（question id + choice index）和输出（next question 或 final verdict），与标题'Answer a question, get the next step'一致。虽然没有显式命名兄弟工具checker_start/checker_tree，但描述的机制（给定回答推进到下一题）自然区别于开始和树查看工具，不过缺少明确的区分语句，所以给4分。
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?
描述隐含了使用条件：当你已有question id并希望提交choice索引时调用。但它没有明确说明何时应使用checker_start或checker_tree替代，也没有排除条件、前提或调用顺序信息。用法靠推断而非明示，属于最低可用水平。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
The tools split into two clear clusters: decision-guide tools (checker_start, checker_answer, checker_tree) and enquiry tools (enquiry_describe, enquiry_fields, submit_enquiry). Each tool has a distinct role, though checker_answer and checker_tree both support reasoning through the guide and could occasionally be confused.
The checker_ and enquiry_ prefixes create a readable pattern, but submit_enquiry breaks the convention by leading with the verb instead of the domain prefix. Within the prefixed groups, terms like start, answer, tree, describe, and fields mix verb-like and noun-like naming styles.
Six tools is well-scoped for the apparent purpose: a decision guide plus an enquiry submission flow. Every tool earns its place, and the count is neither thin nor bloated.
The checker cluster gives complete coverage of the decision guide: start, step through answers, and view the full tree. The enquiry cluster covers explanation, schema, and two-step consent-based submission, so the two workflows have no dead ends.