Class Q Checker: 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 the full burden of behavioral disclosure. It does disclose the key outcome: the tool returns the next question or the final verdict. However, it does not explain whether invoking it records the answer, advances state irreversibly, or what happens on invalid input—gaps that matter for a tool whose title says 'answer'.
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, tightly worded sentence with no filler. The key inputs and outputs are front-loaded, and every word contributes to understanding the tool's behavior.
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 simple two-parameter tool, the description captures the essential I/O: question id plus choice yields next question or final verdict. However, with no annotations and no output schema, it leaves out the return format, error behavior, and the relationship to checker_start/checker_tree, so the agent is left to infer broader 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?
Schema description coverage is 0%, so the description must add meaning to the parameters. It does add useful semantics: the string parameter is a question id and the integer is a choice index. It does not explain how to obtain a valid question id or clarify the structure of the 'next question' return value, but the basic parameter roles are made clear.
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 action: given a question id and choice index, return the next question or final verdict. This clearly identifies the tool's role in a question/answer flow. It does not explicitly contrast itself with siblings like checker_start or checker_tree, but the verb 'answer' and resource 'question' make the purpose distinct enough.
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 'Given a question id and the chosen option' implies usage after a question has been presented, and the title 'Answer a question, get the next step' provides context. However, the description gives no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives such as checker_start or checker_tree.
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: "Happy for my details to go to a relevant planning consultant or rural architect, 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 planning consultant or rural architect, 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?
No annotations are provided, so the description carries the full disclosure burden. It thoroughly covers side effects: validation, summary/consent/token return, email receipt, and the emailed-link requirement before any provider sees the enquiry. It also quotes the exact 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 longer than average, but each part earns its place: disclaimers, ordered steps, consent semantics, and token role. The Step 1/Step 2 structure and front-loaded 'NOT a purchase' make it easy to parse for an agent.
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 annotations and no output schema, the description supplies the necessary return values (summary, consent line, confirmation token) and post-conditions (email, provider visibility only after link click). The two-step contract gives an agent everything needed to invoke this tool correctly.
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 already covers 100% of parameter descriptions, so the baseline is 3. The description adds real semantic value by explaining answers are keyed by enquiry_fields field keys, that confirmation is the step-1 token used for the final submission, and that consent requires the quoted agreement text.
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 action ('Submits an enquiry to Class Q Checker') and immediately clarifies what it is not ('NOT a purchase, NOT a guaranteed quote'). It also distinguishes the two-step submission flow, making the tool's role clear against the related checker and enquiry 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 description gives explicit step-by-step when to call (Step 1 with answers/consent, Step 2 only after the person agrees and with the token) and an explicit when-not ('NOT a purchase'). It does not name a competing sibling tool to prefer in other cases, so it falls just short of full alternative routing.
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!
Catchment 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.
The checker tools are separated by interactive progression (start/answer) versus full-tree reasoning, and the enquiry tools cleanly separate documentation, schema, and submission. The only mild overlap is that checker_tree also contains all questions and verdicts, so an agent could use it to bypass the step-by-step tools.
All names are snake_case and grouped by domain prefix (checker_*, enquiry_*), but word order and parts of speech are mixed: checker_start and checker_answer are imperative, checker_tree and enquiry_fields are nouns, enquiry_describe is object-verb, and submit_enquiry is verb-object. This is readable but not a consistent pattern.
Six tools are well-scoped for the two workflows: three for the eligibility decision guide and three for the enquiry submission process. No tool feels redundant or missing at the count level.
The decision guide has start, step-through, and full-tree coverage, while the enquiry flow has a describe-first explanation, field schema, and a two-step submission with confirmation token. There are no obvious dead ends for the stated purpose.
