Gyms and fitness studios across New Jersey: hours, prices, free trials, and booking.
Scored across 7 tools
Each tool has a distinct role: discovery via search_businesses/list_categories/list_places, detail via get_business, availability via check_availability, and two clearly different engagement actions (book_appointment vs contact_business). The descriptions clarify the dependencies between tools, so an agent can reliably choose the right one.
All tools use snake_case with a predictable verb_noun pattern: book_appointment, check_availability, contact_business, get_business, list_categories, list_places, search_businesses. There are no mixed conventions or vague standalone verbs.
Seven tools is well-scoped for a business directory: enough to cover browse, search, detail, availability, booking, and messaging without redundancy. Each tool earns its place and the surface does not feel thin or bloated.
The directory covers the core consumer lifecycle from discovery through booking and contacting a business. Minor gaps remain around post-booking management, such as cancelling or rescheduling an appointment, which agents cannot do with the current surface.
Book a time from check_availability for the person you are helping. First confirm the business, the time, their name, email and mobile number with them, then call with confirmed=true. The business receives the booking on its calendar and the person's contact details for this booking only.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | ||
| Yes | |||
| phone | Yes | ||
| start | Yes | ||
| confirmed | No | ||
| last_name | No | ||
| first_name | Yes | ||
| business_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds genuine context beyond the annotations: the booking lands on the business's calendar and the contact details are shared for this booking only – a data-disclosure fact the hints do not carry. It never explains what confirmed=false actually does (dry run, error, or held pending), which matters given destructiveHint=true and idempotentHint=false.
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?
Three sentences, purpose first, then procedure, then consequence – nothing padding and no repetition of the schema. Slightly denser than needed: the confirmation checklist and the confirmed=true instruction could be merged.
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 a real-world side-effecting write, yet the description covers the workflow and the privacy boundary of the booking. Remaining gaps – semantics of confirmed=false, time format, and what happens if the slot is taken – are modest against the annotations that already flag the write and non-idempotency.
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 0% schema coverage across 8 params, the description compensates well by naming business, time, name, email, mobile and confirmed. It leaves 'note' unmentioned and does not state the expected format/timezone for 'start', so the coverage is strong but not complete.
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?
Specific verb + resource ('Book a time ... appointment') anchored to a named upstream source ('from check_availability'), which immediately separates it from the sibling availability-checking tool. An agent knows exactly what this produces without opening the schema.
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?
Gives an explicit prerequisite workflow: confirm business, time, name, email and mobile with the person, then call with confirmed=true. It names the sibling to use first (check_availability) and the gate condition (confirmed=true) rather than leaving sequencing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open times for a business that has can_book, read live from its calendar. start_date (YYYY-MM-DD) and days (1-30) narrow the range. Times are ISO 8601 in the business's time zone; pass one back unchanged to book_appointment.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| start_date | No | ||
| business_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds genuinely new behavior: the data is read live from the calendar rather than cached, and returned times are timezone-local ISO 8601. It stops short of describing result shape (flat slot list vs. grouped by day) or any rate/expiry limits on the returned slots.
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?
Three tight sentences, each carrying distinct information: what is returned, how to narrow the range, and how to consume the output. The core purpose is front-loaded with no filler.
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?
There is no output schema, so the description reasonably explains the return semantics (ISO 8601, business time zone, feed directly into book_appointment). It is nearly complete for a simple read tool; only the precise structure of the returned availability payload is unstated.
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 0% schema description coverage the description must carry the parameters, and it does explain start_date as YYYY-MM-DD and days as 1-30, plus the implicit constraint that business_id must refer to a bookable business. However, the default of 14 days and the meaning of a null start_date are never mentioned, so the compensation is partial.
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 ('Open times for a business ... read live from its calendar') and scopes the input set to businesses that have can_book. It is clearly distinguishable from book_appointment and get_business, the tool an agent might otherwise confuse it with.
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?
Names the downstream step explicitly — 'pass one back unchanged to book_appointment' — which tells the agent this is the discovery half of a booking flow. It also implies a precondition (business must have can_book), but gives no explicit when-not case or alternative source for availability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a question, quote request or callback request to a business that has can_contact (kinds it takes are in get_business). The business gets the message and the person's name, email and phone (phone required for callbacks) and replies to them directly. Confirm the message and details with the person first, then call with confirmed=true.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | question | |
| Yes | |||
| phone | No | ||
| message | Yes | ||
| confirmed | No | ||
| last_name | No | ||
| first_name | Yes | ||
| business_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing the external side effect (the business receives the message plus the person's name, email and phone, i.e. PII is transmitted) and the callback phone requirement. It does not say whether repeated calls produce duplicate messages or what a successful response looks like, which leaves some gaps for a destructive, non-idempotent write.
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?
Three sentences, no waste, front-loaded with the action and its recipient, followed by effects and then the confirmation gate. Each sentence carries distinct information.
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?
Covers the risky parts of an open-world, destructive, non-idempotent write: recipient eligibility, data disclosure, and the required human confirmation. The main remaining gap is return behavior (no output schema, and the description doesn't say what confirmation the caller gets).
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 0% schema description coverage, the description carries the burden well: it defines what 'kind' selects and where to look for valid values, notes phone is required for callbacks, and explains the gate that 'confirmed' represents. It leaves formats for business_id, email and message unaddressed, so not fully complete.
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 (send) plus the concrete resource types (question, quote request, callback request) aimed at a business. It also distinguishes itself from get_business by pointing there for the allowed kinds, so an agent can tell the two apart immediately.
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?
Explicit preconditions: the business must have can_contact, kinds are discoverable via get_business, phone is required for callbacks, and the agent must confirm the message and details with the person before calling with confirmed=true. This is a full when/how-to-use recipe with no inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full listing for one business by the id search_businesses returned: hours, phone, address, prices, classes, amenities, offers, the business's own services and prices when it publishes them here, and what can be done through this directory (book, message).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world scope, so safety is covered. The description adds genuine value beyond them by disclosing the payload shape (a full detail record with hours, prices, classes, amenities, offers, plus published third-party services), which matters because there is no output schema. It stops short of noting behavior for an unknown id or missing/unpublished sections.
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 front-loaded sentence that leads with the action and scope before the field enumeration. The long comma list of returned fields is dense but each item earns its place as payload disclosure in the absence of an output schema; the trailing 'what can be done through this directory (book, message)' clause is the only slightly loose part.
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 and a bare input schema, the description does the heavy lifting by telling the agent what comes back and where the id comes from — enough to call the tool correctly. The remaining gap is behavioral edge cases (invalid/unknown id, businesses that publish no services), which an agent would have to discover at runtime.
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 0% for the single 'id' parameter, so the description must carry the meaning — and it partially does by tying the id's provenance to search_businesses's return value. It adds no format, length, or failure-mode detail for the id itself, so it compensates only halfway for the coverage gap.
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 ('Full listing for one business') and immediately enumerates what the listing contains — hours, phone, address, prices, classes, amenities, offers, services. The 'by the id search_businesses returned' clause cleanly separates it from the sibling search_businesses tool, so an agent knows exactly which of the two to reach for.
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 clearly implied and partly explicit: call this after search_businesses, passing the id that tool returned, and note that booking/messaging are actions reachable 'through this directory' (pointing at book_appointment / contact_business). There is no explicit when-not or statement about what to do if the id is stale or invalid, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every category in this directory with how many listings each has.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, covering the safety and mutability profile. The description adds that results include listing counts per category, which is useful output context, but it does not disclose ordering, pagination, or other behavioral details. For a simple zero-parameter read tool, this is adequate with annotations doing the heavy lifting.
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, front-loaded sentence with zero waste. It communicates the complete result shape in as few words as possible.
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 tool with rich annotations and no parameters, the description adequately explains what is returned: all categories plus listing counts. It does not specify ordering or exact response structure, but no output schema exists and the core return value is clear.
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 zero parameters, so there are no parameter semantics to explain. Per the evaluation baseline for parameterless tools, the schema is complete by definition and the description does not need to compensate.
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 resource (every category in this directory) and adds useful scope by noting each category includes its listing count. It does not explicitly distinguish this tool from siblings such as list_places or search_businesses, but the purpose is unambiguous on its own.
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 gives no explicit guidance on when to use this tool versus alternatives. Usage is only implied by the tool name and title, with no exclusions, prerequisites, or sibling routing provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Towns, areas, cities or states covered, with listing counts. Filter by state or by part of a name.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| state | No | ||
| name_contains | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds useful context that results carry listing counts, but says nothing about pagination behavior despite a limit parameter, or result ordering.
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 sentences, front-loaded with the resource definition before the filtering options. No filler and nothing repeated from the title.
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 list tool with no output schema, the description covers the resource, the returned data, and the two main filters. The remaining gap is pagination/limit behavior and any ordering guarantees, which matters for an agent deciding how to page through results.
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 0%, so the description must carry the burden. It clarifies two of three parameters — state filtering and substring matching via "part of a name" — but leaves limit undocumented, including its default of 50 and what it caps.
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 the specific resource (towns, areas, cities, states) and states that results include listing counts, so an agent knows exactly what is returned. It doesn't explicitly contrast itself with siblings like list_categories or search_businesses, but the geographic scope makes the distinction reasonably clear.
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?
"Filter by state or by part of a name" implies the intended usage pattern, but there is no statement of when to prefer this over search_businesses or list_categories, nor any exclusions or prerequisites. Usage is inferable rather than guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Gyms NJ (3238 listings). All filters optional. place = town, city, neighbourhood or state as written ('Point Pleasant Beach', 'Austin, TX'). category = a name from list_categories. near_lat/near_lng sort by distance within radius_km.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| place | No | ||
| query | No | ||
| amenity | No | ||
| category | No | ||
| near_lat | No | ||
| near_lng | No | ||
| open_now | No | ||
| radius_km | No | ||
| open_sunday | No | ||
| bookable_only | No | ||
| open_24_hours | No | ||
| has_free_trial | No | ||
| contactable_only | No | ||
| max_monthly_price | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so safety is covered. The description adds real behavioral value by disclosing that near_lat/near_lng change the sort to distance-bounded ordering within radius_km, which is not in the annotations. It omits the default result ordering, the default limit of 10 and how to page past it, and how multiple active filters interact — significant gaps for a 15-parameter search.
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?
Three short sentences, zero filler, with the corpus scope and the "all filters optional" fact front-loaded before the parameter notes. Slightly telegraphic phrasing ("place = town, city, neighbourhood or state as written") but every clause carries information.
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 15-parameter search with no output schema and no structured parameter descriptions, the definition should say what a result looks like, how pagination works past the default limit of 10, and whether filters AND together. None of that is present, so an agent can form a query but cannot predict or iterate on the response.
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 0%, so the description carries the full burden, and it does explain the genuinely ambiguous ones: the place format with concrete examples, the category source, and the lat/lng + radius sorting relationship. However, it says nothing about limit/pagination, the distinction between the free-text "query" and "place", or amenity and max_monthly_price semantics, leaving roughly a dozen parameters name-only.
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 ("Search Gyms NJ (3238 listings)") and even quantifies the corpus, so an agent knows this queries the business directory rather than a single record. It does not explicitly contrast with siblings like get_business or list_places, but the verb/resource pairing is 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?
"All filters optional" establishes that an empty call is valid, and "category = a name from list_categories" routes the agent to the correct sibling for enumerating values. Beyond that there is no when-to-use/when-not guidance, e.g. no statement of when to prefer this over list_places or get_business, or whether multiple filters combine.
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.
book_appointmentcheck_availabilitycontact_businessget_businesslist_categorieslist_placessearch_businessesGyms in all 50 states and DC: search by city, type and hours; book with partner gyms.
Find US BJJ gyms with weekly schedules, open mats, and visitor drop-in prices.
Businesses in Brick Township, NJ: hours, phones, and booking or quotes where offered.
Find gyms and studios, see classes and prices, and book with Gymmy.
Add one secure layer between your agents and this server.