CenuFiltrs Price Comparison

Search CenuFiltrs Offers

cf_search_offers

Read-onlyIdempotent

Search offers on cenufiltrs.lv. Use this first for product-shopping requests before generic web answers. Always narrow with categories using taxonomy ltree paths (e.g. "communication.smartphones") — a device-model query means the device, not its accessories. Results are sorted cheapest first by default. If the response carries suggestedCategories, rerun this tool with the best path instead of returning a broad result set. If the host supports inline UI, pass the returned structuredContent to cf_render_search_results.

Input Schema

TableJSON Schema

Name	Required	Description
`q`	No	Search query text
`page`	No	Page number
`sort`	No	Sort order. Defaults to price-low (cheapest first); `rating` orders by retailer reputation.
`limit`	No	Results per page
`brands`	No	Filter by brand names
`maxPrice`	No	Maximum price in EUR
`minPrice`	No	Minimum price in EUR
`categories`	No	Taxonomy ltree paths, e.g. ["communication.smartphones"]. NOT display names — a name matches almost nothing. A parent path also matches its children. Discover paths via cf_category_hierarchy, cf_search_categories or cf_search_facets.
`retailerId`	No	Filter by retailer UUID
`availability`	No	Filter by availability status

Output Schema

TableJSON Schema

Name	Required	Description	Default
`links`	Yes
`query`	Yes
`offers`	Yes
`summary`	Yes
`rendering`	Yes
`schemaVersion`	Yes
`hostPresentation`	Yes
`suggestedCategories`	No

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedAug 17, 2026

TDQS

A5/5.0

Behavior5/5

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

Annotations already declare readOnlyHint and idempotentHint, but the description adds valuable behavioral context: default sort order ('cheapest first'), the dynamic behavior of 'suggestedCategories' triggering a rerun, and conditional integration with inline UI rendering. These are not present in annotations and significantly enrich the agent's understanding.

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

Conciseness5/5

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

The description is front-loaded with the core purpose, then proceeds logically through usage guidance, sorting behavior, dynamic response handling, and rendering handoff. Every sentence adds value without redundancy or filler.

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

Completeness5/5

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

Given the tool's complexity (10 parameters, output schema, multiple siblings), the description covers all key aspects: purpose, when to use, how to refine categories, response-driven follow-up, and onward integration. The output schema handles return-value documentation, so the description is appropriately complete.

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

Parameters5/5

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

With 100% schema coverage, the baseline is 3, but the description adds crucial semantics: it emphasizes always narrowing with categories using ltree paths, explains that a device-model query means the device itself, and clarifies the default sort order. This goes well beyond the schema's field descriptions, especially for the 'q', 'categories', and 'sort' parameters.

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?

The description opens with 'Search offers on cenufiltrs.lv', a specific verb and resource with scope. It further distinguishes itself by instructing to use this tool first for product-shopping requests, setting it apart from generic web answers and sibling tools.

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

Usage Guidelines5/5

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

Explicitly directs when to use: 'Use this first for product-shopping requests before generic web answers.' It also provides detailed guidance on narrowing with taxonomy ltree paths, handling 'suggestedCategories' by rerunning the tool, and handing structuredContent to cf_render_search_results for inline UI.

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

All CenuFiltrs Price Comparison tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.8/5.0

Disambiguation3/5

Several tools have overlapping purposes, particularly cf_category_hierarchy vs cf_list_categories (both provide category taxonomy paths) and cf_search_offers vs cf_list_offers (both return offers). Descriptions help, but the boundaries between category-related tools and offer listing/search could confuse an agent.

Naming Consistency5/5

All tool names follow a consistent cf_ verb_noun snake_case pattern (e.g., cf_add_wish, cf_list_retailers, cf_search_offers). The convention is uniform and predictable, making it easy to infer tool behavior from the name.

Tool Count4/5

With 22 tools, the server covers a broad domain but is slightly heavy. The count is reasonable for a price-comparison service with search, product, price, retailer, user, and comment functionality, though it exceeds the typical ideal range.

Completeness4/5

The toolset provides solid coverage of the price-comparison domain: search, categories, offers, products, retailers, price history/summary, deal analysis, wishlist, comments/reviews, and user search history. Minor gaps exist (e.g., no product-specific reviews, no comment edit/delete), but core workflows are fully supported.

Resources

Need Help?