CASP Checklist: the site's own MCP server — checker, enquiry (enquiry = a human handoff, not a...
Scored across 6 tools
The tools split cleanly into two workflows: the checker guide (start, answer, tree) and the enquiry flow (describe, fields, submit). Each tool has a clearly distinct role, and there is no meaningful overlap between them.
The prefixes 'checker_' and 'enquiry_' provide useful grouping, but the action positioning is inconsistent: some tools are verb-led ('checker_start', 'enquiry_describe') while others are noun-led ('checker_tree', 'enquiry_fields') and one reverses the pattern ('submit_enquiry'). It is still readable, but not fully predictable.
Six tools is a well-scoped set covering two focused workflows without unnecessary redundancy. Each tool earns its place, and the count feels appropriate for the server's purpose.
The checker workflow is complete: start, step through, and inspect the whole tree. The enquiry workflow is also complete: understand what it does, see the required fields, and submit with confirmation. No obvious gaps or dead ends exist 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 CASP authorisation checker decision guide.
| 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 burden of behavioral disclosure. It only states that this is the first question; it does not say whether calling it presents a question, returns options, changes state, or expects any follow-up. This is thin operational detail for a tool with no annotation-backed safety or side-effect information.
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, focused sentence with no redundant wording. The key identifier 'first question' is front-loaded, and the sentence is appropriately concise for a zero-parameter entry-point tool.
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 no output schema, the description should explain what the caller receives or what to do next, but it only says the tool is the first question. It does not describe the returned question format, available answers, or how the agent should proceed to checker_answer, leaving important context to inference.
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 input schema is empty with 100% schema coverage, so there are no parameter semantics for the description to clarify. The description adds no parameter-level meaning, but none is required when the tool takes no parameters.
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 tool as the first question in the CASP authorisation checker decision guide, which communicates its entry-point role and distinguishes it from siblings like checker_answer and checker_tree. However, it lacks an explicit action verb such as 'starts' or 'returns', so it describes what the tool is more than what it does.
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 guidance on when to use this tool instead of alternatives like checker_answer, checker_tree, or the enquiry_* tools. The entry-point usage is only implied by the phrase 'first question', with no mention of prerequisites, next steps, or exclusions.
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 CASP authorisation 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 behavioral disclosure burden. It conveys that the tool returns the entire decision tree with no parameters or modification, implying a read-only retrieval. It does not disclose the output format, potential size, or whether the response is best consumed in parts, but the core behavior is reasonably clear.
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, front-loaded sentence with no filler. It names the domain, the scope ('every question, option and verdict'), and the intended reasoning flow, earning its place entirely.
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 no-parameter static reference tool, this is nearly complete: it identifies what content is included and why an agent would use it. The only missing piece is a brief note on the response format or how it relates to checker_answer and checker_start, since there is no output schema or annotations to supply that 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 input schema has zero parameters, so parameter semantics are not applicable. Per the rubric, a zero-parameter tool gets a baseline of 4; 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 clearly states that the tool provides every question, option, and verdict of the CASP authorisation checker guide, making its purpose as a complete decision-tree reference apparent. It does not use an explicit verb like 'retrieve', but the content and intended use ('for reasoning end to end') are specific enough to distinguish it from the step-by-step 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?
The phrase 'for reasoning end to end' implies when to use the tool: when the full decision tree is needed rather than a single answer or starting point. However, it does not explicitly state when not to use it or directly contrast it with checker_answer and checker_start.
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 CASP Checklist: 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?
No annotations exist, so the description carries the full burden—and it delivers. It discloses key behavioral traits: nothing is bought, ordered, or paid; no quote is guaranteed; it is free. It also lists what the tool returns (who receives details, consent wording, and confirmation method). This goes well beyond what structured metadata could provide.
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 'Read first,' then delivers purpose, constraints, and return content in three tight sentences. Every clause adds value, with no repetition or filler.
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-param, no-output-schema tool, the description is nearly complete: it tells the agent what the tool does, important safety-related constraints, and what content is returned. The only minor gap is that it doesn't explicitly state that enquiry_describe itself is non-mutating and side-effect free, though the wording strongly implies this.
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%, so the baseline of 4 applies. The description correctly doesn't attempt to document parameters that don't exist, and no additional param semantics are necessary.
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 exactly what the tool does: 'States plainly what submit_enquiry does on CASP Checklist.' It clearly identifies the resource (submit_enquiry) and the action (describing/explaining), and the title 'What you get' reinforces the informational nature, distinguishing it from the actual submit_enquiry tool.
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 instruction 'Read first' tells the agent to consult this tool before acting, which is a clear usage signal. It establishes context for understanding submit_enquiry, but it does not explicitly name sibling alternatives or state when not to use it. Still, the context is clear enough for an agent to decide.
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 CASP Checklist 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 present, so the description carries the full burden. It implies a read-only metadata lookup by describing the fields and their attributes, and it gives useful integration context with submit_enquiry. However, it does not explicitly state side effects, response shape, or whether any state changes occur; for an introspection tool this is acceptable but not fully transparent.
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 two compact sentences with no filler. The first sentence defines exactly what the tool returns, and the second explains how the returned keys should be used. Every sentence earns its place.
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 no-argument introspection tool with no output schema, the description does a good job by listing the key field attributes and connecting the result to submit_enquiry. It still leaves minor ambiguity about the exact return format and whether the data is static, but nothing critical is missing for correct invocation.
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 the schema coverage is 100%, so the baseline for parameter semantics is 4. The description adds no parameter requirements and appropriately focuses on the output content, which is sufficient for a parameterless tool.
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 CASP Checklist enquiry fields—and enumerates exactly what information is exposed (key, label, type, required, help text, allowed options). It lacks an explicit verb like 'list' or 'get', but the meaning is unambiguous and the tie to submit_enquiry aids differentiation.
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 tells the agent when to use the result: 'Pass answers to submit_enquiry keyed by field key.' This provides clear practical context for invocation. It does not explicitly explain when not to use it or compare it with siblings like enquiry_describe or checker_*, but the usage direction is strong.
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 CASP Checklist — 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: "Happy for my details to go to a relevant MiCA authorisation adviser, who'll contact me directly."
| Name | Required | Description | Default |
|---|---|---|---|
| answers | Yes | the person's answers, keyed by field key | |
| consent | Yes | true only when the person has agreed to: Happy for my details to go to a relevant MiCA authorisation adviser, who'll contact me directly. | |
| 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 provided, the description carries the full burden and does so thoroughly. It discloses the two-call side effect, email delivery, the link-click requirement before providers see the enquiry, the validation step, and the precise consent text.
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 dense but every sentence earns its place. The two-step flow is clearly structured and front-loaded with the crucial non-purchase caveat, and there is no filler or repetition beyond what is operationally necessary.
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, this description covers the complete workflow: what is returned in step 1, what the agent must show the person, when to proceed to step 2, what triggers submission, and what happens after submission. No essential behavior 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?
Although schema coverage is 100%, the description adds meaning beyond field names: answers are keyed by field keys from enquiry_fields, consent must be true with the exact consent wording, and confirmation is the token returned from step 1. This step-to-parameter linkage is not present in the 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?
States a specific action ('Submits an enquiry to CASP Checklist') and explicitly contrasts it with a purchase or guaranteed quote. The title and description both communicate the two-step nature, so an agent can distinguish this from sibling tools like enquiry_describe or enquiry_fields.
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?
Provides a clear two-step protocol: first call with answers and consent to get a token, then second call with the token only after the person agrees. It says what the tool is not ('NOT a purchase, NOT a guaranteed quote'), but it does not explicitly name alternative sibling tools for other use cases.
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.
checker_answerchecker_startchecker_treeenquiry_describeenquiry_fieldssubmit_enquiryClass Q Checker: the site's own MCP server — checker, enquiry (enquiry = a human handoff, not a...
Catchment Checker: the site's own MCP server — checker, enquiry (enquiry = a human handoff, not...
Business Value Now: the site's own MCP server — checker, enquiry (enquiry = a human handoff, not...
Waste Carrier Check: the site's own MCP server — checker, enquiry (enquiry = a human handoff,...
Add one secure layer between your agents and this server.