t00my-mcp

Overview Schema Source Related Servers Discussions Admin

Search Products

search_products

Search toom.de products by keyword and narrow results by brand, price, availability, offers, and sorting. Returns product hits with offer and stock details for the selected market.

Instructions

Search toom.de, optionally narrowed down. First result page only (max ~72 hits, shown up to limit).

Examples: "a drill that is on offer" -> query="bohrmaschine", offers_only=True. "cheapest cordless screwdriver in stock here" -> query="akkuschrauber", availability="in_market", sort="price_asc". "Bosch or Makita under 150 EUR" -> brands=["Bosch","Makita"], max_price=150.

offers_only: toom's "Nur Angebote anzeigen". sort: relevance | price_asc | price_desc | offers | rating (toom's own, raw rating) | best_rated (re-ranks the hits of this page by a score that discounts articles with few reviews: a 5.0 from one review does not beat a 4.8 from 200). min_reviews drops hits with fewer reviews (unrated ones too). availability: in_market (in stock in the selected market) | orderable (not in stock, the market can order it) | home_delivery. filters takes toom's own filter params and values as listed by search_filters (e.g. {"attr.mca_akkuinklusive": ["Ja"]}); different filters are combined with AND, values of one filter with OR.

Each hit has on_offer (toom's offer flag or a promotion such as "Gratis Beigabe", see promotion) and availability for the market: market_reservable, market_orderable ("Auf Anfrage bestellbar": the inquiry is done by the user on the product page) and home_delivery. For stock quantities use compare_markets. Search by words: an exact article number is redirected by toom to a product page.

Input Schema

TableJSON Schema

Name	Required	Default
`sort`	No	relevance
`limit`	No
`query`	Yes
`brands`	No
`market`	No
`filters`	No
`max_price`	No
`min_price`	No
`min_reviews`	No
`offers_only`	No
`availability`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 15, 2026

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so richly: page-size/hit ceiling, exact-article-number redirect behavior, the meaning of each `availability` value (including the 'Auf Anfrage bestellbar' inquiry flow), AND/OR combination semantics for `filters`, and how `best_rated` discounts low-review items. This is far beyond restating the schema.

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?

Front-loaded with the core scope statement and examples before the per-parameter detail, and most sentences carry concrete information. It is dense and long, with some parenthetical asides that could be trimmed, but little is truly wasted.

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

Completeness4/5

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

An output schema exists, so return-value explanation is not required, and the description still describes key hit fields (`on_offer`, `promotion`, `availability`). Given 11 parameters and 0% schema coverage, a few parameters (market, min_price) remain under-specified, keeping it from a 5.

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

Parameters4/5

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

Schema coverage is 0%, so the description must compensate across 11 parameters. It explains sort (with enum values), offers_only, availability, filters, and min_reviews well, and implies query/brands/max_price via examples, but leaves `market`, `limit` details, and `min_price` largely undefined. Strong but incomplete compensation.

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 and resource (search toom.de products) and scopes it precisely: first result page only, max ~72 hits, capped by `limit`. It is clearly distinguishable from siblings like compare_markets (stock quantities) and search_filters (filter vocabulary), which it explicitly cross-references.

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

Usage Guidelines4/5

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

Three worked natural-language examples map intent to parameter combinations, which is excellent guidance for a search tool. It also routes two related needs to siblings (compare_markets for stock quantities, search_filters for filter params/values). It stops short of any explicit when-not-to-use statement, so a 4 rather than 5.

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