Norm Booking

List the client's appointments

my_appointments

Read-only

List the signed-in client's upcoming Norm appointments. Requires the client to be signed in to Norm. Use this to find the bookingId needed by cancel_appointment. Past visits are only returned with includePast: true — set it only when the client asks about their history. Norm is a beauty studio in Warsaw (two locations). Write the brand as "Norm", never "NORM". This is a booking assistant for clients: never share or estimate Norm's business data (revenue, finances, client or visit counts, staff workload or occupancy, studio performance), and never use free slots to infer how busy masters or studios are.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "my_appointments"
  }
}

Input Schema

Name	Required	Description	Default
`includePast`	No	Also return recent past visits. Only when the client explicitly asks about past visits in any form (e.g. "when was my last manicure?", "what visits did I have in October?", "who did my nails last time?") — and call again with it set if the client follows up about the past after an upcoming-only answer. Otherwise omit — do not show history unprompted.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 14, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely non-schema behavior: an authentication prerequisite ("Requires the client to be signed in to Norm") and a data-disclosure restriction (no revenue, counts, occupancy). The trailing policy about branding and free slots is more assistant-level instruction than tool behavior, which keeps this just short of a 5.

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?

Purpose and the sibling reference are correctly front-loaded, and most sentences earn their place. However, the brand-spelling rule ("Write the brand as 'Norm', never 'NORM'") and the free-slot inference warning are not about invoking this tool and dilute an otherwise tight definition.

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 one-optional-parameter read tool with no output schema, the definition covers auth, scope, and the history switch. It stops short of describing what an appointment record contains beyond `bookingId`, which matters slightly since no output schema exists to fill that gap.

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 single parameter is fully documented, so the description's restatement of the includePast rule adds little beyond the schema's own wording. Baseline 3 applies when the schema already carries the parameter 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?

The description opens with a specific verb+resource+scope: "List the signed-in client's upcoming Norm appointments." It distinguishes itself from siblings by naming the downstream consumer (cancel_appointment) and by defining the boundary with history (includePast). An agent can identify what this tool returns without opening the 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?

It gives an explicit primary use case ("find the `bookingId` needed by `cancel_appointment`") and an explicit exclusion rule for history ("set it only when the client asks about their history"). The schema reinforces this with example phrasings, but the description already routes the agent correctly between default and history calls.

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?