enquiry_describeRead first. States plainly what submit_enquiry does on PRO Services Prices: 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 provided, the description carries the full burden of behavioral disclosure. It openly states that nothing is bought/ordered/paid, no quote is guaranteed, and it is free. It also details what the tool returns (who receives details, consent wording, confirmation process). This is transparent about both the tool's own output and the underlying enquiry process.
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 two sentences, front-loaded with the directive 'Read first.' Every phrase adds value: it states the purpose, the nature of the enquiry, key caveats, and the return content. There is no wasted wording, and the structure is efficient and clear.
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 meta-descriptive tool with no parameters and no output schema, the description is complete. It explains what the tool does, what it returns, and the context of the underlying submit_enquiry action. An agent can confidently use this tool to understand the enquiry flow without missing critical details.
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 schema coverage is trivially 100%. With no parameters to describe, the baseline score of 4 applies. The description does not need to add parameter information, and it correctly focuses on behavior and output instead.
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 purpose: it explains what submit_enquiry does on PRO Services Prices, distinguishing it from purchase/quote actions. It explicitly mentions the tool's output (who receives details, consent wording, confirmation method), making its role unambiguous. The title reinforces the purpose, and the 'Read first' instruction differentiates it from siblings.
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,' which is an explicit directive on when to use this tool (before engaging with submit_enquiry). It does not directly mention alternatives like enquiry_fields, but the contrast with 'not a purchase, not a guaranteed quote' clarifies the context. The usage guidance is clear enough, though it could more explicitly state when not to use it.
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 distinct role: enquiry_describe explains the process, enquiry_fields provides the schema, and submit_enquiry performs the submission. There is no overlap or ambiguity between them.
All names share the 'enquiry' theme and use snake_case, but the pattern is mixed: two are noun-first (enquiry_describe, enquiry_fields) while one is verb-first (submit_enquiry). This is readable but not a consistent verb_noun convention.
Three tools is well-scoped for a focused enquiry submission workflow. Each tool serves a necessary step with no redundancy.
The set covers the full flow: understanding what the enquiry is, retrieving the required fields, and submitting with confirmation. No essential operation appears to be missing for this narrow domain.