Stymie Golf

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

Beyond the readOnly, idempotent, and openWorld annotations, the description reveals ranking behavior, nearest-first fallback, retention of missing scorecards, public-access filtering, private-course confirmation requirements, and the instruction to use returned canonical URLs as citations. This is substantive context that materially affects how the agent invokes and uses the tool.

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 long but information-dense, with the primary workflow front-loaded in the first sentence. Every clause adds useful operational detail, and the length is justified by the complexity of a 13-parameter tool, though a few caveats could be grouped more tightly.

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 complex tool with no output schema, the description covers invocation modes, ranking logic, return contents, access handling, exclusions, and citation guidance, making it nearly complete. It omits a couple of parameter clarifications like state and distance_miles, but an agent can still call it correctly and interpret results based on this text.

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 only 23%, and the description compensates well by explaining latitude/longitude, location, access, holes, number_of_courses, and tee yardage/slope ranges. It does not explicitly cover state, distance_miles, or country, so some parameters still rely on schema or inference.

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 names the operation as building a golf trip shortlist, specifies the output as a 1-4 course ranked selection, and ties itself to find_nearby_courses while also supporting direct location input. This distinguishes it from the search-related siblings without requiring the agent to open their schemas.

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 gives explicit workflow guidance: use after find_nearby_courses and pass its coordinates/preferences, or start directly with a plain-language location. It also states exclusions such as no booking, tee-time availability, transit routing, or drive times, but it does not explicitly name alternative sibling tools for those broader search or booking scenarios.

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?

Beyond the readOnly/idempotent annotations, it reveals behavior: location resolution returns a labeled center, results are nearest-first, URLs must be copied verbatim, and distances are straight-line miles not drive/transit times. It also notes coordinates and slug knowledge are optional and warns about ambiguous locations. No contradiction with 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 main guidance is front-loaded ('START HERE'), and every sentence adds distinct value: input requirements, return contents, ambiguity handling, next step, and a caveat about distance types. 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?

For a 9-parameter tool with no output schema, the description covers input, output shape, ranking, URL handling, error/ambiguity behavior, and links to related workflow tools. Nothing essential for invoking 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?

With 56% schema description coverage, the description compensates for the most important parameters: location can be place/station/address/ZIP, access/holes are the key filters to pass when known, and coordinates are optional. It omits limit and distance_miles semantics, though those are documented in the schema, so the gap is minor.

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 opens with 'START HERE to plan golf near...' and states a specific verb/resource: resolve a location and return a ranked shortlist of nearby courses. It clearly differentiates itself from search_courses ('only for a specific course name') and build_golf_trip (the next step).

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?

Provides explicit when-to-use guidance: use this tool first for location-based course planning, use search_courses only for a specific course name, and follow with build_golf_trip. It also handles ambiguity by instructing the agent to ask the golfer to choose a candidate.

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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful content details like grouping courses by state, but it doesn't describe edge cases, error behavior, or response format. This is similar to the TDQS baseline where annotations carry the 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?

Two sentences, front-loaded with the core purpose, then a compact list of return contents, followed by a clear input instruction. Every word earns its place with no redundancy or 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?

Given there is no output schema, the description compensates well by listing the specific fields returned (bio, image, years, nationality, courses grouped by state). It also covers input options. It lacks details on failure modes or pagination, but for a read-only lookup tool this is largely 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?

The schema fully documents both parameters with examples, but the description adds the key semantic that you should provide 'either' the name or slug—implying mutual exclusivity and that at least one is expected. This goes beyond the schema's 'required: 0' and clarifies usage.

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 opens with a specific verb ('Get') and clearly identifies the resource ('details about a golf course architect'), then enumerates the exact contents (bio, Wikipedia image, birth/death years, nationality, courses by state). It naturally distinguishes from siblings like get_course and get_reviews by focusing on the architect entity.

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: when you need architect details, this is the tool. It also provides invocation guidance ('Provide either the architect name or URL slug'), though it does not explicitly mention alternatives or exclusions. Since no sibling tool targets architects, this is acceptable.

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 establish a safe read-only, idempotent operation. The description adds meaningful behavioral context by enumerating the returned fields ('name, location, type, holes...') and the geographic coverage, which an agent could use to decide if this tool answers its need. No hidden side effects or contradictions are present.

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: purpose, return payload, coverage. Each sentence adds distinct information and the main action is front-loaded, so there is no redundant or filler content.

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 one-parameter read-only lookup with no output schema, the description provides enough context to call the tool correctly: it identifies input provenance, lists output fields, and states supported regions. No missing information is required for a successful invocation.

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 single 'slug' parameter is fully documented in the schema, including its source tools, so the schema carries the burden. The description adds only that the slug is 'returned' and complements the schema's 'Paste' instruction, but doesn't introduce new parameter semantics beyond that.

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 resource ('full details for a specific golf course'), clearly distinguishing it from search-oriented siblings by requiring a 'returned Stymie URL or slug' rather than a query. It also enumerates the returned content, making the tool's purpose unmistakable.

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 and schema state that the input must be a URL or slug returned by search_courses, find_nearby_courses, or build_golf_trip, which clearly tells agents when this tool is appropriate: once a specific course identifier has been obtained. It does not explicitly contrast with alternatives in the description, so it stops short of a full when-not/alternative statement.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context by specifying that the count is 'live' and enumerates the coverage categories, which informs the agent about the dynamic nature and scope of the data. This goes beyond the annotations without contradicting them.

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, front-loaded with the primary action and resources, and every word contributes value. The usage guidance is appended naturally without redundancy. It is succinct and well-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?

For a simple, parameterless tool with no output schema, the description is complete. It states the return value (a live count of coverage) and the specific data categories, which is sufficient for an agent to understand what to expect. The annotations cover safety and idempotence, so no further behavioral caveats are needed.

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 is nothing for the description to explain beyond what the schema already shows (an empty schema). The baseline for 0 parameters is 4, and the description appropriately does not invent parameter details.

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 'Return a live count' and explicitly lists the resources covered (course, scorecard, logo, architect, equipment, current-deal coverage). It clearly distinguishes this from sibling tools that retrieve individual records or search results, and the phrase 'instead of quoting hardcoded catalog sizes' further clarifies its unique role.

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 usage guidance: 'Use this instead of quoting hardcoded catalog sizes.' This indicates when the tool is appropriate and when it is unnecessary (when fresh counts are needed). It does not explicitly name alternative sibling tools, but the context is sufficiently clear for an agent to select it over content-retrieval tools.

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 mark the tool as read-only, idempotent, and non-destructive, and the description adds meaningful behavioral context: offers must be checked within 48 hours, be in stock, and have a price below list. It also transparently discloses that links may be affiliate links, providing additional insight beyond the schema and 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 three sentences long, front-loaded with the core purpose, and every sentence adds value: what the tool returns, the freshness/availability criteria, and the affiliate link disclosure. There is no redundancy or filler, making it highly 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?

Given the tool's simplicity, the description is fairly complete: it states what is returned and the key constraints. However, there is no output schema and the description does not describe the result shape (e.g., fields like price, link, or product name). Since the tool is straightforward and annotations cover safety, the missing return-shape details are a minor gap rather than a critical one.

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 schema has 2 parameters (limit, category) with 0% description coverage, so the description carries the burden of explaining them. The description mentions "golf equipment" but does not explain how limit controls the number of results or how category filters deals. The schema's enum for category offers some inherent meaning, but the description does not compensate for the lack of parameter-level documentation.

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-resource combination, "Get currently verified sale offers for golf equipment," clearly identifying the tool's function and domain. It distinguishes itself from sibling tools like search_equipment by emphasizing "verified sale offers" and the specific filtering criteria, making its unique purpose evident.

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 this tool is appropriate by specifying that it returns only verified, in-stock sale offers below list price. It does not explicitly name alternatives or state when not to use it, but the criteria strongly imply use cases involving deal discovery rather than general equipment search.

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 read-only/idempotent behavior, so the description adds value by defining category semantics (e.g., 'easiest' is public-only) and the metrics used (slope, yardage). This goes beyond the schema's enum labels.

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 purpose, and every clause adds value. No filler or redundant wording.

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 read-only leaderboard tool with three simple parameters, the description covers purpose, usage scenarios, and category definitions. It doesn't specify the return format, but the low complexity and lack of output schema make this acceptable.

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 schema covers 100% of parameters, but the description enriches the meaning of the 'category' parameter by explaining what each value represents. It also gives a state code example, adding practical context.

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 retrieves top golf courses ranked by category (hardest, easiest, longest), with specific criteria for each. This distinguishes it from siblings like search_courses or get_course by emphasizing leaderboard-style ranking.

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 concrete use case ('hardest course in NJ' questions) and explains the category criteria, making it clear when to use this tool. It doesn't explicitly name alternatives, but the context is well-defined.

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 cover the safety profile (readOnlyHint, idempotentHint, non-destructive), so the description's added behavior details are valuable beyond them: it specifies the full payload and the coverage limitation ('thousands of courses with scorecard data'). No contradiction exists.

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 tight sentences: the first states the core function and contents, the second adds a relevant coverage qualifier. There is no filler, repetition, or unnecessary detail.

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-only tool with a fully documented parameter and a clear enumeration of return contents, the description is complete. The lack of an output schema is not a gap because the description explicitly describes what the scorecard contains.

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 schema already fully explains the slug parameter, including accepted inputs like canonical URLs and reusable slugs from sibling tools. The description itself adds no additional parameter-level meaning, so the 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 uses a specific verb 'Get' plus a specific resource ('full scorecard for a golf course') and enumerates the exact contents: tee sets, hole-by-hole par, yardage, stroke index, and ratings. This clearly distinguishes it from sibling tools like get_course or get_architect.

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 clear context by defining the returned data and noting that availability depends on courses having scorecard data. It does not explicitly name alternatives or state when not to use it, but the distinct data scope makes the intended use 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?

Annotations already establish readOnly, openWorld, idempotent, and non-destructive behavior. The description adds valuable context: it lists what is returned (canonical URLs, slugs, access, holes, scorecard availability, miles) and warns 'never construct county slugs.' This goes beyond annotations and gives the agent actionable behavioral guidance.

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 paragraph but well-structured: it fronts the core purpose, then provides usage routing, then the return contract, and finishes with next-step guidance. Every sentence serves a purpose; there is no filler. It is slightly longer than strictly necessary but earns its length.

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 an 11-parameter tool with no output schema and many siblings, the description is thorough. It explains the primary use case, how it differs from find_nearby_courses, what the output contains, and how to chain to other tools. It does not explain every filter parameter (type, holes, country), but those are self-evident and covered by the schema. The description is sufficient for correct invocation.

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 82%, so most parameters are already documented. The description adds critical meaning: it clarifies that 'query' searches course names only, not places, and that 'location' may be used for proximity search. This resolves potential ambiguity between query and location, which the schema alone does not fully capture.

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 opens with a specific verb and resource: 'Search for a named course or filter the directory by city/state, access, and holes.' It immediately distinguishes itself from find_nearby_courses by stating that tool should be called first for trips. The purpose is unambiguous and distinguishes this tool from its 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?

Explicitly states when to use find_nearby_courses instead ('For a trip near a place, station, address, or ZIP, call find_nearby_courses FIRST'), and warns against putting place names in query because 'query searches course names.' It also provides clear follow-up actions (get_course or build_golf_trip), leaving nothing to inference.

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 and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by specifying return fields (official URLs, images, MSRP, best-for guidance) and noting that best-for guidance is only included 'when published,' indicating conditional availability.

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, focused sentence that front-loads the tool's purpose and return details. Every phrase earns its place without redundant 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?

For a simple read-only search tool with three parameters, the description is mostly complete: it covers scope and expected output. It doesn't address edge cases like result limits or empty search behavior, but given the simplicity and annotation coverage, the description suffices.

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 schema describes only the query parameter (33% coverage). The description compensates somewhat by listing the five equipment categories in natural language, aligning with the category enum. However, the limit parameter's semantics and any search behavior nuances are not explained in the description, leaving some gaps.

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 searches equipment (golf balls, drivers, putters, rangefinders, launch monitors) and returns specific result fields (URLs, images, MSRP, best-for). This distinguishes it from sibling tools like search_courses and search_tee_times.

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 equipment searches but provides no explicit guidance on when to prefer this tool over search_stymie or other sibling search tools. It doesn't mention exclusions or alternative tools, so usage is implied rather than explicit.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the behavioral trait that the search spans multiple collections ('courses, equipment, architects, and site tools'), which is useful context beyond the annotations. It does not mention pagination or result format, but given the annotation coverage, this is adequate.

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 no filler. The purpose is front-loaded, and the usage guideline is stated directly. Every word earns its place, making it easy for an agent to parse quickly.

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 cross-collection search tool with no output schema, the description covers the essential context: what it searches and when to use it. It lacks explicit description of return format, but the search nature makes this inferable. Given the presence of sibling tools and annotation coverage, the information is sufficiently complete for correct invocation.

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 description does not add any parameter-specific information. The schema provides descriptions for query and state, covering 67% of parameters; limit has no description but is a simple integer. Since schema coverage is above the baseline for compensation, a score of 3 is appropriate—the description neither clarifies nor obscures parameter usage.

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 purpose: 'Search Stymie across golf courses, current equipment, architects, and major site tools.' It names specific collections and distinguishes it from more targeted siblings like search_courses and search_equipment, leaving no ambiguity about what 'Stymie' encompasses.

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 an explicit usage rule: 'Use this first when the user does not specify which Stymie collection they need.' This tells the agent exactly when to invoke this tool and implies that more specific tools are available when a collection is identified, fulfilling the when-to-use/alternative guidance.

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 mark the call read-only and idempotent, and the description adds important non-obvious behavior: live tee-time inventory is not returned, and the result is instead a Stymie course page plus an alert early-access list. This goes well beyond what the annotations cover and sets accurate expectations for the response.

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 carry the full message: the action, the critical caveat, and the return value. No filler or redundant restatement of the schema.

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 read-only lookup with fully documented parameters and no output schema, the description adequately states what the tool returns and its central limitation. It could add a bit more about what the alert early-access list contains, but that gap does not prevent correct invocation.

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 adds no parameter-specific meaning beyond the schema. The baseline of 3 applies because the schema fully documents slug, date, and players.

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 and resource: it searches for tee times at a golf course, and immediately clarifies that it does not return live inventory. This makes the core purpose clear, though it doesn't explicitly contrast with related tools like search_courses or get_course.

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 or when-not-to-use guidance is given, and no sibling alternatives are named. The note about live inventory being unavailable is a useful expectation-setting caveat, but it doesn't help an agent decide between this tool and search_courses, get_course, or find_nearby_courses.

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