Argentine quiniela and Telekino results: cabezas, full draws, number check. Read only.
Scored across 9 tools
Most tools have clearly distinct purposes: check_number verifies a specific number, get_cabezas returns only position-1 winners, get_results returns the full 20-number pizarra, and get_statistics aggregates history. get_cabezas and get_results share the results domain and could be momentarily confused, but descriptions explicitly point users between them.
A dominant get_verb_noun pattern (get_cabezas, get_results, get_statistics, get_telekino, get_number_info, get_reference) plus check_number keeps things predictable. The bare-verb fetch and search deviate slightly but are conventional exceptions.
Nine tools is well-scoped for a quiniela results server, with each tool earning its place across results, checks, history, meanings, telekino and search. No redundancy or bloat.
The surface covers the core lifecycle: reference data, full/cabeza results, number checking, dream meanings, statistics, telekino, and a search/fetch pair. Only minor gaps remain, and prize calculation/betting is intentionally excluded.
Use this when the user asks whether a number came out: '¿salió el 23?', '¿salió el 4512 a la cabeza?', 'controlar quiniela'. Checks a number of 1 to 4 digits (matched by its last digits) against every jurisdiction and turno of a day, a la cabeza or within the first 5, 10 or 20 positions, and lists where it came out. It does not calculate prizes or take bets. When the host shows the result as a widget, the user already sees every number: do not repeat them in a table or list, answer in one or two sentences (what is still pending, or what stands out).
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Draw day in Argentina: YYYY-MM-DD, "today" or "yesterday". Omit for the latest results. | |
| number | Yes | The number played, 1 to 4 digits, e.g. "23" or "0451". | |
| positions | No | Positions covered: 1 (a la cabeza), 5, 10 or 20 (default 20). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish a safe, idempotent, closed-world read. The description adds genuinely useful behavior the annotations cannot: matching is by trailing digits, coverage spans every jurisdiction and turno, and no side effects like bets or prize calculation occur. The output-presentation rule (don't repeat the widget's numbers, answer in one or two sentences) is extra context the agent could not infer.
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 the trigger condition, then scope, then exclusions, then output formatting. The embedded user utterances and the widget-formatting sentence are both load-bearing, though the description is longer than strictly necessary for such a small 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?
There is no output schema, but the description explains the return shape ('lists where it came out'), the matching rule, and the date default is handled in the schema. It is complete enough to call correctly; only minor gaps remain around result granularity (per-jurisdiction list vs. summary).
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 semantics: 'matched by its last digits' explains matching behavior the schema pattern does not, and the 'a la cabeza or within the first 5, 10 or 20 positions' phrasing clarifies the positions parameter's meaning beyond the enum constants.
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 precise verb and resource ('checks a number of 1 to 4 digits... against every jurisdiction and turno') and anchors it with real user phrasings ('¿salió el 23?', 'controlar quiniela'). This is clearly distinguishable from siblings like get_results or get_cabezas, which enumerate draws rather than validating a played number.
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 explicit when-to-use triggers via quoted user utterances and a clear when-not ('does not calculate prizes or take bets'), plus guidance on how to answer when a widget is shown. It never names an alternative sibling tool, so the routing guidance stops short of tier 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the full content of a document id returned by search.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | A document id from search, e.g. cabezas:2026-10-10. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that it returns 'full content,' which is useful return-behavior context, but it does not mention auth, rate limits, or output format 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?
One short sentence with zero waste, front-loading the return behavior and the source of the required id. Every word 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 one-parameter retrieval tool with full schema coverage and annotations covering safety, the description is nearly sufficient. It does not explain the return format or domain-specific content, but no output schema exists, so the omission is minor.
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 single id parameter is fully documented with an example ('cabezas:2026-10-10'). The description restates that the id comes from search, adding no new syntax or 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?
The description states a specific verb and resource: 'Returns the full content of a document id returned by search.' It clearly distinguishes this tool from the sibling 'search' by indicating it retrieves content rather than finding ids, but it does not differentiate from other retrieval siblings like get_cabezas or get_results.
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 'id returned by search' implies this tool is used after calling search, giving implied usage context. However, there is no explicit when-to-use guidance, no exclusions, and no named alternatives among the many sibling retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks what came out in the Argentine quiniela on a day: '¿qué salió hoy?', 'quiniela de hoy', 'cabezas de ayer', 'resultados de la quiniela', 'quiniela nacional/provincia hoy'. Returns the cabeza (the winning number in position 1) of every jurisdiction and turno for that day; draws not held yet are 'pending'. Pass jurisdiction only when the user names specific quinielas; otherwise the widget shows the five best-known (Ciudad, Provincia, Córdoba, Santa Fe, Entre Ríos). For all 20 numbers of a draw use get_results. When the host shows the result as a widget, the user already sees every number: do not repeat them in a table or list, answer in one or two sentences (what is still pending, or what stands out).
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Draw day in Argentina: YYYY-MM-DD, "today" or "yesterday". Omit for the latest results. | |
| jurisdiction | No | Only these jurisdictions, comma-separated keys or names (e.g. chaco or mendoza,neuquen). Omit for all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely non-obvious behavior: not-yet-held draws return 'pending', the widget already displays all numbers so the agent must answer in one or two sentences rather than repeating a table. It stops short of describing response shape or ordering, but that is a modest gap given the annotation coverage.
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 the trigger conditions, then the return semantics, then the widget/presentation constraint. Every sentence carries a distinct instruction, though the example-phrase list makes it longer than strictly necessary for an agent.
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 fully covers what comes back (the position-1 number per jurisdiction and turno, 'pending' for future draws) plus how to present it. Nothing an agent needs to call and render this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3), and the description goes further by explaining the effective default of omitting jurisdiction — the widget shows the five best-known quinielas (Ciudad, Provincia, Córdoba, Santa Fe, Entre Ríos) — which refines the schema's terse 'Omit for all'. It also constrains jurisdiction to be used only when the user names specific ones.
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 (returns the cabeza — position-1 winner — for every jurisdiction and turno on a given day), and explicitly delimits itself from the sibling get_results ('For all 20 numbers of a draw use get_results'). An agent can distinguish it from the other nine siblings without opening a 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?
Provides explicit trigger phrases in the user's language ('¿qué salió hoy?', 'cabezas de ayer'), a condition for narrowing (pass jurisdiction only when the user names specific quinielas), and the alternative tool for a different need. When-to-use, when-not-to-narrow, and the alternative are all stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks what a number means in the quiniela or which number a dream corresponds to: '¿qué significa el 48?', 'el 23 en la quiniela', 'soñé con un perro'. Returns the meaning from the traditional quiniela dream table (la quiniela de los sueños) for a number from 00 to 99, plus the latest times it came out a la cabeza. Cultural tradition, not a prediction.
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | A number from 00 to 99 (longer numbers use their last two digits). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, and the description adds meaningful context: it returns both the dream-table meaning and recent cabezas results, and warns that this is cultural tradition rather than a prediction. That caveat is genuinely useful behavioral framing not present in 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?
Front-loads the usage trigger and examples, then states the return and the cultural caveat; every clause earns its place. It is a single dense paragraph, slightly long but not padded.
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 so adequately: it names the meaning source and the cabezas output. It stops short of describing structure or edge cases (e.g., invalid numbers), but nothing critical to calling the tool 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 description coverage is 100% and the single parameter already documents the 00-99 range and the last-two-digits behavior. The description only restates the 00-99 range, adding no syntax or format detail beyond the schema, 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 verb and resource: returns the quiniela dream-table meaning for a number 00-99 plus its latest cabezas appearances. The scope (cultural tradition, not a prediction) further distinguishes it from predictive or results-oriented siblings like get_statistics or get_results.
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 triggers on user intent with three concrete example phrasings ('¿qué significa el 48?', 'el 23 en la quiniela', 'soñé con un perro'), which is strong routing guidance. It does not, however, name or exclude alternatives such as check_number or get_cabezas, so the agent must infer those boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when you need today's date in Argentina, the latest draw day, the list of quinielas (the 12 jurisdictions, which turnos each plays) or the turno schedule ('¿a qué hora es la nocturna?', '¿qué quinielas hay?'). Returns reference data only, no results.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=true, idempotent=true, openWorld=false and destructive=false, so the safety profile is fully covered without the description. The text adds only the useful scope constraint that output is reference data rather than draw results; nothing about caching, locale behavior or freshness is disclosed.
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 trigger condition is front-loaded in the first clause, and the whole definition is two sentences. The first sentence is long and crammed with parentheticals, which slightly hurts scanability but not enough to waste space.
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 enumerate the reference categories returned. For a zero-parameter, read-only lookup whose annotations already state the safety profile, this is nearly complete; only freshness/format details are absent.
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 takes zero parameters, so the baseline is 4 and there is no schema content the description needs to compensate for. It still usefully describes what kinds of reference values the caller gets back, which is beyond a bare parameter listing.
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 concrete resource (reference data) and enumerates exactly what it covers: today's date in Argentina, the latest draw day, the quiniela jurisdictions/turnos, and the turno schedule. The closing clause 'Returns reference data only, no results' cleanly separates it from result-oriented siblings like get_results or get_number_info.
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 an explicit trigger ('Use this when you need...') and even supplies representative user phrasings such as '¿a qué hora es la nocturna?'. The 'no results' clause implies that result queries belong elsewhere, but no sibling tool is named outright.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user wants the full results (the pizarra: 20 numbers) of a quiniela or a turno: 'pizarra de la nocturna', 'los 20 números de la Provincia', 'quiniela de Córdoba vespertina de ayer'. Returns all 20 positions, the cabeza, the draw number and the letters. Filter by jurisdiction (ciudad, provincia, cordoba, santafe, entrerios, montevideo, mendoza, chaco, corrientes, neuquen, jujuy, chubut), by turno (previa (10:15), primera (12:00), matutina (15:00), vespertina (18:00), nocturna (21:00)) or both; at least one is required. When the host shows the result as a widget, the user already sees every number: do not repeat them in a table or list, answer in one or two sentences (what is still pending, or what stands out).
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Draw day in Argentina: YYYY-MM-DD, "today" or "yesterday". Omit for the latest results. | |
| turno | No | Turno key: previa, primera, matutina, vespertina or nocturna. | |
| jurisdiction | No | Jurisdiction key, slug or name, e.g. ciudad, provincia, santa-fe, Córdoba. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds what they cannot: the exact payload returned (all 20 positions, cabeza, draw number, letters), the constraint that at least one filter must be supplied, and the host-widget behavior rule about not re-tabulating numbers the user already sees.
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 the usage condition, followed by return content, filter rules, and an output-format instruction; every sentence carries information. The example-phrase list and inline turno times add length, but they are functional rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description fully compensates by enumerating the returned fields (20 positions, cabeza, draw number, letters) and the accepted filter vocabulary. Combined with the annotations and the widget-handling instruction, an agent has everything needed to invoke and answer correctly.
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% (baseline 3), but the schema defines no enums, so the description adds real semantics: the enumerated jurisdiction values and the turno keys with their clock times (previa 10:15, nocturna 21:00), plus the 'at least one is required' rule that the schema does not express. It does not add much beyond the schema for the date parameter.
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 with scope: retrieve the full pizarra (20 numbers) of a quiniela or turno. The parenthetical '(the pizarra: 20 numbers)' and the contrast with the narrower get_cabezas / get_number_info siblings make it unmistakable which results set is returned.
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 trigger utterances ('pizarra de la nocturna', 'los 20 números de la Provincia') and states the filter requirement (jurisdiction and/or turno, at least one). It also tells the agent how to behave when a widget is rendered. It stops short of explicitly naming which sibling to use instead when only a cabeza or a single number is wanted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks for the history of past results: 'números más salidos', 'números más atrasados', 'qué número salió más en la Provincia'. Returns how often each ending (00-99) came out a la cabeza, overall and in the last 90 days, and the ones absent the longest. Descriptive history only: draws are random and these figures do not predict anything; never use them to suggest numbers to play.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Numbers per ranking (default 10). | |
| jurisdiction | No | Jurisdiction key or name; omit for all jurisdictions combined. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, not open-world, non-destructive), and the description adds genuinely new behavioral content: the output is a descriptive ranking over two time windows, draws are random, and the results must never be used to recommend numbers. That use-policy warning is not expressible in 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?
Three front-loaded sentences: when to use, what comes back, and the caveat. Each sentence carries distinct information, and the trigger examples precede the return description so an agent can route on the first clause.
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 does the work of describing the return shape (frequency overall and over 90 days, longest-absent endings), which is enough for an agent to call and interpret it. It is slightly incomplete on ordering/format of the two rankings and whether jurisdiction affects ranking composition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters (limit, jurisdiction) are documented in the schema, so the baseline is 3. The description hints at what is ranked ('each ending 00-99', 'overall and in the last 90 days') but adds no syntax or format detail for limit or jurisdiction beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Returns how often each ending (00-99) came out a la cabeza') and pins down the scope: overall, last 90 days, and longest-absent. This cleanly separates it from siblings like get_results (raw draw history) and check_number (single-number lookup).
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 trigger phrasing tied to real user queries ('números más salidos', 'números más atrasados', 'qué número salió más en la Provincia'), so the agent knows when to pick it. It does not explicitly contrast with get_results or get_cabezas, which is the one remaining gap given the 'history of past results' overlap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks about Telekino or Rekino: 'telekino de hoy', 'último sorteo del telekino', 'telekino 2449'. Returns the winning numbers, the winners and prize amounts per hit level, and the winning cartons of the latest sorteo or a given one.
| Name | Required | Description | Default |
|---|---|---|---|
| sorteo | No | Sorteo number; omit for the latest. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the exact payload contents (winning numbers, per-hit-level winners and prizes, winning cartons) and the latest-vs-specific default, which matters because 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?
A single front-loaded sentence led by 'Use this when', with quoted trigger examples that directly aid intent matching. No filler or redundant restatement.
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-optional-parameter read tool with no output schema, the description covers what it returns and when it applies, while annotations carry the safety profile. Only minor gaps remain, such as behavior for an invalid or out-of-range sorteo number.
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 single 'sorteo' parameter is fully documented in the schema, including the omit-for-latest default. The description's 'latest sorteo or a given one' merely restates that, adding no new format or range semantics, 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 concrete verb+resource set: returns winning numbers, winners, prize amounts per hit level, and winning cartons for the latest or a specified sorteo. The Telekino/Rekino domain is unambiguous, though it never explicitly contrasts itself with look-alike siblings such as get_results or get_number_info.
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 when-to-use triggers with real user phrasings ('telekino de hoy', 'último sorteo del telekino', 'telekino 2449'), which is strong selection guidance. It offers no when-not conditions or named alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Quiniela Hoy results with a natural-language query in Spanish or English (e.g. 'quiniela nocturna de ayer', 'Córdoba 2026-10-03', 'qué significa el 23', 'telekino'). Returns document ids to pass to fetch.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What to look for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real value with two facts the structured fields do not carry: the tool accepts Spanish or English queries, and it returns document ids rather than full content (important since there is no output schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both front-loaded: capability first, return/handoff second. The four examples are compact and each demonstrates a distinct query shape (relative date, location+date, conceptual, single term), so they earn their space rather than 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 one-parameter search with no output schema, the description covers input style, language coverage, and the shape of the return value plus the downstream tool. Minor gaps remain around result volume, ranking, and pagination behavior, but nothing that would cause a mis-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 100% and the single parameter is documented as 'What to look for,' so baseline would be 3. The four inline query examples elevate this by showing the parameter is free-form natural language spanning dates, locations, single terms, and conceptual questions — meaning the schema alone would not convey.
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 (Quiniela Hoy results) scoped to natural-language queries, and the 'Returns document ids to pass to fetch' clause differentiates it from the retrieval siblings by positioning it as the entry point of a two-step flow. It stops short of naming which sibling it is *not* for (e.g. get_results for direct structured lookups).
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 'document ids to pass to fetch' sentence gives clear workflow context — search first, fetch second — which is exactly the usage guidance an agent needs to chain these tools. There are no explicit exclusions or conditions telling the agent when to prefer get_results, get_number_info, or check_number 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.
check_numberfetchget_cabezasget_number_infoget_referenceget_resultsget_statisticsget_telekinosearchLive Argentina data: dolar rates, quiniela and lotteries, holidays, river levels, inflation, news.
Rey Fortuno online casino (Argentina): games, sports odds and provably-fair checks. Read-only.
Winning numbers for 30+ world lotteries, minutes after each draw. Free, no key, CC BY 4.0.
Argentina data tools: dolar blue/MEP/CCL, INDEC inflation, feriados, CUIT/CBU, FX; x402 pay-per-call
Add one secure layer between your agents and this server.
