enquiry_describeRead first. States plainly what submit_enquiry does on Office Relocation Quotes: 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?
No annotations are provided, so the description carries the behavioral disclosure burden. It does explain that the described process has no purchase, no payment, and no obligation, and it says the tool returns details about recipients, consent wording, and confirmation. However, it does not explicitly state that calling this tool itself is side-effect-free or read-only, though the name and purpose imply it.
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 front-loaded with the imperative 'Read first,' then delivers the core purpose, the key behavioral facts, and the return contents in three tight sentences. Every sentence earns its place with no wasted words.
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-argument informational tool with no output schema, the description is complete: it tells the agent what the tool does, why it matters, what the underlying process entails, and exactly what will be returned. Nothing an agent needs to decide whether to call it is missing.
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?
There are 0 parameters, so the baseline is 4 and the description does not need to document any arguments. It adds no parameter info because none is needed.
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 verb and resource: it 'States plainly what submit_enquiry does on Office Relocation Quotes'. It clearly positions itself as the read-first explanatory tool, and the title reinforces what the user gets (an enquiry with a human, not a purchase or guaranteed quote). This makes it easy to distinguish from sibling tools submit_enquiry and 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 description opens with 'Read first,' giving an explicit timing signal that this tool should be used before submit_enquiry. It does not name alternatives or state when not to use it, but the context is clear enough for an agent to sequence it correctly.
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 purpose: one explains the process, one provides the schema, and one performs the submission. There is no overlap or risk of selecting the wrong tool.
Names are readable and share the 'enquiry' concept, but they follow mixed patterns: 'enquiry_describe' is noun-verb, 'enquiry_fields' is noun-noun, and 'submit_enquiry' is verb-noun. A more consistent set would use 'describe_enquiry', 'get_enquiry_fields', and 'submit_enquiry'.
Three tools is well-scoped for a focused enquiry-submission server. Each tool covers an essential step in the workflow without redundancy.
The surface fully covers the enquiry lifecycle: understanding the process, retrieving the required fields, and submitting with two-step confirmation. No additional CRUD operations are necessary for this domain.