enquiry_describeRead first. States plainly what submit_enquiry does on Citizenship Descent 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 arguments | |||
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
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 clarifies that no purchase, order, or payment occurs, that no quote is guaranteed, that the service is free, and that the response includes who receives details, consent wording, and confirmation method. This is strong behavioral disclosure.
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 uses each sentence to add meaningful context: what the tool explains, what it does not do, and what the response contains. No wasted words.
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 zero parameters, no output schema, and no annotations, the description fully equips an agent to understand when to call this tool and what to expect from it. It covers purpose, boundaries, and return content sufficiently.
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 reflects this with empty properties, so there is nothing for the description to explain. Per the baseline for zero-parameter tools, a 4 is appropriate.
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 purpose: it "states plainly what submit_enquiry does" on Citizenship Descent Checker, acting as a read-first explainer. It distinguishes itself from the actionable sibling submit_enquiry and from checker tools by emphasizing it is informational, not a purchase or guaranteed quote.
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" is an explicit cue to use this before interacting with submit_enquiry, giving clear when-to-use context. However, it does not explicitly mention alternatives or when-not-to-use scenarios, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a clearly distinct role: checker_start and checker_answer handle interactive progression, checker_tree provides the full decision map for offline reasoning, and the enquiry_* tools separate explanation, schema, and submission. Even where data overlaps, the descriptions clearly indicate which tool to use for which purpose.
The checker_ and enquiry_ prefixes create a useful grouping pattern, and all names are lowercase snake_case. The only minor inconsistency is submit_enquiry using verb-first naming while the other enquiry tools use the enquiry_ prefix, but this does not create real confusion.
Six tools is a well-scoped size for this server: three cover the decision guide interaction and three cover the enquiry flow. Each tool earns its place with no redundant or trivial additions.
The decision guide is fully covered by start, answer, and tree, allowing both step-by-step and end-to-end reasoning. The enquiry flow is also complete with explainer, field schema, and a two-step consent-based submission process, leaving no obvious dead ends.