Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Padel Finder MCP Server Find available padel courts near London for this weekend"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP (Model Context Protocol) server for finding available padel courts via Playtomic API. Now supports both Goose MCP-UI and ChatGPT Apps with real Playtomic API integration.
find_nearby_courts - Find padel venues near a location
check_availability - Check available time slots at a venue
find_available_games - Find the nearest available game
compare_prices - Compare prices across venues
get_venue_details - Get detailed venue information
search_by_duration - Find slots with specific duration (60/90/120 min)
get_weekly_availability - View availability across multiple days
find_cheapest_time - Find cheapest available slots
get_peak_hours - Analyze busy/quiet times at venues
save_favorite_venue - Save a venue to favorites
remove_favorite_venue - Remove from favorites
list_favorite_venues - List all favorites
quick_book_check - Check availability at all favorites
set_availability_alert - Set up alerts for preferred slots
list_availability_alerts - List all active alerts
cancel_availability_alert - Cancel an alert
Related MCP server: Fotocasa1 MCP Server
npm install
npm run buildCreate a .env file based on .env.example:
# Playtomic API Configuration
PLAYTOMIC_CLIENT_ID=your_client_id_here
PLAYTOMIC_CLIENT_SECRET=your_client_secret_here
PLAYTOMIC_API_BASE=https://api.playtomic.io/v1
PLAYTOMIC_RATE_LIMIT_PER_MIN=1
PLAYTOMIC_SPORT_ID=1
# Geocoding Configuration
GEOCODING_PROVIDER=nominatim
GEOCODING_API_KEY=
# Server Configuration
NODE_ENV=development
PORT=3000Contact Playtomic support to request API credentials
Review the Playtomic External API v1.5 Documentation
Set PLAYTOMIC_CLIENT_ID and PLAYTOMIC_CLIENT_SECRET in your .env file
npm start:stdionpm startnpm run devAdd to your MCP client configuration:
{
"mcpServers": {
"padel-finder": {
"command": "node",
"args": ["path/to/padel-finder/dist/index.js"]
}
}
}The server automatically detects ChatGPT clients and returns widgets in text/html+skybridge format. No special configuration needed.
Playtomic API: Real authentication, venue search, and availability checking
Geocoding: Nominatim OSM integration with 7-day caching
Rate Limiting: Smart queuing system respecting 1 req/min limit
Caching: Optimized TTLs (5min availability, 24h venues, 7d geocoding)
Preact Widgets: Lightweight React alternative (3KB vs 44KB)
Widget Bundler: Server-side rendering to HTML
Core Widgets: SlotCards, SearchForm, WeeklyCalendar, PriceComparison
UI Adapter: Automatic client detection (Goose vs ChatGPT)
Backward Compatible: Existing Goose MCP-UI still works
Display Modes: Inline, fullscreen, picture-in-picture support
Dual Format Support: Returns text/html for Goose, text/html+skybridge for ChatGPT
Auto-Detection: Detects client from User-Agent headers
Zero Breaking Changes: Existing integrations continue to work
Create widget component in src/widgets/YourWidget/index.tsx:
import { h } from 'preact';
import type { YourWidgetProps } from '../common/types.js';
export function YourWidgetWidget(props: YourWidgetProps) {
return <div>Your widget content</div>;
}Register in src/widget-renderer/bundler.ts:
case 'YourWidget':
const { YourWidgetWidget } = await import('../widgets/YourWidget/index.js');
WidgetComponent = YourWidgetWidget;
break;Use in tools via UI adapter:
const uiAdapter = getUIAdapter();
const widget = await uiAdapter.createYourWidgetUI(data);Authentication: Bearer token with auto-refresh
Rate Limiting: 1 request per minute (queued automatically)
Batching: Fetches up to 25 hours per request
Error Handling: Graceful fallback to cached data
Provider: Nominatim OSM (free, no API key required)
Caching: 7-day cache for addresses and reverse geocoding
Fallback: Hardcoded coordinates for popular UK cities
API Response: < 500ms p95 (with caching)
Cache Hit Rate: > 80% after warmup
Widget Bundle: < 200KB per widget
Widget Render: < 100ms initial load
Set environment variables in Render dashboard
Deploy using npm start (HTTP/SSE server)
Health check: GET /health
npm run dev # HTTP/SSE with hot reload
npm start:stdio # stdio transport for MCP clientsAPI Integration:
# Test venue search
curl -X POST http://localhost:3000/messages -d '{"method":"tools/call","params":{"name":"find_available_games","arguments":{"location":"London","date":"2025-01-29"}}}'Widget Rendering: Check that widgets render correctly in ChatGPT Apps
Backward Compatibility: Verify Goose clients still receive HTML format
401 Unauthorized: Check PLAYTOMIC_CLIENT_ID and PLAYTOMIC_CLIENT_SECRET
429 Rate Limit: Normal - requests are automatically queued
Timeout: Check network connectivity, API may be slow
No results: Try more specific address or use coordinates
Rate limit: Nominatim allows 1 req/sec - caching helps
Not rendering: Check browser console for errors
ChatGPT API not available: Widgets fall back to static HTML
MIT
Start booking process for a padel court slot with interactive checkout wizard. Opens a multi-step checkout flow.
| Name | Required | Description | Default |
|---|---|---|---|
| price | Yes | Price of the booking | |
| currency | No | Currency code | EUR |
| venue_id | Yes | The venue ID | |
| court_name | No | Name of the court | |
| start_time | Yes | Start time in ISO 8601 format (e.g., "2026-01-31T19:00:00Z") | |
| venue_name | Yes | Name of the venue | |
| duration_minutes | Yes | Duration of the booking in minutes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions a multi-step checkout flow implying interactivity, but it doesn't disclose side effects (e.g., holds a slot), whether it's idempotent, or what happens on subsequent steps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear sentences with no waste, but the second sentence ('Opens a multi-step checkout flow') largely restates the first. Could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and no output schema or annotations, the description is incomplete. It does not explain return values, what happens after checkout starts, or how the agent should proceed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it starts a booking process and opens a checkout wizard, but it's vague about what exactly the tool accomplishes (e.g., does it create a reservation?). It doesn't clearly distinguish from sibling tools like quick_book_check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as quick_book_check or check_availability. No prerequisites or context for invocation are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel an existing availability alert.
| Name | Required | Description | Default |
|---|---|---|---|
| alert_id | Yes | The alert ID to cancel |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states 'cancel' with no details on side effects, idempotency, or permissions required. Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, clear sentence with no redundant words. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple cancellation with one parameter, but lacks context on error handling, idempotency, or what happens if alert doesn't exist. Could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter alert_id is fully described in schema (100% coverage). Description adds no extra meaning, meeting baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states action (cancel) and resource (existing availability alert), making tool purpose immediately clear. Differentiates from siblings like set_availability_alert and list_availability_alerts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites (e.g., alert must exist), and no conditions for success or failure.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check available padel court time slots at a specific venue. Returns slots with weather info, booking links, and calendar links.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Date to check availability (YYYY-MM-DD format) | |
| end_time | No | Optional end time filter (HH:mm format, e.g., "18:00") | |
| venue_id | Yes | The venue ID (obtained from find_nearby_courts) | |
| start_time | No | Optional start time filter (HH:mm format, e.g., "09:00") | |
| venue_name | No | Optional venue name for display purposes | |
| include_weather | No | Include weather information for each slot (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, description carries full burden. It discloses returns include weather info, booking links, calendar links, but lacks details on data freshness, rate limits, or any side effects. Behavior is adequately described for a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with purpose, no wasted words. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains return values. Parameter detail is in schema. Could mention that venue_id comes from find_nearby_courts (schema does, but description could for completeness). Overall adequate for a simple tool with many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so descriptions are already in schema. The tool description adds no additional parameter semantics beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action 'check available padel court time slots' with specific resource and venue scope. Distinguishes from siblings like find_nearby_courts (find venues) and book_court (book slots).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the tool name and description, but no explicit guidance on when to use this tool vs alternatives like get_weekly_availability or find_available_games. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare padel court prices across multiple venues. Shows cheapest options first.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Date to compare prices (YYYY-MM-DD format) | |
| location | Yes | Your location (address, city name, or coordinates) | |
| time_end | No | End of time range (HH:mm format) | |
| time_start | No | Start of time range (HH:mm format) | |
| max_distance_km | No | Maximum search distance (default: 10km) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description mentions sorting behavior but lacks details on what is compared (e.g., availability, court types) and other behavioral traits like data sources or limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey primary action and ordering, but slightly more structure (e.g., listing output format) could improve scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no description of return values; for a 5-parameter comparison tool, agents need to know what results look like and any constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions; description adds no extra semantics beyond what schema provides, meeting baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compares padel court prices across venues and orders results by cheapest first, distinguishing it from siblings like check_availability or find_cheapest_time.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use versus alternatives like get_venue_details or find_cheapest_time; usage is implied but not contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the nearest available padel games based on your location and preferred time. Returns slots with weather info, booking links, and calendar links.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Date to find games (YYYY-MM-DD format) | |
| location | Yes | Your location (address, city name, or coordinates like "51.5074,-0.1278") | |
| max_results | No | Maximum number of results (default: 20) | |
| include_weather | No | Include weather information for each slot (default: true) | |
| max_distance_km | No | Maximum distance to search (1-50km, default: 10) | |
| preferred_time_end | No | Preferred latest start time (HH:mm format, e.g., "21:00") | |
| preferred_time_start | No | Preferred earliest start time (HH:mm format, e.g., "18:00") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions return data (weather, booking links, calendar links) but does not discuss aspects like side effects, authentication, rate limits, or result ordering. This is minimal for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences that front-load the action and then describe the return values. There is no extraneous information, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description provides adequate context about return values (weather, links). However, it lacks details on result sorting or how the nearest games are determined, which could be useful for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with all parameters documented individually. The description aligns with the required location and date parameters but adds no new semantic meaning beyond what the schema provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Find'), resource ('available padel games'), and context ('location and preferred time'). It effectively distinguishes from sibling tools like find_nearby_courts and check_availability by focusing on game availability with weather and links.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding games by location and time but does not provide explicit guidance on when to use this tool versus alternatives like check_availability or find_cheapest_time. No exclusions or when-not-to-use are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the cheapest available padel court slots in your area. Results are sorted by price (lowest first).
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Date to search (YYYY-MM-DD format) | |
| location | Yes | Your location (address, city name, or coordinates) | |
| time_end | No | End of time range (HH:mm format) | |
| time_start | No | Start of time range (HH:mm format) | |
| max_results | No | Maximum number of results (default: 10) | |
| max_distance_km | No | Maximum search distance (default: 15km) | |
| min_duration_minutes | No | Minimum slot duration in minutes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It states results are sorted by price (lowest first), which is useful, but omits details like what happens when no slots are found, whether location is required, or any rate limits. The minimal information leaves too many gaps for reliable agent invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The key action and a critical behavioral trait (sorting) are front-loaded. Efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, no output schema, and no annotations, the description is insufficient. It does not explain what results contain (e.g., times, courts, prices) or provide any usage context. A more complete description would outline return format, edge cases, or required prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no extra meaning to parameters beyond what the schema already provides. It does not clarify how optional parameters like time_start, time_end, or min_duration_minutes interact with result sorting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds cheapest padel court slots and specifies sorting by price. The name aligns with purpose. However, it does not explicitly differentiate from siblings like compare_prices or check_availability, though the focus on cheapest and automatic sorting provides a distinct aim.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as compare_prices, check_availability, or find_nearby_courts. The description only implies usage for finding cheapest slots, but lacks exclusion criteria or context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find padel courts and venues near a given location. Returns a list of venues with their addresses and distances.
| Name | Required | Description | Default |
|---|---|---|---|
| location | Yes | Location to search near (address, city name, or coordinates like "51.5074,-0.1278") | |
| radius_km | No | Search radius in kilometers (1-50, default: 10) | |
| max_results | No | Maximum number of venues to return (1-50, default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it returns a list with addresses and distances, which is helpful, but lacks details on rate limits, authentication, or what happens with empty results. It implies a read-only operation but does not explicitly state safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the purpose and output. Every word earns its place; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and returns list with addresses and distances. Given no output schema, it provides a good overview. However, it could mention ordering (e.g., by distance) or behavior when no results are found.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good parameter descriptions. The description adds minimal beyond what the schema provides, only mentioning 'near a given location' and return fields. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds padel courts and venues near a location, using a specific verb and resource. It distinguishes itself from sibling tools like book_court or check_availability by focusing on location-based search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use (finding courts/venues near a location) but does not explicitly mention when not to use or suggest alternatives like search_by_duration or find_available_games.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze availability patterns at a venue to find peak and off-peak hours. Shows when courts are typically busy or quiet.
| Name | Required | Description | Default |
|---|---|---|---|
| venue_id | Yes | The venue ID to analyze | |
| venue_name | No | Venue name for display | |
| sample_date | No | Date to sample (defaults to next suitable day) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the output (shows busy/quiet times) but does not disclose behavioral traits like data source, refresh rate, read-only nature, or requirements. Minimal transparency beyond basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no unnecessary words. Directly communicates the tool's purpose and output. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description only vaguely describes output as showing when courts are busy/quiet. Missing details on format (e.g., list of hours, percentages, comparison). For a tool analyzing patterns, more specificity about output structure would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are described in the input schema (100% coverage). The description adds no additional parameter semantics beyond what the schema already provides. Baseline score 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes availability patterns to find peak and off-peak hours, using specific verb 'Analyze' and resource 'availability patterns'. It distinguishes from sibling tools like check_availability and get_weekly_availability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding busy/quiet times but does not explicitly state when to use vs alternatives (e.g., check_availability for specific slots, get_weekly_availability for full schedule). No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific padel venue including address, contact info, courts, and amenities.
| Name | Required | Description | Default |
|---|---|---|---|
| venue_id | Yes | The venue ID to get details for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits beyond the obvious read operation. It fails to mention any potential side effects, authentication needs, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is front-loaded with the purpose and includes relevant details. No unnecessary words, every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only 1 parameter and no output schema, the description is fairly complete. It outlines the key information that will be returned (address, contact, courts, amenities). However, it could be more explicit about what 'detailed information' includes, the scope of data, or if there are any limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'venue_id' with a clear description. The tool description adds context about the response contents but does not enhance the parameter meaning beyond the schema. Baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and explicitly lists the resource 'detailed information about a specific padel venue' including examples like address, contact info, courts, and amenities. It clearly distinguishes from siblings which are for booking, checking availability, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool instead of alternatives like find_nearby_courts or list_favorite_venues. The description only states what it does, not when it is appropriate or when another tool would be better.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View padel court availability across multiple days (up to a week). Includes weather forecast for planning.
| Name | Required | Description | Default |
|---|---|---|---|
| location | No | Or search by location | |
| num_days | No | Number of days to check (1-7, default: 7) | |
| time_end | No | Filter by time end (HH:mm) | |
| venue_id | No | Specific venue ID to check | |
| start_date | Yes | Start date (YYYY-MM-DD format) | |
| time_start | No | Filter by time start (HH:mm) | |
| include_weather | No | Include weather forecast for each day (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only mentions including weather forecast, but does not disclose whether the operation is read-only, what the response format looks like, or any side effects. This is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences that convey the core purpose without any wasted words. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description should provide more context about the expected output or behavior. It mentions weather but omits details on return format (e.g., list of days with slots). Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the schema parameter descriptions. It does not explain parameter interactions or provide usage examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'View' and the resource 'padel court availability across multiple days', which is specific and distinguishable from siblings like 'check_availability' (likely single-day). The mention of 'up to a week' further clarifies scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing multiple days of availability, but does not explicitly state when to use this tool versus siblings like 'check_availability' or 'find_available_games'. No exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all availability alerts (active and past).
| Name | Required | Description | Default |
|---|---|---|---|
| include_inactive | No | Include triggered/cancelled alerts (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states that the tool lists alerts, with a parameter for inactive ones. Missing details on sorting, pagination, rate limits, output format, or what constitutes 'active' vs 'past'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence that conveys the core purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with one optional parameter and no output schema, the description is adequate but minimal. It does not specify the structure of returned alerts or any ordering/limitations, which could be useful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description of the 'include_inactive' parameter is clear. However, the tool description says 'active and past', which conflicts slightly with the default behavior (only active). The description adds minimal extra value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('list') and the resource ('availability alerts'), and specifies the scope ('active and past'). It effectively distinguishes this tool from siblings like 'set_availability_alert' and 'cancel_availability_alert'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus other related tools such as 'check_availability' or 'set_availability_alert'. No mention of prerequisites or context where listing alerts is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all your saved favorite venues.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description only states the action without disclosing read-only nature, authentication requirements, or behavior when no favorites exist; with no annotations, the description carries the full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words, immediately conveys the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Minimal description for a simple tool; lacks details on return format or output fields, but adequate for a straightforward list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0 parameters and 100% coverage; description adds no parameter details but baseline is 4 for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'List' and resource 'favorite venues', distinguishing it from sibling tools like save_favorite_venue and remove_favorite_venue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives; lacks context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Quick check: See availability at all your favorite venues for a specific time. Perfect for "Can I play tonight?"
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Date to check (defaults to today) | |
| time_preference | No | Time preference: "morning" (06-12), "afternoon" (12-18), "evening" (18-23), or "HH:mm-HH:mm" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only mentions 'See availability' and 'favorite venues', but does not clarify if it's read-only (assumed), what happens if there are no favorites, or any side effects. The description lacks explicit behavioral context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, no fluff, and front-loaded with the key action. It is appropriately concise for a simple tool, though it could structure the info better (e.g., separate purpose from use case).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is incomplete. It does not explain what the return result looks like (e.g., list of venues with availability), error conditions, or edge cases like empty favorite list. For a tool with siblings offering more detail, this description lacks sufficient completeness for an agent to understand the full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add any meaning beyond the schema; it only mentions 'specific time' without elaborating on the parameters. The schema already documents date and time_preference with patterns, so the description adds no extra value for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks availability at all favorite venues for a specific time, using a specific verb 'See availability' and resource 'all your favorite venues'. It distinguishes from siblings like 'check_availability' (likely single venue) and 'list_favorite_venues' (only lists, not checks).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a use case ('Can I play tonight?') implying when to use it, but does not explicitly state when not to use it or how it differs from alternatives like 'check_availability' or 'find_available_games'. No usage exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a venue from your favorites.
| Name | Required | Description | Default |
|---|---|---|---|
| venue_id | Yes | The venue ID to remove |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It only states the action without disclosing side effects, required permissions, or reversibility. A removal tool should indicate whether the operation is destructive and if it requires authentication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose. It is front-loaded and contains no unnecessary words, though it could benefit from additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple removal tool with one parameter and no output schema, the description mostly covers the basics. However, it lacks context about preconditions or side effects, making it minimally adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the parameter descriptively named and described. The tool description adds no extra meaning beyond 'the venue ID to remove'. Baseline 3 is appropriate as the schema already documents the parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'remove' and the resource 'venue from your favorites', distinguishing it from sibling tools like save_favorite_venue (add) and list_favorite_venues (list). It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., save_favorite_venue). It does not mention prerequisites like the venue needing to be in favorites, or consequences of removing a non-favorite venue.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a venue to your favorites for quick access. You can optionally give it a nickname.
| Name | Required | Description | Default |
|---|---|---|---|
| nickname | No | Optional nickname for quick reference | |
| venue_id | Yes | The venue ID to save | |
| venue_name | Yes | The venue name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'Save a venue', which implies a mutation but lacks details on side effects, idempotency, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 3 parameters, the description is adequate but lacks behavioral context like error conditions and duplicate handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description's mention of optional nickname adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Save' and resource 'venue to your favorites', distinguishing it from sibling tools like 'remove_favorite_venue' and 'list_favorite_venues'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for quick access but does not explicitly state when to use versus alternatives or provide context for prerequisites or duplicates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find padel courts available for a specific duration (e.g., exactly 90 minutes). Filters out slots that don't match your duration requirement.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Date to search (YYYY-MM-DD format) | |
| location | Yes | Your location (address, city name, or coordinates) | |
| time_end | No | End of time range (HH:mm format) | |
| max_price | No | Maximum price per slot | |
| time_start | No | Start of time range (HH:mm format) | |
| max_distance_km | No | Maximum search distance (default: 10km) | |
| duration_minutes | Yes | Required slot duration in minutes (typically 60, 90, or 120) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the key behavior (filtering by duration), but it does not mention other behavioral traits such as output format, pagination, or non-destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with clear front-loading of purpose and zero wasteful phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 7 parameters, no output schema, and no annotations, the description is too brief. It lacks details on output format, time range interaction, and differentiation from similar sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal additional meaning (reiterating duration filtering) but does not deepen semantics for other parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Find') and resource ('padel courts') and specifies the unique filtering criterion ('specific duration'), distinguishing it from siblings like check_availability or find_nearby_courts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a specific duration is required, but it does not provide explicit when-not-to-use or alternatives among the 19 sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set up a persistent alert for when a preferred time slot becomes available. Alerts are saved to disk and support webhook notifications.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Date to watch (YYYY-MM-DD format) | |
| venue_id | Yes | The venue ID to watch | |
| venue_name | No | Venue name for display | |
| webhook_url | No | Webhook URL for notifications (required if notification_method is webhook) | |
| preferred_time_end | Yes | End of preferred time window (HH:mm) | |
| notification_method | No | How to notify: webhook (POST to URL), log (write to file), or callback (return in response) | log |
| preferred_time_start | Yes | Start of preferred time window (HH:mm) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses persistence ('saved to disk') and notification support, but lacks details on limits, idempotency, duplicate handling, or error conditions. Some transparency, but significant gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no waste. Front-loaded with the core action and key behaviors (persistence, webhook support). Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters and no output schema or annotations, the description is adequate but incomplete. It covers persistence and notification method but does not explain the response, error handling, or success indication. An agent might need more context to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema; it only describes the tool's overall purpose. Parameters are well-documented in the schema, so no extra semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action 'set up a persistent alert' with specific conditions 'when a preferred time slot becomes available'. It distinguishes from sibling tools like 'check_availability' (which checks existing slots) and 'list_availability_alerts' (which lists alerts), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for monitoring future availability but does not provide explicit when-to-use vs alternatives like 'check_availability' or 'find_available_games'. No exclusions or conditions are mentioned, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test widget rendering and interactivity with a simple Hello World widget
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. The description states purpose but does not mention side effects, safety, or constraints. For a test tool, it is likely safe but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, front-loaded sentence: 'Test widget rendering and interactivity with a simple Hello World widget'. No wasted words, clear and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and a simple purpose, the description is mostly adequate. It could be more specific about what 'Hello World widget' entails, but overall sufficient for a test tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the input schema is empty, so schema coverage is 100%. The description does not need to add parameter meaning; baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it tests widget rendering and interactivity with a Hello World widget. However, it does not differentiate from the sibling tool 'test_slot_cards' which likely has a similar testing purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'test_slot_cards' or other tools. The description only says what it does, not when it should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test slot cards widget with mock booking data
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present. The description uses 'mock booking data' implying no real side effects, but it does not explicitly state behavioral traits like being non-destructive or read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using a single phrase without extra words. However, it lacks sentence structure and could be more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and a simple test purpose, the description is somewhat complete. However, it could clarify that this tool is for internal testing and not for actual booking operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description does not need to add parameter info, making this dimension satisfactory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Test slot cards widget with mock booking data', indicating it's a test tool for a specific widget. It distinguishes from real booking tools among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool or when to avoid it. The description does not mention that it's for testing only or that it won't affect real data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v2.0.0book_courtcancel_availability_alertcheck_availabilitycompare_pricesfind_available_gamesfind_cheapest_timefind_nearby_courtsget_peak_hoursget_venue_detailsget_weekly_availabilitylist_availability_alertslist_favorite_venuesquick_book_checkremove_favorite_venuesave_favorite_venuesearch_by_durationset_availability_alerttest_hello_worldtest_slot_cardsScored across 19 tools
Several tools overlap in purpose, especially those related to availability checking (check_availability, find_available_games, find_cheapest_time, quick_book_check, get_weekly_availability). While descriptions differentiate them, an agent may still struggle to select the correct one. The inclusion of test tools adds further ambiguity.
Most tools follow a clear verb_noun pattern (e.g., book_court, check_availability, save_favorite_venue). The only deviation is quick_book_check, which uses an adjective+noun+noun structure. Overall, naming is predictable and consistent.
With 19 tools, the count is on the higher side for a focused padel finder server. The inclusion of two test-only tools (test_hello_world, test_slot_cards) that are unrelated to the core domain makes the set feel bloated. Removing those would bring it to a more reasonable 17.
The tool surface covers venue discovery, availability, pricing, favorites, and alerts well. However, the booking lifecycle is incomplete: there is only book_court (which starts a process) but no tool to confirm, cancel, or view bookings. This gap could cause agent failures.
Search and discover 25,000+ MCP servers across all major registries. Connect and pay autonomously.
Skiplagged MCP Server for flight search, hotel booking, and travel planning
Hotel booking MCP server. Search, book, and manage reservations across 250K+ properties worldwide.
MCP server for Google Veo AI video generation
