compare_tableEach option's value on every criterion of the Six routes to a completed conveyance, compared comparison — the full table.
| Name | Required | Description | Default |
|---|---|---|---|
| option | No | one option's name, else all |
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 full burden of behavioral disclosure. It describes what the table contains but does not say whether it returns, displays, or exports the table, nor does it mention how the optional 'option' parameter affects the result or whether the operation is read-only.
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, but the phrasing 'compared comparison' is redundant and the noun phrase 'Six routes to a completed conveyance' is awkward. It conveys the essential idea without much waste, but the structure is not as clean or front-loaded as it could be.
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 simple table-query tool, the description gives a basic sense of the output, but with no output schema and no annotations it should clarify how the table is organized and what the 'Six routes' are. The optional filtering behavior is covered by the parameter schema, so this is not severely incomplete, just somewhat thin.
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?
Schema description coverage is 100%, and the schema already explains that 'option' is 'one option's name, else all.' The description adds no further parameter-level meaning, so the baseline score of 3 is appropriate.
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 comparison table and states its content: each option's value on every criterion. It is reasonably clear, but it lacks a direct verb and does not explicitly differentiate compare_table from the sibling tools compare_criteria and compare_options beyond the phrase 'the full table.'
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?
No guidance is given about when to use this tool versus compare_criteria or compare_options. The phrase 'the full table' implies a comprehensive view, but there are no explicit conditions, alternatives, or exclusions to help an agent choose it confidently.
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: three expose different views of comparison data, and three support the enquiry submission flow. There is no meaningful overlap between tools, even within the compare_* group, because each returns a different granularity of information.
The compare_* tools follow a consistent verb_noun pattern, but the enquiry tools mix conventions: enquiry_describe and enquiry_fields are noun-first, while submit_enquiry is verb-first. All names are readable and snake_case, but the ordering inconsistency prevents a higher score.
Six tools is well-scoped for a comparison-and-enquiry site: three tools cover the comparison content and three cover the enquiry submission flow. Each tool earns its place without unnecessary redundancy or missing essentials.
The tool set covers the full user journey: understanding the comparison, viewing criteria and options, inspecting the full table, learning what the enquiry does, fetching form fields, and submitting with a two-step consent confirmation. There are no obvious dead ends or critical missing operations for this domain.