enquiry_describeRead first. States plainly what submit_enquiry does on Generator 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 provided, the description carries the full burden of behavioral disclosure. It transparently states that nothing is bought, ordered, or paid, that no quote is guaranteed, and that it is free. It also discloses what the tool returns: who receives the details, consent wording, and confirmation method. This is comprehensive and beyond what annotations could have provided.
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 two sentences, front-loaded with 'Read first,' and every word earns its place. It conveys the purpose, key constraints (no purchase, no guaranteed quote, free), and return content without any fluff. This is a model of concise, efficient writing.
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 description tool with no parameters, no output schema, and no annotations, the description is fully self-contained. It explains what the tool does, what it returns, and the context (Generator Servicing Cost). An agent can correctly decide when to call it and what to expect from the result. There are no missing pieces.
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% (trivially). The description does not need to explain parameters, and it doesn't attempt to. Per the rubric, 0 parameters warrants a baseline of 4, which is appropriate here since the description adds no parameter-specific value but also requires none.
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 function: it 'States plainly what submit_enquiry does' and explains that it starts an enquiry with human providers who quote directly. The title reinforces this by summarizing what the user gets. It distinguishes itself from siblings by being the 'Read first' explanatory tool, not 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 description begins with 'Read first,' providing explicit guidance to use this tool before submitting an enquiry. It also clarifies the context (Generator Servicing Cost) and what the tool does not do (purchase, guaranteed quote). However, it does not explicitly mention alternatives like enquiry_fields, but the 'Read first' directive serves as a clear usage instruction.
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: describe explains the process, fields provides the schema, and submit performs the submission. There is no overlap or ambiguity between them.
All tool names follow the consistent 'enquiry_' prefix plus a clear verb or noun: describe, fields, submit. The pattern is uniform and predictable.
Three tools are well-scoped for the single enquiry submission workflow. Each tool earns its place and the count is appropriate for the narrow purpose.
The tool set covers the full enquiry lifecycle: reading guidance, fetching field definitions, and submitting with a confirmation token. No obvious gaps exist for the stated purpose.