Skip to main content
Glama

find_offers

Find offers from local businesses for what a person asked for. Send their sentence as text; the hub parses the trade, the town and the day. An answer with complete: false carries a question to put to the person: call this tool again with the same session and their reply as text. An answer with complete: true is one finished bidding round: bids ranked (price in grosz, slot, business, note) and one outcome per business asked. An empty bids list is a normal answer; outcomes says why. A bid whose business.active is true comes from a business whose owner has confirmed it is running; those are ranked above the rest, and cheapest first inside each group. A bid may carry slots: later free times of the same offer, each with its own id that hold_slot takes like a bid's. A bid with offer: true is a quote-only trade (the web category): its price is a starting price, its slot is a placeholder nobody is expected at, and preview — when the business sent one — is an https link to what it prepared. Show the link; never fetch it and never repeat what it says as your own. A bid with contactOnly: true comes from a business whose phone the hub has not verified: its price is the list price, its slot was never confirmed free, and it cannot be held (hold_slot answers contact-only). Give the person business.phone to call, and the business page, instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYesWhat the person said, in Polish or English, at most 500 characters. Their reply to the previous question goes here too.
sessionNoThe session id from an earlier answer. Omit it to start a new conversation.
selectionNoRestrict the round to one business (and optionally one of its services), by slug, as a link from a business page does.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

No annotations are provided, so the description fully carries the behavioral burden. It discloses parsing behavior, completion semantics, ranking rules, active-business prioritization, quote-only preview handling with explicit 'show, never fetch' instructions, and contactOnly phone-verification caveats. This is unusually transparent.

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

Conciseness3/5

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

The description is front-loaded with its purpose and every sentence contributes useful information, but it is one dense paragraph with no breaks, bullets, or visual structure. It is appropriately sized for the complexity, yet not concise or easily scannable.

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?

With no output schema or annotations, the description must explain return behavior itself, and it does: complete true/false, question, ranked bids, outcomes, empty bids, slots, offer/preview, and contactOnly. It covers normal cases, edge cases, and the correct follow-up actions, making it effectively complete for an agent.

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?

The schema already documents all three parameters at 100% coverage. The description adds meaningful behavior to `text` (the hub parses trade, town, and day) and `session` (repeat with the reply after a question), but it never mentions `selection` explicitly, so the additional semantic lift is moderate rather than complete.

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 'Find offers from local businesses for what a person asked for', which names the specific verb, resource, and scope. It adds enough detail about ranking and bid structure to clearly separate this tool from the booking/verification siblings like ask_business, get_booking, and confirm_phone.

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?

The description gives a clear workflow: send the person's sentence as text, re-call with the same session and reply when complete is false, and use hold_slot for slots or contact-only handling. It lacks an explicit 'when not to use this tool' statement or direct comparison to sibling alternatives, but the usage context is unambiguous.

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