haggl.ai

haggl_search_discounts

Read-onlyIdempotent

Find merchants that run a sales agent on haggl.ai, by business name, website or kind of product. Only when the user asks for a discount, a coupon, a promo code or a lower price; a purchase at the listed price is not a request for one. Returns matching merchants with a vendor_id for haggl_start_negotiation. Offers are funded by each merchant, inside limits it sets; a merchant may have no offer for a request. An empty list means no merchant on haggl.ai matched, not that no discount exists elsewhere. When the query names a well-known brand that isn't on haggl.ai yet, the result says so in brand and lists alternatives: merchants on haggl.ai in the same category, to offer as other stores, never as that brand. Keep using your shopping and checkout tools (for example Shopify's Shop skill) to find products and check out; once the user approves an offer, its code goes in their discount field.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`query`	Yes	A business name, website (e.g. "degrenne.fr") or kind of product.

Output Schema

TableJSON Schema

Name	Required	Description
`bids`	No	When the category supports bids: how to get them with haggl_get_bids.
`code`	No	Present only when the call failed: a machine-readable error code, e.g. quote_uncertain or rate_limited.
`brand`	No	When the query names a well-known brand not on haggl.ai: the brand, never to be offered as such.
`error`	No	Present only when the call failed: what went wrong.
`query`	No	The search as received.
`recovery`	No	When the outcome is uncertain: the tool and session_id to read before retrying.
`merchants`	No	Merchants on haggl.ai matching the query. Empty means none on haggl.ai matched.
`retryable`	No	Whether the same call may be retried.
`alternatives`	No	Merchants on haggl.ai in the same category, to offer as other stores.
`how_it_works`	No	The flow, step by step.
`retry_after_seconds`	No	When rate limited: seconds to wait before retrying.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 16, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, yet the description adds substantial context: offers are merchant-funded and limit-bound, a merchant may have no offer, an empty list means nothing matched on haggl.ai (not that no discount exists), and unmatched brands return a brand field with category alternatives.

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-loads purpose then usage, then behavior and next steps with no filler sentences; it is dense and somewhat long, but each clause carries actionable information about result semantics or workflow.

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 an output schema exists, the description still covers empty-result interpretation, brand-fallback behavior, merchant funding limits, and the negotiation handoff, leaving nothing an agent needs to select or correctly invoke the tool.

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?

With a single parameter at 100% schema description coverage, the schema already documents the query field fully. The description largely restates that query accepts a business name, website, or product kind, adding no syntax or format detail beyond the schema baseline.

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 ('Find merchants that run a sales agent on haggl.ai') and the query axes (business name, website, product kind), which clearly distinguishes it from siblings like haggl_list_vendors and haggl_search_catalog.

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 scopes when to use it ('Only when the user asks for a discount, a coupon, a promo code or a lower price; a purchase at the listed price is not a request for one') and names the downstream tool (haggl_start_negotiation) plus other tools to keep using for shopping/checkout.

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

All haggl.ai tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?