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?
无注释，描述承担全部行为披露责任。描述仅说明会返回下一个问题或最终裁决，但未披露是否存在副作用（例如是否提交/记录答案）、无效choice时的行为、或是否修改任何状态。对流程推进型工具来说，这些不确定性是智能体选择工具时的关键决策要素。
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?
一句话完成全部核心说明，条件在前、结果在后，结构清晰，无冗余内容。'Given X and Y, return Z'句式高效传达输入输出映射，信息密度高且易解析。
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?
作为有状态流程的步进工具，描述缺少关键上下文：'下一个问题'与'最终裁决'的返回条件未说明；无输出schema导致返回值结构完全不透明；也未说明此工具在checker流程中的位置及与兄弟工具的关系。核心操作逻辑已覆盖，但在无注释和无输出schema的条件下，信息量仍不足以让智能体无误解地使用。
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是'chosen option'的索引。但未说明question的具体格式、choice的有效范围（schema仅限制最小值为0）或如何获取合法选项列表，且参数名question与描述中的'question id'存在轻微语义错位。
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?
描述明确说明了函数的作用：给定问题ID和选项索引，返回下一步（下一个问题或最终裁决）。动词'return'和资源'next question or final verdict'清晰，与标题'Answer a question, get the next step'一致。但未明确说明checker工具间的流程关系（如与checker_start、checker_tree的衔接），与兄弟工具的区分度有限。
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?
描述未提供任何使用时机指导，未说明何时使用此工具而非checker_start、checker_tree或enquiry_describe。没有'当...时使用'或'不要使用...'的条件说明，也没有提及前置条件（如必须先开始一个检查流程）。智能体无法仅凭此描述判断该工具在整个流程中的调用位置。
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 tool set cleanly separates into two prefixes: checker_* for the decision guide and enquiry_* for the estimator form. Within each group, each tool has a distinct role: start, answer, tree for the checker; describe, fields, submit for the enquiry.
All tool names use snake_case with a consistent domain-prefix pattern: checker_start, checker_answer, checker_tree and enquiry_describe, enquiry_fields, submit_enquiry. The naming makes the grouping and purpose immediately predictable.
Six tools is a well-scoped count for a server covering two distinct workflows: a decision guide and an enquiry submission flow. Every tool earns its place and there is no unnecessary redundancy.
The checker workflow is complete: start gives an entry point, answer navigates the tree, and tree allows full end-to-end reasoning. The enquiry workflow is also complete: describe explains the process, fields provides the schema, and submit_enquiry handles the two-step consent and confirmation flow.