LayUp Sports Booking

Server Details

Search bookable London courts, pitches, lanes and pickup games across every major UK provider.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 99.8% over 43 days
Last Tested: 2026-09-29 00:22
Transport: Streamable HTTP · MCP 2025-06-18
URL

TDQS

A4.4/5.0

Scored 2026-09-27 16:50 across 5 tools

Disambiguation4/5

Most tools have clearly distinct roles, and refine_search explicitly clarifies that it returns counts rather than slots (vs search_slots) and get_venue is scoped to a single venue. There is mild conceptual overlap among the three discovery tools, but the descriptions ground each one in a distinct use case.

Naming Consistency5/5

All names follow a clean snake_case verb_noun pattern (create_alert, get_venue, list_sports, refine_search, search_slots). The convention is predictable and consistent throughout.

Tool Count5/5

Five tools is well-scoped for a slot-discovery service, with each tool earning its place (overview, broad search, refinement, venue drill-down, alerts). Nothing feels padded or redundant.

Completeness4/5

Discovery is well covered: overview, broad search, region/count aggregation, venue drill-down, and new-slot alerts. The main gap is alert lifecycle management (no list/update/delete alerts) and no per-slot detail tool, though booking itself is handled via external links.

Available Tools

5 tools

create_alertAInspect

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. A confirmation email is sent first — the user must click confirm before any alerts fire (so always tell them to check their inbox). LayUp does the watching; the notification arrives by email, not in this chat.

ParametersJSON Schema

Name	Required	Description
`area`	No	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.
`email`	Yes	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.
`sport`	No	One of Football, Tennis, Squash, Padel, Swimming. Omit for any.
`time_to`	No	Latest London time-of-day, 'HH:MM'.
`max_price`	No	Only alert on slots at or under this GBP price.
`time_from`	No	Earliest London time-of-day, 'HH:MM' (e.g. '18:00').
`venue_names`	No	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.
`venue_slugs`	No	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.
`days_of_week`	No	Only 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.

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations, the description discloses important behaviors: a confirmation email is sent first and alerts only fire after the user clicks confirm, LayUp does the watching asynchronously, and the notification arrives by email rather than in the chat. This gives the agent accurate expectations for a non-read-only, external-effect tool.

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?

Every sentence earns its place: core behavior, when to use, prerequisite, confirmation caveat, and delivery channel. The most important decision-relevant information is front-loaded, and there is no filler or redundant restating of the tool name.

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?

For a 9-parameter tool with no output schema, the description supplies the essential operational context: asynchronous monitoring, email delivery, confirmation requirement, and the distinction from chat-based responses. Combined with the fully detailed schema, an agent has everything needed to invoke this tool correctly.

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?

The input schema already provides full 100% coverage of all 9 parameters with detailed descriptions, so the description does not need to repeat parameter details. It adds only the key requirement that the email must come from the user, but the schema already covers that with strong guidance against inventing placeholders. Baseline 3 is appropriate.

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 and resource: 'Set up an email alert'. It then explains the tool's unique behavior — LayUp watches for NEW matching slots and emails the user — which clearly separates it from search_slots, a sibling that finds available slots now rather than monitoring for future ones.

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 explicitly says when to use the tool: when the user can't find a slot now and wants to be notified, or asks to 'monitor'/'watch'/'let me know when'. It also gives required preconditions (user's email) and a critical follow-up instruction (tell them to check their inbox for the confirmation email).

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

get_venueA

Read-only

Inspect

List upcoming bookable slots at a single venue, identified by its venue_slug (as returned by search_slots). Use to drill into one venue after a search.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Max slots to return (1-30, default 15).
`venue_slug`	Yes	The venue_slug from a search_slots result.

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds the scope of 'upcoming bookable slots' but doesn't disclose additional behavioral details like pagination or return format. This is adequate but not extensive.

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?

Two concise sentences: the first states the action and resource, the second provides usage context. No redundant or filler 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?

For a simple read-only tool with full schema coverage and no output schema, the description sufficiently explains what it does and when to use it. Sibling tools are already differentiated.

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%, so both parameters are fully documented. The description mentions venue_slug comes from search_slots, but the schema already states that, so the description adds no extra semantic value.

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 clearly states the tool lists upcoming bookable slots at a single venue, identified by venue_slug. It explicitly references search_slots for the slug, distinguishing it from the sibling search_slots tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description says 'Use to drill into one venue after a search,' which gives clear context for when to use it. It doesn't explicitly mention when not to use it or alternative tools, but the guidance is unambiguous.

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

list_sportsA

Read-only

Inspect

List the sports LayUp covers with a count of slots available in the next 7 days. Useful as a quick overview before a more specific search.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds useful behavior beyond annotations: it returns a count of slots for the next 7 days and lists all sports covered. This context is not redundant with the annotations.

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?

The description is two sentences, front-loaded with the action and resource. Every word earns its place, with no filler or repetition of the tool name.

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?

Given the tool has no parameters and no output schema, the description covers the essential information: what it lists, the count, and the 7-day window. It could mention the return format more explicitly, but is sufficient for a simple overview tool.

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?

The tool has zero parameters, and the schema is empty, so there are no parameter semantics to clarify. The baseline for zero parameters is 4, and the description adds no unnecessary parameter information.

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 clearly states the tool lists sports covered by LayUp with a count of slots in the next 7 days. It uses a specific verb (List), identifies the resource (sports), and includes a time-bound scope, distinguishing it from siblings like search_slots and get_venue.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly positions it as a quick overview before a more specific search, giving contextual guidance on when to use it. It doesn't name the alternative tool explicitly, but the reference to 'more specific search' clearly points to siblings like search_slots.

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

refine_searchA

Read-only

Inspect

Find out WHERE and WHEN there is availability, before asking the user a clarifying question. Takes the same filters as search_slots and returns counts by area, day, time band and price — not slots. Use it when the request is under-specified ('find me a tennis court', 'somewhere for a group') so the question you ask back is grounded in real supply: ask 'Wandsworth (8 venues) or Richmond (7)?' rather than an open 'which area?'. Also use it when a search returned nothing, to say which nearby area or time DOES have slots instead of reporting a dead end.

ParametersJSON Schema

Name	Required	Description
`area`	No	Optional. Same geographic resolution as search_slots — borough, neighbourhood, region, postcode or venue name. Omit to see every area.
`sport`	No	One of Football, Tennis, Squash, Padel, Swimming.
`date_to`	No	ISO date or datetime — latest start. Defaults to 7 days out.
`time_to`	No	London-local latest start time of day, 'HH:MM'.
`date_from`	No	ISO date or datetime — earliest start. Defaults to now.
`max_price`	No	Maximum price in GBP.
`time_from`	No	London-local earliest start time of day, 'HH:MM'.
`min_courts`	No	Only count venue-hours with at least this many free at the same time. Same meaning as in search_slots.
`booking_type`	No	'spot', 'court' or 'pitch'.

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds the key behavioral fact that the output is aggregated counts rather than bookable slots, plus the operational note that it shares filters with search_slots. It does not mention result limits, cardinality of areas returned, or latency, so it is strong but not exhaustive.

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 purpose before any usage detail, and each sentence carries distinct information (function, contrast with sibling, two use cases, example phrasing). It runs long with multiple illustrative quotations, which adds warmth but also redundancy.

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?

With no output schema, the description carries the burden of describing returns and does so precisely — counts broken out by area, day, time band and price, explicitly not slots. Combined with the usage triggers and shared-filter note, an agent has everything needed to call and interpret it.

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 description coverage is 100%, with defaults, formats and enum values all documented on the parameters themselves. The description only adds that the filters mirror search_slots, which is useful context but not parameter-level meaning beyond the schema. Baseline 3 applies.

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 states a concrete function — returning availability COUNT aggregations by area, day, time band and price — and explicitly contrasts that with search_slots, which returns actual slots. An agent can distinguish it from its sibling without opening either 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?

Two explicit trigger conditions are given (under-specified requests and zero-result searches), plus a reference alternative in search_slots for the case where actual availability is wanted. The concrete example of the clarifying question it enables makes the when/when-not boundary unambiguous.

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

search_slotsA

Read-only

Inspect

Search bookable sports slots in London across every provider LayUp aggregates. Use when a user wants to find a court, pitch, lane, class or pickup game for football, tennis, squash, padel or swimming. Filter by sport, area/borough, date range, time of day and max price. Returns upcoming slots with venue, London-local time, price, provider and a booking link. Times default to the next 7 days.

ParametersJSON Schema

Name	Required	Description
`area`	No	Where to look. Resolved geographically, so any of these work: a borough ('Hackney'), a neighbourhood ('Shoreditch', 'Maida Vale'), a region ('North London', 'Central London'), a postcode or outward code ('W9 2RF', 'SE1'), or a venue name ('Clissold'). Returns venues near the resolved point, not just ones with the word in their name.
`limit`	No	Max results to return (1-30, default 15).
`sport`	No	One of Football, Tennis, Squash, Padel, Swimming.
`date_to`	No	ISO date or datetime — latest start. Defaults to 7 days out.
`time_to`	No	London-local latest start time of day, 'HH:MM'.
`date_from`	No	ISO date or datetime — earliest start. Defaults to now.
`max_price`	No	Maximum price in GBP. Published prices above this are removed; unpublished-price slots ('Check App', common for padel/tennis) are kept and flagged.
`time_from`	No	London-local earliest start time of day, 'HH:MM' (e.g. '18:00'). Samples the soonest upcoming slots; combine with date_from to target a specific day.
`min_courts`	No	Only return venues with at least this many courts/pitches free AT THE SAME TIME. Use for groups: padel and tennis are 4 per court, so 16 people need 4. Nobody else can answer this — venues cannot see each other and the booking platforms only see their own sites. Results are one slot per venue; that venue had at least this many free at that hour.
`booking_type`	No	'spot' = book one place (pickup game / swim seat), 'court' = whole court, 'pitch' = whole pitch.

TDQS

A4.2/5.0

Behavior4/5

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

Annotations only supply readOnlyHint and openWorldHint, so the description usefully adds return-shape context (venue, London-local time, price, provider, booking link) and a default window ('next 7 days'). It omits pagination/result-ceiling behavior beyond the limit param, but the added operational context goes beyond the annotations.

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 usage, then filters, then return format and default window; each sentence carries information. Dense but well-organized, with only minor overlap between the filter list and the schema.

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?

With no output schema, the description steps in to describe what is returned (venue, local time, price, provider, booking link) and the default time window. Combined with the rich schema, an agent has everything needed to call it correctly.

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 each parameter already carries a rich description (min_courts, max_price unpublished-price handling, area geographic resolution). The description only summarizes filters (sport, area/borough, date range, time of day, max price) that are already fully documented in the schema, adding little beyond it.

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+resource ('Search bookable sports slots in London') and scopes it ('across every provider LayUp aggregates'). Distinctly differentiates from siblings like get_venue and list_sports by describing multi-provider slot search rather than a single venue or sport list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Use when a user wants to find a court, pitch, lane, class or pickup game...' gives a clear triggering context. However, it never mentions the sibling refine_search or create_alert as the alternative path for follow-up refinement or alerts, so the routing guidance is incomplete.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

2 tool updatesSep 27, 2026

Addedrefine_search

Changedsearch_slots1 field changed

addedInput schema / properties / min_courts

Added value: +{
+  "description": "Only return venues with at least this many courts/pitches free AT THE SAME TIME. Use for groups: padel and tennis are 4 per court, so 16 people need 4. Nobody else can answer this — venues cannot see each other and the booking platforms only see their own sites. Results are one slot per venue; that venue had at least this many free at that hour.",
+  "type": "integer"
+}

2 tool updatesSep 26, 2026

Changedcreate_alert1 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."

Changedsearch_slots1 field changed

changedInput schema / properties / area / description

Previous value: -"London borough, area or venue name to match (e.g. 'Hackney', 'Southwark', 'Clissold')."New value: +"Where to look. Resolved geographically, so any of these work: a borough ('Hackney'), a neighbourhood ('Shoreditch', 'Maida Vale'), a region ('North London', 'Central London'), a postcode or outward code ('W9 2RF', 'SE1'), or a venue name ('Clissold'). Returns venues near the resolved point, not just ones with the word in their name."

1 tool updateJul 30, 2026

Changedcreate_alert1 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."

1 tool updateJun 20, 2026

Changedcreate_alert3 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."

1 tool updateJun 19, 2026
- Addedcreate_alert
3 tool updatesJun 12, 2026
- First observedget_venue
- First observedlist_sports
- First observedsearch_slots

Related MCP Connectors

GetCourt A
io.github.denis1011101
Find upcoming tennis, padel and squash games with free spots, by city, sport, level and date.
Sports Search
21
mcp A
team.jogo
Find pickup soccer or drop-in football games via your AI. 70+ cities, one-click RSVP.
Sports Location Services Calendar Management
52
Aurinia — book across venues via your AI assistant A
online.aurinia
Find availability and book across a network of independent venues via your AI assistant.
Health & Wellness Travel & Transportation
82
Awning A
help.awning
Find and book local services, classes and rentals; businesses set up and manage their pages.
E-commerce & Retail Search Location Services
341

Related MCP Servers

sportlink-mcp
Sports Search
AlanGr12
F
license
A
quality
C
maintenance
Enables AI agents and LLMs to query SportLink data through natural language, including searching for events, trainings, jobs, clubs, and coaches, as well as viewing profiles and calculating matches.
Updated 24 days ago (2026-09-04 13:30 UTC)
7
-
AltSportsLeagues MCP Server
Sports Research & Data
asd-git-master
A
license
A
quality
D
maintenance
Enables AI agents and sportsbooks to discover, evaluate, and monitor alternative sports leagues with tools for discovery, valuation, fingerprinting, and market data.
Updated 7 months ago (2026-03-09 18:29 UTC)
35
MIT
football-docs
Sports Documentation Access
withqwerty
A
license
A
quality
B
maintenance
Searchable football data provider documentation for AI coding agents. Enables agents to look up verified docs on event types, qualifier IDs, coordinate systems, and more across 15 providers.
Updated 18 days ago (2026-09-10 23:43 UTC)
7
163 npm
66
MIT
sports-mcp-server
Sports Search
YJSummers
F
license
Not graded
quality
C
maintenance
Provides comprehensive sports intelligence including live scores, standings, schedules, betting odds, news, highlights, and more via SSE transport.
Updated 2 months ago (2026-07-21 03:59 UTC)
-

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?