enquiry_describeRead first. States plainly what submit_enquiry does on Render Cost Calculator: 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 full behavioral burden and does it well: it discloses that nothing is bought, ordered, or paid, that no quote is guaranteed, that the process is free, and that it returns who receives details, the consent wording, and the confirmation method. This is strong disclosure for a describe-style tool.
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, each earning its place: the 'Read first' directive is front-loaded, the core purpose is stated next, and the caveats plus return contents follow without redundancy. The title also reinforces the non-purchase nature without being repeated verbatim in the body.
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 describe tool with no output schema and no annotations, the description is complete: it explains what the tool does, what it does not do, and what it returns. An agent has enough context to invoke it correctly without further detail.
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 takes zero parameters and schema coverage is 100%, so there is no parameter burden for the description to bear. Baseline of 4 is appropriate since parameter semantics are inherently not applicable.
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 a specific purpose: it 'States plainly what submit_enquiry does' on the Render Cost Calculator, and distinguishes the outcome (an enquiry with human providers who quote directly) from a purchase or guaranteed quote. It is clearly differentiated from the sibling submit_enquiry, which is the actual 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?
'Read first' gives an explicit usage cue that this tool should be consulted before acting, and the explanation of what submit_enquiry does helps an agent decide not to invoke the mutating sibling. However, it does not explicitly mention when to choose this over calculator_describe or enquiry_fields.
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: running the calculator, describing the calculator, describing the enquiry flow, listing enquiry fields, and submitting an enquiry. The descriptions reinforce these boundaries, so an agent should not confuse one tool with another.
Names are readable and use a shared domain vocabulary, but the patterns are mixed: 'calculate' is a bare verb, 'calculator_describe' and 'enquiry_describe' are noun-verb, while 'submit_enquiry' is verb-noun. This is inconsistent but still predictable enough to navigate.
Five tools is well-scoped for a small calculator/enquiry server. Each tool covers a necessary step in the workflow—calculation, description, field lookup, and submission—without unnecessary duplication or bloat.
The tool set fully covers the apparent domain: it lets agents understand the calculator, run it, understand the enquiry process, retrieve the required fields, and submit an enquiry with consent and confirmation. There are no obvious dead ends or missing lifecycle steps.