Horse Truth Machine Intelligence

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

Annotations already establish readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds genuinely new context beyond the annotations: it is FREE, and it enumerates the supported payment mechanisms, which matters for an autonomous purchasing agent. It stops short of describing the shape of the returned navigation payload.

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 tight sentences, front-loaded with the 'FREE:' qualifier that matters most to a cost-sensitive agent. Every sentence carries a distinct payload: what it returns, when to call it, and which sibling to use instead.

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, no-output-schema discovery tool whose annotations cover safety, the description supplies purpose, trigger, alternatives, and payment modes. The one remaining gap is that it does not hint at the structure of the returned checkout/navigation data an agent would need to act on.

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, which is the baseline-4 case; the description correctly implies a parameterless discovery call. There is no parameter surface for it to clarify further.

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 (Return) and resource (self-service purchase/products/sandbox/checkout navigation) with its audience (an autonomous client buying Horse Truth access). It also explicitly distinguishes itself from the sibling sandbox_preview, so an agent can route between them 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?

Gives an explicit trigger ('when you need to know how to pay'), enumerates the three payment paths (x402 per call, credit pack, Apify marketplace), and names the alternative tool plus its differentiating condition ('use sandbox_preview instead to see what a result looks like'). Nothing 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=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds real context beyond that: an explicit price ('PAID: US$0.02 per successful autonomous x402 call, or 1 Horse Truth direct credit') and the ordering/return shape ('newest first, each with the fields that changed and when'). It doesn't mention rate limits or whether the credit is charged on failure, so it stops 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?

Four sentences, each doing distinct work: cost, payload, when-to-use, alternatives. The pricing constraint is front-loaded where a cost-sensitive agent will see it, and there is no repetition 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?

No output schema exists, so the description must carry the return shape, and it does state the unit (change events with changed fields and timestamps, newest first). It stops short of describing pagination behavior or whether an empty result is possible for a horse with no material changes, which is the only remaining gap for this otherwise well-specified 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 description coverage is 100%, including naming conventions, the (NZ) suffix rule, the resolve_horse fallback, and the 1-100 range with default 50, so the schema does the heavy lifting. The description only reinforces ordering ('newest first') and adds no syntax or format detail the schema lacks, so the 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 states a specific verb and resource: 'Return material Horse Truth change events for one horse,' with scope ('newest first,' 'each with the fields that changed and when'). It explicitly distinguishes itself from horse_snapshot (current state) and horse_explanation (reasons), so an agent can separate it from 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?

Usage is stated both positively ('Use this tool when you want the history of material changes for one horse') and by exclusion, naming two sibling tools and the conditions that select them (current state, reasons behind it). Nothing 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 cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds genuinely new behavioral context the structured fields lack: a per-call cost of US$0.02 or one Horse Truth credit, tied to 'successful' calls, which matters before an agent invokes it repeatedly.

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 payment line is well front-loaded and earns its place, but the idea 'two to five horses' is repeated three times across the first, second, and fourth sentences. The middle sentence largely duplicates the opening one, so the text is longer than the information content requires.

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 returns, and 'compact derived snapshots' leaves the content and shape of the comparison unspecified. Safety, cost, and routing are covered, but an agent cannot anticipate what measures come back or in what form.

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 baseline is 3: the schema already documents the horses array, its 2-5 bounds, form-guide formatting, country-suffix handling, and the resolve_horse fallback. The description only restates the count range, adding no syntax or naming 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?

States a specific verb and resource ('Compare compact derived snapshots for two to five horses') with the cardinality bound explicit. It also names the sibling it does not replace (horse_snapshot for a single horse), so an agent can separate the two 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?

Gives an explicit when-to-use condition ('when you want two to five horses side by side on the same derived measures') and a named alternative with its own trigger ('Use horse_snapshot instead for a single horse'). The 2-5 vs 1 boundary is 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/closed-world/non-destructive, but the description adds real behavioral context the annotations cannot: a paid cost model (US$0.02 per successful x402 call or 1 Horse Truth credit) and the guarantee that raw provider records are not exposed. It does not cover rate limits or failure/refund semantics, so it stops 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?

Three sentences, each earning its place, with purpose and the sibling routing front-loaded after a brief cost banner. The pricing sentence leads, which is slightly unusual ordering but compact and information-dense rather than wasteful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read tool with full schema coverage, no output schema and clear annotations, the description supplies what is missing: cost, output shape ('list of factors each with its derived value'), and the privacy boundary. An agent can call it correctly without further context.

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

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

Only one parameter and schema description coverage is 100%, so the schema already documents the horse-name format, case-insensitivity and the resolve_horse fallback. The description adds no parameter-level meaning beyond that, so the baseline of 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+resource: returns a structured explanation of the current derived Horse Truth read. It also draws the boundary against siblings by contrasting 'the reasons behind the current read' with the summary values of horse_snapshot and the deltas of horse_changes.

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?

Explicit when-to-use ('when you want the reasons behind the current read') plus named alternatives for adjacent needs (horse_snapshot for summary values, horse_changes for change over time). Nothing is left to inference about routing.

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 read-only/no-destruction safety. The description adds non-obvious behavioral context: pricing (US$0.02 per x402 call or 1 credit) and that raw provider records are withheld. It doesn't state return shape or failure behavior, but the pricing disclosure is meaningful context beyond 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-loaded pricing and purpose, followed by scoping and alternatives. Every sentence earns its place, though the pricing and credit phrasing adds some density.

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?

Covers purpose, routing, cost, and data exposure for a single-param read tool with annotations. No output schema exists, so a brief return-value note would help, but the essential call information is present.

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 schema already documents the horse param fully. The description adds routing value by pointing to resolve_horse when the name is uncertain, which slightly exceeds baseline but doesn't add syntax 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?

Specific verb+resource: returns 'derived intelligence' for one horse, with scope defined (race history, every read). Explicitly distinguishes from siblings horse_snapshot, horse_explanation, and horse_changes, so an agent can route correctly without reading 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?

States when to use ('when you need the full derived state of one horse') and names three specific alternatives with their differing purposes. Nothing left to inference for tool selection.

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 cover the safety profile (readOnly, non-destructive, closed-world), so the bar is lower, and the description adds material context beyond them: this is a paid call at US$0.02 per successful autonomous x402 call or 1 Horse Truth credit, which tells the agent about cost and the x402 payment path. It stops short of stating whether billing occurs on failure or anything about the receipt's structure.

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 sentences, front-loaded with the cost model and then purpose and alternative. Slight redundancy in repeating 'cryptographic receipt' across the purpose sentence and the when-to-use sentence, but nothing is wasted overall.

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, so the description carries the burden of explaining what the receipt actually contains (format, verifiability method, fields), and it does not. For a tool whose entire value is producing a verifiable proof artifact, the missing receipt detail is a real gap.

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 'horse' parameter is documented at 100% schema coverage, including the Australian form-guide naming convention and the pointer to resolve_horse. The description adds nothing about the parameter, so the schema carries the full burden — baseline 3.

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: it 'returns a cryptographic receipt for the current derived horse-intelligence payload.' It also explicitly distinguishes itself from horse_intelligence, telling the agent that this is the proof artifact rather than the read itself.

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 an explicit when-to-use ('when you need a cryptographic receipt for the current read, so you can later prove what was returned') and names the alternative for the other case ('Use horse_intelligence instead for the read itself'). The routing decision is fully specified.

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, destructiveHint=false and a closed-world scope, so safety is covered. The description adds genuinely new behavior beyond the structured fields: the call is paid (US$0.02 per successful x402 call or 1 direct credit) and the data comes from an already-warmed canonical model cache, implying low latency and no recomputation. It stops short of describing ordering direction or result shape, so not 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?

Front-loads the most decision-relevant fact (pricing) and then the purpose and routing. The third sentence largely restates the purpose sentence ('current ranked list' vs 'current derived ... rankings'), which is mild redundancy but not enough to hurt readability.

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 tool with no output schema, the description covers cost, data source, and alternative tools. It omits ranking order/ties semantics and any hint about the returned record shape, which are minor gaps given the simple contract.

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 'limit' parameter is fully documented in the schema with range and default. The description adds no meaning about the limit or its interaction with the ranking set, so the 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 ('Return current derived Horse Truth rankings') and explicitly scopes it to the current ranked list of horses in the Horse Truth model, distinguishing it from named-horse tools. An agent can identify the tool 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?

Gives an explicit when-to-use ('when you want the current ranked list of horses') and names two concrete alternatives for a different need ('Use horse_snapshot or horse_compare instead for named horses'). Routing between siblings is 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 cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false). The description adds genuinely new behavioral context: the per-call cost (US$0.02 per successful x402 call or 1 Horse Truth credit) and the fact that billing is on success, which matters for agent budgeting. It does not mention auth requirements, rate limits, or failure behavior when a signal is unavailable for a horse.

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?

Pricing is front-loaded, followed by purpose, signal enumeration, and routing guidance — a sensible order with no filler. There is mild redundancy in listing 'readiness' and 'class' twice across the enumeration and the usage example, which keeps it from a 5.

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 partially carries the return-value burden by describing what race_day_signals and stride_measures yield. For a two-parameter lookup tool with full schema coverage and clear annotations, that is nearly sufficient; the shape of a generic signal response and what happens when a signal is missing for a horse are the remaining gaps.

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 goes further by giving semantic meaning to enum values the schema leaves bare: race_day_signals is unpacked into four measured components and stride_measures into four stride metrics, and several other signal names are illustrated. The remaining 14 enum values are still only names, so it falls short of full compensation.

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 verb and resource (return one named derived Horse Truth signal for a horse) and enumerates the signal families it can produce. It explicitly distinguishes itself from horse_snapshot (several signals) and horse_intelligence (everything), so an agent can route 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?

It states the selection condition directly ('use this tool when you need one named signal only') and names both alternatives with the condition that selects each. It also clarifies the special enum values race_day_signals and stride_measures as within-scope calls rather than separate 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 establish that this is a read-only, non-destructive, non-open-world tool. The description adds useful behavioral context: it is paid, can use a direct credit, and returns a compact derived snapshot including alerts. It does not detail freshness, caching, or failure/payment behavior, so it is strong but not exhaustive.

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 compact and every sentence contributes useful information. However, it leads with pricing before the core purpose, so it is slightly less front-loaded than ideal.

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 read-only tool with full schema coverage and no output schema, the description gives enough context to call it correctly. It explains the return gist, the paid nature, and when to use sibling tools instead.

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 fully explains the single 'horse' parameter, including name formatting and the resolve_horse fallback. The description only reinforces 'one horse' and adds no parameter semantics beyond the schema, so the baseline of 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 states a specific verb and resource: 'Return a compact derived operating snapshot for one horse.' It also enumerates the snapshot contents and explicitly distinguishes itself from horse_intelligence, horse_explanation, and horse_changes.

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 a clear use case ('when you want a short current summary of one horse') and names the alternatives for full state, reasons, and historical changes. This lets an agent choose between sibling tools without opening their schemas.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: the tool is paid ($0.001 per autonomous x402 call, or 1 direct credit), which materially affects an agent's decision to call it. It stops short of describing the return shape (single identity vs. ranked candidates) or no-match behavior.

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 sentences, each earning its place: cost disclosure, purpose, and routing. Front-loading the paid notice is appropriate for a metered tool, and the fallback routing is placed last where it reads naturally.

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 resolution tool with no output schema, the description covers purpose, cost, and the alternative path. The notable gap is the return contract: whether a resolution yields a single canonical identity, multiple candidates, or an ambiguity error, which matters for a tool whose whole job is disambiguating uncertain names.

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% with a single parameter, and the schema already states 'Full or partial horse name' with an example. The description reinforces the partial/fuzzy matching intent ('partial or uncertain horse name'), but adds little syntax or format detail beyond what the schema provides. 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 ('Resolve a horse identity against Horse Truth profiles') and immediately distinguishes itself from siblings by naming horse_snapshot and horse_intelligence as the tools for the known-name case. An agent can tell exactly what this tool is for 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?

Explicit when-to-use ('when you have a partial or uncertain horse name and need the exact Horse Truth identity before other calls') and explicit when-not-to-use with named alternatives ('use horse_snapshot or horse_intelligence instead once you know the exact name'). Nothing 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=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds non-obvious economics: no paid entitlement is consumed, no raw provider records are exposed, and the default horse is chosen once a day by a published rule. It stops short of stating any rate limits or freshness/caching behavior for the teaser.

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 key qualifier ('FREE') and orders information well: what it returns, the alternate mode, the cost/privacy guarantees, then the routing guidance. Slightly redundant across 'FREE', 'before paying', and 'no paid entitlement is consumed', but each sentence carries real 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?

No output schema exists, and the description compensates by characterizing the return: a real derived proof vs. a public teaser, plus paid next-action recommendations. With annotations covering safety and a single fully documented parameter, the definition is nearly sufficient; only the teaser's exact shape and any rate/freshness limits are left implicit.

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

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

Schema description coverage is 100% and the single 'horse' parameter's description already states that omitting it yields the default sample proof and passing a name yields only the free public page teaser. The tool description restates the same semantics without adding format, validation, or fallback behavior for unrecognized names, so the schema does the heavy lifting.

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?

Names a concrete resource and two distinct outputs: a real derived Horse Truth proof for today's default sample horse, plus the cheapest exact paid next actions, and an alternate mode (free public teaser) when a horse name is passed. An agent can distinguish it from horse_intelligence or horse_snapshot 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?

Explicitly states when to use it ('to see a real example result, or the free public teaser for one horse, before paying') and routes the agent elsewhere by name: discover_purchase_options for payment, horse_intelligence for the full paid read. Both the trigger and the alternatives are stated, not implied.

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