Skip to main content
Glama

CUBBY HOUSE — AU Mattress Commerce for Agents

dome_search_products

Search the CUBBY HOUSE Australian mattress catalogue (14 retailers, 145 products). Params: q (keyword), retailer, size, min_price, max_price, firmness_min, firmness_max, sort (price_asc|price_desc|name), limit, offset.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNo
sizeNo
sortNo
limitNo
offsetNo
retailerNo
max_priceNo
min_priceNo
firmness_maxNo
firmness_minNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.3/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the full behavioral burden, and it discloses almost nothing: no auth requirements, no default sort, no description of whether 'q' is fuzzy or exact, no return shape, and no pagination semantics beyond the raw limit/offset names. The catalogue size count is the only real behavioral signal, which is thin for a 10-parameter search tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences, front-loaded with the resource and scope before the parameter inventory. The param list mildly restates schema names, but the brief hints on q and sort give it some justification and nothing is padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter tool with no annotations, no output schema, and 0% schema coverage, the description is too skeletal: it omits default ordering, the firmness scale, pagination expectations, and what a result record contains. An agent could invoke it but would be guessing on several inputs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it only partially does: it clarifies that q is a keyword and enumerates the sort values (already in the schema enum), but min_price/max_price, firmness_min/max (what scale?), retailer, and limit/offset defaults are left entirely undefined. The names are largely self-explanatory, keeping this at a middling 3 rather than lower.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Search') and a precisely scoped resource ('CUBBY HOUSE Australian mattress catalogue'), even quantifying the scope (14 retailers, 145 products). The sibling tools (retailer traction, profile matching, lead submission) are functionally distinct, so an agent can route here without ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied by the word 'Search' plus the filter list; there is no explicit when-to-use statement, no exclusions, and no mention of when to prefer this over dome_match_profile, which could plausibly also surface products. Adequate but leaves the agent to infer routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources