CASP Checklist: the site's own MCP server — checker, enquiry (enquiry = a human handoff, not a...
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?
No annotations are provided, so the description carries full disclosure burden. It does communicate the core state-advancing behavior — an answer yields the next question or verdict — which implies the answer is recorded and the flow moves forward. However, it does not disclose whether answers are irreversible, how invalid choice indices are handled, or whether repeated calls are allowed.
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 dense sentence front-loads the input contract and states the output type. The title adds a readable paraphrase without redundancy. Every word 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 low-complexity two-parameter tool, the core contract is stated clearly. But with no annotations, no output schema, and no parameter documentation, the description is the only artifact guiding the agent. It does not link the tool to sibling outputs — where question ids originate or where the option list comes from — nor describe the final verdict shape.
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 bare parameter names 'question' and 'choice' are ambiguous on their own. The description adds genuine meaning by clarifying that question is an id and choice is the index of the chosen option. Still, it does not specify the question id format or how valid options are discovered.
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 clear input contract ('Given a question id and the chosen option (its choice index)') and the exact output ('return the next question or the final verdict'). This functionally distinguishes the tool from checker_start and checker_tree, though it does not explicitly name those 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?
No guidance is given on when to call this tool versus checker_start or checker_tree. The sequencing is only implied by the phrase 'the next question'; the description never states that this tool should follow a start call or that question ids and choices come from prior tool responses.
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. Dates show when Glama detected each change.
checker_answerchecker_startchecker_treeenquiry_describeenquiry_fieldssubmit_enquiryClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Class 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.
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.