enquiry_describeRead first. States plainly what submit_enquiry does on Transport Statement 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 burden of behavioral disclosure. It does convey that the tool is informational ("States plainly", "returns") and clarifies that no purchase or payment occurs. However, it is somewhat ambiguous whether those guarantees describe this tool or submit_enquiry, and it does not explicitly state that 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?
The description is compact and front-loaded with the important reading instruction. The content is not padded, though the phrasing is slightly indirect and could more simply say what the tool does rather than describing submit_enquiry's behavior.
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 with no output schema, the description covers the essential return contents: who receives the details, consent wording, and confirmation mechanism. It is complete enough for an agent to know what to expect, though exact output formatting is not specified.
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, so parameter documentation is not needed. The description appropriately focuses on what the tool returns and what it clarifies, which is sufficient given the empty schema.
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 states the tool's function: it explains what submit_enquiry does, starting an enquiry with human providers, and returns the recipient details, consent wording, and confirmation process. This distinguishes it from actually performing the enquiry, though it does not explicitly contrast with 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 phrase "Read first" gives a clear implied usage cue: consult this before using submit_enquiry. However, there is no explicit when-not-to-use guidance or direct comparison with the sibling tools, so the guidance is contextually implied rather than fully specified.
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 targets a distinct aspect of the enquiry flow: describe explains the process, fields provides the schema, and submit performs the actual two-step submission. There is no overlap or ambiguity between them.
Naming is mixed: two tools use an 'enquiry_' prefix with the verb at the end ('enquiry_describe') or no verb ('enquiry_fields'), while the third uses a verb-first pattern ('submit_enquiry'). The names are readable and share a common root, but the verb placement is inconsistent.
Three tools is perfectly scoped for a single, narrow enquiry submission workflow. Each tool serves a necessary step without redundancy or unnecessary expansion.
The tool set covers the full enquiry lifecycle: learning about the process, getting field definitions, and submitting with the required two-step confirmation. No obvious operations are missing for the stated purpose.