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?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It states it returns the next step but does not disclose side effects, requirements (e.g., whether the question must exist), error behavior, or what happens if the choice is invalid. This is a significant gap for a tool that advances sequential logic.
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 a single, concise sentence that effectively front-loads the core action and inputs. It avoids redundancy and is efficiently sized for the tool's simplicity.
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 tool's moderate complexity (2 parameters, no output schema), the description provides the basic gist but is incomplete for confident invocation. It does not explain what the returned object looks like, whether the flow terminates, or relationship to siblings, which an agent would likely need to know.
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 description adds minimal parameter meaning: it identifies 'choice' as the chosen option's index and 'question' as an id, but does not explain how to obtain the question id, the exact format of the choice index, or range constraints beyond the schema's minimum 0. The description lacks detail to fully compensate for undocumented schema.
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 specific verb ('return') and resource ('next question or final verdict') tied to the tool name 'checker_answer', clarifying it advances a flow for a given question and choice. It doesn't explicitly differentiate it from siblings like checker_start or checker_tree, but the flow progression is clear.
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 implies usage: call this when you have a question id and a chosen option to progress in a flow. It doesn't explicitly state when not to use it or mention alternatives like checker_start (for beginning) or checker_tree (for exploring paths), leaving some inference needed.
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 six tools split cleanly into a decision-guide workflow (start/answer/tree) and an enquiry submission workflow (describe/fields/submit). Each tool has a distinct role: start initializes, answer advances stepwise, tree provides full context, and the enquiry tools cover explanation, schema, and submission. No two tools could plausibly be used for the same action.
The checker_ and enquiry_ prefixes create clear, predictable grouping, and every name is snake_case. The main deviation is that some names are action-oriented (start, answer, describe, submit) while tree and fields are data-oriented nouns, so the grammatical pattern is not perfectly uniform.
Six tools is well-scoped for the two distinct workflows the server exposes. There is no redundancy or padding; each tool maps to one clear capability.
For the checker, start, answer, and tree cover entry, stepwise navigation, and full reasoning respectively. For the enquiry, describe, fields, and the two-step submit flow provide the explanation, schema, validation, confirmation, and final submission needed for a complete user journey.