A
licenseA
qualityD
maintenanceEnables AI agents and sportsbooks to discover, evaluate, and monitor alternative sports leagues with tools for discovery, valuation, fingerprinting, and market data.
35
MIT
LayUp Sports Booking
Server Details
Search bookable London courts, pitches, lanes and pickup games across every major UK provider.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
100% free. Your data is private.
Tool Definition Quality
A4.4/5.0
Tool DescriptionsA
Average 4.4/5 across 4 of 4 tools scored.
Server CoherenceA
Disambiguation5/5
Each tool has a clearly distinct purpose: search_slots for finding slots, get_venue for drilling into a specific venue, list_sports for an overview, and create_alert for notifications. There is no overlap or ambiguity among them.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern: create_alert, get_venue, list_sports, search_slots. The naming is uniform, predictable, and easy to navigate.
Tool Count5/5
With 4 tools, the set is well-scoped for a sports booking aggregator. Each tool covers a distinct core function (search, venue details, sport overview, alerts) without unnecessary bloat or missing essentials.
Completeness4/5
The core workflow of searching slots, viewing venue details, and setting alerts is covered. Minor gaps exist, such as no built-in booking (relying on external links) and no way to manage or cancel alerts, but these are acceptable given the design.
Available Tools
4 toolscreate_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 | Default |
|---|---|---|---|
| area | No | 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. | |
| 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. |
Tool Definition Quality
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the critical async confirmation step: 'A confirmation email is sent first — the user must click confirm before any alerts fire (so always tell them to check their inbox).' It also notes notifications arrive by email, not chat. This goes well beyond the basic readOnlyHint=false annotation and is essential for correct invocation.
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?
Three sentences that each earn their place: what it does, when to use, and the must-know confirmation caveat. It is front-loaded, free of fluff, and logically structured.
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?
With 9 parameters (1 required) and no output schema, the description covers the critical non-obvious behaviors: confirmation email, email channel, and standing watch. It does not explain return values, but none are expected. Slightly lacking is explicit mention of how to cancel a standing alert, but the schema's days_of_week description hints at 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?
The input schema descriptions cover 100% of parameters and include rich details (e.g., area vs venue_names, email validity). The tool description adds little param-specific meaning, only reinforcing 'Requires their email'. Baseline 3 is appropriate when schema carries the load.
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 for the user', and clearly distinguishes this from sibling search tools by explaining the async watch behavior ('watches for NEW matching slots... and emails them when one appears'). This makes its purpose unmistakable and distinct.
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?
It gives explicit when-to-use criteria: 'Use when the user can't find a slot now and wants to be notified, or asks to monitor/watch/let me know when.' This strongly implies the contrast with immediate search tools. It does not name alternatives explicitly, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_venueARead-onlyInspect
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. |
Tool Definition Quality
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_sportsARead-onlyInspect
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 | |||
Tool Definition Quality
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.
search_slotsARead-onlyInspect
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 | Default |
|---|---|---|---|
| area | No | London borough, area or venue name to match (e.g. 'Hackney', 'Southwark', 'Clissold'). | |
| 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. | |
| booking_type | No | 'spot' = book one place (pickup game / swim seat), 'court' = whole court, 'pitch' = whole pitch. |
Tool Definition Quality
A4.6/5.0
Behavior5/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 meaningful behavioral context beyond those: it states that results include venue, London-local time, price, provider, and booking link, explains the default time window (next 7 days), and discloses max_price filtering behavior (removes published above, keeps unpublished flagged slots). This fully informs the agent of what to expect.
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 concise, well-structured, and front-loads the core purpose. It first states what the tool does, then when to use it, then what filters and return values are provided. Every sentence earns its place with no fluff or repetition of schema field details.
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 output schema, the description compensates by explicitly describing the return contents and default behaviors. It covers the main filters and clarifies the London-local timezone aspect. It does not explicitly address edge cases like zero results or pagination, but mentions the limit parameter default, making it sufficiently complete for a search tool.
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 100% coverage of all 9 parameters with detailed descriptions, so the baseline is 3. The tool description mentions filters generically ('Filter by sport, area/borough, date range, time of day and max price') but adds no new parameter-specific semantics beyond what the schema offers. It does not contradict 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?
The description clearly states 'Search bookable sports slots in London across every provider LayUp aggregates' with specific verbs and resources. It distinguishes itself from sibling tools (create_alert, get_venue, list_sports) by focusing on searching across providers, and enumerates supported sports and result contents.
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 includes an explicit 'Use when a user wants to find a court, pitch, lane, class or pickup game...' which directly tells the agent when to invoke this tool. It also lists filter criteria and result details, providing clear usage context without needing to reference alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Servers
- AlicenseAqualityAmaintenanceSearchable 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.734645MIT
- Flicense-qualityCmaintenanceProvides comprehensive sports intelligence including live scores, standings, schedules, betting odds, news, highlights, and more via SSE transport.
- AlicenseAqualityDmaintenanceGives your MCP host (Claude Desktop, Cursor, Continue, Zed) access to live scores, match details, standings, top scorers, knockout brackets and player stats across football, basketball, cricket and tennis. Backed by the free public SportScore API — no key, no signup, CORS-open.8819MIT