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