enquiry_describeRead first. States plainly what submit_enquiry does on AI vs Hire: 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 it does so well by stating that nothing is bought, ordered, or paid, that no quote is guaranteed, and that it is free. It also previews what the tool returns: recipients, consent wording, and confirmation mechanism. It stops short of explicitly saying the describe call itself has no side effects, but the framing makes that clear enough.
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 and front-loads the most important instruction ('Read first'), then explains behavior and return content. The only minor issue is that 'AI vs Hire' is used without explanation, slightly obscuring a key context term.
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?
Given the tool is a zero-parameter informational helper with no output schema, the description supplies adequate context about what the tool does and what information it returns. It lacks explicit output-format detail, but for a no-arg describe-style tool this is a minor gap.
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 already covers everything (100% coverage), so the description does not need to explain parameters. The baseline of 4 applies because there is nothing for the description to add about inputs.
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 a read-first explainer for what submit_enquiry does, with a specific resource (the enquiry submission flow) and a specific purpose (disclosing behavior before action). It contrasts with submit_enquiry by framing this as the descriptive counterpart, though it does not explicitly name other siblings like calculator_describe.
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 signal that this tool is meant to be consulted before taking action, likely before calling submit_enquiry. It also clarifies what the tool does not guarantee (no purchase, no guaranteed quote), which helps an agent avoid misuse. However, it does not explicitly state when not to use this tool or suggest alternatives.
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: calculate runs the calculator, calculator_describe documents it, enquiry_describe explains the enquiry flow, enquiry_fields provides the schema, and submit_enquiry performs the submission. There is little risk of selecting the wrong tool.
Tool naming mixes patterns: 'submit_enquiry' is verb_noun, 'calculate' is a bare verb, 'calculator_describe' and 'enquiry_describe' are noun_verb, and 'enquiry_fields' is a compound noun. The names are readable and the action/metadata split is recognizable, but there is no consistent convention.
Five tools is a tight, well-scoped set for a calculator-plus-enquiry server. Each tool covers a necessary part of the workflow without redundancy or bloat.
The surface covers the full intended workflow: inspect calculator assumptions, run a calculation, understand the enquiry process, get enquiry fields, and submit with explicit two-step consent. No obvious dead ends or missing operations are apparent.