enquiry_describeRead first. States plainly what submit_enquiry does on CCTV Drain Survey 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 provided, the description carries the full transparency burden and succeeds. It discloses that nothing is bought, ordered, or paid, that no quote is guaranteed, and that the service is free. It also states exactly what the tool returns: recipient details, consent wording, and confirmation method.
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 concise and front-loaded with 'Read first,' which immediately directs the agent. There is slight redundancy with the title ('not a purchase, not a guaranteed quote' vs. 'nothing is bought, ordered or paid; no quote is guaranteed'), but the extra clarity about cost and return content justifies the length.
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 parameterless informational tool with no output schema, the description is complete: it explains what the tool is for, what it does not do, what it returns, and how to use it relative to submit_enquiry. An agent has enough context to invoke it correctly and understand the result.
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 coverage is 100%, so there are no parameter semantics to explain. The baseline for a parameterless tool is 4, and the description appropriately does not clutter itself with irrelevant parameter details.
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 states the tool's purpose: it explains what submit_enquiry does on the CCTV Drain Survey Cost flow, distinguishing an enquiry from a purchase or guaranteed quote. It also names the content returned, so an agent understands this is an informational/descriptive tool, not the action tool itself. The title reinforces this by framing the output as 'What you get.'
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' strongly implies this tool should be consulted before using submit_enquiry, giving clear contextual placement among siblings. It does not explicitly mention when not to use it or compare it with enquiry_fields, but the purpose is evident enough that an agent would know to call this before taking an action.
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: enquiry_describe explains the process, enquiry_fields provides the schema, and submit_enquiry executes the submission. There is no overlap or ambiguity between them.
All tools clearly reference 'enquiry', but word order varies: enquiry_describe and enquiry_fields put 'enquiry' first, while submit_enquiry puts it last. This is a minor deviation from a fully consistent verb_noun pattern.
Three tools is well-scoped for a focused enquiry submission flow: one to understand the process, one to provide fields, and one to submit. Each tool earns its place and there is no bloat.
The tool set covers the entire enquiry lifecycle, from explanation and field schema to submission with a two-step confirmation. No obvious gaps exist for the stated purpose.