enquiry_describeRead first. States plainly what submit_enquiry does on M365 Migration 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, the description carries the full burden and does well: it states that nothing is bought, ordered, or paid, that no quote is guaranteed, that it is free, and that it returns who receives details, consent wording, and confirmation. This goes well beyond a mere summary of the tool's action.
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 short, front-loaded with the 'Read first' instruction, and every sentence contributes meaningful caveats or return-value information. There is no redundant or filler content.
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 informational tool, the description covers purpose, usage timing, behavioral caveats, and what information is returned. It does not detail the exact response format, but that is likely unnecessary for this simple reference tool.
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 coverage is 100%, so the baseline is 4. The description appropriately provides no parameter-specific detail because there are no parameters to document.
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 identifies the tool as a read-first explainer for submit_enquiry on M365 Migration Cost, using the specific verb 'states plainly' and naming the exact resource and context. It distinguishes itself from submit_enquiry by clarifying the tool is informational, not the action itself.
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 imperative 'Read first' clearly tells the agent to consult this tool before using submit_enquiry. It also explains what submit_enquiry is not (no purchase, no guaranteed quote), which helps prevent misuse, though it does not explicitly compare against the sibling 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: enquiry_describe explains the process, enquiry_fields provides the schema, and submit_enquiry performs the submission. There is no overlap in purpose or ambiguity about which tool to call.
All names are snake_case and readable, but the pattern is slightly mixed: enquiry_describe and enquiry_fields use an object-first style while submit_enquiry uses a verb-first style. This is a minor deviation rather than a real usability problem.
Three tools is exactly right for the narrow scope of submitting an enquiry: one to learn about the process, one to get field definitions, and one to perform the submission. No tool feels redundant or missing.
The tool surface fully covers the enquiry workflow: contextual explanation, field discovery, and two-step confirmation-based submission. There are no obvious gaps such as missing validation, consent handling, or a dead-end in the submission process.