Eight-ball pool in the browser: table state, shot physics, rules and live match data.
Scored across 4 tools
Each tool has a distinct primary role: players, rules, terminology, and cross-collection search. pool_search intentionally overlaps with the other tools as a fallback, but its description clearly tells the agent to use it instead of guessing, so the boundary is still understandable.
All tools use the same pool_ prefix followed by a short lowercase noun: player, rules, search, term. The convention is consistent and predictable throughout.
Four tools is well-scoped for a compact billiards reference server covering players, rules, terms, and search. Each tool corresponds to a meaningful collection rather than padding the surface.
The set covers the main reference needs: player lookup, terminology, rules, and unified search. The only notable gap is that pool_rules is explicitly limited to the simulated eight-ball rules, so agents needing authoritative rules for snooker, carom, or other pool games may have to rely on terms or external sources.
Who are the great pool, snooker and carom players, and what is each one known for? 45 players, each with the method they are known for. Filter by part of a name (q), by country as commonly listed, or by ONE lower-case game tag; combine them, or send nothing for all 45. The game tag has exactly one spelling each: eight-ball, nine-ball, ten-ball, rotation, one-pocket, straight pool, snooker, three-cushion carom, money games - '9-ball' and 'Nine-ball' will miss. The order is editorial and is NOT a ranking; do not present a position as a standing.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Part of a name. Example: Reyes | |
| game | No | One lower-case tag from the list. | |
| country | No | As commonly listed. Example: Philippines |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the result-set size (45), that ordering is editorial, and that positions are not standings — genuinely useful behavioral context an agent would otherwise get wrong. It does not describe the returned fields beyond 'the method they are known for', which is the main remaining gap.
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?
Roughly four sentences, front-loaded with what the tool returns before the filtering rules and the ordering caveat. It is dense and slightly run-on, but each sentence carries distinct information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter, zero-required, annotation-free lookup tool with no output schema, it covers size, filtering, tag spelling, and ordering caveats — enough to call it correctly. It stops short of describing the shape of each returned record, which matters since no output schema exists.
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 3 is the baseline, but the description adds real meaning: exact lower-case tag spellings with a concrete counterexample ('9-ball' and 'Nine-ball' will miss), single-tag limitation, and that country is matched as commonly listed. q is only restated as 'part of a name', so it adds less there.
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 resource (45 pool/snooker/carom players, each with the method they're known for) with an explicit count, so an agent knows exactly what it retrieves. It never differentiates itself from the sibling pool_search, which is the most likely source of confusion, so it stops 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?
Clear operational guidance: filter by name fragment, country, or exactly ONE game tag, combine them, or send nothing for the full 45. It also adds a strong usage constraint — 'the order is editorial and is NOT a ranking; do not present a position as a standing'. It gives no guidance on when to prefer this over pool_search, so no exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How is eight-ball played? The seven rules this game enforces: the break from behind the head string, the open table until the first called pot, calling the ball and the pocket, what counts as a foul, ball in hand anywhere as the penalty, the eight last and only in the called pocket, and what loses the frame. No arguments. THESE ARE THIS GAME'S RULES - WPA eight-ball as the simulation applies it, not the full WPA rule book. For a tournament question cite https://wpapool.com/rules-of-play/ alongside.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does meaningful work: 'No arguments' signals a zero-input read, and 'THESE ARE THIS GAME'S RULES - WPA eight-ball as the simulation applies it, not the full WPA rule book' scopes the authority of the answer and warns the agent not to treat it as the complete official rule set. It stops short of stating the return shape or that the answer is static/cacheable, but for a parameterless read tool the risk surface is small.
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 enumeration of the seven rules is genuinely useful for matching a question to this tool, but the opening rhetorical question ('How is eight-ball played?') delays the point, and 'No arguments' plus the capitalized 'THESE ARE THIS GAME'S RULES' restate the same scoping idea. A lead sentence stating what is returned would front-load it better.
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 zero-parameter tool with no output schema and no annotations, the description covers what the answer contains, its authority limits, and the no-input nature. The only gap is guidance on how it relates to the sibling lookup 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?
The schema has zero properties, so the baseline of 4 applies. 'No arguments' correctly reinforces that the call takes no input, which is the only parameter fact an agent needs.
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 makes clear this returns the seven eight-ball rules the simulation enforces, and enumerates them (break, open table, called pot, fouls, ball in hand, the eight, losing the frame), so an agent knows exactly what content comes back. It is distinguishable from pool_player/pool_search/pool_term by content, though it never explicitly names those siblings as alternatives.
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: the framing as an eight-ball rules reference suggests it should be called for rule questions, and 'For a tournament question cite https://wpapool.com/rules-of-play/ alongside' gives an instruction about citation rather than about when to select this tool. There is no explicit statement of when to prefer this over pool_term or the other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The word could be a term, a game name, a rule, a player or a feature and you do not know which: search every collection in one call. Each hit says which collection it came from and how it matched (exact, key or body). Use this instead of guessing which of the other tools to call. One required argument.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | One word or short phrase. Example: bank | |
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses that results span multiple collections and are tagged with match type (exact, key, body), but says nothing about read-only nature, result ordering, pagination, or what happens when nothing matches.
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 with the core capability front-loaded and no filler. The opening clause about the ambiguous word is slightly roundabout but earns its place by motivating the cross-collection search.
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 two-parameter search tool with no output schema, the description covers what is searched, what a hit contains, and why to prefer it over siblings. The main remaining gap is the undocumented limit/pagination behavior.
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?
At 50% schema coverage, the description must compensate — and it only restates that there is "one required argument", which the schema already shows. The optional limit parameter is undocumented in both the schema and the description, so an agent has no guidance on result-size control.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — "search every collection in one call" — and describes the result shape ("each hit says which collection it came from and how it matched"). This clearly distinguishes it from the per-collection siblings pool_player, pool_rules and pool_term.
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 this instead of guessing which of the other tools to call" gives an explicit rule for choosing this tool over its siblings. It does not say when the targeted siblings would be better (e.g. once you already know the item is a rule), so the alternative-selection guidance is one-sided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What does a pool, billiards or snooker word mean? 36 terms and 27 names of games in the family, one line each - screw, stun, throw, half-ball, snooker, bank, kick, carom, jaws, rattle, scratch, shape, run out, and what separates pool from snooker from carom. One argument: the word itself, one word or short phrase, any case. A whole sentence will match on the explanation or not at all, so pull the word out first. Omit q to get all of them. found:false means THIS SITE has no line about it - it does not mean the term does not exist, and you must not supply a definition of your own in its place.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | One word or short phrase. Example: screw | |
| kind | No | terms = the 36 playing terms; names = the 27 games in the family; both = search each. | both |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does substantial work: it explains that found:false means the site lacks an entry (not that the term is nonexistent), forbids inventing a definition, and warns that sentence-length input fails to match. It does not state what a successful entry looks like beyond "one line each".
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?
Front-loaded with purpose, then the argument rules, then the all-important found:false caveat at the end where it belongs. Some filler in the term list ("and what separates pool from snooker from carom") inflates the first sentence without adding selection value.
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, and the description covers the key return-value semantics (found:false, one line per entry) plus both parameter behaviors. Complete enough to call correctly, with only the exact entry shape left unspecified.
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 the baseline is 3, but the description adds real meaning: input must be a single word or short phrase, is case-insensitive, and may be omitted to retrieve all entries. The kind enum is left entirely to the schema, which is acceptable given its self-documenting description.
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?
Opens with a specific question the tool answers ("What does a pool, billiards or snooker word mean?") and quantifies scope: 36 terms, 27 game names. The resource is unmistakable, though it never differentiates itself by name from siblings pool_player, pool_rules, or pool_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete invocation guidance: pass the word itself, any case, and "pull the word out first" because a full sentence will not match. Also states that omitting q returns everything. It stops short of saying when to prefer pool_search or pool_rules instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
pool_playerpool_rulespool_searchpool_termBuild, publish and update browser games with saves, leaderboards and realtime multiplayer built in.
Sports data across 8 sports under one canonical schema — scores, stats, standings, Elo, odds
Public league standings, schedules and brackets; start a league or bracket with no account.
Run racket-sport tournaments from your AI assistant: fair draws, scores, live standings.
Add one secure layer between your agents and this server.
