enquiry_describeRead first. States plainly what submit_enquiry does on Commercial EPC 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 full responsibility and does so well: it states that nothing is bought, ordered, paid, or guaranteed, and that the service is free. It also discloses what information will be returned, including 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?
Three sentences deliver the essential information with no filler: a usage command, the tool's purpose, the safety/expectation context, and the return contents. The most important framing, 'Read first', is front-loaded.
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, the description provides enough context for an agent to know why it exists, what it covers, and what it will produce. It also addresses the key concerns an agent would have before submitting an enquiry, making it complete.
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 schema has zero parameters, so there is nothing for the description to explain about arguments or inputs. The baseline for a parameterless tool is appropriate, and the description uses the space to clarify behavior instead.
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 that enquiry_describe explains what submit_enquiry does, grounding it to the specific 'Commercial EPC Cost' context. It also distinguishes itself from submit_enquiry by being the read-first informational tool rather than the action 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 'Read first' gives explicit sequencing guidance, implying the agent should call this before submit_enquiry. It does not explicitly mention alternatives or exclusions regarding enquiry_fields, so it stops short of full 5-level guidance.
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 performs the submission. No two tools overlap in purpose, so an agent should be able to select the right one without ambiguity.
All names are lowercase snake_case and share the 'enquiry' domain, but the pattern is mixed: enquiry_describe and enquiry_fields place the noun first, while submit_enquiry places the verb first. The naming is readable but not as consistent as a uniform verb_noun convention.
Three tools is an appropriate scope for a single enquiry-submission workflow: one to orient, one to define the fields, and one to submit. Each tool earns its place without unnecessary redundancy.
The tool set covers the full enquiry lifecycle from understanding the process and schema to two-step submission with consent confirmation. There are no obvious missing operations for the narrow commercial EPC cost enquiry domain.