Find soccer fields for hourly rent in the US, check live availability and get booking links.
Scored across 3 tools
Each tool targets a distinct stage of the field-rental workflow: discovery via search_fields, detailed field lookup via get_field, and time-slot availability via get_availability. The only potential overlap is that search_fields can filter by open slots, but its purpose remains field discovery while get_availability returns detailed start times for one field.
All tools use a consistent snake_case verb_noun pattern: search_fields, get_field, get_availability. The verbs are predictable and the resource-oriented nouns make the set easy to scan.
With only three tools, the surface is tightly scoped to search, field details, and availability. Each tool has a clear role and no redundant operations are present.
The set covers the core consumer workflow: find fields, inspect a field, and check availability with booking links. A direct booking action or richer filtering might be missing, but booking_url fields suggest booking is intentionally handled externally.
Open start times with prices for one field over up to 14 days, each with a booking_url.
| Name | Required | Description | Default |
|---|---|---|---|
| date_to | No | Defaults to date_from | |
| duration | No | Booking length in minutes | |
| field_id | Yes | ||
| date_from | Yes | YYYY-MM-DD, in the field's local timezone |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description does add real value with the 'up to 14 days' range cap and the fact that each slot carries a booking_url, but it is silent on what happens if the range exceeds 14 days (error vs truncation), what an empty result means, and how pricing is expressed.
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 dense sentence with the core payload (start times, prices, booking_url) front-loaded and the 14-day scope attached. Nothing is wasted, though the sentence compresses several distinct facts into one clause chain.
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 does sketch the return shape (start times, prices, booking URLs), which is the right instinct. For a 4-parameter read tool it is still thin on edge behavior — empty results, range overflow past 14 days, and how duration filters slots are all unaddressed.
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 75%, so date_from, date_to, and duration are already documented in the schema. The description's phrase 'for one field' usefully clarifies that field_id selects a single field rather than a set, but it says nothing about duration, which materially changes which start times are returned.
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 names a specific resource and return payload: open start times with prices for one field, each with a booking_url. It is clearly distinct from get_field and search_fields, which operate on field records rather than availability, though it never states that contrast explicitly.
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 is only implied — an agent can infer this is the tool for checking open slots for a known field over a date range. There is no explicit 'use this when...' guidance, no note that a field_id must be obtained first (e.g. via search_fields), and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Details for one field: address, surface, size, hourly prices, opening hours and operator.
| Name | Required | Description | Default |
|---|---|---|---|
| field_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds value by enumerating the returned attributes, but says nothing about behavior for a nonexistent field_id or any error/permission context.
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 front-loaded sentence with no wasted words; the returned-field list is compact though presented as a slightly cryptic comma-separated run.
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 read-only single-record fetch with an annotated safety profile and no output schema, the field enumeration does useful work. However, the undocumented identifier parameter and the absence of sibling differentiation leave visible 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 0%, so the single parameter field_id is undocumented in the schema. The description only implies 'one field' is identified somehow and adds no detail on the identifier's form, valid range, or behavior on invalid input.
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?
States a specific verb-and-resource pair (details for one field) and enumerates what is returned (address, surface, size, prices, hours, operator). It implicitly contrasts with search_fields by retrieving a single field, though it never names that sibling.
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 is only implied: 'one field' suggests this is the lookup-by-id tool rather than the search tool, but there is no explicit when-to-use or when-not-to-use guidance and no mention of get_availability or search_fields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find rentable fields near a location. With a date, returns only fields with open slots that day (at start_time if given), each with a booking_url.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | ||
| lng | No | ||
| city | No | Used when lat/lng are not given | |
| date | No | YYYY-MM-DD, in the field's local timezone | |
| size | No | ||
| state | No | Two-letter US state code, e.g. TX | |
| surface | No | ||
| duration | No | Booking length in minutes | |
| start_time | No | HH:mm, 24-hour | |
| radius_miles | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the 'readOnlyHint' annotation, the description clarifies a key behavioral trait by explicitly stating that the results returned include a 'booking_url' for each field. This is crucial information about the output payload structure that is not detailed in the input schema.
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 extremely concise, using two short sentences to cover the resource, the core functionality (search), and the key constraints (availability and booking URL). There is zero wasted language.
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 an output schema, the description successfully completes the context by guaranteeing the inclusion of a booking URL in the results. It effectively communicates that the tool returns actionable, available slots.
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?
With schema description coverage at only 50%, the description does not offer sufficient compensation. It lists a date and start_time, but it does not elaborate on how the parameters interact (e.g., if 'city' is used, does it imply a default radius?) or what the expected format nuances are beyond the schema's type constraints.
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's primary function: to 'Find rentable fields near a location.' This is a specific action (find) applied to a resource (rentable fields), distinguishing it as a search/discovery tool compared to the listed siblings which suggest direct retrieval.
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?
It provides contextual clues for usage by specifying that results are filtered based on availability ('returns only fields with open slots that day'). However, it does not explicitly state when to use this search tool versus calling the sibling 'get_availability'.
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.
get_availabilityget_fieldsearch_fieldsFind pickup soccer or drop-in football games via your AI. 70+ cities, one-click RSVP.
Live golf tee time availability across US courses. Search by location, date, players, and price.
Book parking, car washes, EV charging, gas and auto repair across the US with live pricing.
Search bookable London courts, pitches, lanes and pickup games across every major UK provider.
Add one secure layer between your agents and this server.
