Norm Booking

Book an appointment

book_appointment

Book a real appointment at Norm. This creates a genuine booking in the studio calendar and the client will be expected to show up — ALWAYS repeat the service, price, date, time, master and studio back to the client and get an explicit yes before calling this. Requires the client to be signed in to Norm. The booking is made for the signed-in phone number; there is no way to book on someone else's behalf. Before booking, if the service has add-ons, offer them once in one line (name, price, extra minutes); book them only if the client says yes. May include one optional follow-up slot (optionalNextStep); mention it once, accept 'no', never re-offer in this conversation. Never offer discounts or promotions.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "variantId": "<variantId>",
      "date": "<date>",
      "time": "<time>"
    },
    "name": "book_appointment"
  }
}

Input Schema

Name	Required	Description
`date`	Yes	Appointment date, YYYY-MM-DD (Warsaw time).
`time`	Yes	Start time, HH:MM (Warsaw time) — must be one returned by `find_slots`.
`studio`	No	Defaults to norm1.
`addonIds`	No	Optional add-on ids (`addons[].id` from `find_slots`) the client said yes to. Each adds its price and minutes to the visit; omit when the client wants none.
`stafferId`	No	Preferred master id. Omit to take whoever is free at that time.
`variantId`	Yes	Service variant id, from `find_services` or `find_slots`.
`clientNote`	No	Optional note for the master, in the client's own words. Before confirming, you may invite the client in ONE natural question to say in a few words what they would like done and what they currently have on (e.g. old gel/hybrid on the nails, their current hair colour). It is optional — never insist, never turn it into a checklist; omit it if they skip.
`customerName`	No	The client's first name. Required for first-time clients; ask if you do not have it.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 14, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations only declare it as a non-readonly, non-idempotent, non-destructive open-world write; the description adds the far more important real-world consequence (the client is booked and expected to show up), the authentication prerequisite, and the hard constraint that the booking is tied to the signed-in phone number with no booking on another's behalf. It does not say what happens when the slot is already taken or what a successful call returns, which matters given there is no output schema.

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 the core action in the first sentence, then layered guidance in descending priority. It is dense but nearly every clause is an actionable rule; the mention of `optionalNextStep`, which the model cannot pass under additionalProperties:false, is the one clause that does not earn its place.

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 high-consequence mutation with eight parameters and no output schema, the description covers authentication, consent confirmation, add-on upselling rules, and client-note etiquette, which is the bulk of what an agent needs. Remaining gaps are failure handling (slot already taken, insufficient permissions) and what the call returns on success.

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?

Schema coverage is 100% and the property descriptions are already rich (addonIds, clientNote, stafferId), so the schema carries the parameter burden and baseline 3 applies. The description adds only light cross-parameter meaning (add-ons are booked only on an explicit yes, name required for first-time clients), and it references an `optionalNextStep` field that does not exist in the schema — mild noise rather than added semantics.

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 ("Book a real appointment at Norm") and immediately scopes the effect: a genuine booking in the studio calendar. An agent can distinguish it from cancel_appointment, find_slots and my_appointments 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?

Gives explicit preconditions (client must be signed in, must repeat service/price/date/time/master/studio and get an explicit yes, time must come from find_slots) and explicit prohibitions (never re-offer the follow-up slot, never offer discounts or promotions). Add-on handling is spelled out as an offer-once rule, so when-to-use and when-not-to-use are both covered.

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

All Norm Booking 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?