Horse Truth Machine Intelligence

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds contextual flavor ('FREE', 'self-service', 'autonomous client') but does not disclose additional behavioral details such as output format or whether external requests are made. This is acceptable given the annotations.

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

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

The entire description is one sentence with roughly 20 words, so it is concise and front-loaded with the 'FREE' qualifier. The listing of 'purchase, products, sandbox and checkout navigation' is slightly dense but not padded or redundant.

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, read-only tool with no output schema, the description conveys the essential purpose and the intended autonomous-purchase context. It could specify what exactly the 'navigation' includes or whether it returns URLs, steps, or structured data, but the description is sufficient for a low-complexity 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?

The tool has zero parameters incl/no required parameters, so parameter semantics are inherently trivial. With schema coverage at 100% and no parameters to document, there is nothing for the description to add; the baseline of 4 for zero-parameter tools 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 a specific verb ('Return') and a concrete resource ('self-service purchase, products, sandbox and checkout navigation') tied to a clear goal: buying Horse Truth machine access. The purchase focus clearly separates it from siblings like horse_rankings and resolve_horse.

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

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

The description provides clear context for when the tool is relevant: when an autonomous client needs the navigation steps required to purchase access. It does not explicitly name alternatives or exclusions, but the use case is unambiguous enough for an agent to select it appropriately.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description need not repeat that. It adds the payment cost (US$0.02 per call or 1 Horse Truth credit), which is important behavioral context. However, it does not describe the format of change events or any filtering behavior beyond 'material'.

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 concise with two sentences, front-loading the payment information. It is well-structured and easy to read, though the second sentence is terse and could be expanded without losing conciseness.

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 tool with 2 parameters and no output schema, the description is incomplete. It lacks explanation of the limit parameter, the meaning of 'material', and the return format. Given the low schema coverage, more detail is needed for an agent to call it 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 0%, so the description must compensate. It only mentions 'for one horse' which implies the horse parameter, but does not explain the limit parameter or the format of the horse identifier. The description adds minimal meaning 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 clear verb 'Return' and resource 'Horse Truth change events' for one horse, distinguishing it from siblings like horse_snapshot (snapshot) and horse_compare (comparison). However, the term 'material' is vague and could be interpreted differently, so it's not a perfect 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?

No guidance on when to use this tool vs alternatives. It does not mention any conditions, exclusions, or comparisons to sibling tools. The description only states what it does, not when to prefer it over others.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds the 'PAID' cost context and the 'compact derived snapshots' nature, which is useful. However, it doesn't disclose what 'compact derived' means, whether it returns a comparison table or just multiple snapshots, or any rate limits. With annotations covering safety, a 3 is appropriate.

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 sentence with the cost front-loaded and the core function stated clearly. It's efficient and doesn't waste words. The pricing info is arguably a separate concern but earns its place as a critical usage constraint.

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

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

For a read-only comparison tool with one parameter, the description is mostly adequate. The main gaps are: what 'compact derived snapshots' means, what the output looks like (no output schema), and whether horse strings need pre-resolution. The pricing is disclosed, which is good. Given the tool's simplicity, a 3 is reasonable.

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 0%, so the description must compensate. The description explains the 'horses' parameter implicitly: it's an array of 2-5 horse identifiers. However, it doesn't specify what format the strings should be (names, IDs, URIs) or whether they need to be resolved first. The sibling 'resolve_horse' suggests resolution might be needed, but the description doesn't clarify. Baseline 3 is fair since the description adds some meaning but leaves format ambiguity.

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 compares compact derived snapshots for two to five horses, which is a specific verb and resource. It distinguishes itself from siblings like horse_snapshot (which likely returns a single horse's snapshot) and horse_changes (which tracks changes), though it doesn't explicitly name an alternative.

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 you need to compare snapshots of multiple horses. It doesn't explicitly state when not to use it or name alternatives, but the sibling list and the phrase 'compact derived snapshots' provide some context. The pricing note is a usage consideration but not a when-to-use guideline.

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 indicate a safe read-only operation. The description adds meaningful context: it is a paid call with specific pricing, and it deliberately omits raw provider records, which is an important privacy/redaction 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?

The description is compact and front-loaded with the most operationally critical fact, the pricing, before stating the core behavior. No filler is present, though the dense jargon slightly reduces 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?

With one required parameter and no output schema, the description should clarify the expected input and output shape, but it does neither. The pricing and redaction details are useful, but an agent cannot confidently construct a correct call or interpret the return value from this description alone.

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 0%, and the description does not explain what the required 'horse' string parameter should contain, any format constraints, or how it relates to the Horse Truth read. The description entirely fails to compensate for the missing schema documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a clear action ('Return a structured explanation') and resource ('current derived Horse Truth read'), and adds a distinguishing constraint ('without exposing raw provider records'). It does not explicitly compare itself to siblings like horse_intelligence or horse_snapshot, so it stops short of full differentiation.

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 choose this tool over its siblings or what prerequisite conditions apply. The phrase 'current derived Horse Truth read' implies some stateful dependency, but it is not explained.

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?

The description discloses behavioral traits beyond the annotations: the cost (US$0.02 per call or 1 Horse Truth credit) and the fact that raw provider records are not exposed, implying the output is a derived summary. Annotations already indicate read-only and non-destructive, so the added context about output nature and payment is valuable. It does not describe the exact return format, but given the annotations cover safety, this is sufficient.

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

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

The description is two short sentences with no wasted words, making it efficient. However, the payment information is front-loaded before the core purpose, which could be seen as slightly distracting from the primary function. Still, it remains concise and to the point, earning a high score.

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 tool with one parameter and no output schema, the description covers cost and output nature but omits parameter semantics and explicit usage guidance. It mentions that raw records are not exposed, which is helpful, but it does not specify the output format or how to structure the 'horse' parameter. Given the tool's simplicity, a bit more detail would round out the description, but it is not wholly inadequate.

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 defines a single required string parameter 'horse' with zero description coverage. The tool description does not clarify what constitutes 'horse' (e.g., an ID, name, or other identifier). With 0% schema description coverage, the description fails to compensate for this ambiguity, leaving an agent uncertain about the required input format.

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-resource pair: 'Return derived intelligence for one horse.' This clearly indicates the tool's function and scope. However, it does not explicitly distinguish it from sibling tools like horse_snapshot or horse_signal, relying on the term 'derived intelligence' to imply a departure from raw data without direct contrast.

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

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

The description provides no guidance on when to use this tool versus alternatives. There is no mention of preferred contexts, exclusions, or comparison with sibling tools. The only additional information is the payment mechanism, which is not usage direction. An agent cannot determine when to choose this over horse_snapshot or horse_explanation.

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

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

Annotations already mark the operation as read-only and non-destructive. The description adds valuable behavioral context beyond annotations: the payment requirement (US$0.02 per call or 1 Horse Truth credit) and the receipt-based output nature. No contradiction with readOnlyHint.

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, efficient sentence with no filler. However, the payment note is front-loaded ahead of the actual functional purpose, and 'PAID:' reads as a separate label rather than part of a natural flow.

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 zero parameter documentation, the description is incomplete for a tool that requires a correctly formatted 'horse' argument. It also lacks any usage context relative to the ten sibling tools, leaving the agent to guess when this receipt tool is the right choice.

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 shows a single required 'horse' string with 0% description coverage, and the description does not explain what 'horse' should contain (ID, name, URL, etc.). The tool cannot be invoked correctly without this information, and nothing in the description compensates for the 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 states a specific action ('Return a cryptographic receipt') and a specific resource ('the current derived horse-intelligence payload'), which clearly signals this tool produces a receipt, not the payload itself. This differentiates it from siblings like horse_intelligence and horse_snapshot, though the phrase 'current derived horse-intelligence payload' is somewhat jargon-heavy.

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 includes cost/payment information but provides no guidance on when to use this tool versus a sibling like horse_intelligence or horse_snapshot. There are no explicit conditions, exclusions, or alternative routing cues.

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

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

Annotations already mark the tool read-only and non-destructive. The description adds meaningful behavior beyond that: it is a paid call ('US$0.02 per successful autonomous x402 call') and serves data from an 'already-warmed canonical model cache,' which clarifies cost and freshness characteristics. No contradiction with annotations.

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

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

Two short sentences carry high-value information: cost/credit and source/cache semantics are front-loaded, followed by the core action. Every clause earns its place and there is no redundant restatement 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?

For a simple read-only tool with one optional integer parameter, the description covers cost, data source, and result type. It does not spell out the exact ranking format or default limit, but the annotations and schema cover the rest, so nothing critical is missing for a competent agent.

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 optional 'limit' parameter is self-explanatory from its name and 1–500 bounds in the schema, but the description adds no detail about how limit affects the returned rankings or what the default behavior is. With 0% schema description coverage, some compensation would have been helpful, though the parameter is simple enough to remain usable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific action and object: 'Return current derived Horse Truth rankings.' That is a clear verb+resource statement, and 'rankings' differentiates it from sibling snapshot, change, and compare tools without requiring the agent to open 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?

The description implies this tool is for retrieving current rankings and prominently warns that calls are paid, but it never states when to prefer it over siblings such as horse_snapshot or horse_signal, nor does it mention any exclusions. The payment warning is useful context but not explicit selection guidance.

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

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

Annotations already communicate read-only and non-destructive behavior. The description adds meaningful behavioral context beyond that: the paid nature (US$0.02 per successful call or 1 Horse Truth credit) and the constraint that exactly one named signal is returned. No contradiction with annotations exists.

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

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

The description is concise and front-loads the critical payment condition before the core purpose. The example signal list is compact but useful. Minor jargon like 'x402 call' and 'Horse Truth direct credit' is unexplained, slightly reducing clarity.

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 minimal parameter documentation, the description leaves key gaps: what the returned signal looks like, how the horse should be identified, and how this tool relates to siblings. The pricing detail is useful, but the overall definition is not complete enough for confident autonomous invocation.

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

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

Schema description coverage is 0%, so the description must compensate, but it only partially does. It gives example signal names that mirror the enum, but does not define what each signal means or clarify what form the 'horse' parameter should take. The agent gains little semantic clarity beyond the schema itself.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action ('Return') and resource ('one named derived Horse Truth signal for a horse'), with concrete example signals. It is specific and understandable, though it does not explicitly distinguish itself from siblings like horse_snapshot or horse_intelligence.

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 no guidance on when to use this tool versus sibling tools, nor does it mention prerequisites, exclusions, or alternative selection criteria. It only describes what the tool returns, leaving the appropriate invocation context to inference.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the call is paid (US$0.02) and that the snapshot is 'compact derived', offering some insight into processing. However, it does not disclose error behavior, latency, or what happens if the horse identifier is invalid. Given the annotations, this is adequate but not rich.

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 concise: two short sentences with no fluff. The pricing information is deliberately front-loaded, which is important for autonomous calls. The structure is clean and scannable.

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?

The tool lacks an output schema and provides no description of the snapshot's contents, format, or how to handle the horse identifier. Given the number of sibling tools (horse_changes, horse_compare, etc.), the description does not provide enough context to help an agent choose correctly or know what to expect.

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

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

The description makes no mention of the 'horse' parameter, its expected format, or how it should be supplied. With 0% schema coverage and only a string type in the schema, the agent is left with no additional meaning. This is a critical gap for a tool with a required 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?

The description states a clear action: 'Return a compact derived operating snapshot for one horse.' It specifies the resource (horse) and the type of output (snapshot). It does not explicitly distinguish from siblings like horse_explanation or horse_signal, but the term 'snapshot' implies a concise operational view, which is reasonably distinct.

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

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

The description provides pricing details but no guidance on when to use this tool versus alternatives. There is no mention of scenarios where this tool is preferred over horse_intelligence, horse_signal, or horse_rankings. An agent is left to infer usage from the name and description alone.

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 destructiveHint=false. The description adds a meaningful cost model, disclosing that only successful calls are charged and specifying payment modes. This is valuable context beyond the annotations, though 'autonomous x402 call' is left unexplained.

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

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

The description is two short sentences with no fluff. However, leading with the pricing model rather than the tool's core purpose is a slight structural misstep, since the most important information for selection is the purpose.

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 entity-resolution tool with annotations covering safety, the description covers the core purpose and cost, which is adequate. It lacks query format details, output shape, and failure semantics, but given the tool's simplicity this is a moderate gap, not a fatal one.

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

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

The single parameter 'query' has 0% schema description coverage. The description gives it minimal semantic meaning ('a horse identity') but does not specify format, examples, or accepted identity types (e.g., name, ID, alias), leaving the agent to guess what to pass.

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 ('resolve') and resource ('horse identity against Horse Truth profiles'), clearly indicating an entity-resolution lookup. It doesn't fully clarify what 'resolve' entails or contrast with siblings like horse_snapshot, but it is distinct enough for an agent to differentiate.

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

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

No guidance is given for when to use this tool versus siblings such as horse_snapshot or horse_intelligence. The cost note implies a paid operation, but there is no explicit condition like 'use this when you need to canonicalize an identifier' or 'prefer this over horse_snapshot when...'.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds valuable context beyond that: it specifies that no paid entitlement is consumed and no raw provider records are exposed, which clarifies the side effects (none) and the scope of data. This aligns with the annotations and provides extra reassurance for an agent considering cost or data exposure.

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 sentence that front-loads the key differentiator ('FREE') and then states the purpose and constraints. Every word earns its place: 'FREE' signals cost, 'fixed' implies determinism, 'schema/capability preview' explains output, and the no-raw-records clause sets expectations. No fluff or repetition.

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 tool with no parameters, no output schema, and annotations covering safety, the description covers the essentials: what it returns (a fixed preview), that it's free, and that it doesn't expose raw data. It could be slightly more explicit about the intended use case (e.g., 'Use this to understand the structure of Horse Truth data before purchasing'), but the current wording is sufficient for an agent to decide to call it for a preview.

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

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

The tool has zero parameters, so the schema is trivially covered. The description does not need to explain parameters since there are none. The baseline for 0 params is 4, and the description adds no parameter-related details (which is appropriate). No gaps exist here.

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 a specific verb ('Return') and a specific resource ('fixed Horse Truth schema/capability preview') with context ('for Chance With Wolves'). It also distinguishes itself from sibling tools (like horse_rankings or resolve_horse) by being a preview rather than data retrieval or analysis. The phrase 'no raw provider records are exposed' further clarifies its non-data nature.

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: it's free and doesn't consume paid entitlement, so it's presumably for previewing capabilities without purchasing. However, it does not explicitly state when to use this tool versus siblings, nor does it mention any alternative. The 'FREE' hint suggests a trial/preview context but leaves the 'when not to use' implicit.

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