enquiry_describeRead first. States plainly what submit_enquiry does on Compare Vet Software: 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 behavioral disclosure burden. It plainly states that nothing is bought, ordered, or paid, that no quote is guaranteed, that it is free, and that it returns consent wording, recipient details, and confirmation method. This gives an agent a solid understanding of the tool's non-transactional, descriptive behavior.
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 reasonably compact and front-loaded with 'Read first,' followed by the core explanation and return-value summary. It is slightly redundant with the title, but every sentence adds useful differentiation or behavioral detail.
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 informational tool, the description is complete: it states purpose, behavioral caveats, and what is returned. It orients the agent to the relevant sibling (submit_enquiry) and leaves no critical gap for correct invocation.
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 input schema has zero parameters, so there are no parameter semantics to clarify. The baseline of 4 applies because the description correctly needs no parameter-level 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 identifies the tool's specific job: to explain what submit_enquiry does—starting an enquiry with human providers who quote directly. It clearly distinguishes this informational tool from the action-oriented submit_enquiry and from purchase-related flow, so an agent can tell them apart.
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 directive 'Read first' explicitly tells the agent to use this tool before engaging with submit_enquiry. It gives clear context for use, though it does not enumerate alternatives among the other sibling tools or 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.
The three compare tools are clearly separated into criteria/filters, options list, and full comparison table, while the three enquiry tools cover description, fields, and submission. There is minor potential confusion between compare_criteria and compare_table, but their descriptions make the boundary clear.
compare_criteria, compare_options, compare_table, and submit_enquiry follow a verb_noun pattern, but enquiry_describe and enquiry_fields break that pattern with a noun-first convention. The split is readable but not fully consistent.
Six tools is well-scoped for a comparison-and-enquiry workflow. Each tool serves a distinct step in browsing the comparison or submitting an enquiry, with no redundant tools.
The toolset covers the full user journey: exploring criteria, options, and the full table, then understanding, preparing, and submitting an enquiry with a two-step confirmation flow. There are no obvious missing operations or dead ends.