Skip to main content
Glama

commit_order

Place a binding order with a business, inside limits they set in advance. This is the only tool here that commits anyone to anything. Either name the figure yourself, or send items from get_rate_card and we price them from the merchant's own card. Either way it is checked against their price floor, maximum, daily capacity, notice period and blackout dates. Send time to take one slot rather than a whole day — check_availability lists them. No model reads any part of this call: the fields you send are the fields we check, so a commitment cannot be talked into existence by anything written in prose. Returns committed. When true you get a ref, the exact terms agreed and basis naming which of their settings allowed it. When false, reason names the single limit that refused: "not-authorised", "below-price-floor", "above-maximum" (a person decides that one), "capacity-full", "blackout-date", "inside-lead-time", "currency-mismatch", "date-in-past", "unknown-items", "quote-mismatch" (their prices changed), "slot-taken", "not-a-slot-start". A refusal is final for those terms — change them or use contact_business; do not retry the same call. The business may later withdraw. Read state from check_commitment before relying on it. Authentication: bearer token required. Register once at POST /api/v1/agents/register, exchange the credentials at POST /api/v1/agents/token.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateYesThe day the work or delivery is for, as yyyy-mm-dd, in the business's own local calendar.
kindYesThe `kind` field from the same search result.
slugYesThe `slug` field from a search_businesses result.
timeNoOptional. A slot start on that day, HH:MM in 24-hour time and in their timezone. It must be one of the starts check_availability lists; times between them are refused rather than rounded to the nearest one.
itemsNoOptional. Lines from their rate card, as request_quote takes them. When present, the price is theirs rather than yours and is computed fresh at this moment — a card that changed since you quoted refuses with "quote-mismatch" instead of billing the new figure.
amountNoWhat the buyer is offering to pay, as a number. Required unless you send `items`. This is your figure, not ours — we only check it against the limits the business set. Sent alongside `items`, it must equal what their card comes to, or the call is refused.
currencyNoISO code, e.g. MDL or EUR. Required unless you send `items`. It must match the currency their limits are in.
quantityNoOptional. How many, as a whole number. Defaults to 1. Leave it out when you send `items` — the quantities are on the lines.
descriptionNoOptional. What the order is for, in plain words. Recorded and shown to the business; it is never parsed and never changes what we check.

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden. It discloses bindingness, safety checks (price floor, maximum, capacity, blackouts), integrity guarantees (no model reads the call), refusal finality, possible later withdrawal, and authentication requirements. This is exceptionally transparent.

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?

The description is long but densely packed with essential information for a high-stakes binding action. It is front-loaded with purpose and uses structured lists (refusal reasons) for readability. Every sentence adds value, though it is more verbose than the simplest tools.

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 9 parameters, no annotations, and no output schema, the description fully covers the return contract (committed, ref, terms, basis, reason), the auth flow, and edge cases like quote-mismatch. It leaves no critical behavioral gap.

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?

Although schema coverage is 100%, the description adds crucial semantics: the mutual exclusivity and equality requirement between amount and items, the currency matching constraint, time slot validation against check_availability, and the non-parsing of the description field. These are not apparent from the schema alone.

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 a clear verb+resource: 'Place a binding order with a business'. It also distinguishes from all siblings by noting 'the only tool here that commits anyone to anything', making its unique role explicit.

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?

It explains when to use it (to commit), and how to choose between naming a figure or sending items from get_rate_card. It also gives exclusions: 'do not retry the same call' and suggests alternatives like contact_business or check_commitment for follow-up.

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.

TDQS

A4.6/5.0
Disambiguation4/5

Most tools have clearly distinct purposes, but ask_business and ask_business_freeform both serve the core function of asking a question about a listing, which could cause misselection. The detailed descriptions mitigate the overlap, but the similar intent remains a minor ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (ask_, check_, contact_, get_, search_, send_), with only ask_business_freeform adding a modifier that still fits the convention. Naming is predictable and readable.

Tool Count5/5

Nine tools is well-scoped for a knowledge base server, covering discovery (search, get), questioning (ask), asynchronous communication (contact, followup, replies, escalation), and verification. Each tool earns its place without unnecessary bloat.

Completeness5/5

The tool set provides full coverage of the domain: finding businesses, reading profiles, asking structured and freeform questions, escalating unresolved queries, opening and continuing conversations, and checking verification. Poll-based tools handle dead ends explicitly, so there are no obvious gaps.

Resources