Private Clubs

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

With no annotations, the description must carry the behavioral burden. It usefully discloses which attributes are compared and explicitly excludes membership fees, pointing to an account-holder resource. However, it does not state read-only behavior, authentication requirements, or any failure mode (e.g., invalid slug).

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 tight sentences with no waste; the core capability is front-loaded and the fee exclusion follows as necessary scope clarification. Every clause 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?

For a simple read-only comparison tool with no output schema and full schema coverage, the description covers what is compared and what is excluded, which is most of what an agent needs. It stops short of describing the return shape or confirming the operation is non-mutating.

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?

Only one parameter and schema description coverage is 100%, so the schema already documents 'slugs' fully; the baseline is 3. The description's 'two or three' restates the minItems=2/maxItems=3 constraint without adding format guidance for what a valid slug looks like.

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 (compare) and resource (private clubs) plus the exact comparison dimensions (location, course, amenities, waitlist). This clearly separates it from siblings like get_club (single club) and search_clubs (discovery), so an agent can route to it 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?

The description implies the use case (side-by-side evaluation of 2-3 clubs) and adds a scope exclusion (membership fees not included, available elsewhere), but it never names the sibling tools or states when to prefer compare_clubs over search_clubs followed by get_club calls.

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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose a real data-scope trait — membership fees are excluded and live at theprivateclubs.com — which is genuinely useful. However, it says nothing about auth requirements, error behavior for an unknown slug, or what 'details' actually covers.

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 with zero filler; the core purpose leads and the fee-exclusion caveat follows. Nothing could be cut without losing meaning.

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 single-parameter read with no output schema and no annotations, the description is adequate but thin. It omits what fields 'details' returns and how failure for an invalid slug is surfaced, leaving an agent without expectations about 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?

There is a single parameter with 100% schema description coverage ('The club URL slug'), so the schema already does the work. The description only implies that a slug identifies one club and adds no format, case, or validation detail. 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?

States a specific verb and resource ('Get details for a specific private club'), which an agent can distinguish from list/search siblings like search_clubs and get_clubs_by_state. It stops short of naming the sibling it is not, so differentiation relies on inference from 'specific'.

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: you invoke this when you already have a club identifier, and the note about membership fees hints at sibling get_membership_info. There is no explicit when-to-use or when-not-to-use statement, and no guidance on how to obtain a slug (e.g., via search_clubs).

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?

No annotations are provided, so the description carries the full burden. 'Get' implies a read operation and 'private' scopes results, but nothing is said about return format, pagination, result limits, or whether all clubs are returned or a capped subset. For a no-annotation tool this is thin 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?

A single front-loaded sentence with no wasted words. It is arguably over-terse rather than verbose, but every word earns its place and the scope constraint comes first.

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 annotations, no output schema, and two parameters, the description is too minimal to be complete. It omits how the optional 'type' filter behaves when absent, whether results are paginated, and the Canadian province case, leaving an agent to guess on several practical points.

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 documented in the schema, giving a baseline of 3. The description adds no syntax or format detail beyond what the schema provides and does not explain the optional 'type' filter or its default behavior.

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 (Get) and resource (clubs) with a scoping qualifier (by US state), and the word 'private' narrows the result set meaningfully. It is distinguishable from search_clubs and get_club without opening a schema, though it stops short of explicitly naming sibling alternatives. Minor inconsistency: the description says 'US state' while the schema also allows Canadian provinces.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as search_clubs for broader queries or get_club for a single record. The only usage signal is the tool name itself, which the agent must infer.

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?

With no annotations, the description carries the behavioral burden and does real work: it discloses that fee figures are NOT returned and redirects the agent to theprivateclubs.com for account holders and to verified fees for members. That output-boundary disclosure is valuable. It stops short of describing auth requirements for this call itself or the response shape.

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 tight sentences, front-loaded with what is returned before the caveat about what is not. Every clause earns its place with no padding.

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 single-parameter read tool with no output schema, the description covers the essential agent-facing facts: what is returned and what is deliberately withheld. Only the response shape and any auth/rate considerations are left implicit.

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?

One parameter with 100% schema description coverage ('The club URL slug'), so the schema already does the work and the baseline of 3 applies. The description adds no format or syntax detail beyond what the schema states.

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 (get) and a specific resource (membership availability / waitlist status) scoped to a club, which is clearly distinct from get_club, compare_clubs, and search_clubs. It does not, however, name or explicitly differentiate itself from those siblings, so it falls short of a 5.

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 implied — check waitlist/membership status for a given club — but there is no explicit statement of when to use this instead of get_club or compare_clubs, and no prerequisites or exclusions are given. Adequate but with a clear gap.

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?

With no annotations, the description carries the full behavioral burden. It usefully discloses one data limitation (membership fees are excluded), but says nothing about result limits, pagination, ordering, or what fields come back — all material for an agent that must compose a response. The excluded-data caveat is the only real 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?

Two sentences, purpose first, with no filler. The second sentence about fee exclusion is not padding — it prevents a likely agent error of promising fee data — though it doubles as a site pointer, which slightly dilutes it.

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 five-parameter, zero-required search tool with no output schema and no annotations, the description should at minimum signal return shape or result-size behavior. It covers scope and one data exclusion but leaves the agent guessing at what a result set looks like and how large it may be.

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 schema already documents all five parameters including the enum-like list of club types and the 'full names only' constraint for state. The description only echoes which dimensions are filterable (location, type, amenities, waitlist) and adds no syntax, format, or combination semantics 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?

States a specific verb (search) and resource (private clubs) plus the filterable dimensions: location, type, amenities, waitlist status. It is clear what the tool returns a filtered set of, but it never distinguishes itself from siblings like get_clubs_by_state or get_club, leaving the agent to infer the boundary.

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 by the verb 'search'; there is no explicit when-to-use statement and no named alternative such as get_clubs_by_state or compare_clubs. The note that membership fees are not included and live elsewhere hints that a different call is needed for fee data, but it doesn't route the agent to a specific sibling tool.

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