Skip to main content
Glama
Sign In

eenable — a shop with no checkout

by me.eenable
OverviewDiscussionsAdmin

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

NameRequiredDescriptionDefault
nameYesBuyer's name, as it should appear on the invite
emailYesBuyer's email — receives the calendar invitation
topicNoWhat 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_idNoA slot_id exactly as returned by check_availability. Required for the four session types; omit entirely for products that are not appointments.
timezoneNoBuyer's IANA timezone
backgroundNoAnything the buyer wants the seller to read beforehand: context, links, what they have already tried. Shown in the calendar invitation.
session_typeYesWhich 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_tokenYesThe 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_outcomeNoWhat 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_sessionYesSet 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / email / pattern
      Previous value: -"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"New value: +"^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare the mutation/safety profile; the description adds the operational traits that matter: the slot is held for 30 minutes, a payment link is produced, the email drives both the calendar invitation and the receipt, and catalogue_token/buyer_confirmed_session are gated on a real buyer answer. It also explains why topic/desired_outcome exist (seller prep time the buyer paid for), which is beyond anything structured.

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-loaded with purpose and the 30-minute hold, then prerequisites. Some repetition of the 'ask the buyer, do not choose for them' rule, which is also stated in the session_type and buyer_confirmed_session schema descriptions, but the closing sentence justifies the fields rather than restating them.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter, non-idempotent creation tool with no output schema, the description covers prerequisites, side effects, and the key gating flag. It stops short of describing failure modes (expired hold, invalid token, duplicate order) which an agent would benefit from knowing before calling.

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 the baseline is 3, but the description adds real semantics: it reinforces that email must be the buyer's real address because the invite and receipt go there, and that topic/desired_outcome must be captured verbatim from the buyer rather than invented. It does not touch slot_id/timezone/background, leaving those entirely to 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?

States a specific verb and outcome: 'Reserve a slot and get a payment link,' and immediately differentiates itself from non-tool alternatives ('there is no checkout on the website'). An agent can tell this apart from cancel_order, get_order_details, or order_certificate without opening any schema.

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?

Explicit sequencing: call list_products first, present options to the buyer, wait for their answer, confirm time and price, then call this tool. It also names the disqualifying condition ('choosing a session on their behalf ... is not acceptable here'), which is exactly the when-not guidance an agent needs.

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 toolsInspect
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