Class Q Checker: the site's own MCP server — checker, enquiry (enquiry = a human handoff, not a...
Scored across 6 tools
The three checker_* tools are clearly separated into start, stepwise answer, and full-tree reasoning. The three enquiry-related tools also have distinct roles: description, field schema, and submission. Minor overlap exists because checker_tree provides an alternative to the interactive start/answer flow, but descriptions clarify the intended use.
All names use snake_case and are mostly domain-prefixed, but the pattern is not uniform: checker_start/checker_answer/checker_tree and enquiry_describe/enquiry_fields use noun-prefixed forms, while submit_enquiry uses verb_noun order. Verb/noun structure varies across the set, making the convention only partially predictable.
Six tools for a focused Class Q eligibility checker plus enquiry workflow is well-scoped and neither bloated nor thin. Each tool has a clear, non-redundant role in the process.
The surface covers the full workflow: starting the checker, stepping through questions, reasoning over the full tree, understanding the enquiry, retrieving field definitions, and submitting with consent. No obvious operation is missing for the stated purpose.
Given 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose the key behavior—returning either the next question or a final verdict—but it does not mention whether the flow state is mutated, what happens for invalid choices, or any session/state requirements.
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, information-dense sentence. The title and description work together without repetition or filler, and the key input/output behavior is front-loaded.
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?
Adequate for a two-parameter tool: it names both inputs and describes the possible return. However, with no output schema and no annotations, it falls short of fully describing the response shape, error behavior, or what the caller should do with the returned next question/final verdict.
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 schema has 0% description coverage, so the description's clarification that `question` is a question id and `choice` is the chosen option's index is essential. It adds meaning beyond the raw property names and types, though it omits details like how to obtain valid question ids or bounds beyond minimum 0.
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 operation: given a question id and a choice index, return the next question or final verdict. This clearly differentiates it from sibling tools like checker_start or checker_tree, which have different roles in the flow.
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 implied: use this when a user has answered a question and the flow should advance. However, it does not explicitly state when not to use it, what prerequisites exist (e.g., starting with checker_start), or how it relates to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The first question of the Class Q eligibility checker decision guide.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that this is the first question, but it does not clarify whether calling the tool returns the question text, initializes a session, or has any side effects. This is insufficient for an agent to understand the tool's operational behavior.
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, short sentence with no wasted words, which is concise. However, it is under-specified: it could be reworded to state an action and expected outcome without losing brevity. The structure is acceptable but not ideal for operational clarity.
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 tool with no output schema and no annotations, the description should explain what invoking the tool returns or what starting the guide entails. The current phrase is ambiguous—it could be interpreted as the tool itself being a question rather than a tool that returns or presents the first question. This leaves an agent uncertain about the response and next steps, making the definition incomplete.
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 has zero parameters and schema description coverage is 100% (vacuously), so there are no parameter semantics to document. The description adds a mild hint that no input is required, which is consistent with the empty schema, and no compensation for param documentation is needed.
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 identifies a specific resource (the Class Q eligibility checker decision guide) and its position ('first question'), but it lacks an explicit verb indicating what the tool does when called. It reads more like a static label than an operational instruction, and it does not differentiate from related siblings like checker_answer or 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?
No guidance is provided on when to use this tool versus alternatives. The name 'start' implies it is the entry point, but the description does not state this explicitly, nor does it mention any exclusions or relationship to sibling tools such as checker_answer or checker_tree.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every question, option and verdict of the Class Q eligibility checker guide, for reasoning end to end.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 describes the content of the tool but not its behavior: no explicit statement that it is a read-only retrieval, no mention of response format, side effects, or any operational constraints.
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 sentence that communicates scope and purpose compactly. It is slightly redundant with the title ('The whole decision tree') but still adds useful specificity about the contents.
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 tool with no output schema, the description gives sufficient context: an agent can infer the tool returns the full decision tree for reasoning. It lacks explicit return-format details, but the simplicity of the tool keeps the gap small.
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 has zero parameters and an empty input schema, so there is nothing to document. The baseline of 4 applies; no parameter information is needed.
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 clearly identifies the resource: the complete Class Q eligibility checker decision tree, including every question, option, and verdict. It distinguishes itself from step-by-step siblings like checker_start and checker_answer by presenting the whole tree for end-to-end reasoning, though it never uses an explicit verb like 'returns' or 'provides'.
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 phrase 'for reasoning end to end' implies this is used when the full tree is needed, contrasting with the interactive sibling tools. However, it does not explicitly state when to choose this over checker_start/checker_answer, nor does it name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read first. States plainly what submit_enquiry does on Class Q Checker: it starts an enquiry with human providers who quote directly. Nothing is bought, ordered or paid; no quote is guaranteed; it is free. Also returns who receives the details, the consent wording, and how the person confirms.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does a good job by stating that nothing is bought, ordered, or paid, that no quote is guaranteed, and that the tool returns who receives the details, the consent wording, and confirmation behavior. It could go further by explicitly stating that the tool itself is read-only, but the informational nature is strongly implied.
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 compact and front-loaded with the most important instruction, 'Read first.' Every sentence earns its place: it states the purpose, clarifies what is NOT happening, and lists the returned content. There is no filler or 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?
For a zero-parameter, no-output-schema informational tool, the description is complete enough. It fully explains what the tool does, what it clarifies, and what information it returns, so an agent can call it correctly without needing additional external context.
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 accepts zero parameters, so there is no parameter burden for the description to carry. Per the baseline for zero-parameter tools, a score of 4 is appropriate; the description does not need to explain parameters that do not exist.
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 purpose: it plainly explains what submit_enquiry does, including that it starts an enquiry with human providers and that nothing is purchased or guaranteed. This clearly distinguishes enquiry_describe as an informational/pre-flight tool from submit_enquiry, which performs the actual submission.
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 opening 'Read first' explicitly tells the agent to use this tool before acting, and the title and description signal it is the safe explanatory companion to submit_enquiry. However, it does not explicitly name sibling alternatives or give when-not-to-use guidance, so it stops slightly short of full usage routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every field of the Class Q Checker enquiry: key, label, type, whether required, help text and the allowed options where there are any. Pass answers to submit_enquiry keyed by field key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It does this well by listing exactly what field attributes are returned and noting that allowed options appear only where they exist. It also reveals the cross-tool contract with submit_enquiry. It does not explicitly say the operation has no side effects, but the metadata-oriented wording makes that clear enough.
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 sentences, no filler. The core output description is front-loaded, and the integration note about submit_enquiry earns its place by explaining how the returned keys are used.
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 introspection tool, the description is nearly complete: it states the returned content and the downstream consumer. It does not specify whether the response is a list or a keyed map, which an output schema would normally clarify, but the essential call contract is clear.
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 has zero parameters, so the baseline is 4. The description does not need to explain parameter behavior, and it does not confuse the parameterless call with the submit_enquiry payload it mentions.
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 identifies the resource precisely ('the Class Q Checker enquiry') and enumerates its contents: key, label, type, required status, help text, and allowed options. It is clear what the tool exposes, but it lacks an explicit action verb like 'List' or 'Return' and does not explicitly distinguish itself from siblings such as enquiry_describe.
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 instruction 'Pass answers to submit_enquiry keyed by field key' provides a concrete usage context: this tool supplies the field keys needed when submitting an enquiry. It does not explicitly state when not to use it or compare alternatives, but the integration note gives an agent enough situational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submits an enquiry to Class Q Checker — NOT a purchase, NOT a guaranteed quote. Step 1: call with the answers (keyed by field key from enquiry_fields) and consent=true; it validates and returns a summary, the consent line and a confirmation token — show the person the summary and the consent line. Step 2: only if the person agrees, call again with the same answers, consent=true and the confirmation token; the enquiry is then submitted, and the person receives an email with a link they must click before any provider sees it. Consent means the person has read and agreed to: "Send my contact details to up to three relevant planning consultants or rural architects, chosen by Class Q Checker, who'll contact me directly. I'll be emailed each firm's name as my details go to it, and can stop any more firms getting them."
| Name | Required | Description | Default |
|---|---|---|---|
| answers | Yes | the person's answers, keyed by field key | |
| consent | Yes | true only when the person has agreed to: Send my contact details to up to three relevant planning consultants or rural architects, chosen by Class Q Checker, who'll contact me directly. I'll be emailed each firm's name as my details go to it, and can stop any more firms getting them. | |
| confirmation | No | the confirmation token from step 1, after the person has approved the summary |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discharges it well: it discloses that step 1 only validates and returns a summary/consent line/token, that step 2 causes an email to be sent, that a link must be clicked before providers see anything, and that contact details go to up to three firms with per-firm notification and opt-out. These are real side effects and data-sharing consequences an agent must understand before calling.
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-loaded with the key disambiguation and structured as Step 1 / Step 2, so it is easy to scan. The verbatim consent string is lengthy, but it is the actual text the agent must show the person, so it earns its place; a small amount of repetition around consent is the only waste.
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?
There is no output schema, but the description compensates by describing exactly what step 1 returns (summary, consent line, confirmation token) and what happens after step 2 (email with a click-through link). For a two-phase, consent-gated submission tool with a nested answers object, nothing material is left unexplained.
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 100%, so the baseline would be 3, but the description adds meaning beyond the schema: it explains that answers are keyed by field key obtained from enquiry_fields, and that confirmation is the token returned by step 1 and must only be sent after approval. That sequencing and provenance is not derivable from the schema alone.
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?
Names a specific verb (submits) and resource (an enquiry to Class Q Checker), and immediately disambiguates what it is NOT ('NOT a purchase, NOT a guaranteed quote'), which is exactly the confusion a sibling like checker_answer could cause. The two-step nature is stated up front so an agent knows the shape of the operation before reading further.
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 explicit call conditions for each step: step 1 with answers + consent=true, step 2 only after the person approves, with the confirmation token. It also routes to the sibling that supplies the field keys (enquiry_fields) and states the consent prerequisite that gates the whole call.
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.
submit_enquiry1 field changedInput schema / properties / consent / descriptionPrevious value: -"true only when the person has agreed to: Happy for my details to go to a relevant planning consultant or rural architect, who'll contact me directly."New value: +"true only when the person has agreed to: Send my contact details to up to three relevant planning consultants or rural architects, chosen by Class Q Checker, who'll contact me directly. I'll be emailed each firm's name as my details go to it, and can stop any more firms getting them."checker_answerchecker_startchecker_treeenquiry_describeenquiry_fieldssubmit_enquiryCatchment Checker: the site's own MCP server — checker, enquiry (enquiry = a human handoff, not...
CQC Registration Checker: the site's own MCP server — checker, enquiry (enquiry = a human...
Smoke Control Checker: the site's own MCP server — checker, enquiry (enquiry = a human handoff,...
SAR Builder: the site's own MCP server — checker, enquiry (enquiry = a human handoff, not a...
Add one secure layer between your agents and this server.