Skip to main content
Glama

LayUp Sports Booking

create_alert

Set up an email alert for the user: LayUp watches for NEW matching slots (e.g. a cancellation freeing up a peak court) and emails them when one appears. Use when the user can't find a slot now and wants to be notified, or asks to 'monitor'/'watch'/'let me know when'. Requires their email. NARROW IT FIRST. An alert with no venues attached matches hundreds of slots, so the emails read as a dump rather than an alert: of 20 such alerts, 1 was ever confirmed and 8 died unconfirmed at the send cap. Call this without venue_names and the tool will NOT create an alert — it returns the venues LayUp covers in that area so you can ask the user which ones they want, and prompts for the days and times that suit them. Then call again with their answers. LayUp does the watching; the notification arrives by email, not in this chat.

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": {
      "email": "<email>"
    },
    "name": "create_alert"
  }
}

Input Schema

NameRequiredDescriptionDefault
areaNoWhere to watch, resolved geographically: a borough ('Hackney'), a neighbourhood ('Maida Vale'), a region ('North London'), or a postcode ('W9 2RF', 'SE1'). A postcode is the most precise option when the user gives one. NOT a venue name — to watch a specific venue use venue_names. Omit for all London.
emailYesThe user's REAL email address, as given by them (required — alerts are emailed here). Never invent, guess or substitute a placeholder like user@example.com; if you don't have it, ask the user first.
sportNoOne of Football, Tennis, Squash, Padel, Swimming. Omit for any.
time_toNoLatest London time-of-day, 'HH:MM'.
max_priceNoOnly alert on slots at or under this GBP price.
time_fromNoEarliest London time-of-day, 'HH:MM' (e.g. '18:00').
venue_namesNoPin the alert to specific venues BY NAME, exactly as shown in search results (e.g. ["Hay's Galleria", "Padel Box"]). Use this whenever the user names venues — the server resolves names to the right venue(s). Prefer this over venue_slugs.
venue_slugsNoPin the alert to specific venues by their exact venue_slug (only if you already have slug values from search_slots). For most cases use venue_names instead. Omit for any venue.
days_of_weekNoOnly alert on these days (e.g. ['Sat','Sun'] for weekends). The alert is standing — it keeps watching these days every week until the user unsubscribes. Omit for any day.
all_venues_in_areaNoSet true ONLY after the user has explicitly said they want every venue in the area rather than a chosen few. Without venue_names the tool refuses and hands you the venue list to offer them — area-wide alerts match hundreds of slots, are never confirmed and lapse unused.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / all_venues_in_area
      Added value: +{
      +  "description": "Set true ONLY after the user has explicitly said they want every venue in the area rather than a chosen few. Without venue_names the tool refuses and hands you the venue list to offer them — area-wide alerts match hundreds of slots, are never confirmed and lapse unused.",
      +  "type": "boolean"
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / area / description
      Previous value: -"London borough / area / neighbourhood to match (e.g. 'Hackney', 'Maida Vale'). NOT a venue name — to watch a specific venue use venue_names. Omit for all London."New value: +"Where to watch, resolved geographically: a borough ('Hackney'), a neighbourhood ('Maida Vale'), a region ('North London'), or a postcode ('W9 2RF', 'SE1'). A postcode is the most precise option when the user gives one. NOT a venue name — to watch a specific venue use venue_names. Omit for all London."
  3. Changed1 schema field changed
    • changedInput schema / properties / email / description
      Previous value: -"The user's email address (required — alerts are emailed here)."New value: +"The user's REAL email address, as given by them (required — alerts are emailed here). Never invent, guess or substitute a placeholder like user@example.com; if you don't have it, ask the user first."
  4. Changed3 schema fields changed
    • changedInput schema / properties / area / description
      Previous value: -"London borough / area / venue name to match. Omit for all London."New value: +"London borough / area / neighbourhood to match (e.g. 'Hackney', 'Maida Vale'). NOT a venue name — to watch a specific venue use venue_names. Omit for all London."
    • addedInput schema / properties / venue_names
      Added value: +{
      +  "description": "Pin the alert to specific venues BY NAME, exactly as shown in search results (e.g. [\"Hay's Galleria\", \"Padel Box\"]). Use this whenever the user names venues — the server resolves names to the right venue(s). Prefer this over venue_slugs.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • changedInput schema / properties / venue_slugs / description
      Previous value: -"Pin the alert to one OR MORE specific venues (venue_slug values from search results). Omit for any venue."New value: +"Pin the alert to specific venues by their exact venue_slug (only if you already have slug values from search_slots). For most cases use venue_names instead. Omit for any venue."
  5. Added

TDQS

A4.6/5.0
Behavior4/5

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

Goes well beyond the annotations by disclosing non-obvious behavior: the tool refuses to create an alert without venue_names and instead returns a venue catalog, alerts are delivered by email and not in chat, and the alert is standing until the user unsubscribes. It omits only secondary behavior such as frequency, unsubscribe mechanics, or per-user alert limits. No contradiction with readOnlyHint=false.

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?

Purpose and trigger come first, with the narrowing rule and the two-step flow after — good front-loading for a tool with a complicated interaction. It loses a point for repetition: the 'no venue_names means no alert' rule appears in the prose, again in the second half, and a third time in the all_venues_in_area schema description, and the 20-alert statistic is motivational rather than operational.

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?

Ten parameters with no output schema would normally leave gaps, but the description explicitly covers the non-obvious return path (a venue list plus a prompt for days/times when venue_names is missing) and the delivery channel. An agent has everything needed to run the interaction end to end.

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 already 100%, so baseline is 3; the description earns above that by explaining cross-parameter behavior the schema cannot: venueless creation is blocked, all_venues_in_area is only legitimate after explicit user consent, and area is geographic rather than a venue name. It doesn't add format hints for time_from/time_to or max_price beyond what the schema says.

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 ('Set up an email alert') and immediately defines the resource's semantics: LayUp watches for NEW matching slots and emails them. That clearly separates it from search_slots (a one-shot query) and refine_search, since the agent knows this creates a standing watcher rather than returning results.

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 trigger conditions ('when the user can't find a slot now and wants to be notified, or asks to monitor/watch/let me know when') plus the required prerequisite (their email). It also prescribes the exact two-step interaction sequence, so the agent knows not just when to call but what to do with the response.

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.

Resources