Revalidation Tracker: the site's own MCP server — checker, enquiry (enquiry = a human handoff,...
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 bears the full burden of behavioral disclosure. It states it returns the next step but does not disclose side effects, requirements (e.g., whether the question must exist), error behavior, or what happens if the choice is invalid. This is a significant gap for a tool that advances sequential logic.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that effectively front-loads the core action and inputs. It avoids redundancy and is efficiently sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema), the description provides the basic gist but is incomplete for confident invocation. It does not explain what the returned object looks like, whether the flow terminates, or relationship to siblings, which an agent would likely need to know.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds minimal parameter meaning: it identifies 'choice' as the chosen option's index and 'question' as an id, but does not explain how to obtain the question id, the exact format of the choice index, or range constraints beyond the schema's minimum 0. The description lacks detail to fully compensate for undocumented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('return') and resource ('next question or final verdict') tied to the tool name 'checker_answer', clarifying it advances a flow for a given question and choice. It doesn't explicitly differentiate it from siblings like checker_start or checker_tree, but the flow progression is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: call this when you have a question id and a chosen option to progress in a flow. It doesn't explicitly state when not to use it or mention alternatives like checker_start (for beginning) or checker_tree (for exploring paths), leaving some inference needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The first question of the Revalidation requirements checker decision guide.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden of behavioral disclosure. It only labels the tool as a question, without stating that calling it returns or presents the first question, whether it creates any session state, or what the agent should expect in the response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description should clarify what the tool returns and how the decision-guide flow proceeds. It does not mention the response format, the next steps, or how this tool relates to checker_answer and checker_tree, leaving important context to inference from sibling names.
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 properties and zero required parameters, so there is no parameter semantics for the description to clarify. This is the appropriate baseline for a no-parameter 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 title 'Start: Revalidation requirements checker' plus the description 'The first question of the Revalidation requirements checker decision guide' make the tool's role as an entry point reasonably clear. It identifies the resource and its position in a flow, but it does not use an explicit verb and does not differentiate from 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 explicit when-to-use guidance is provided. 'First question' weakly implies it precedes checker_answer, but the description never tells the agent to use this tool to initialize the guide or when to prefer a sibling tool.
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 Revalidation requirements 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?
With no annotations provided, the description carries the full burden. It discloses that the tool returns the entire decision tree content ('every question, option and verdict'), implying a static informational read. It does not discuss output format, size, or state, but for a zero-parameter content tool this is a reasonable baseline.
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 front-loads the key idea ('every question, option and verdict') and then states the purpose. Every word contributes meaning, with no filler or redundancy beyond the title.
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 tool with no output schema or annotations, the description gives the essential content scope and intended use. However, it does not clarify how the tree is structured or how the agent should consume the result when reasoning end to end, leaving some ambiguity about the return format.
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. There is nothing for the description to add about parameter semantics; the empty schema already tells the agent no input 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 tool as exposing the complete decision tree for the Revalidation requirements checker, listing its contents ('every question, option and verdict'). It is somewhat redundant with the title but adds the specific purpose of end-to-end reasoning, which helps distinguish it from the step-oriented checker_answer and checker_start 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' communicates when this tool should be used: when the agent needs the full decision structure rather than a single step or answer. It does not explicitly name alternatives or exclusions, but the context is clear enough given the sibling names.
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 Revalidation Tracker: 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, and it delivers: it discloses that nothing is bought, ordered, or paid, no quote is guaranteed, it is free, and it describes what the tool returns (recipient details, consent wording, confirmation method). This is strong transparency for a zero-parameter informational tool.
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 roughly 50 words and every sentence earns its place: purpose, expectations (free, no purchase, no guaranteed quote), and return content. 'Read first' front-loads the key usage instruction. Mildly rambling phrasing ('States plainly what submit_enquiry does') keeps it from a 5.
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 tool, the description is complete: it defines the tool's role relative to the sibling submit_enquiry, sets user expectations, and enumerates what the tool returns. It does not mention any auth requirements or rate limits, but these are unlikely to be relevant for a descriptive read-only tool.
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 0 parameters, and the rubric sets a baseline of 4 for that case. The description adds value beyond the empty schema by explaining what informational content the tool returns, which is the relevant semantic information an agent needs.
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 verb and resource: it 'states plainly what submit_enquiry does' on Revalidation Tracker, distinguishing it from the action tool submit_enquiry by positioning this as the read-first explainer. The title reinforces this by framing the output as explaining what the user gets. It falls short of 5 because it never directly says 'this tool explains the enquiry process,' instead describing via reference to submit_enquiry.
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?
'Read first' explicitly signals it should be used before submit_enquiry, which is clear usage context. However, it gives no explicit when-not-to-use guidance or named alternatives among the sibling tools. Usage is implied rather than fully specified.
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 Revalidation Tracker 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?
With no annotations, the description carries the burden of behavioral disclosure. It states exactly what the tool returns (key, label, type, required, help text, options) and that the output is meant to inform submit_enquiry calls. It does not explicitly say it is read-only or non-mutating, but as a zero-parameter metadata retrieval, the behavior is transparent 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 tight sentences. The first front-loads the resource and lists the returned attributes; the second gives a cross-reference to submit_enquiry. No filler or redundancy, and every clause 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 simple, zero-parameter tool with no output schema, this description is complete: it tells the agent what fields are returned and how to use them with submit_enquiry. The lack of formatting details is acceptable because the caller only needs the keys and labels. The relationship to sibling tools is sufficiently clear through 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 has zero input parameters, so the baseline of 4 applies. The description adds no input parameter details because none exist, but it usefully references the field key as the output-to-input contract for submit_enquiry, which aids correct downstream invocation.
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: every field of the Revalidation Tracker enquiry, and enumerates the exact attributes returned (key, label, type, required, help text, allowed options). It distinguishes itself from submit_enquiry by noting that answers should be keyed by field key, and the title adds context. It lacks an explicit verb like 'lists' or 'returns', so it is slightly less direct than ideal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a workflow: call this tool to learn the field keys, then pass answers to submit_enquiry keyed by those keys. It does not explicitly state when to use this vs enquiry_describe or the checker tools, and gives no exclusion criteria. The pointer to submit_enquiry is helpful and provides some 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 Revalidation Tracker — 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 CPD or revalidation support provider, 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 CPD or revalidation support provider, 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 full responsibility and succeeds. It reveals the two-step consent workflow, the exact consent wording, the email link requirement, and the fact that providers only see the enquiry after the person clicks the link.
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 detailed but efficiently organized into numbered steps and opens with the most critical distinction: not a purchase and not a guaranteed quote. The repeated consent details are not redundant because they define a required user-facing boundary.
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 two-step, consent-sensitive tool with no output schema, the description covers everything needed to invoke it correctly: inputs, validation result, confirmation token, approval condition, email behavior, and provider visibility. There is no critical missing 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 coverage is 100%, so the baseline is 3. The description adds workflow context beyond the schema: answers are keyed by enquiry_fields, consent must match a specific agreed statement, and confirmation is the token from Step 1 reused only after approval.
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 verb and resource: 'submits an enquiry to Revalidation Tracker' and immediately clarifies it is not a purchase or quote. It also frames the two-step nature of the operation, making it distinct from sibling tools like enquiry_describe and 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?
It provides explicit step-by-step usage: Step 1 with answers and consent=true, then Step 2 only if the person agrees, using the confirmation token. It also excludes misuse by stating this is NOT a purchase and NOT a guaranteed quote.
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!
Waste Carrier Check: the site's own MCP server — checker, enquiry (enquiry = a human handoff,...
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...
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 six tools split cleanly into a decision-guide workflow (start/answer/tree) and an enquiry submission workflow (describe/fields/submit). Each tool has a distinct role: start initializes, answer advances stepwise, tree provides full context, and the enquiry tools cover explanation, schema, and submission. No two tools could plausibly be used for the same action.
The checker_ and enquiry_ prefixes create clear, predictable grouping, and every name is snake_case. The main deviation is that some names are action-oriented (start, answer, describe, submit) while tree and fields are data-oriented nouns, so the grammatical pattern is not perfectly uniform.
Six tools is well-scoped for the two distinct workflows the server exposes. There is no redundancy or padding; each tool maps to one clear capability.
For the checker, start, answer, and tree cover entry, stepwise navigation, and full reasoning respectively. For the enquiry, describe, fields, and the two-step submit flow provide the explanation, schema, validation, confirmation, and final submission needed for a complete user journey.