enquiry_describeRead first. States plainly what submit_enquiry does on Fire Alarm Servicing Cost: 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, the description carries the behavioral disclosure burden and does well: it states the action is free, involves no purchase/order/payment, provides no guaranteed quote, and returns recipient/consent/confirmation details. It does not explicitly declare the tool itself as 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 at three sentences and front-loads the 'Read first' instruction. Minor redundancy exists between the title ('not a purchase, not a guaranteed quote') and the description ('Nothing is bought, ordered or paid; no quote is guaranteed'), but each sentence 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 zero-parameter, informational tool with no output schema, the description covers what the tool returns and what assumptions to avoid. It lacks an explicit statement of output format, but that is a minor gap given the low complexity and explanatory purpose.
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 is empty with zero parameters, so there are no parameter semantics to explain. The description adds useful context about what is returned, but no parameter-level documentation is needed; baseline 4 applies.
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 an explanatory preamble to submit_enquiry: 'States plainly what submit_enquiry does' and clarifies what is not happening ('Nothing is bought, ordered or paid'). It distinguishes the describe action from the actual submission action, though it does not explicitly frame itself as 'describes the enquiry flow' beyond that.
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' gives a clear ordering cue to use this before submit_enquiry, and the title warns it is not a purchase or guaranteed quote. However, it does not mention the sibling enquiry_fields or explain when to prefer this tool over that alternative, so usage guidance is partial rather than complete.
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: one explains the process, one provides the field schema, and one submits the enquiry. There is no overlap between them, so an agent can confidently select the right tool for each step.
The names are readable and semantically related, but the patterns are mixed: enquiry_describe and enquiry_fields lead with the noun, while submit_enquiry follows verb_noun. This is a minor inconsistency rather than chaos, so it earns a middle score.
Three tools is well-scoped for a narrowly defined enquiry submission workflow. Each tool earns its place: orientation, schema discovery, and submission.
The tool surface fully covers the enquiry lifecycle described: explaining the process, enumerating required fields, and submitting with explicit consent and confirmation handling. No obvious missing step or dead end exists for the stated purpose.