compare_tableEach option's value on every criterion of the Snagging and defect management systems used by UK housebuilders and contractors 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?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only restates the output content. It does not mention whether the operation is read-only, how supplying or omitting the 'option' parameter changes the result, what shape the returned data takes, or any other behavioral traits beyond the literal content.
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 text is short, but the single sentence is grammatically tangled ('...systems used by UK housebuilders and contractors comparison — the full table'), which impairs readability. The key idea (full table of all options vs criteria) is embedded awkwardly at the end rather than being cleanly front-loaded.
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?
Although the tool is simple (one optional parameter, no output schema, no nested objects), the description omits any relation to sibling tools and conveys its purpose in confusing phrasing. An agent cannot reliably decide between this and compare_options or compare_criteria without inspecting their schemas, and the return value is only vaguely described.
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% — the only parameter 'option' is already fully described as 'one option's name, else all.' The description adds nothing about the parameter's effect on the output, so the baseline score of 3 applies.
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 resource (the comparison table of snagging and defect management systems) and what it contains (each option's value on every criterion), which clearly distinguishes it from the narrower sibling views compare_criteria and compare_options. However, the grammar is convoluted and there is no explicit verb stating what the tool does, so it reads more like a data label than a behavioral definition.
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 its siblings. 'The full table' weakly implies it is the comprehensive view compared to compare_criteria and compare_options, but those alternatives are never named and no selection logic or exclusion criteria are provided.
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 clear, distinct role: comparison tools separate criteria, options, and the full table, while enquiry tools separate explanation, fields, and submission. There is no meaningful overlap between any two tools.
Tool names consistently use snake_case, but the pattern is mixed: compare_* tools are verb-first, enquiry_describe and enquiry_fields are noun-first, and submit_enquiry is verb-first. The names are readable and grouped by domain, but the convention is not fully uniform.
Six tools is well-scoped for this site: three comparison tools cover the comparison table experience, and three enquiry tools cover the enquiry flow. Each tool earns its place with no redundant or excessive additions.
The tool surface covers the full apparent purpose: comparing snagging and defect management systems and submitting an enquiry. The enquiry flow is complete with describe, fields, and two-step submission, leaving no obvious dead ends.