Skip to main content
Glama
Crawlora MCP

Crawlora MCP

Official

slickdeals_search

Search Slickdeals community deals by keyword to retrieve deal threads with title, price, merchant, votes, and post details. Narrow results by forum or deal type.

Instructions

Search Slickdeals community-submitted deals by keyword. Searches Slickdeals (slickdeals.net), a community deal/coupon aggregator, for deal threads matching a free-text keyword query. Each result is one community-submitted deal thread with its title (which conventionally embeds the deal price), a best-effort price extracted from that title, the merchant domain, the community vote ("thumb") score, the public Slickdeals username who posted it, and when it was posted. Pair a result's thread_id or url with GET /slickdeals/deal for the full detail record, including comment count and category. An optional forum_id restricts results to one Slickdeals legacy sub-forum (e.g. Hot Deals, Coupons) -- obtain a value from GET /slickdeals/forums, a closed enum validated before the request is made. An optional deal_type_id restricts results to one Slickdeals deal-type tag (e.g. Coupon, Free / Freebie, YMMV) -- obtain a value from GET /slickdeals/deal-types, also a closed enum validated before the request is made; composes with forum_id.

Input Schema

NameRequiredDescriptionDefault
qYesFree-text keyword query
forum_idNoRestrict results to one Slickdeals legacy sub-forum, from GET /slickdeals/forums
deal_type_idNoRestrict results to one Slickdeals deal-type tag, from GET /slickdeals/deal-types

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.5

TDQS

A4.4/5.0
Behavior4/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 well: it enumerates returned fields, flags the price as 'best-effort extracted from title', and notes both filters are closed enums validated before the request is made. It omits pagination, result limits, and rate-limit behavior, which leaves some operational gaps for a 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?

Core purpose is front-loaded in the opening sentence, and each subsequent sentence covers sequencing or filters. It is dense and slightly repetitive (redefining Slickdeals and the tracker parenthetical), which trims a point but nothing is wasted outright.

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?

There is no output schema, yet the description fully specifies the result shape (title, extracted price, merchant domain, thumb score, poster, timestamp) and the cross-tool workflow, giving the agent everything needed to call and use the tool correctly.

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 100%, so baseline is 3, but the description adds genuine value: concrete forum examples (Hot Deals, Coupons), deal-type examples (Coupon, Free / Freebie, YMMV), the source endpoints to fetch valid IDs, and the note that the two filters compose. That goes beyond the schema's terse param descriptions.

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 states a specific verb (search) and resource (Slickdeals community-submitted deal threads) plus the scope (free-text keyword query). It distinguishes itself from downstream siblings by pointing to GET /slickdeals/deal for full detail, and the enumerated result fields make the output unambiguous.

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?

It clearly explains how to obtain forum_id and deal_type_id values and how to chain thread_id/url into GET /slickdeals/deal for detail. It gives strong when-to-use context but never contrasts itself with the sibling slickdeals_search_advanced, so the agent must infer which search variant to pick for complex queries.

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

Deploy Server

Other Tools