OpenMapp

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

readOnlyHint=true already establishes the safe-read profile, and the description adds meaningful behavioral value beyond it: the default filter posture, that visitor fees are only returned 'when known', and that booking fields appear only 'when the gym takes reservations' — non-obvious conditional return behavior.

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 tightly packed sentences; the geographic scope and default filters are front-loaded and every clause carries information about either inputs or returns.

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 exists, yet the description enumerates the return payload (drop-in policy, visitor fee, matching class times, reservePrice/reserveUrl) and states the conditional cases where fields are absent, so an agent knows both how to call it and what to expect back.

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 all six parameters are already documented, including their defaults. The description restates the drop-ins/today defaults without adding format or interaction detail beyond the schema, so the baseline 3 applies.

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+resource (find BJJ gyms) plus geographic scope (US city, neighborhood, or ZIP). It is clearly distinguishable in practice from get_gym or list_cities, though it never names a sibling to route against 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?

Implies usage context by declaring defaults ('open to drop-ins, classes today'), which tells the agent what the unfiltered call returns, but gives no explicit when-to-use vs get_gym/list_cities guidance or when to override the defaults.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is clear. The description adds valuable disclosure of what the response contains, including that booking details (price, reserveUrl) appear only when the gym takes reservations, which is non-obvious conditional behavior.

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?

It is one dense sentence that front-loads the return payload, plus a short usage note. Every phrase earns its place and there is 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?

With a single fully described parameter, annotations covering safety, and no output schema, this description is complete: it fully outlines the return contents and the conditional booking data.

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% and the schema already documents the id parameter with an example slug. The description only repeats 'id or slug from find_gyms', adding no format or validation detail 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 states a specific verb and resource ('Full public gym card'), and enumerates the exact contents (address, drop-in policy, fee, timetable, booking). It is clearly distinguishable from siblings like find_gyms (search) and start_reservation (booking action).

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?

'Use an id or slug from find_gyms' gives clear prerequisite context, implying this is a detail-fetch after search. It does not explicitly say when-not to use it, but the dependency on find_gyms makes the workflow obvious.

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

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

readOnlyHint=true already signals a safe read, so the bar is lower, and the description adds what the agent actually gets back (gym counts, drop-in counts, open-mat counts). It says nothing about result volume or default-limit behavior, but the return-shape disclosure is genuinely useful given there is no output 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?

Two sentences with no waste: the first defines the payload, the second defines the usage and the sibling relationship. Front-loaded with the resource and its contents.

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 three-param read-only lookup with no output schema, the description covers resource, payload fields, filtering, and the call-ordering relationship to find_gyms. Nothing an agent needs in order to select and call it correctly is missing.

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 q, limit, and state are already documented in the schema, which sets the baseline at 3. The description restates the city-name and two-letter-state filters but adds no format or syntax detail beyond what the schema provides, and omits limit entirely.

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 (lists US cities OpenMapp covers) plus the exact payload contents: gym counts, drop-in-welcoming gym counts, and open-mat listings. This distinguishes it from find_gyms, which returns gyms rather than coverage.

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?

Explicitly tells the agent to use it to check coverage before calling find_gyms, naming the sibling alternative and the ordering condition. It stops short of stating when-not to use it, but the routing intent is unambiguous.

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

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

readOnlyHint=true already tells the agent this is a safe, non-mutating operation, and the description adds essentially nothing beyond it. The one behavioral note — that the resulting link can carry an open gym drawer — largely duplicates the gym_id schema description ('open the details drawer'). No mention of return type, URL construction, expiry, or authentication needs.

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 compact sentence with no filler, and the primary scope ('for a city search') is front-loaded ahead of the optional variant. It is efficient, though its brevity reflects under-specification rather than disciplined editing.

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 tool is simple (two params, one required, no nesting) and the annotations cover the safety profile, so not much is required. Still, with no output schema the description should clarify that the return value is a link/URL, and it offers no routing guidance relative to the four 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 both parameters are already fully documented in the schema and the baseline is 3. The description's mention of 'city search' and 'gym drawer' merely restates those same parameters in prose without adding format, constraints, or interaction rules.

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 identifies the resource (an OpenMapp map link) and its scope (city search, optional open gym drawer), which is more than the title alone. However, it contains no verb, so it never states what the tool actually does — presumably generate/return a deep link — and it does nothing to distinguish itself from siblings like find_gyms, get_gym, or list_cities. It is a noun phrase rather than a task statement.

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?

There is no explicit when-to-use, when-not-to-use, or alternative named. The phrase 'optionally with a gym drawer already open' hints at a scenario, but the agent must infer it is for producing a shareable/navigable map reference rather than fetching data, which is exactly the ambiguity against find_gyms and get_gym.

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

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

Annotations only supply readOnlyHint=true; the description independently confirms the non-mutating nature ('does not book anything') and adds substantive context about output fields and the unavailable-status branch. This goes well beyond what the annotation declares.

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, front-loaded with the core purpose, then return values, then the non-booking caveat and fallback. Every sentence carries distinct information with no repetition of 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?

With no output schema, the description compensates by enumerating the returned fields (next date, start time, price, cancellation policy, reserveUrl) and the unavailable-status response shape (reason, reservableClasses). An agent has everything needed to interpret 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 100%, so all five parameters are documented in the schema itself (id source, weekday enum, date pattern/default, name disambiguation, time format). The description adds no parameter-level detail, so the baseline 3 applies.

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 action (check reservability) on a specific resource (a class at a gym) and immediately disambiguates from what the name implies by clarifying it does not book anything. The agent knows exactly what this returns and that the actual booking happens elsewhere.

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?

Clearly frames the use case — verifying that a class can be reserved online right now and retrieving the visitor-facing link — and explains the fallback path when status is unavailable (reason plus reservableClasses). It doesn't need to name an alternative tool because no sibling overlaps, but it also doesn't state prerequisites such as whether the gym/class ids must first come from find_gyms.

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