Perch Data

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

With destructiveHint and idempotentHint annotations already declaring the destructive and idempotent nature, the description adds specific behavioral details: it aborts only starting/running runs, returns updated run details, and explains the graceful option with a 30-second timeout. This goes beyond the annotations without contradicting them, though it could mention edge cases like double-abort 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 well-structured: the main purpose is stated first, followed by behavioral details, then usage guidelines and examples. It is concise but includes an unnecessary repetition of 'Abort' in the USAGE line. The examples are helpful and the overall length is appropriate for the tool's complexity.

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

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

Given the tool's simplicity (2 params, one required), the description is complete: it explains the core action, the conditions under which it has no effect, the return of updated run details, the graceful option, and provides concrete examples. The presence of an output schema means the description need not detail return fields. No critical information 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?

Both parameters (runId and gracefully) are fully described in the schema (100% coverage), and the description repeats the graceful behavior without adding new information beyond the schema. Since the schema already explains the parameters thoroughly, the description provides no extra value here, warranting the baseline score of 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?

The description clearly states the tool aborts an Actor run that is starting or running, and specifies that it has no effect on finished runs (SUCCEEDED, FAILED, ABORTING, ABORTED, TIMED-OUT). This precisely distinguishes it from sibling tools like get-actor-run (read-only) and call-actor (starts a run), leaving no ambiguity about the action and resource.

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 USAGE section explicitly says to use it when a run is 'taking too long or misconfigured,' and the no-effect statement implicitly warns against using it on already-finished runs. However, it does not explicitly name alternative tools (e.g., get-actor-run for checking status), so it falls short of the 'explicit alternatives' criterion for a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds meaningful behavior: exact identifier required, default output flags, selective output patterns, and readme fallback behavior. 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?

Well-structured with the main action and constraint front-loaded, followed by bulleted output-parameter guidance and examples. It is somewhat long but each section earns its place and aids correct invocation.

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

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

Given the nested output object and multiple boolean flags, the description covers the identifier requirement, output defaults, selective patterns, readme behavior, MCP-specific use, and example queries. The presence of an output schema also reduces the need to explain return values. Nothing critical 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% with descriptions for all parameters and nested boolean properties. The description adds value beyond the schema by documenting defaults ('All fields true except mcpTools'), selective patterns, and common use cases like 'inputSchema only' and 'mcpTools for MCP Actors'.

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?

Description states a specific verb ('Get detailed information') and resource ('an Actor') with the required identifier format. This clearly differentiates it from sibling tools focused on runs, datasets, and KV records, and it is not a tautology of the name.

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 guidance: 'Use when querying Actor details, documentation, input requirements, or MCP tools' plus concrete example queries. It also warns against constructing plausible-looking Actor names. It does not explicitly name sibling alternatives, but the use-case framing is sufficient.

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?

Beyond the readOnly/idempotent annotations, the description discloses key behaviors: waitSecs blocks up to a cap, summary describes past execution, and nextStep prescribes a follow-up action with interpolated identifiers. It also clarifies that storages are returned as an alias map, giving the agent a realistic picture of the response.

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 well organized with a front-loaded purpose, a structured return summary, a dedicated USAGE section, and compact examples. Every sentence contributes either behavioral detail or invocation guidance, with no filler or redundancy.

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

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

Given the simple two-parameter schema and the presence of an output schema, this description is complete: it explains what the tool returns, how waitSecs affects behavior, how summary and nextStep should be interpreted, and when to invoke it. An agent has everything needed 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 description coverage is 100%, so the runId and waitSecs parameters are already fully documented. The description adds a small amount of practical framing — "Pass waitSecs > 0 to block until terminal" — and concrete examples, but it mostly restates information already present in the input 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 — "Get detailed information about a specific Actor run" — and then lists the exact result fields. It clearly distinguishes this from siblings like get-dataset-items or fetch-actor-details by centering on run status and run-level metadata.

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 USAGE section explicitly says to use this tool to check the status of a run started by an Actor-running tool and explains when to use waitSecs. It does not explicitly name sibling alternatives or state when not to use this tool, so it falls short of full exclusion-based 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?

With annotations already declaring readOnlyHint=true and idempotentHint=true, the description adds valuable behavioral context: returns rows themselves, default limit of 20, and clean=true behavior. It also clarifies the nature of the return value beyond the 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?

Well-structured with clear USAGE and USAGE EXAMPLES sections. Some redundancy ('Get items (rows)...' and 'Returns the rows themselves...') but overall efficient and front-loaded with 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?

Given the tool has 8 parameters, an output schema, and rich annotations, the description adequately covers key behaviors, usage triggers, and examples. It doesn't explain every parameter but relies on the schema for that, which is appropriate.

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 baseline is 3. The description adds extra meaning by explaining default limit (20) and the clean=true shortcut, which supplements the schema. It also provides examples for fields usage, though most parameter semantics are in 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?

Description clearly states the tool gets items (rows) from a dataset and explicitly distinguishes it from metadata, counts, or schema. It names the exact resource (dataset items) and the action (get), and provides direct trigger phrases for when to use it.

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 use cases ('when the user provides a datasetId and asks to retrieve results...'), and clarifies what it is not for (metadata, counts, schema). However, it does not name alternative tools explicitly, only implies them.

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 readOnlyHint, idempotentHint, and destructiveHint as false. The description adds valuable behavioral context beyond this: the exact key name requirement and the preservation of Content-Encoding with automatic client decompression. No contradictions 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?

The description is well-structured with a concise opening definition, a short behavioral note, and clear usage examples. Every section earns its place without unnecessary fluff.

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 two-parameter read-only tool with full schema coverage, an output schema, and strong annotations, the description covers the essential context: how to target a record, what to expect (Content-Encoding), and when it applies. The sibling context also helps differentiate it from listing operations.

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?

Input schema coverage is 100%, so the schema already documents both parameters. The description adds usage examples and the 'exact key name' requirement, but these are minimally additive beyond the schema's own property descriptions.

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 uses a specific verb and resource: 'Get the value stored under a specific key in a key-value store.' It also distinguishes itself by explicitly stating this is 'a single record, not a listing of all keys,' which separates it from sibling tools like get-dataset-items.

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 a clear usage context: 'Use when you need to retrieve a specific record (JSON, text, or binary) from a store.' It does not name alternative tools explicitly, but the 'not a listing of all keys' phrase gives implicit exclusion guidance for listing-style operations.

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 says it 'calls the Actor' and retrieves its output, which communicates that this is not a pure read from an existing resource. Annotations also flag readOnlyHint=false and destructiveHint=true, so the side-effect profile is known. However, the description does not mention billing, long-running full sweeps, or snapshot dataset writes; the schema partially covers these, but the description itself stays high-level.

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 compact sentences with the operation and resource named first, followed by a concise output summary. There is no filler or redundant elaboration.

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 eight richly described parameters and an output schema present, the description does not need to enumerate return fields. It supplies enough domain context: actor rows, niche rows, demand signals, and intended usage patterns like search and monthly snapshots.

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

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

The input schema has 100% description coverage with rich parameter explanations, examples, and defaults, so the description does not need to repeat parameter semantics. The description adds useful output-shape context, but it does not meaningfully explain individual parameters beyond what the schema already provides.

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

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

The description clearly states that this tool calls the specific Actor 'perchpermits/apify-store-trends' and retrieves its output, then summarizes what the Actor reports: store niches, actor rows, niche rows, and A-G flags. It is specific enough to distinguish from generic run/dataset tools, though it does not explicitly name a sibling 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 explicitly gives two usage contexts: searching a niche in seconds or running a monthly catalog snapshot. This is clear guidance for when to invoke the tool, though it does not explicitly state when not to use it or name alternative sibling 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?

The description and parameter docs disclose substantial behavioral context beyond the annotations: billing implications ('charged as enriched-event', 'charged as ladder-analysis'), rate limits and 429 behavior, wait cap with nextStep polling, and dataset append persistence. This goes well beyond the readOnlyHint/destructiveHint annotations and contains no contradiction.

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 main description is only two sentences and front-loads the actor invocation and output summary. The longer parameter explanations are justified by the tool's complexity and all earn their 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?

Despite having 12 parameters and zero required ones, the description plus rich parameter docs cover invocation, output retrieval, billing, rate limiting, polling, and optional dataset persistence. The output schema exists, so restating return values is unnecessary.

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?

Although schema coverage is 100%, the descriptions add significant meaning: waitSecs explains polling and fire-and-forget behavior, enrich explains billing and when rows remain plain, status gives concrete use cases, and archiveDatasetName explains persistence without extra charge. This is far more than the baseline schema coverage would require.

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 identifies a specific action—calling the perchpermits/kalshi-weather-markets-nws Actor and retrieving its output—and enumerates exactly what the output contains (strike ladders, prices, implied probabilities, NWS observations, forecasts, climate reports). The Kalshi/NWS scope clearly differentiates it from the sibling Polymarket weather tool, even without naming it explicitly.

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

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

There is no explicit when-to-use versus when-not-to-use guidance and no mention of alternatives. The intended use case is implied by the output description, but the agent is not told why to prefer this tool over sibling options like the Polymarket weather markets tool or when this tool would be inappropriate.

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 declare readOnlyHint false, openWorldHint true, and destructiveHint true, covering safety. The description adds the note 'No CAD, no rendering, seconds per plan,' offering a performance expectation. It does not elaborate on side effects or authentication, but annotations already carry that burden, so a 3 is appropriate—the description adds some behavioral context but not much.

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 sentences plus the Actor description, which is concise and front-loaded with the Actor call and purpose. It avoids verbosity, though the first sentence could have been merged with the purpose, but overall it remains succinct and well-structured.

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 description gives output types (SVG, CSV, totals) but does not explain how to interpret results, handle errors, or cover edge cases. Given that an output schema exists and the input schema is well-documented, the tool is mostly complete, but some context about the Actor's limitations or prerequisites 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%; all parameters have detailed descriptions in the schema itself. The tool description adds nothing about parameters, so the baseline of 3 applies. The schema provides the full semantic weight for parameters like `spec`, `units`, `waitSecs`, and `validateOnly`.

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 the tool calls a specific Actor and then reproduces the Actor's purpose: turning a JSON room spec into an SVG floor plan, CSV cabinet takeoff, and quote-ready totals. The verb 'calls' and the concrete output types give clear intent. It doesn't explicitly differentiate from sibling tools, but the name and the Actor description make it obvious this is for kitchen floor plan takeoffs.

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 provided on when to use this tool versus alternatives. The description only says it calls an Actor and retrieves results, with no mention of conditions, prerequisites, or exclusions. For example, it doesn't say when not to use it or that it is specifically for kitchen plans rather than other plan types.

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 says 'retrieves its output results,' implying a read-only operation, while annotations declare readOnlyHint=false and destructiveHint=true. This is a direct contradiction; the description fails to disclose any destructive or side-effecting behavior, and actually undercuts the annotation.

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 sentences with no filler. The first sentence clearly states the action, and the second gives the actor's purpose. It is appropriately sized for the information it conveys.

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

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

Given the tool has 21 parameters, multiple modes (search/contractors), enrichment options, and a rich output schema, the description is too minimal. It fails to mention the two modes, the optional enrichment, or that it can rank contractors. The contradiction with annotations is a critical omission, making the overall context incomplete.

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 description adds no parameter-specific meaning beyond what the schema already provides; it simply names the actor. It does not compensate for any gaps, but none exist in 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 clearly states the tool calls the Actor 'perchpermits/nashville-building-permits' and retrieves its output, with a specific actor description of Nashville building permits data. It is specific about the verb and resource, but does not explicitly differentiate from sibling tools beyond the unique name.

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, no prerequisites, and no exclusions. The only extra hint is 'Pay per record,' which is not a usage guideline. Sibling tools are not mentioned.

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

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

Annotations already carry readOnlyHint=false, openWorldHint=true, and destructiveHint=true, so the safety profile is known. The description adds that the tool launches a remote Actor and retrieves results, plus useful data-source context ('Free official APIs only'), but it does not explain what the destructive hint means or what side effects the Actor run may have.

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 short and mostly information-dense. The first sentence is slightly generic but the Actor description earns its place by explaining the dataset's value. No significant fluff, though 'retrieves its output results' is somewhat redundant with 'calls the Actor.'

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

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

Given the tool is a complex Actor wrapper with 8 optional parameters and an output schema, the description conveys the dataset's meaning but omits operational context such as when to use it, how long runs may take, or how it relates to polling tools. The output schema covers return values, so the main gap is usage orientation.

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

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

The input schema has 100% description coverage, with each parameter already documented in detail, so the description does not need to compensate. The tool description adds no param-specific meaning beyond what the schema provides, matching the baseline of 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?

The description states a specific action—calls the named Actor and retrieves its output results—and the Actor description clarifies the exact data content (temperature ladders joined to settling airport stations). It is clearly distinct from generic sibling tools like get-actor-run or fetch-actor-details because it names the exact Actor and its dataset.

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 choose this tool over alternatives such as get-actor-run or fetch-actor-details, nor any exclusions or prerequisites. The only implicit usage signal is the Actor description, but there is no explicit when-to-use statement.

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 frames the operation as retrieval: 'calls the Actor ... and retrieves its output results,' while annotations mark readOnlyHint=false and destructiveHint=true. It also fails to disclose the paid run side effects, wait/poll behavior, or dataset-appending behavior implied by waitSecs and archiveDatasetName. This is an annotation contradiction.

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 sentences, front-loads the wrapper behavior, and packs the actor's value proposition into the second sentence without 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 16-parameter actor-invoking tool with an output schema, the overview plus cost is useful, but it omits the run lifecycle and side-effect context that would reconcile the description with its annotation flags and parameters like waitSecs and archiveDatasetName.

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 every parameter is already documented in the input schema. The description adds only high-level filter mentions and pricing, which does not materially exceed the schema's baseline.

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 identifies the exact Actor and, in the Actor description, names the resource and output: 'ATP and WTA matches for any day, live or finished... one JSON row per match.' This is a specific verb-resource pairing and clearly distinguishes it from sibling tools like the weather-market or store-trends tools.

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 clear context: 'Filter by tour, tournament, player' and states it is 'Built for betting models and AI agents.' It does not explicitly contrast against alternatives or say when not to use it, 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.