enquiry_describeRead first. States plainly what submit_enquiry does on Broker vs Advisor: 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 burden. It clarifies that the workflow involves no purchase, no payment, and no guaranteed quote, and it states that the tool returns specific explanatory content. This makes the informational/read-only nature evident, though it never explicitly says this tool itself has no side effects.
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?
Every sentence earns its place: read-first guidance, what the tool does, what it does not do, and what it returns. The description is front-loaded with 'Read first.' and remains compact with no filler.
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, no-output-schema explanatory tool, the description is complete enough. It covers purpose, key caveats, and the nature of the returned information, so an agent can invoke it and understand the outcome.
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 schema description coverage is 100%, so there are no parameter semantics to document. Per the baseline for zero-parameter tools, the description does not need to add parameter detail.
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 action: it 'states plainly what submit_enquiry does' and enumerates the return content ('who receives the details, the consent wording, and how the person confirms'). This clearly separates it from submit_enquiry, though it does not explicitly differentiate it from other sibling tools like enquiry_fields.
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' clearly signals that this tool should be used before acting, and the description positions it as the explanatory precursor to submit_enquiry. It provides context (Broker vs Advisor) but does not explicitly state when not to use it or name alternative tools.
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.
The two prefixes (checker_ and enquiry_) cleanly separate the decision guide from the enquiry flow. Within each group, start/answer/tree and describe/fields/submit have distinct roles, and the descriptions make overlap unlikely.
All names are lowercase snake_case and grouped by prefix, which provides strong consistency. The post-prefix words mix nouns and verbs (start, tree, describe, submit_enquiry), so it is not a uniform verb_noun pattern.
Six tools is appropriate for this narrow scope: three for the decision guide lifecycle and three for the enquiry submission flow. No tool feels redundant or missing at a high level.
The tool set covers the complete user journey: learn about the guide, step through it or inspect the full tree, understand the enquiry, fetch its fields, and submit with consent/confirmation. No obvious dead-end or missing operation is apparent.