Good Turn Studio (all tools)

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, and the description confirms it 'never sends or files anything' – consistent, no contradiction. It adds the return shape (plain text with [brackets], checklist, tips), which is useful, but says nothing about authoritativeness, jurisdiction limits, or whether the letter is legally reviewed. With annotations carrying the safety profile, 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?

Three sentences, front-loaded with purpose then examples then return behavior, with no filler. The opening restates the title ('Draft an appeal letter for the user to review and send'), which is mild redundancy, but everything else earns its place.

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

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

There is no output schema, and the description compensates by describing what the letter, checklist, and tips contain and by clarifying the tool's non-action boundary. For a 14-parameter tool it is reasonably complete, though it does not mention that most parameters are optional or how missing fields degrade the draft.

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% across all 14 parameters, so the schema already documents each field, its enum values, and the reason/denial_code relationship. The description only alludes to placeholders for missing values ('anything not given') and adds no syntax or format detail 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?

States a specific verb ('Draft') and resource ('appeal letter') and immediately scopes it with example requests ('my insurer denied my MRI', 'out-of-network denial') that agents can pattern-match to user intent. It is clearly distinguishable from siblings like get_appeal_rights and explain_denial_code, which supply inputs rather than produce a letter.

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 two quoted example requests give concrete triggering conditions for when to invoke this tool, and the closing sentence establishes that it is for drafting only. It does not explicitly say when NOT to use it or point to a sibling for the underlying rights/deadline lookups, but the context is clear.

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 idempotentHint=true, so the safety profile is covered. The description adds genuine context beyond that: the tool returns plain-language meaning, the responsible party, billing liability derived from the group code, and a conditional letter link.

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 purpose well, but the first two sentences essentially restate the title and the second sentence duplicates the code examples already in the schema. The return-value sentence does the real work, so there is some avoidable 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?

With no output schema, the description carries the full burden and does describe the returned fields (meaning, fixer, billing liability, letter link). It is complete enough to call correctly, though it does not specify multi-code input behavior despite saying 'each code'.

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 goes further by explaining that the code's group prefix (CO, PR, OA, PI) drives the billing-liability output, which the schema's format examples do not convey, and it ties plan_type to get_appeal_rights semantics.

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 (explain) and resource (denial codes on an Explanation of Benefits), and the example utterances ('my EOB says CO-50', 'PR 204', 'N130') make the domain unmistakable. An agent can distinguish it from appealmyclaim_get_appeal_rights or draft_appeal_letter 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?

The quoted user requests give strong, concrete triggers for when to reach for this tool, and the mention of a letter link signals its relationship to the appeal flow. There is no explicit when-not or named alternative, so it stops short of the 5 benchmark.

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/idempotent/no-destructive, so the safety profile is covered. The description adds real behavioral context beyond the annotations: that supplying the denial date yields only an approximate file-by date, and that the user's own notice governs. It does not describe output shape, but as a read-only lookup that gap is minor.

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

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

Front-loaded with purpose, then example queries, then the accuracy caveat. Slight redundancy in restating the title 'Appeal My Claim. How long someone has to appeal...' before the examples, but every remaining sentence earns its place.

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

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

For a read-only, zero-required-parameter lookup with no output schema, the description covers what the caller gets (deadlines/decision windows), the role of denial_date, and a caution about accuracy. Only the literal return shape is unspecified, which is acceptable here.

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 all three parameters are already documented, including the urgent enum and plan_type's cross-reference. The description only loosely ties denial_date to 'the date on the denial notice' — no format or default guidance beyond the schema, so baseline 3 is appropriate.

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 pair ('how long someone has to appeal, and how fast the plan must decide') that clearly distinguishes it from sibling get_appeal_rights and draft_appeal_letter. An agent can pick it apart from the other appealmyclaim tools without opening 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?

Example user phrasings ('how long do I have to appeal?', 'when is my appeal due?', 'how fast does my insurer have to answer?') give clear triggering context, and it references get_appeal_rights for the plan_type value space. It stops short of stating when NOT to use this tool or what it does not cover.

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, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered; the description still adds value by disclosing what the call returns (decision-maker, appeal steps, deadlines, free help) and the default behavior when plan_type is omitted. No rate limits or data-freshness caveats are mentioned, but nothing is contradicted.

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, front-loaded with purpose, then trigger examples, then return contents, then the optional-parameter rule. The opening restatement of the display name is slightly redundant, but the rest is dense with useful information and free of filler.

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

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

With no output schema, the description correctly carries the job of enumerating what comes back (who decides, steps across appeal tracks, deadlines, free help including the state insurance department) and how to call it with zero required parameters. The only gap is that it never clarifies how it relates to the deadline-focused sibling, which an agent choosing between the two would want.

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, but the description adds real semantics on top: omitting plan_type yields the rules for most private plans, which reinforces and clarifies the schema's stated default. State is not elaborated beyond the schema, and both parameters are optional per 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 clear verb (get) plus the resource (appeal rights, steps and free help) scoped by plan type and state, and the example questions make the intent unmistakable. It does not, however, differentiate itself from the sibling appealmyclaim_get_appeal_deadlines, even though it lists deadlines among its own outputs, leaving a small routing ambiguity.

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 quoted example requests ("what are my appeal rights in California?", "my insurer denied my claim, what can I do?") give an agent concrete trigger conditions, and the closing note tells it what to do when plan type is unknown. There is no explicit statement of when NOT to use it or which sibling to prefer instead.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond that: the result is banded, respects a cap, and identifies who collects the royalty. It does not cover edge cases (e.g., non-UK resales or zero-price handling), 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?

The core content is compact and front-loaded, but the first two fragments ('Art Spotter - Eye of the Beholder.' and a restatement of the title) are brand boilerplate that repeat structured fields rather than adding information. The useful clause starts only at 'The royalty owed...'.

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 compensates by previewing the return shape (band, cap, collector). For a single-parameter, read-only calculation tool this is close to complete; only the US/non-UK scope boundary and any price-range constraints are left unstated.

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

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

Schema coverage is 100% and the single price parameter is already documented as 'Resale price in pounds'. The description adds no syntax, currency, or format detail beyond the schema, so baseline 3 applies.

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

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

The description names a specific domain concept (UK Artist's Resale Right) and states exactly what is produced: the royalty owed to an artist on a resale through a gallery, dealer or auction house, broken down by band with cap and collector. This is far more specific than a generic 'calculate royalty' and distinguishes it from artspotter siblings like get_fair_art_price or price_commission, though those siblings are never named.

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 implied by the UK-resale framing but there is no explicit statement of when to use this versus price_commission, get_fair_art_price, or compare_where_to_sell. An agent must infer the trigger condition from domain knowledge rather than being told.

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 read-only, idempotent, open-world, non-destructive behavior. The description adds behavioral value by disclosing what the checks cover, including reverse image search links and detection of stolen images, AI-disguised work, and payment scams. It still omits return format and any auth or rate-limit context.

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 purpose is front-loaded in the first two sentences. The third sentence is a long list but remains informative rather than repetitive. The only minor waste is the branded subtitle, which largely duplicates the title.

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 still communicates the kinds of results an agent would expect (reverse image search links and scam/stolen-image/AI checks). Annotations cover the safety profile, and parameters are fully documented, making the definition reasonably complete, though it could be more explicit about the output shape.

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 both parameters are already documented. The description mentions 'link' and 'picture' in prose, aligning with the url and image fields, but adds no syntax, format, or optionality detail beyond the schema. Baseline 3 is appropriate.

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: 'Check an art listing,' with clear scope ('before buying') and an enumeration of what gets checked (artist index vs marketplace, reverse image search, stolen images, AI work, payment scams). It distinguishes this tool from other Art Spotter tools implicitly through its listing-verification focus, though it does not explicitly name sibling alternatives.

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

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

It gives a clear usage context: use this before buying an artwork. However, it does not include exclusions, prerequisites, or explicit alternatives (e.g., verify_artwork_passport or search_art), so the routing guidance is not fully developed.

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, idempotentHint=true, openWorldHint=true and destructiveHint=false, so safety and idempotency are covered without the description. The description adds some value by stating it fetches an external file and returns a list of things to fix, but omits any auth requirements, failure modes (unreachable/invalid URL), or rate-limit 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?

Two sentences that are efficiently front-loaded on the core action and return behavior. The leading 'Art Spotter - Eye of the Beholder' branding duplicates the title and the app name, wasting a little space, but the rest earns its place.

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

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

For a one-parameter, read-only fetch tool with no output schema, the description covers what is read and that a fix-list is returned, which is adequate. It is short on the specifics an agent might want — what kind of issues get flagged, what happens on a malformed or unreachable file — so it is complete only to the minimum viable level.

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 single url parameter is already documented as 'The https address of the artworks.json file'. The description reinforces this by naming the canonical format location (artspotter.pages.dev/artworks), which is a marginal but real addition. Baseline 3 applies since the schema carries the semantic load.

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 clear verb+resource ('Check an artist's artworks.json') and elaborates that it reads the file and 'lists anything to fix', so the validation/lint purpose is unambiguous. It does not, however, distinguish itself from the sibling artspotter_check_art_listing or artspotter_verify_artwork_passport, so an agent gets no help choosing among the close-looking check/verify 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?

There is no explicit when-to-use guidance, no prerequisites (e.g. when an artworks.json exists vs. a passport or listing), and no mention of the alternatives it competes with. Usage is only implied by the nature of the tool, which is the bare minimum.

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 readOnly, idempotent, non-destructive and openWorld behavior, so the safety profile is covered. The description adds that results are ranked by money kept and that fee tables are region-limited (US/UK), but it says nothing about fee-table freshness, currency-to-table binding, or rate limits. Useful 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?

Two of the five sentences are brand/title restatement ('Art Spotter - Eye of the Beholder. What an artist keeps on each selling platform'), which delays the substantive scoping information. The remaining sentences carry real content, but the front-loading is wasted on framing.

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

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

With no output schema, the description does the work of describing the return implicitly: per-platform net-kept figures sorted by money kept. Combined with the safety annotations and full schema coverage, an agent has enough to call this correctly; only the exact response shape is not spelled out.

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 schema already documents all four parameters. The description implies that kind=print activates print-on-demand handling and that currency selects the applicable fee table, which is marginal added meaning over the schema. 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 names a specific computation (net proceeds after fees per selling platform) and its scope (price -> money kept, sorted, US/UK tables, POD option for prints). This clearly separates it from siblings like artspotter_get_fair_art_price or artspotter_calculate_resale_royalty. It stops short of explicitly naming those siblings 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?

Usage is implied by the phrasing 'For a sale price...', which tells the agent this is a per-price comparison query, but there is no explicit when-to-use vs when-to-use-an-alternative guidance. No prerequisites or exclusions are stated.

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, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is fully covered externally. The description adds what content categories are returned (UK arts council grants, Own Art 0% finance, ARR; US grants and group copyright), which is useful but offer no auth, rate-limit, or output-format context.

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 content is front-loaded and reasonably short, but the opening brand line and the title-restating sentence are redundant padding. The two country-specific sentences carry the real information.

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 optional-parameter, read-only lookup with no output schema, the description conveys the topic, country coverage, and concrete examples. Annotations cover safety, so the remaining gap (return format) is minor and not required to call the tool correctly.

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

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

Schema coverage is 100% with the country field documented as 'GB or US.', so a 3 would be the baseline. The description goes further by mapping each value to what it returns (UK institutions versus the US $85 group registration for 2-20 artworks), which genuinely helps the agent reason about the 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 names the specific resource (grants, buyer finance, royalties, copyright for artists) and scopes it to UK and US schemes, so an agent understands this retrieves funding/copyright information. The first two sentences largely restate the title verbatim, but the country-specific content adds distinguishing detail versus siblings like artspotter_calculate_resale_royalty.

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 statement, no exclusions, and no sibling alternative named, despite calculate_resale_royalty covering an adjacent topic. The country breakdown implies the parameter choice but not when this tool should be selected over alternatives.

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, openWorldHint and non-destructive, so the safety profile is covered. The description adds real behavioral context about the result: it returns typical price, the middle half of prices, and price per square inch, drawn from independent artists' shops and comparable works - which is consistent with openWorldHint=true and tells the agent what kind of estimate it gets.

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

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

Two sentences that are front-loaded with the purpose and then the output detail; the second sentence is list-shaped but every clause (typical price, middle half, price per square inch, source) earns its place. No redundant restatement of the 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?

There is no output schema, so the description carries the burden of describing the return values and does so well (typical price, interquartile range, per-square-inch). With 100% parameter coverage and full annotation coverage, nothing critical is missing for a read-only lookup 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%, so all six parameters (including the kind and unit enums and the original/print flag) are already documented in the schema. The description echoes 'size and medium' and 'original work or prints' but adds no format or default detail beyond what the schema provides, so baseline 3 applies.

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

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

The description states a specific resource (fair price for a new artwork) and the two dimensions it keys on (size and medium), and it explains what is being measured against (comparable works in independent artists' own shops). This clearly separates it from sibling pricing tools like price_commission or calculate_resale_royalty, though it does not name those siblings 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?

Usage is implied by 'fair price for a new artwork by size and medium' - an agent can infer this is for pricing a not-yet-sold work. However, there is no explicit when-to-use/when-not-to-use statement and no routing to the related siblings (price_commission, compare_where_to_sell, calculate_resale_royalty).

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 readOnly, idempotent, openWorld and non-destructive behavior, so the safety profile is covered. The description adds useful dataset scope: geography (UK/US/CA), recurring nature, and fields such as entry fees and usual closing month. It does not say what an unfiltered call returns or how large the result set is.

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 front-loads the domain, but the opening brand line 'Art Spotter - Eye of the Beholder' carries no operational meaning. The second sentence is a comma-spliced fragment listing data attributes rather than a structured statement.

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 list tool with no output schema, no required params and fully documented schema fields, the description covers the domain adequately. It omits what happens with no filters, whether results are paginated, and whether closing dates are current or typical, which an agent calling it would benefit from knowing.

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 kind, media and country are already documented in the schema. The description corroborates country (UK, US, CA) and media examples but adds no filtering syntax or default behavior beyond the schema. Baseline 3 is appropriate.

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 identifies the resource: recurring open calls, prizes, residencies and listing sites for artists in the UK, US and Canada. It is easy to distinguish from siblings like artspotter_search_art or artspotter_price_commission. It never uses an explicit verb such as 'list', relying on the tool name for that.

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 statement of when to use this tool versus alternatives, nor any prerequisites or exclusions. The filterable dimensions (kind, media, country) are only implied by the data description. An agent must infer the use case from the name 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, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: what is generated (a certificate with an image fingerprint), the output forms (printable text plus schema.org data), and the downstream purpose (tamper detection). It does not mention auth or rate limits, but with annotations carrying that load a 4 is fair.

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?

Essentially one dense sentence that leads with the artifact and its purpose, with no filler sentences. It is slightly redundant with the title ('Art Spotter - Eye of the Beholder. A free artwork passport for an artist's work'), which repeats the title and annotation text verbatim.

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 usefully compensates by naming both output forms (printable text and schema.org data) and the fingerprint mechanism. For a 7-parameter generation tool the picture is largely complete; only prerequisites and the exact certificate contents beyond the field list are left unspecified.

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

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

Schema description coverage is 100% and every parameter (including image, required) is documented in the schema itself. The description enumerates six of the seven fields, which mirrors rather than extends the schema, and it never clarifies the image URL requirement or edition/size formats. Baseline 3 is correct.

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: 'Makes a certificate for a work' with an explicit field list (title, artist, year, medium, size, edition) and the artifact produced (a fingerprint plus printable text and schema.org data). The closing clause about others later checking the picture is unchanged implicitly contrasts it with the sibling verify_artwork_passport, so an agent can separate create from verify.

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 implied by the framing ('an artist can publish'), and the mention that anyone can 'later check the picture is unchanged' hints at the verify sibling, but no explicit when-to-use, when-not-to-use, or named alternative is given. Adequate context, no routing 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 declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuine value by enumerating the response contents (deposit, revision rounds, cancellation fees, copyright, contract checklist), which tells the agent what the guide actually covers. No auth, rate-limit or freshness caveats are given.

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 purpose and sizing/level inputs are front-loaded in the first two sentences. The final sentence is an undifferentiated laundry list of covered topics, which is informative but slightly padded rather than tightly written.

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 all five parameters documented, the description usefully enumerates the expected return content so the agent knows what answers are possible. It is nearly complete for a read-only lookup tool, missing only selection guidance against the neighboring price tools.

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

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

Schema description coverage is 100% with clear enum and unit docs, so the schema carries the burden. The description only loosely echoes two parameters ('by size and the artist's level') without adding format or interaction detail beyond what the schema already states, so baseline 3 applies.

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

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

States a specific verb+resource ('a price guide for a commissioned piece by size and the artist's level') and the exact scope of what it returns. It is clearly distinct in topic from siblings like artspotter_get_fair_art_price or artspotter_calculate_resale_royalty, though it never names an alternative to differentiate 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?

Usage is implied by the content ('commissioning a piece'), so an agent can infer this is for pre-commission pricing queries. However, there is no explicit when-to-use trigger or when-not guidance, and no routing away from the similar-sounding get_fair_art_price sibling.

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 readOnly, openWorld, idempotent, non-destructive, so safety is covered. The description adds genuinely non-redundant behavior: that it reaches both independent-artist shops and eBay, and that results carry title, artist, size, price, shipping origin, image and a direct buy link. That return-content disclosure matters since there is no output schema.

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

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

Three sentences, front-loaded with what it does and the scope of the search, then the result contents. The branding repetition ('Art Spotter - Eye of the Beholder. Find art for sale from independent artists.') slightly duplicates the title, but there is no filler beyond that.

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 13-parameter, all-optional search tool with no output schema, the description adequately covers sources, filterable facets, and returned fields including buy links. It does not explain how multiple filters combine or what happens with zero results, and limit/default behavior is left to the schema, so a small gap remains.

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 one of the 13 parameters is already documented in the schema (including enum values for kind and unit). The description restates the facet list (words, kind, original or print, price, size, colour) without adding syntax, format, defaults, or interaction rules beyond the schema. Baseline 3 is appropriate.

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 (searches/find) plus resource (art for sale from independent artists) and even names the two corpora searched: independent artists' own shops and eBay. An agent can tell this apart from artspotter_check_art_listing or artspotter_get_fair_art_price, which are verification/pricing tools rather than discovery. Loses a point only because it doesn't explicitly contrast itself with a close sibling.

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 its use case (finding artwork to buy) and enumerates the facets you may search on, but never says when to use it versus alternatives or when not to. There are no stated prerequisites, exclusions, or routing hints to any of the 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?

With no output schema, the description carries the return-value burden and does disclose the derived outputs (art width, hanging height, gap above furniture, gallery wall spacing) plus a side effect of surfacing a search for works in that size range. Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so this adds genuine context beyond structured data.

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 purpose is front-loaded and there is no filler, but the opening two sentences largely restate the tool title and name, and the final sentence is a run-on list. It is adequate rather than tight.

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?

It covers what the tool computes and hints at returned search results, which is reasonable given no output schema. However it is silent on whether wall_width and furniture_width are mutually exclusive or combinable, and on how the 'ready search' behaves, leaving a gap for a zero-required-parameter 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%, so unit, wall_width and furniture_width are already fully documented with their conditional meaning. The description only echoes 'art width for the furniture or wall' without adding format, ranges, or guidance on supplying one vs. both parameters. 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 names a specific outcome (what size art fits a wall / how high to hang it) and enumerates the computed values (width, hanging height, gap above furniture, gallery spacing), which distinguishes it from siblings like artspotter_search_art or artspotter_get_fair_art_price. It is clear, though it never explicitly names which sibling it is not.

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 when-to-use guidance, no mention of prerequisites, and no routing to alternatives. The only implicit usage signal is the schema's distinction between wall_width and furniture_width, which lives in the schema, not the description.

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, openWorldHint and destructiveHint=false, covering the safety profile. The description adds one genuine behavioral detail: it recomputes the fingerprint rather than trusting a stored value. It does not discuss auth, rate limits, or failure modes (e.g. what happens when the image is unreachable).

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

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

Three short sentences, no filler, with the purpose stated first and the mechanism second. Every sentence earns its place.

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

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

For a two-parameter, no-output-schema read tool, the description covers the intent and the result semantics ('says whether it matches'), which substitutes for a missing output schema. It stops short of describing error or mismatch-handling behavior, but nothing essential 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%, so both parameters are documented in the schema itself. The description only loosely re-references 'the picture' and 'the fingerprint,' adding no format or syntax 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 (check) and resource (a picture against an artwork passport), and clarifies the mechanism (recomputes the fingerprint and compares it to the passport value). This clearly distinguishes it from the sibling artspotter_make_artwork_passport.

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 the use case (verifying a picture against an existing passport) but never states when to use this versus alternatives or what preconditions are needed (e.g. a passport must already exist from make_artwork_passport). Usage is inferable but not explicit.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds that output is delivered 'one line at a time' (implying the n parameter pages through lines) and is voice-oriented, which is modest but real context beyond 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?

Two short sentences, but the first is an exact duplicate of the title and the second is app-wide boilerplate covering readings, plans, search and passage lookup — content that has nothing to do with this specific tool. Useful signal ('one line at a time') is buried inside the 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?

With no output schema, the description must explain what is returned, and it never defines a 'card' or the per-line output shape an agent would receive when paging through n. For a tool whose whole purpose is line-by-line voice output, this leaves a meaningful 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?

Schema description coverage is 100%, so n, date, and reading are already fully documented in the schema; the baseline is 3. The description adds nothing about what a 'card' number means or how date/reading interact with daily defaults.

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 restates the title verbatim and adds only an app-level tagline ('Bible: daily readings, plans, search and passage lookup'). 'Today's reading one line at a time' hints at the resource and granularity, but the verb is never stated and the concept of a 'card' is left undefined. It does not distinguish this tool from bible_get_reading, bible_get_today, or bible_get_passage.

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 use this tool versus its many siblings (bible_get_reading, bible_get_today, bible_get_passage, bible_list_readings). The phrase 'for voice' faintly implies a use case but sets no condition or exclusion an agent could act on.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=true, covering the safety profile. The description only adds that the underlying translation is the World English Bible; it says nothing about return format, handling of invalid references, or output size. With annotations carrying the behavioral burden, 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?

Two short sentences with the passage-scope information front-loaded. The leading brand fragment 'Bible Swipe.' carries no operational meaning and is slightly wasteful, but overall the description is tight and adequately sized.

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-only retrieval tool with no output schema, the description is largely complete: it identifies the source text and the accepted reference formats. It could note error behavior for malformed references or what a returned passage looks like, but the essential information an agent needs to invoke it correctly 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% and the schema gives a simple example ('John 3:16'), so the baseline is 3. The description goes further by enumerating the supported reference forms (verse, range, chapter, cross-chapter) and giving the explicit cross-chapter syntax 'Genesis 1:1-2:3', which materially clarifies how to format the single `ref` 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 clearly states the resource (a passage of the World English Bible) and the granularities supported: any verse, range, chapter, or cross-chapter range. The verb is implicit ('get') but the intent is unambiguous. It does not differentiate from siblings like bible_get_reading or bible_search_readings, so it falls short of a 5.

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

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

There is no when-to-use guidance, no exclusion criteria, and no mention of alternatives such as bible_get_reading, bible_search_readings, or bible_get_card. The agent must infer usage entirely from the name and sibling list.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that — no indication of what 'line by line' means in the response, whether the plan variant paginates, or how much content is returned.

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?

Very short and front-loaded, but the space is spent restating the title and an app-level tagline rather than conveying tool-specific information. Structurally clean yet redundant, so no sentence earns much.

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 lookup tool with one parameter and no output schema, the description should clarify what is returned and how it differs from sibling retrieval tools (card, passage, today). It does neither, leaving the agent to guess which Bible retrieval tool fits a request.

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

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

Schema description coverage is 100% and the single 'id' parameter is already well documented in the schema (accepts a reading id from list_readings or a plan name like "japji"). The description adds no format or validity detail 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?

The description repeats the tool title verbatim ("One reading or plan, line by line") and then lists app-level features ("daily readings, plans, search and passage lookup") rather than stating what this specific tool does. It never names a verb+resource such as 'returns the text of a reading' and gives no basis for distinguishing it from bible_get_passage, bible_get_card, bible_get_today, or bible_list_readings.

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 when-to-use guidance, no condition distinguishing this from bible_get_passage/bible_get_today/bible_list_readings, and no mention of prerequisites. The only routing hint ('an id from list_readings') lives in the schema parameter description, not the tool description.

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, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds that the output is 'line by line' and mirrors the app's current display, which is mild extra context, but says nothing about return format, ordering, or what happens on an invalid date.

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?

Short and front-loaded, but the second sentence largely restates the product title and is filler for a zero-required-parameter read tool; it doesn't earn its place relative to the first sentence.

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 with no output schema, the definition covers the essentials: it returns today's reading split into lines. It is adequate but leaves the shape of the response (verse-level fields, ordering) unspecified, which an agent would need to infer.

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?

With a single optional parameter and schema description coverage at 100%, the schema already documents the date format and the UTC-today default. The description correctly adds nothing beyond that, so the baseline of 4 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 with scope: today's reading returned line by line. 'Same as the app shows today' pins the content source. It stops short of distinguishing itself from siblings like bible_get_reading or bible_list_readings, and the trailing 'Bible: daily readings, plans, search and passage lookup' sentence is a category blurb rather than a purpose statement.

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 choose this over bible_get_reading, bible_list_readings, or bible_get_passage, and no exclusions or prerequisites. The only contextual hint is that output matches what the app shows today, which is not a usage rule.

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, openWorldHint and destructiveHint=false, so the safety profile is fully covered structurally. The description adds nothing behavioral beyond that — no note on result size, ordering, or what 'curated' means, and the World English Bible mention is generic app context.

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?

It is short, but the first two fragments are redundant with the title, and the third sentence is unrelated app-level boilerplate that does not help invoke this specific tool.

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 parameters, no output schema, and annotations covering safety, the definition is nearly complete, but it never says what a caller receives (plan identifiers, reading lists, etc.), which is the one thing an agent would still need.

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

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

The tool takes zero parameters, so the baseline of 4 applies; there is no parameter meaning for the description to add or omit.

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 the resource ('all curated daily readings and plans') but uses no verb, so it reads as a restatement of the title rather than a statement of what the tool does (list? fetch?). It does not distinguish this tool from siblings like bible_search_readings, bible_get_reading, or bible_get_today, which an agent must choose between.

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 use this tool versus bible_search_readings, bible_get_reading, or bible_get_today. The trailing 'Bible: daily readings, plans, search and passage lookup' clause describes the whole app, not the selection condition for this tool.

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, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds two useful behavioral facts beyond that — results are ranked by relevance, and the corpus is the World English Bible translation. It still says nothing about result count, pagination, or empty-result 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 text is short, but two of its three fragments restate the title ("Bible Swipe" and "Search the curated readings, best match first" verbatim), so a third of the content is duplicated metadata rather than new information. It is front-loaded but not fully earned.

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-only search with full annotation coverage and no output schema, the definition is minimally sufficient — it states the corpus and ranking. It leaves gaps on what a "reading" is and how results are shaped, but the annotations shoulder most of the load.

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 ("q") with 100% schema description coverage, including worked examples ("forgiveness or shepherd"). The description contributes no additional query-syntax guidance, so the baseline of 3 is appropriate.

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 verb+resource pair ("Search the curated readings") is identifiable, and "best match first" signals ranked results. However, it never distinguishes this from bible_get_passage, bible_list_readings, or the many *_search_readings siblings, so an agent cannot tell which to pick. Purpose is legible but not differentiated.

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 when-to-use guidance at all — no statement of when to search versus call bible_get_passage or bible_list_readings. "Best match first" hints at ranking but says nothing about when this tool is the right choice.

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 safety (readOnly, openWorld, idempotent, non-destructive), yet the description adds substantial behavioral detail beyond them: result ordering (well-read 'shelf' picks first, then shared 'subjects'), one-per-author and one-per-series constraints, English-language and age-band scoping, and an explicit exclusion list (no self-help, textbooks, anthologies, study guides, category romance, explicit books). It also explains the picked_from/because fields, which the annotations do not.

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 intent is front-loaded (title repeats the name, then the two use cases) and every following sentence carries substantive ranking or filtering information. It is somewhat dense and the 'picked_from' jargon is unexplained, but there is little filler to cut.

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

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

With no output schema, the description carries the return-value burden and largely does so, explaining suggestion contents, ordering, and the picked_from/because fields. Minor gaps remain, such as what country does to shop links and any result-count or pagination behavior, so it is not fully exhaustive.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: 'common other titles work (1984, The Sorcerer's Stone)' clarifies title-matching tolerance, and it explains the interaction between title/author/same_author that the schema only hints at. It does not add much beyond the schema for country, keeping it just above 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 names the exact job: return books similar to one the user enjoyed or matching a genre, with concrete request phrasings ('books like The Martian', 'a good cosy mystery'). It implicitly distinguishes itself from the sibling get_author_books by stating that other books by the same author are excluded unless same_author=true. An agent can route between 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?

It gives clear trigger examples and states when same-author results appear (same_author=true) and what input to supply ('Give title or subject; common other titles work'). It stops short of explicitly naming the sibling tools (get_author_books, get_book) as alternatives, so the routing is inferred rather than spelled out. Clear context but no explicit exclusions naming a competitor tool.

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, openWorldHint, and destructiveHint=false, so the safety profile is fully covered structurally. The description adds one genuine behavioral fact beyond that – results are ordered newest first – but says nothing about result limits, pagination, or whether a partial author name is tolerated.

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

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

Three short fragments, front-loaded with the operation and its ordering rule. The opening 'Books Like This' merely restates the tool title and is dead weight, but nothing else is wasted.

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 tool with full schema coverage and complete annotations, the description is close to sufficient, and the absence of an output schema means return values need not be explained. It still omits any hint of result size, buy-link behavior, or fallback when an author name is ambiguous.

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 the meaning of 'author' and the country enum values for buy links, so the schema carries the parameter burden. The description adds no syntax, format, or disambiguation guidance beyond what the schema already states, which is the baseline for full coverage.

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+resource combination (retrieving an author's books) and adds a scope detail ('newest first'). It does not, however, explicitly distinguish itself from siblings like bookslikethis_get_book (single book) or bookslikethis_find_similar_books, so an agent must infer the boundary from the resource alone.

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?

Concrete trigger phrasings ('what has Andy Weir written?', 'Sally Rooney's books') make the intended entry point obvious and map cleanly onto author-name lookups. There is no explicit exclusion or guidance on when to prefer bookslikethis_get_book or find_similar_books instead.

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 readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: "Misspellings are fine" (input tolerance) and the screen_checked=false caveat that film/TV status may be unavailable, which the agent cannot infer from structured fields.

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 opening two sentences ("Books Like This. A book's details and any film or series made from it.") essentially duplicate the name and title fields, which is wasted space. The example requests and the screen_checked caveat are well-placed and front-load value, but the redundant lead-in dilutes 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 simple read-only lookup with one required parameter and no output schema, the description is nearly complete: it covers purpose, adaptation lookup, misspelling tolerance, and the degraded film/TV case. It stops short of describing what 'details' the response contains, which an agent might want with no output schema 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 description coverage is 100%, so title, author, and country are all fully documented in the schema (including the country enum values and the 'add author for short/common titles' hint). The description adds no parameter meaning beyond what the schema already provides, 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+resource: retrieves a book's details plus any film or series adaptation, which is a clear, non-tautological purpose. It does not, however, name or distinguish itself from the sibling tools bookslikethis_find_similar_books and bookslikethis_get_author_books, so an agent gets no explicit routing signal.

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 example requests ("tell me about Project Hail Mary", "is The Name of the Wind being made into a film?", "how long is Dune?") clearly map user intents onto this tool and give strong contextual guidance. There is no explicit statement of when NOT to use it or which sibling to prefer for other book queries.

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 readOnly/idempotent/non-destructive, so the bar is lower, and the description adds real value beyond them: the return format (.ics), the exact event contents and alert timing, and 'Nothing is stored' (no persistence). It doesn't cover rate limits or formatting quirks, but adds substantive behavioral context.

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

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

Front-loaded with the purpose and then details the return artifact without padding. The final sentence about get_cancel_steps is slightly tangential to this tool's own invocation but earns its place as routing context.

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 the return value and does so thoroughly (event contents, alerts, no storage). An agent has enough to invoke correctly; only explicit exclusions for when not to call it are 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%, so the schema already documents country, service, and renews_on; baseline is 3. The description references renews_on's role indirectly but adds no format or semantic detail beyond what the schema supplies.

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 (get/returns) and resource (calendar reminder for the last safe day to cancel) and describes the concrete artifact returned: an .ics all-day event with steps, official link, and 9am alerts. It is distinguishable from the sibling get_cancel_steps, which yields a link, not a calendar file.

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 usable context by noting get_cancel_steps surfaces this link as add_to_calendar whenever renews_on is provided and the day hasn't passed, effectively describing the condition under which this tool applies. It stops short of an explicit when-not-to-use statement, so no code-5 routing 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 declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that: it enumerates the return contents (official page, steps, catches, cheaper option) and discloses the UK-region special-casing and the 'US only' edge case.

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 purpose, then examples, then return shape and regional handling. It is slightly long due to six sample queries, but each sentence is informative and nothing is padded with boilerplate.

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, no-output-schema tool the description is sufficiently complete: it explains what is returned, how country affects the answer, and the required service name. It does not spell out pagination or error behavior, but those are not material for this lookup.

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 each of the three params is well documented in the schema (including the renews_on-derived cancel_by and add_to_calendar). The description only marginally adds meaning, mainly the 'US only' cross-border nuance, so the baseline 3 for high-coverage schemas is appropriate.

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: telling the user how to cancel one subscription, and the example queries (cancel Netflix, leave Sky, stop Audible) pin down the domain sharply. The word 'one subscription' subtly distinguishes it from cancelmysub_list_services, but no sibling is named, so the differentiation is left to inference.

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 six natural-language example requests make the intended trigger conditions very clear. However, there is no explicit when-not guidance and no mention of the alternative siblings (get_cancel_reminder, identify_charge, list_services), so an agent must infer the boundaries.

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 readOnly/idempotent/openWorld and non-destructive, so safety is covered. The description adds genuine behavioral value by disclosing output shape: a likely service, a short candidate list plus where-to-check for Apple/Amazon/Google/Microsoft, or a 'match: purchase' verdict for one-off orders.

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

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

Front-loaded with the key task, but the opening two sentences ("Cancel My Sub. Which subscription is this charge?") merely restate the title, and the clause describing the Apple/Amazon/Google/Microsoft candidate case is grammatically tangled. Some of the length is redundant rather than earned.

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 usefully covers return behavior and the chaining step, which is adequate for a single-input read tool. The one gap is the no-match case, which is never addressed.

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

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

Schema coverage is 100% and the schema already describes the single 'text' parameter with its 120-character limit. The description goes beyond that by showing the exact form of real statement strings, which materially helps an agent format the input.

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 identifies which subscription a statement charge belongs to. The concrete examples ("APPLE.COM/BILL", "AMZN Digital", "DD *DOORDASH DASHPASS") let an agent recognize the intended task instantly, and the relationship to sibling get_cancel_steps as a follow-up is clear.

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 clear trigger context via sample user requests and names the downstream step ("Then call get_cancel_steps"). However, it never states when NOT to use it versus cancelmysub_list_services or cancelmysub_get_cancel_reminder, so alternatives are only implied.

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 readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuine behavioral context beyond that: it discloses that the response also includes the current FTC click-to-cancel rule status and UK rules (uk_rules), which is not derivable from the annotations or 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?

The opening two fragments ('Cancel My Sub. Every subscription Cancel My Sub covers.') largely duplicate the title, which is wasted space. The example queries and the FTC/UK rule note earn their place, and the useful content is reasonably front-loaded despite the redundant lead.

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, parameterless-required listing tool with no output schema, the description is nearly sufficient: it explains what is returned (covered services plus FTC/UK rule status) and gives trigger examples. It slightly lacks clarity on how results are organized by country/category, but the schema covers those inputs.

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

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

Schema coverage is 100%, and both the country and category parameters are fully documented in the schema (including the GB/UK and default-country behavior). The description adds no additional parameter meaning, 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 the resource covered (every subscription Cancel My Sub covers) and effectively communicates that this is a listing/lookup tool for supported services. However, it never uses an explicit verb like 'list' and does not distinguish itself from siblings such as cancelmysub_get_cancel_steps or cancelmysub_identify_charge, resting partly on a restatement of the title.

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?

Two concrete example user queries ('which subscriptions can you help me cancel?', 'what gyms do you know?') give implied usage context. There is no explicit when-not guidance and no reference to the sibling tools, so an agent must infer that this is the discovery entry point versus the step/reminder 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 declare readOnly=true, openWorld=true, idempotent=true, destructive=false, so the safety profile is covered. The description adds some value by stating prices are checked live, reflect the shopper's own country and currency, and aggregate specific sources — but says nothing about latency, rate limits, or return shape.

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?

It is short and front-loaded, but wastes space: 'Cheapest Price' duplicates the title, and 'lowest current price for a product' is stated twice across the two sentences. The source list is the only accretive 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, so the description carries some burden for describing what is returned; it names sources but not the response structure (e.g. price format, link fields). For a simple 3-param read tool with full annotations the coverage is adequate but not thorough.

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 schema already documents q, used, and country (including the enum list and the 'leave out to use shopper's location' note). The description marginally reinforces the country/currency behavior but adds no syntax or logic beyond the schema. 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+resource: it returns the lowest current price for a product and names the sources (eBay, Best Buy US, Amazon, local shops). Clear and unambiguous, though it does not differentiate from any named alternative tool (siblings are all in unrelated domains, so this omission is minor).

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

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

Usage is only implied — an agent looking to check a product's price would infer this tool fits. There is no explicit when-to-use, when-not-to-use, or reference to an alternative (e.g. a price-drop or bill tool), and no prerequisites are stated.

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 the safe, idempotent, open-world read profile. The description adds genuine context beyond them: the data source (city trip records), that NYC figures are typical Uber/Lyft prices while other cities reflect taxi meter rates, and the hourly granularity plus 'whether waiting saves money'. It does not mention rate limits, caching, or data freshness, keeping it 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?

The opening 'Fair Fare.' is wasted and the second sentence simply repeats the title verbatim, delaying the substantive content. The remaining two sentences are dense and informative, but the front-loading wastes the most prominent position on brand/title 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?

With no output schema, the description does the heavy lifting by explaining what is returned: typical hourly prices, the cheapest and most expensive hours today, and whether waiting saves money. Together with annotations and fully documented optional params, this is near-complete, though it omits any note on data recency or result format.

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 schema already documents city, when, and miles (including the NY-only restriction on miles). The description restates the NYC-only nature of 'miles' but adds no syntax, format, or default detail beyond the schema, 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 concrete purpose ('Cheapest time of day to take a ride') and clarifies the different outputs for New York versus other cities, making the tool's role distinct from fare-estimation siblings. It does not explicitly name or contrast itself with siblings like fairfare_estimate_fare or fairfare_get_taxi_tariff, so it falls short of a 5.

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

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

Usage is only implied: the agent can infer it should call this when seeking the cheapest hour to ride. There is no explicit when-to-use/when-not guidance and no mention of alternative tools (e.g. estimate_fare for a specific fare), leaving routing 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 read-only, idempotent, non-destructive, open-world. The description adds real value beyond them: the data source (NYC daily open data), what fields are returned (active status, expiry), and the non-obvious privacy detail that the licence holder's name is never returned even when matched.

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 purpose and the returnable facts in dense but readable sentences. The trailing sentence 'Other cities get the official way to check' is a bit vague but still earns its place as routing guidance.

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 describing returns and does so (active status, expiry, name-match result). A little more on the non-NYC guidance path would fully close the 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?

Schema coverage is 100%, so 3 is the baseline, but the description adds semantics beyond the schema by clarifying that the name argument is verified for a match and that the matched name is never echoed back, and by confirming city defaults to nyc for a live check.

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 (check) and resource (a New York taxi or ride-app driver's licence) with scope qualifiers (TLC number, NYC open data). It is clearly distinguishable from siblings like fairfare_check_fare or fairfare_check_fleet_file.

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?

Explains that the tool does a live NYC check when city=nyc and returns guidance for other cities, plus the conditional behavior when a name is supplied. It doesn't explicitly name a sibling alternative, but the usage context is clear.

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 openWorldHint, so safety is covered. The description adds genuinely useful behavioral context by disclosing the output contents (verdict, next steps, and a refund message). It says nothing about prerequisites such as needing either from/to or miles plus a city, which matters for an 8-param tool.

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 purpose is front-loaded in the first two sentences and the return contents follow efficiently. The opening 'Fair Fare. Was I overcharged?' partially duplicates the title, which is the only minor waste.

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 correctly compensates by describing what comes back: a verdict, next steps for the regulator, and a refund message. Combined with 100% schema coverage this is close to complete, missing only an explicit note on required input combinations.

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 mentions the tariff/airport/Uber comparison but adds no syntax, defaults, or format details beyond what the schema provides, so baseline 3 applies.

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

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

The description states a specific verb and resource ('check a fare that was paid') and spells out the comparison basis (official meter tariff, airport flat fare, or typical Uber/Lyft prices). It is clear the agent is analyzing a past trip, not estimating a future one. It does not, however, name or rule out the sibling fairfare_estimate_fare, so differentiation is inferred from the name rather than stated.

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 implied by 'Was I overcharged?' and 'Check a fare that was paid', which signals the retrospective-dispute scenario. There is no explicit when-not guidance and no reference to alternatives such as estimate_fare for prospective trips, leaving the agent to infer the boundary.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so safety and network behavior are covered. The description adds that the result is a list of things to fix, but does not disclose output format, pagination, or failure modes. With annotations carrying the safety profile, this is an acceptable 3.

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 content is front-loaded and understandable, but it opens with a bare 'Fair Fare.' brand token and then restates the title ('Check a cab firm's fleet.json') before reaching the substantive clause. Those opening fragments consume space without adding meaning, so it is efficient but not tight.

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, non-destructive read tool with full annotation coverage and no output schema, the description supplies enough context: what fleet.json is, where the format lives, and that the tool returns a list of issues to fix. The only gap is not describing the output structure more concretely.

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 url parameter whose meaning is already documented. The description reinforces the context (the open fleet.json format at fairfare.pages.dev/fleet) but adds no syntax or format detail beyond the schema. Baseline 3 is appropriate when 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?

The description names a specific verb and resource ('Check a cab firm's fleet.json') and adds what the operation does ('reads... and lists anything to fix'). This distinguishes it from siblings like fairfare_check_driver_licence or fairfare_estimate_fare, which operate on different resources. The separate title repeats the same wording, so the added value beyond the structured fields is modest.

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 explains that this validates a firm's fleet.json, implying it is used to verify a fleet file, but offers no explicit when-to-use vs alternatives or prerequisites. It never states an exclusion or points to a sibling for a different task. Usage is implied rather than guided.

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, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description does add useful scope context — 'typical Uber and Lyft prices in New York' signals an estimate rather than a live quote and a NYC-centric coverage — plus that the result carries actionable links. It stops short of stating latency, freshness, or geographic limits outside NY beyond the one reference.

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?

It is a single sprawling sentence built from a long comma list of outputs, with no front-loaded statement of the action. It is not padded with filler, but the structure buries the tool's core function behind an inventory of return values.

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, enumerating what comes back (distance, time, meter fare, flat fares, Uber/Lyft estimates, links) is genuinely useful. However, for a 4-parameter open-world tool it omits the selection context versus fairfare_check_fare and any note on accuracy or coverage limits, so it is only adequate.

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 from/to/city/when are fully documented in the schema and the baseline is 3. The description adds at most a faint signal for 'when' via 'the extras that apply at that hour', and nothing for city or the accepted place formats.

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 title and opening frame the tool as 'what a trip should cost by taxi, Uber or Lyft', but the description body is a comma-run of return contents rather than a stated action ('estimates the fare between two places'). It also never distinguishes itself from the very similar sibling fairfare_check_fare, leaving the agent to guess which to call.

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 when-to-use guidance at all: no mention of fairfare_check_fare, fairfare_best_time_to_ride, or fairfare_get_taxi_tariff as alternatives, and no statement of when this estimator is the right choice over tariff lookup. The only implicit cue is that inputs are two places.

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, openWorldHint and destructiveHint=false, so the safety and mutation profile is fully covered by structured data. The description adds no behavioral context beyond that — no staleness, coverage, or rate-limit notes — only a content inventory, so it is a baseline 3.

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 front-loaded sentence with a dense, useful topic list and no filler paragraphs. The opening fragments 'Fair Fare.' and 'Getting a ride at an airport.' restate the name and title, which is minor redundancy rather than bloat.

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 only one required parameter, full schema coverage, and no output schema, the description's topic inventory usefully previews what the agent gets back for a given airport. Given the annotations already cover the read-only profile, nothing essential to invoking it correctly is missing.

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

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

Schema description coverage is 100% for the single 'code' parameter, including examples (JFK, LAX, LHR, Heathrow), so the schema carries the semantics. The description adds nothing about the code argument, which is the correct baseline of 3 when 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?

The description states a recognizable purpose (airport ground-transport guidance) and enumerates concrete topics — Uber/Lyft pickup, taxi rank, flat fares, drop-off charges, meet-and-greet, public transport with prices — which lets an agent distinguish it from fare-estimate or tariff siblings. The verb is implicit (it retrieves rather than computes), and it never names a sibling tool, so it stops short of a 5.

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

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

There is no when-to-use guidance and no routing to alternatives such as fairfare_get_taxi_tariff, fairfare_estimate_fare, or fairfare_best_time_to_ride. The agent must infer from topic hints alone whether this or a neighboring tool is correct.

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, openWorldHint and destructiveHint=false, so safety behavior is covered. The description adds useful context about what a tariff record contains (surcharges, flat fares, tipping custom, source attribution), but says nothing about coverage limits, rate limits, or freshness of the official source.

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

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

A single front-loaded sentence naming the resource, followed by a readable enumeration of returned fields. The list is long but each item is a distinct piece of tariff data, so little waste.

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's enumeration of tariff components (starting charge, per-mile rate, waiting rate, time-of-day tariffs, extras, flat fares, tipping) effectively documents the return shape. What remains missing is differentiation from sibling fare tools.

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

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

Schema coverage is 100% and the single city parameter is fully documented in the schema, including the list_cities reference and examples. The description adds nothing about the parameter, 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 names a specific resource (a city's official taxi meter tariff) and enumerates its contents, so the agent knows exactly what data comes back. It does not, however, distinguish this from close siblings like fairfare_check_fare or fairfare_estimate_fare, which also concern taxi pricing.

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 when-to-use guidance, no mention of prerequisites beyond the schema's pointer to list_cities, and no routing to alternatives such as estimate_fare or check_fare. The agent must infer the distinction between 'look up the tariff' and 'check/estimate a fare' on its own.

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, openWorldHint and destructiveHint=false, covering the safety and repeat-call profile. The description adds only a scope trait (results are limited to cities with a filed tariff and airports with ground transport facts) — no pagination, ordering, or rate-limit context, so it adds modest value above 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?

Two short sentences, front-loaded with the subject, and no filler. It loses a point because the opening 'Fair Fare. Cities and airports covered.' merely restates the name and title verbatim before the one sentence that carries new information.

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 no-parameter listing tool with no output schema, the description should at least characterize the returned shape or how to use the results. It conveys scope of coverage but not the form of the response or a next step (e.g., feed a city into check_fare), leaving the agent to infer the rest.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; per the rubric this is a baseline 4. The description's mention of what the list contains is scope, not parameter meaning.

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 the resource (cities and airports) and, via the tool name plus 'covered', the list action, so an agent can tell this is a coverage-enumeration endpoint. The third sentence sharpens scope (only cities with an official taxi tariff on file, only airports with ground transport facts). It does not, however, distinguish itself from fairfare_get_taxi_tariff or fairfare_get_airport beyond the plural/listing framing.

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

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

Usage is only implied: by describing this as the set of cities and airports 'on file', it hints that this is a discovery call to see what data exists, but it never says when to call it (e.g., before check_fare/estimate_fare) or when not to. No alternative sibling is named, and no conditions are given.

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, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuinely useful behavior the annotations cannot convey: fares are cached 'cheapest found in the last 48 hours' and the live price only appears on the booking page, so the agent knows the returned prices are stale and non-binding.

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 core statement is front-loaded, but 'Cheap flights from any city, to one place or anywhere, with the cheapest days to fly' largely restates the title and opening sentence, and the 'Fare Deals.' brand prefix adds nothing. Roughly half the text is redundant marketing copy.

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

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

With no output schema, the description does useful work by telling the agent what the data represents (cheapest days in a month) and that pricing is a 48-hour cached estimate rather than a live quote. The remaining gap is the shape of the returned day/price list, which is minor for a simple lookup.

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 schema already documents 'from', 'to', 'month' and 'country' including the month format and currency semantics. The description adds no parameter-level meaning beyond that, 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 resource and scope: 'Cheapest departure days for a route in a month', which an agent can act on. It does not, however, differentiate itself from its sibling faredeals_find_deals, so an agent choosing between the two gets no help.

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 when-to-use guidance, no mention of the sibling faredeals_find_deals, and no prerequisites. The phrase 'from any city, to one place or anywhere' gestures at flexibility but doesn't tell the agent when this tool is the right pick over other fare 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 cover safety (readOnly, idempotent, openWorld, non-destructive), so the bar is lower. The description adds that fares are 'recent' (freshness hint) and references an undocumented 'say' output field, which is genuinely useful since no output schema exists — but it never explains what 'say' contains or how results are shaped.

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?

Short and front-loaded, but the opening 'Fare Deals.' merely restates the tool name and earns nothing, and the closing 'The say field is a ready-made answer' is cryptic rather than informative.

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 search tool with a fully documented schema, the core is adequate. However, with no output schema, the description should explain the 'say' field it advertises, and it offers no routing against its faredeals siblings.

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 all nine parameters are already documented in the schema with examples. The description adds no parameter meaning beyond that, which is the baseline 3 when 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?

States a specific resource and scope: cheapest recent fares from a city to a place or anywhere. That is clear enough to distinguish the tool's function, but it does nothing to separate it from the sibling faredeals_cheapest_dates, which plausibly overlaps.

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 when-to-use guidance, no conditions, and no mention of the sibling tools faredeals_cheapest_dates or faredeals_look_up_place. The agent must infer routing entirely on its own.

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, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuinely useful context beyond that: fares are the cheapest found in the last 48 hours (data freshness) and the live price lives on the booking page (data currency caveat). This is real behavioral disclosure, not repetition.

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 redundant 'Fare Deals.' lead restates the app name and title, and the middle sentences are promotional ('Cheap flights from any city, to one place or anywhere'). The valuable freshness/caveat sentences are buried at the end rather than front-loaded.

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 should describe what a lookup returns (resolved airport/city codes and names), which it never does. The data-freshness note partially compensates, but an agent cannot predict the return shape.

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 'q' parameter is documented with an example (Lisbon or LIS), so the schema carries the load. The description's 'from any city, to one place or anywhere' hints at scope but adds no format or resolution detail beyond the schema; 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+resource pair ('Look up a city or airport code') that an agent can act on. However it does not differentiate itself from the sibling faredeals_find_deals and faredeals_cheapest_dates, and the trailing 'Cheap flights from any city... cheapest days to fly' language describes deal searching rather than a code lookup, muddying the purpose.

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 when-to-use guidance and no mention of the sibling tools (find_deals, cheapest_dates) that an agent would need to disambiguate fare-search behavior. The agent must infer this is a resolver/lookup step from the title 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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds that omitting type returns every source, which is a useful default, but that fact is largely already implied by the schema's "or all" enum value. Little additional behavioral context is offered.

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 core purpose is front-loaded in the first two sentences, followed by a compact list of motivating queries. The example list is long but each item earns its place by mapping a real user phrasing to the tool. Slightly repetitive of the schema's alias list.

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 lookup with two optional params, full annotations, and no output schema, the description is largely sufficient: it states purpose, examples, and default behavior. It stops short of describing the shape of the returned source list, which an agent might want when chaining results.

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 both parameters are already well documented in the schema, including the alias words and the country default behavior. The description's examples restate that same information rather than adding syntax or format meaning. Baseline 3 is appropriate.

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 gives a concrete verb+resource: it returns "Federal and other official places to look, by type", which tells an agent exactly what comes back. The example queries make the resource even more tangible. It does not, however, mention its sibling findmymoney_get_state_search, so an agent must infer the boundary between the two.

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 demonstrated through a rich set of example requests ("how do I find an old 401k?", "unclaimed tax refund", "my mum died, did she leave money..."), which is strong when-to-use guidance. The fallback behavior "Without a type, returns every source" is stated. There is no explicit when-not-use or named alternative routing, keeping it out of 5 territory.

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 read-only, idempotent, non-destructive, open-world behavior. Beyond that, the description discloses the return shape (official state link, direct search_url, MissingMoney.com, tips, claim checklist, scam warning) and the multi-state layout rule ('first at top level, rest in more_states') – value the annotations cannot convey, especially with no output schema.

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

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

Front-loads the identity ('Find My Money. A state's official unclaimed property search.'), then usage examples, then return contents. Efficient overall, though the four example phrasings are somewhat redundant and could be trimmed without loss.

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 describing returns and does so (link, search_url, MissingMoney.com, tips, checklist, scam warning). It also handles the multi-state edge case, so an agent can call it correctly and interpret the response.

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 schema already documents both 'state' (accepted formats, comma/'and' lists up to 8, big city names) and 'country' (GB/UK behavior, default). The description's multi-state sentence describes result layout rather than parameter syntax, so it adds little beyond the schema. 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+resource: 'A state's official unclaimed property search,' with the leading 'Find My Money' branding. An agent immediately knows this retrieves official unclaimed-money search links for a given state. It does not explicitly distinguish itself from the sibling findmymoney_get_sources, so it stops short of a 5.

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

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

Four worked example queries ('do I have unclaimed money in Ohio?', UK money owed, Texas unclaimed property, multi-state 'where do I look?') give clear, concrete context for when to invoke it. No explicit exclusions or named alternative tools, but the trigger conditions are 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 declare read-only, idempotent, open-world, non-destructive behavior, so the safety profile is covered. The description adds real value beyond that: it enumerates the returned stats and scopes the tool explicitly ('Stats only, not betting advice'), which prevents an agent from misusing it as a prediction/advice source.

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

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

Three short sentences, front-loaded with the purpose, then an example, then the output/scope. The leading 'Form Guide.' is slightly redundant with the title but the rest earns its place with no 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?

There is no output schema, and the description compensates by listing the fields returned and clarifying scope. With a fully documented 5-parameter schema and full annotation coverage, the only missing piece is explicit routing among the other formguide_* tools.

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

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

Schema description coverage is 100%, and each parameter (home, away, team1, team2, country) is documented in the schema itself, including the legacy-alias behavior of team1/team2 and the country effect on US Eastern times. The description adds no parameter-level meaning beyond this, 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 (compare) and resource (two clubs), and enumerates the output ('positions, form, goals, this season's meeting and the next date they play'). It implicitly contrasts with formguide_get_team by emphasizing 'two clubs side by side', but never names that sibling, so an agent must infer the boundary rather than read 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 a concrete trigger utterance ('Arsenal v Leeds, how do they compare?') plus a temporal cue ('before they meet'), which gives clear context for when to reach for this tool. It stops short of stating when NOT to use it or which sibling handles single-team or table queries instead.

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 readOnly, idempotent, non-destructive and openWorld, so safety is covered. The description adds genuine operational context beyond that: the default league when no filter is given and the international-break behaviour (next fixtures returned regardless of the window).

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

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

Three short sentences, front-loaded with purpose, then example queries, then the default-scope rule. No filler and nothing buried.

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, zero-required-parameter query tool with no output schema, the description covers defaults, edge cases and timezone behaviour adequately. It stops short of describing the shape of what comes back, which is the only remaining 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?

Schema coverage is 100%, so the baseline is 3, but the description adds one fact the schema does not carry: the implicit Premier League default when both team and league are omitted. Its other statements (404 on unknown league, US/CA kick-off times) duplicate schema text, limiting the lift.

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 (upcoming fixtures) and explicitly bounds the scope to a club or a league, which separates it cleanly from formguide_get_results (past results) and formguide_get_table. An agent can route to it 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 concrete trigger phrasing ("who do Liverpool play next?", "what's on in La Liga this weekend?") and states the fallback scope when neither team nor league is supplied. It does not explicitly name a sibling alternative (e.g. get_results for completed matches), 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.

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorld, so the safety profile is fully covered. The description adds one genuinely useful behavioral fact not in structured data — that omitting both team and league defaults to the Premier League — but says nothing about return format or the 404 behavior hinted at in 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?

Front-loaded with the core purpose, then example queries, then the default — logical ordering with little waste. The leading 'Form Guide.' fragment is slightly redundant with the title but functions as a fast domain signal.

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 tool with no output schema, full parameter documentation, and safety annotations, the description covers purpose, triggers, and the default fallback adequately. The only omissions are return shape and error handling, which are minor for this tool's complexity.

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

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

Schema coverage is 100% and each parameter already carries a clear description (range for 'n', example club names, allowed league list). The prose adds no syntax, formatting, or precedence detail beyond what the schema supplies, 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+resource ('Latest results for a club, or the last round of a league') and the example queries pin down intent precisely. It implies but never explicitly distinguishes itself from siblings like formguide_get_fixtures or formguide_get_table, so an agent must infer that this is past results rather than upcoming or standings.

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

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

Gives concrete trigger phrasing ('how did Chelsea get on?', 'what were the Serie A results?') and documents the no-argument fallback to the Premier League. It stops short of naming alternative siblings or stating when NOT to use it, so no exclusions are provided.

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 non-destructive behavior. The description adds useful non-obvious context that points include official deductions and that a deducted club's row carries points_deducted, which is behavioral detail beyond the structured fields.

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 very short, front-loaded, and contains no filler. Every phrase contributes either the resource, example usage, or a non-obvious data rule.

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 low-complexity read-only tool with full input schema coverage and annotations covering safety, the description is nearly complete. It omits a detailed return shape, but the response is intuitively a league table and the one non-obvious field is explained.

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 league parameter is already fully documented with allowed values and default behavior. The description adds no parameter syntax or format detail beyond what the schema provides, so the baseline is 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 resource, 'League table', and gives example queries that make the intent clear. It does not distinguish this tool from siblings like formguide_get_results or formguide_compare_teams, so it stops short of a 5.

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

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

It provides clear context for when to use the tool through example requests such as 'show me the Championship table' and 'who is top of La Liga?'. However, it gives no explicit exclusions or alternatives among the 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered elsewhere. The description adds nothing behavioral on top of that – no note on the openWorld lookup behavior, no hint about failure modes or the meaning of combining position/form/fixtures in one call.

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

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

Three short sentences, front-loaded with the resource and outputs, then user-phrasing examples. Nothing redundant, though the leading 'Form Guide.' fragment duplicates the title.

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 lookup with no output schema, the description does convey what comes back (position, form, next games), which is adequate. It falls short on sibling routing, which is significant given three overlapping formguide tools, and offers no detail on the response shape.

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 schema already explains every parameter including the q/team aliasing, allowed leagues, and country-coded shirt links. The description's example queries loosely map to the team parameter but add no syntax or constraint detail beyond the schema, 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 resource and enumerates the three outputs returned: league position, recent form, and next games. It is clear what the tool produces, but it never distinguishes itself from the sibling tools formguide_get_table, formguide_get_results, and formguide_get_fixtures, which appear to cover the same three sub-topics individually.

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 example queries ('how are Arsenal doing?', 'what's Spurs' form?') imply when to reach for this tool, which is useful trigger guidance. However, it gives no explicit alternative or exclusion, and given four sibling formguide tools that overlap heavily on table/results/fixtures, an agent gets no help deciding between 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 declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety and repeatability profile is covered. The description adds one behavioral trait beyond that ('for voice', 'one line at a time'), indicating output shaped for spoken delivery, but says nothing about return format, pagination across cards, or defaults 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 text is short, but it opens by restating the title almost verbatim (including a stray double period) and then spends its second half on product-wide copy rather than this tool. Front-loaded enough, but a meaningful share of the content does not earn its place.

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

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

For a zero-required-parameter, read-only tool with a fully documented schema and no output schema, the definition is minimally adequate: it conveys that a card is one line of today's reading. It is missing what a 'card' actually contains and how to page through it, which would help an agent use 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 schema already documents n, date, and reading (including defaults to 1, today UTC, and today's reading). The description adds no parameter-level meaning beyond this, which is the expected baseline when 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?

The description states the resource (a daily Bhagavad Gita card read 'one line at a time, for voice'), which hints at the granularity of the unit and differentiates it somewhat from a whole-reading tool. However, the second sentence describes the entire app surface ('daily verses, plans, search and verse lookup; whole books from the Library'), which is not this tool's function, and it never distinguishes get_card from close siblings like gita_get_today, gita_get_reading, or gita_get_verse.

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 or when-not-to-use guidance and no named alternative. 'For voice' faintly implies a voice/TTS context, but an agent cannot tell from this text why it would pick get_card over gita_get_today or gita_get_reading.

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, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds genuinely useful output context — that the chapter is returned in Sanskrit with transliteration and English — which matters since there is no output schema. It adds nothing about size, pagination, or error behavior for out-of-range chapters.

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 content-bearing line ('A whole chapter in Sanskrit with transliteration and English') is front-loaded and useful, but the lead brand name 'Gita Scroller' is filler and the long second sentence catalogs unrelated app features, violating the 'every sentence earns its place' standard.

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 annotation coverage and no output schema, the essential information (what content comes back) is present. What is missing is differentiation from the many sibling Gita retrieval tools and any handling note for invalid chapter numbers.

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 'chapter' parameter is fully documented with a 1–18 range, so the schema carries the semantics. The description only implies chapter selection via 'a whole chapter' and adds no format or edge-case detail beyond the schema.

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

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

The name and title already convey 'a whole chapter in Sanskrit with transliteration and English,' and the first two sentences of the description largely restate that. The trailing clause about 'daily verses, plans, search and verse lookup; whole books from the Library, read a passage at a time' describes the app as a whole rather than this tool, so it does not sharpen the boundary against siblings like gita_get_verse, gita_get_reading, or gita_read_book.

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 statement of when to use this tool versus gita_get_verse (single verse), gita_get_reading (passage), or gita_read_book (whole book). The tagline even names adjacent capabilities (search, verse lookup, daily verses) without routing the agent to the tool that owns them, which could actively mislead 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?

The annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered externally. The description adds nothing behavioral beyond that — no note on return shape, whether remote content is fetched, or what 'line by line' implies for output.

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 first two sentences largely restate the tool name and title, and the trailing clause ('daily verses, plans, search and verse lookup; whole books from the Library') describes the whole app rather than this tool. This is clutter rather than informative brevity.

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 rich annotations and full schema coverage, the definition is minimally adequate. However, it never clarifies how a 'reading' differs from a 'card', 'chapter', or 'today', so the agent lacks the context needed to confidently pick this tool over its siblings.

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

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

Schema coverage is 100% and the single 'id' parameter is well documented in the schema with concrete examples ('japji', 'The Gita in 18 Days'). The description adds no parameter meaning of its own, 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 implies retrieving a single reading or plan and even hints at the format ('line by line'), so the basic purpose is inferable. But it never states the verb cleanly and does not distinguish this tool from close siblings like gita_get_today, gita_get_card, or gita_read_book, leaving the agent to guess which one to call.

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 guidance, no mention of alternatives, and no exclusions. The schema notes the id comes from list_readings, but the description itself provides no routing logic between this tool and its many sibling readers.

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, idempotentHint, destructiveHint=false, openWorldHint), so the remaining burden is light, but the description adds essentially nothing behavioral beyond 'same as the app shows today'. It does not say what is returned (one line? a full chapter?), whether a reading always exists for a given day, or how it behaves outside the app's configured plan.

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 first sentence duplicates the title verbatim, and the second sentence is a catalog of sibling-tool features (plans, search, verse lookup, whole books) that does not describe this tool's behavior. It is short, but a significant share of the text does not earn its place in this definition.

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-required-parameter read tool with no output schema, the minimum viable information is present: it says what the tool returns conceptually (today's reading, line by line) and leaves the date override to the schema. It stops short of describing the return shape, pagination/line handling, or behavior when no reading exists for the day, which matters because there is no output schema to fall back 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?

Schema description coverage is 100% and the single optional 'date' parameter is fully documented in the schema (YYYY-MM-DD, defaults to today UTC). The description contributes no additional parameter semantics, so the baseline of 3 for high schema coverage 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 recognizable verb+resource ('Today's reading, line by line') and scopes it to today, so the core purpose is discoverable. However, it never distinguishes itself from close siblings like gita_get_reading, gita_get_verse, or gita_list_readings, and the second sentence instead enumerates capabilities belonging to those siblings (plans, search, verse lookup, whole books), which muddies rather than sharpens the purpose.

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 gita_get_reading (which presumably takes an explicit date/passage) or gita_get_card. The family blurb mentions other features but attaches no conditions or exclusions to any of them, so an agent must infer the routing entirely from the tool name.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds useful content context (output includes Sanskrit, transliteration, and English), but says nothing about pagination, range size limits, or error behavior for invalid chapters/verses.

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 title fragment 'A verse or range (e.g' is truncated and duplicated in the body, and the second sentence drifts into a feature list for the whole Gita Scroller app rather than this tool. Structure is muddled rather than front-loaded on what the tool does.

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

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

For a two-parameter, fully documented, non-destructive read tool with no output schema, the description does mention the returned content shape, which is the main missing piece. However, it omits any routing guidance against the many gita_* siblings, leaving the agent under-informed for selection.

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% for both parameters, including the '47-51' example and the 1-18 chapter bound, so the schema carries parameter semantics. The description's 'range (e.g. 47-51)' merely echoes the schema and adds no formatting or edge-case detail (e.g. whether a range may span chapters).

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 conveys the resource (a Bhagavad Gita verse or range) and the content returned (Sanskrit, transliteration, English), but it opens with the brand name 'Gita Scroller' rather than a verb+resource statement for this specific tool. It never distinguishes itself from siblings like gita_get_chapter, gita_get_card, gita_get_reading, or gita_get_today, so an agent must infer the boundary.

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 second sentence lists app-level features ('daily verses, plans, search and verse lookup; whole books from the Library') but gives no condition for choosing this tool over gita_get_chapter, gita_get_card, or gita_get_reading. There are no exclusions or alternatives stated.

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, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered structurally. The description adds nothing beyond repeating the title phrase 'read a passage at a time', giving no extra behavioral context such as what the list covers or its ordering.

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?

Sentences are redundant: 'Gita Scroller' appears twice and 'read a passage at a time' appears twice, with the actionable information (that this lists books) never actually stated. The blurb is not front-loaded around the tool's function.

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 list tool with no output schema, the description should at minimum clarify that it enumerates available books and what they are. Instead it stays at the level of a promotional tagline, leaving the return content ambiguous.

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

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

The tool takes zero parameters, so the description has no parameter semantics to supply. Baseline 4 applies for a parameterless tool where the schema already fully covers the (empty) input.

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 text largely restates the title and reads as product marketing ('Gita Scroller. The whole books in the Library...') rather than naming an action. It never says it LISTS books or what that list contains, and it does not distinguish the tool from siblings like gita_list_readings or gita_read_book.

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 when-to-use, when-not-to-use, or alternative routing. Mentioning 'daily verses, plans, search and verse lookup' just names adjacent app features (which map to sibling tools like gita_get_today, gita_search_readings, gita_get_verse) without telling the agent when to pick this one.

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, openWorldHint, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds no behavioral context beyond that—no mention of what the list contains, ordering, pagination, or whether results include verse text or just metadata.

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?

It is short, but the content is poorly structured: sentence one duplicates the title, and the rest is a run-on fragment string of unrelated app features ('whole books from the Library, read a passage at a time') that does not belong in a list_readings definition. Space is spent without paying for itself.

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 parameters and full annotation coverage, very little is strictly required, and the description at least signals that curated readings and plans are returned. However, with no output schema, it gives no hint of the return shape or volume, leaving the agent guessing about what a listing contains.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4; there are no parameter semantics for the description to clarify or compensate for. No penalty applies, but nothing here elevates it above 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 opening sentence repeats the title almost verbatim ('All curated daily readings and plans') and never supplies a verb, so the action (listing available readings/plans) must be inferred from the name. It also fails to distinguish this from siblings like gita_list_books, gita_get_reading, or gita_search_readings. The remaining clauses describe app-wide scope rather than this tool, muddying rather than sharpening the purpose.

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 or when-not-to-use guidance, and no sibling is named as an alternative. The phrase 'search and verse lookup' gestures at gita_search_readings and gita_get_verse but as app-level marketing, not routing advice, so the agent gets no selection criterion.

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, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds that reading is sequential and carries across chapter boundaries and spans a multi-book Library, which is modest extra behavioral context, but it says nothing about pagination limits or return shape.

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 first sentence 'Gita Scroller.' and the second sentence restate the title almost verbatim, wasting space. The remaining clause then lists sibling capabilities ('daily verses, plans, search and verse lookup') that do not belong to this tool, so the text is repetitive and partially off-topic rather than front-loaded and purposeful.

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 four parameters fully documented in the schema and safety annotations present, the description only needs to add reading-flow context. It gestures at sequential reading across chapters but omits how passage navigation interacts with section/n/ref overrides and what a call returns, leaving it adequate but not complete for a 4-parameter 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%, so the schema already documents book, section, n and ref with examples, which sets the baseline at 3. The description adds no syntax or format detail beyond that ('a passage at a time' loosely gestures at n/section) so it does not raise the bar above 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 conveys that this reads passages from a book one at a time ('read a passage at a time', 'whole books from the Library'), which gives a usable verb+resource. However, it muddies the identity by also listing adjacent capabilities ('daily verses, plans, search and verse lookup') that belong to sibling tools, so it does not cleanly distinguish itself from gita_get_reading, gita_get_chapter or gita_get_verse.

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?

'Follow next for the next passage; it carries on into the next chapter' is a hint about sequential scrolling, and 'whole books from the Library' hints at multi-book scope. But there is no explicit when-to-use or when-not-to-use guidance and no sibling is named as an alternative, leaving the agent to guess against eight other gita 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 declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds one useful behavioral detail — results are ordered by best match — but says nothing about result count, matching semantics, or fallback when nothing matches.

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

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

The search preamble is front-loaded and efficient, but the second sentence ('Bhagavad Gita: daily verses, plans, search and verse lookup; whole books from the Library, read a passage at a time') is app marketing that does not describe this tool's behavior and pads the definition.

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 search with no output schema, the essentials are present and annotations cover safety. It stops short of describing the shape of the search response or its limits, which an agent would need to interpret results.

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 a single documented 'q' parameter that already includes the example 'duty or fear'. The description contributes no additional parameter meaning, so the baseline 3 for schema-complete cases 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 ('Search the curated readings') plus the ranking behavior ('best match first'), which distinguishes it from gita_get_reading and gita_list_readings. The remaining clause is app-level boilerplate rather than tool-specific, but the core purpose is unambiguous.

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 versus gita_get_reading, gita_get_verse, or gita_list_readings, and no exclusions or prerequisites. 'Best match first' is a ranking note, not usage direction.

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, destructiveHint=false and openWorldHint, so the safety profile is fully covered. The description adds genuine value by disclosing what the payload contains (each line in Gurmukhi, romanized transliteration, and English), which is behavior beyond the annotations, but says nothing about page size, limits, or ordering.

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 first two sentences are tight and front-loaded. The third sentence is undifferentiated multi-feature boilerplate that reads like a store listing rather than tool guidance, diluting the definition.

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

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

For a simple single-parameter read with complete annotations and full schema coverage, the description covers the essentials: what is returned, in which languages, keyed by Ang. No output schema exists, but the content-language disclosure compensates adequately; only pagination/size behavior is unaddressed.

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

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

Schema coverage is 100% and the single 'ang' parameter is fully documented in the schema with type, range, and meaning. The description's 'Every line on an Ang' adds no syntax or semantics beyond that, so baseline 3 is correct.

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: retrieve every line on an Ang, with the content formats (Gurmukhi, transliteration, English). It hints at the sibling landscape ('Ang and shabad lookup', 'whole books from the Library') but never cleanly distinguishes get_ang from gurbani_get_shabad or gurbani_read_book, which is the main clarity gap.

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 closing sentence is an app-level feature dump ('daily shabad, plans, search, Ang and shabad lookup; whole books from the Library, read a passage at a time') rather than a routing rule. It never says when to choose this tool over gurbani_get_shabad, gurbani_get_reading, or gurbani_read_book, so the agent must infer.

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 readOnly, idempotent, openWorld, and non-destructive, so safety is covered. The description contributes one useful trait beyond that: the output is "for voice" and delivered "one line at a time," implying a TTS-friendly, incremental card. It says nothing about return shape or paging beyond that phrase.

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 tool purpose is buried in a sentence that repeats the title nearly verbatim, followed by a generic catalog of unrelated Gurbani features and a stray double period. The second sentence is noise for an agent trying to decide whether to call this tool.

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 should clarify what a 'card' contains, and it only gestures at that ('one line at a time, for voice'). Params and safety are fully covered by schema and annotations, so this is minimally adequate but leaves the core deliverable underspecified.

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 clear docs for n, date, and reading, so the schema does the heavy lifting. The description adds no meaning beyond the schema (e.g., how 'reading' ids map to cards), 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?