enquiry_describeRead 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 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 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.
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.