HK Racing AI

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds the metric semantics (win/place rates) and constrains the universe to Hong Kong courses, but says nothing about result volume, granularity, or auth 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 front-loaded sentence with no filler; the scope and valid code set are packed in without redundancy.

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 carries the burden of explaining what comes back, and it does name the returned metrics. It stops short of clarifying granularity (per-draw buckets vs. per-horse) or what a caller should already know about the course/rail concepts.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 75%, and the description usefully enumerates the valid rail/course codes (A, A+3, B, B+2, C, C+3, AWT) and where AWT applies (Sha Tin all-weather). It does not mention the lang parameter, which the schema already documents.

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 resource and metric ('Win and place rates by draw for a Hong Kong course') and enumerates the scoping dimensions (venue, distance, rail position). No sibling tool covers draw statistics, so an agent can distinguish it 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?

There is no guidance on when to call this versus alternatives, no prerequisite context (e.g., that a meeting/race context is needed), and no exclusions. Usage is only inferable from the required parameters.

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 openWorldHint=false, so the safety profile is covered. The description adds useful scope context (fixed window of the last 10 runs, inclusion of a written form summary and AI rank), but says nothing about failure behavior for unknown horse identifiers or data freshness.

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 compact single sentence is front-loaded with the core resource and then lists the returned fields, with the accepted identifier formats appended at the end. No filler, though cramming the field list and input-acceptance notes into one sentence slightly muddies the structure.

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 only two simple parameters, the description usefully enumerates the return payload (career record, last 10 runs with class/distance/draw/jockey/position/odds/AI rank, form summary). Routing guidance and identifier-matching behavior are the remaining omissions.

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. The description's note about accepting Chinese or English names, brand numbers, or ids merely restates the schema and adds no syntax detail, and it omits the lang output-language parameter entirely. 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?

The description names the resource precisely (a Hong Kong racehorse profile) and enumerates the data it returns — trainer, rating, pedigree, last 10 runs, form summary. It clearly belongs to the horse-lookup family rather than get_person, get_race, or get_meeting, though it never states an explicit verb like 'retrieve/fetch'.

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 guidance on when to use this tool versus the sibling 'search' tool, nor any note on whether the horse must already be identified or if this is the discovery entry point. The agent must infer usage entirely from the name and field list.

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 it read-only, idempotent and closed-world, so the safety profile is covered. The description adds genuine behavioral context beyond that: the default-date resolution rule (next upcoming, or latest if none scheduled) is a non-obvious trait an agent needs to predict output. It doesn't discuss pagination or result size, keeping it short of a 5.

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 front-loaded and the default-behavior rule placed last where it reads as a caveat. The return-field enumeration in the first sentence is dense but every item earns its place given there is no output schema to carry 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?

With no output schema, the description carries the burden of describing the return payload, and it does so field by field plus the conditional first-three behavior. Combined with 100% schema coverage on inputs and read-only annotations, an agent has nearly everything needed; only pagination/volume expectations are 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?

Schema description coverage is 100%, so all three parameters (date format, lang enum, venue aliases) are already fully documented in structured fields, establishing the baseline of 3. The description only echoes the optionality of date through the fallback rule and adds no enum syntax or venue-format 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?

It names a specific verb+resource ('Hong Kong horse racing meeting') and enumerates exactly what comes back: every race with post time, class, distance, course, status, the AI top pick, and the first three finishers. This cleanly separates it from the sibling get_race, which is a single-race lookup, so an agent can route without opening either 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 usage by explaining the no-date fallback ('returns the next upcoming meeting'), which tells the agent the tool is safe to call with zero arguments. However, it never states when to prefer this overview over get_race or get_tips, and gives no exclusions or preconditions, so routing among siblings is left 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, idempotentHint and openWorldHint=false, so safety is covered. The description usefully adds the time window ('last two seasons') and the returned categories, but says nothing about permissions, data staleness beyond that window, or handling of unknown names.

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 tight sentence that front-loads the subject and then lists the returned metrics. No filler or repetition of the tool name.

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 carries the burden of describing returns and does so by naming rides, wins, placings and recent rides. Combined with annotations covering the safety profile, it is largely complete, lacking only input-format guidance.

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 only 33%; the lang enum and its behavior are fully documented in the schema, but jockey and trainer have no description there. The description names neither, though their meaning is self-evident from the tool's subject, so the gap is minor rather than damaging.

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 subject (a Hong Kong jockey and trainer's joint record) and enumerates the outputs: rides, wins, placings and recent rides together. This clearly separates it from siblings like get_person or get_track_record, though it doesn't name an alternative 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?

There is no when-to-use or when-not-to-use guidance, and no mention of alternatives such as get_person or get_track_record for related query types. The scope ('last two seasons') implies a use case but the agent must infer it.

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 openWorldHint=false, so the safety profile is covered. The description adds the concrete payload shape (rides, wins/seconds/thirds, rank, win rate, frequent partners, recent rides), which is meaningful behavioral context 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 short sentences, zero filler: the metric list is front-loaded and the input-format note compactly follows. 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?

With no output schema, the description usefully enumerates the returned fields, and input formats are covered. The only gap is the lack of disambiguation against the many sibling statistics tools, which is minor for a straightforward lookup.

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 67%, and the description compensates where the schema is thin: it clarifies that 'name' accepts Chinese, English or an id, and that 'role' is jockey or trainer. The lang parameter's enum is documented in the schema, so nothing critical is missing.

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('Season statistics for a Hong Kong jockey or trainer') and enumerates the returned metrics, so the agent knows exactly what it gets. It does not, however, differentiate itself from plausible siblings like get_standings or get_track_record, leaving overlap in the reader's mind.

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 input guidance ('Accepts a Chinese or English name or id'), which is useful, but says nothing about when to choose this tool over get_standings, get_partnership or get_track_record. Usage is only implied by the jockey/trainer framing.

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 openWorldHint=false, so the safety profile is covered. The description adds useful context that the payload changes over time (pre-race field vs. post-race results/dividends), which is real behavioral value; however it does not describe pagination, caching, or how the dual pre/post state is signaled (a key ambiguity for an agent).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense sentence that front-loads the resource and lists exactly what is returned. It is efficient and free of filler, though the long comma-delimited enumeration is slightly heavy to parse.

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?

Comprehensive content enumeration covering both pre-race and post-race states for a read-only lookup, and annotations cover safety. No output schema exists, yet the description already describes the returned fields well enough for selection; only minor gaps remain around pre/post-race state signaling.

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 four parameters (date format, lang, venue aliases, race_no bounds) are documented in the schema. The description adds no parameter-level detail beyond naming the resource, so 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 resource (one Hong Kong race) and precisely enumerates the returned content: field with draw, jockey, trainer, weight, rating, odds, AI win probability/rank, plus post-race finishing positions, margins and dividends. Clearly distinguishes itself from siblings like get_meeting (whole meeting) and get_horse (a single runner).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied — an agent can infer it should call this for a single race rather than a full meeting, but no explicit when/when-not or alternative-naming guidance is given relative to get_meeting or get_horse.

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 openWorldHint=false, covering the safety profile. The description adds content-level context (season championship table, 30-day window) but omits behavioral details such as whether 'top' limits/paginates results, sort order, or whether the 30-day window is a separate column or a filter.

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 dense sentence that front-loads the resource and lists return fields with no filler. It is well-sized for the tool's scope, though the trailing 'and the last 30 days' is slightly ambiguous.

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 carries the return-value burden and does partially meet it by naming the columns. However, it is silent on result size/ordering (the 'top' parameter's effect) and on when this tool should be preferred, leaving gaps for a 3-parameter tool.

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 only 33%: 'lang' is documented but 'top' (default 20, max 60) and 'role' are not. The phrase 'jockey or trainer' loosely echoes the role parameter, but the description says nothing about the 'top' limit or how many rows are returned, so it does not compensate 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?

The description names a specific resource ('jockey or trainer championship table') and enumerates the returned columns (rank, rides, 1st/2nd/3rd, win rate, last 30 days), so an agent can tell this apart from siblings like get_draw_stats or get_person. It is clear but never explicitly differentiates itself from the other tools in the set.

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 when-to-use guidance, no exclusion of alternatives, and no stated prerequisites. The agent must infer from the resource name that this is the tool for season standings rather than, say, get_track_record or get_tips.

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 openWorldHint=false, covering the safety profile. The description adds a useful default behavior (no date → next upcoming meeting) and mentions settlement data, but does not disclose rate limits, pagination, or other operational details.

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 that efficiently conveys the core functionality and default behavior. It is concise and well-structured, though it could be slightly clearer with the default behavior integrated.

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 explains what the tool returns (top four, ranked by win probability, with settlement) and the default date behavior. It is complete enough for an agent to invoke correctly, though it could mention data availability or freshness.

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 fully documents each parameter (date format, lang enum, venue aliases). The description adds no additional parameter usage details beyond what the schema provides.

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 returns 'AI top four' selections for 'every race at a Hong Kong meeting', ranked by win probability, and includes settlement information. This is a specific verb+resource that distinguishes it from siblings like get_race or get_meeting.

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 (when no date, the next upcoming meeting is returned) but does not explicitly state when to use this tool versus alternatives like get_race or get_meeting, nor does it provide exclusions or alternatives.

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, openWorldHint=false, and idempotentHint=true, so safety and idempotency are covered. The description adds valuable behavioral context beyond that: the record is pre-race-sealed, results are measured against backing the favourite, and losses are explicitly included, which helps the agent understand data completeness. It does not cover pagination, return format, or rate limits, so a 4 rather than 5.

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 that immediately states what the tool returns. Every clause earns its place by specifying the scope, dividend type, comparison baseline, and inclusion of losses. 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 no output schema, the description does a good job explaining the content of the returned record (picks, win/place amounts, comparison with favourite, losses included). Annotations cover the safety profile and the schema covers the only parameter. However, the return structure (e.g., list format, fields per race) is not described, leaving a minor gap for an agent expecting to parse 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?

The input schema has 100% description coverage for the single lang parameter, including its enum values and default. The description does not add any parameter-specific meaning. With high schema coverage, the baseline score of 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 names a specific resource — the public, pre-race-sealed record of every AI top pick — and specifies the exact scope ($10 win + $10 place at HKJC dividends, compared with backing the favourite, losses included). This clearly distinguishes it from siblings like get_tips (current tips) and get_standings (league standings). An agent can tell what data it returns 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 states what the record contains but gives no explicit guidance on when to use this tool versus alternatives such as get_tips or get_standings. Usage is only implied by the resource name. No exclusions, prerequisites, or alternative routes are mentioned.

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 openWorldHint=false, so the safety profile is covered. The description adds scope not in the annotations: it is restricted to Hong Kong racing entities and it returns ids rather than entities themselves, which shapes how the agent should chain calls.

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, zero filler: the accepted identifier forms come first and the return contract and consumer tools follow. 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?

With no output schema in play, the description usefully explains that ids are returned and which tools consume them, and it bounds the search domain to Hong Kong. It does not mention result limits, ranking, or what happens on partial/ambiguous matches, but nothing essential for making a correct call 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 only 50% (query has no schema description), so the description must carry weight here — and it does, specifying that query accepts Chinese name, English name, or brand number and giving the H464 brand-number example. The lang parameter's output-language semantics are left entirely to 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) plus the exact resources (Hong Kong racehorses, jockeys, trainers) and the accepted identifiers (Chinese name, English name, brand number e.g. H464). It also names the downstream siblings (get_horse / get_person), so an agent can distinguish it from the get_* retrieval tools without opening any 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 phrase 'Returns ids usable with get_horse / get_person' clearly signals this is the lookup step that precedes detail retrieval, which is real usage context. It does not state any when-not condition or explicitly rule out the other siblings (get_race, get_meeting), 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.