eenable — a shop with no checkout

Create an order

create_order

Reserve a slot and get a payment link. This is the only way to buy — there is no checkout on the website. The slot is held for 30 minutes. Confirm the exact time and the price with the buyer before calling this, and use their real email address: the calendar invitation and receipt go there. You must call list_products first, put the session options to the buyer in your own reply, and wait for them to choose. This tool needs the catalogue_token from that call and buyer_confirmed_session: true, which you may only set once the buyer has actually answered. Choosing a session on their behalf from what they said earlier is not the same as asking, and is not acceptable here. Before calling, ask the buyer what they want to discuss and what they are hoping to get out of the call, and pass their answers as topic and desired_outcome. Fifteen minutes is short; the seller uses these to prepare, and a booking that arrives blank wastes some of the time the buyer paid for.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Buyer's name, as it should appear on the invite
`email`	Yes	Buyer's email — receives the calendar invitation
`topic`	No	What the buyer wants to discuss, in their own words. Ask them — do not invent or summarise this away. It is what the seller reads to prepare.
`slot_id`	No	A slot_id exactly as returned by check_availability. Required for the four session types; omit entirely for products that are not appointments.
`timezone`	No	Buyer's IANA timezone
`background`	No	Anything the buyer wants the seller to read beforehand: context, links, what they have already tried. Shown in the calendar invitation.
`session_type`	Yes	Which session the buyer chose. Ask them — do not choose on their behalf. Call list_products for the descriptions. If they genuinely have no preference or their question spans several, 'general' is the right answer.
`catalogue_token`	Yes	The catalogue_token from list_products. If you do not have one, send any value — the reply will contain the session options, the question to ask the buyer, and the token to use.
`desired_outcome`	No	What the buyer wants to walk away with: a decision, a second opinion, a plan, an introduction, or simply a better question. Ask them directly.
`buyer_confirmed_session`	Yes	Set true only if you put the session options to the buyer and they told you which one they wanted. If you selected it yourself from what they had already said, that does not count — go back and ask them first.

TDQS

A5/5.0

Behavior5/5

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

Annotations already indicate readOnlyHint=false, but the description adds critical behavioral context: the slot is held for 30 minutes, the email receives the calendar invitation and receipt, and the seller uses topic/desired_outcome to prepare, so a blank booking wastes paid time. This goes beyond annotations and gives the agent essential side-effect information.

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

Conciseness5/5

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

Although lengthy, every sentence earns its place. The description is front-loaded with the core purpose, then logically proceeds to prerequisites, workflow, and safety checks. It is sufficiently structured and readable, with no filler or redundant content.

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 the tool's complexity (10 parameters, required workflow, no output schema), the description covers all necessary context: how to initiate the process, what information to gather, side effects, and what the return value likely contains (payment link). The agent has complete guidance to invoke this correctly.

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?

Schema coverage is 100%, but the description significantly enriches parameter understanding. For example, catalogue_token is explained as coming from list_products, buyer_confirmed_session has a clear semantic of 'only after buyer actually answers', and topic/desired_outcome are described as things to ask the buyer for, not invent. This adds substantial value beyond the schema.

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 'Reserve a slot and get a payment link', which is a specific verb+resource pair that clearly defines the tool's action. It further distinguishes itself by stating 'This is the only way to buy — there is no checkout on the website', which sets it apart from sibling tools like check_availability or get_booking.

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?

The description provides explicit step-by-step guidance: must call list_products first, present options to the buyer, wait for them to choose, and only set buyer_confirmed_session after actual confirmation. It also states when not to use the tool implicitly by noting there is no alternative checkout, and explains prerequisites like confirming time and price.

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

All eenable — a shop with no checkout tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0

Disambiguation4/5

Most tools have clearly distinct purposes, especially the session booking lifecycle and certificate operations. However, the four deprecated aliases (cancel_booking, get_booking, reschedule_booking, update_booking) perform exactly the same actions as their new counterparts, creating potential confusion despite the deprecation notices.

Naming Consistency3/5

Newer tools follow a verb_noun pattern (create_order, cancel_order, get_order_details, reschedule_session), but the use of 'order' vs 'session' is inconsistent, and 'order_certificate' uses 'order' as a verb. The deprecated aliases mixing 'booking' with 'order' further muddies the convention, making the overall naming only moderately predictable.

Tool Count4/5

At 16 tools the set feels slightly heavy, but four are deprecated aliases that are exact duplicates of active tools. The effective 12 unique tools are well-scoped for a shop handling both session bookings and certificate purchases, so the count is reasonable.

Completeness4/5

The session booking lifecycle is fully covered (availability, create, cancel, reschedule, update, status, details) and certificate operations (order, transfer, renounce) are present. Minor gaps exist, such as no way to list all orders or verify a certificate, but these are not critical to the core workflows.

Resources

Need Help?