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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the return shape (total, count, page, has_more, next_page?, results[]) and mentions 'slim artwork records', which provides useful behavioral context beyond the annotations. No contradictions.

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

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

The description is compact and front-loaded with the core purpose. It includes an args summary and a returns line, and the usage guidance is appended at the end. While the args section duplicates schema info, the overall structure is efficient and free of fluff.

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

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

For a read-only list operation with rich annotations, the description covers the core need: it states what it returns, how pagination works, when to use it over a sibling, and parameter defaults. It lacks explicit error-handling or rate-limit notes, but these are not essential here. It is sufficiently complete for an agent to call it correctly.

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

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

Schema coverage is 100% and each parameter already has a detailed description in the schema. The description's 'Args:' section simply repeats the parameter names and defaults without adding new meaning. The only addition, the limit hint about verbose records, is already present in the schema. Hence 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 states the verb 'List' and the resource 'collection works by one artist', and explicitly differentiates from the sibling whitney_search_artworks by explaining the matching mechanism. This gives an agent a precise understanding of what the tool does and how it differs from 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 explicitly says 'Use this rather than whitney_search_artworks with an artist name' and spells out the reason (matches on artist record vs credit line) and the benefit (handles collaborative and attributed works correctly). This is a clear, actionable usage guideline with an alternative and a scenario.

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

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

Beyond the read-only/idempotent annotations, it discloses the exact return envelope, generic pass-through of exhibition fields, HTML stripping, prose truncation, and uneven historical coverage. This is substantial behavioral context that the annotations do not provide.

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?

Purpose is front-loaded, followed by a compact Args/Returns structure. The caveat sentence about generic fields and patchy coverage is dense but valuable; no words are 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?

With a rich schema, annotations, and the return envelope in the description, an agent has everything needed to call the tool correctly. The coverage caveat also sets expectations about data completeness, which is important for agent decision-making.

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

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

Input schema coverage is 100% and the schema already documents id formats, page semantics, limit bounds, and response_format. The description's Args list adds no new meaning, so it gets the baseline score rather than higher.

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 first line names the exact operation ('List Whitney exhibitions featuring one artist') with a specific verb, resource, and scope. The 'artist ID' argument makes clear this is artist-centric, distinguishing it from the search/get exhibition siblings.

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 makes the intended use clear: pass an artist ID to get that artist's exhibitions, with pagination and format options. It doesn't explicitly call out alternatives or exclusion cases, but the artist-relationship is stated upfront so there is little ambiguity.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is known. The description adds valuable behavioral detail: the biography is stripped of HTML and truncated, and it clarifies that ulan_id and wikidata_id are useful for cross-referencing. This goes beyond what annotations convey.

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

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

The description is well-structured with an 'Args' and 'Returns' section, front-loading the core purpose in the first sentence. Every sentence earns its place, and it avoids redundant filler. The length is appropriate for the tool's complexity.

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

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

An output schema exists, and the description complements it with clarification on biography formatting and cross-referencing utility. For a read-only get-by-id operation, nothing essential is missing. The agent has enough to invoke it correctly without further investigation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description restates the id format ('TMS ID or 'T'-prefixed reference') and the response_format defaults, which match the schema. It does not add new semantic detail about parameters beyond what the schema already specifies, so it neither compensates nor falls short.

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

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

The description states a specific action ('Fetch one artist's full record') on a precise resource, and the subject matter (Whitney artist) distinguishes it from sibling tools like whitney_get_artwork or whitney_get_exhibition. It also mentions the biography inclusion, which sets expectations. This is far beyond a tautology.

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 makes clear it is for retrieving a single artist by ID, which implies it should not be used for searching (where whitney_search_artists would be appropriate). It does not explicitly name alternatives or state when not to use it, but the context is unambiguous enough for an agent to choose correctly.

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. The description goes beyond annotations by detailing that fields are omitted when empty, that alt_text may be AI-generated and flagged by alt_text_is_ai_generated, and that a 404 message is returned for invalid IDs. This provides valuable behavioral context not covered by the annotations alone.

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

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

The description is well-structured: a one‑line purpose statement, concise args list, return structure, and error note. It may be slightly long due to listing the return fields (which might also be in the output schema), but every section adds useful information—args, behavior, and errors—so it remains efficient and front-loaded with the core purpose.

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

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

For a simple get‑by‑ID tool with strong annotations and an existing output schema, the description covers everything an agent needs: how to obtain the ID, the optional response format, the structure and omission behavior of the return, and error handling. No critical information is missing.

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

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

Schema coverage is 100% for both parameters, so the baseline is 3. The description adds value by clarifying that the id is 'the TMS ID, as returned by whitney_search_artworks'—linking it to the search tool and confirming the ID source. It also gives context for response_format ('for reading' vs 'for machine processing'), which is not fully captured by the schema's enum description.

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 ('Fetch') and resource ('one artwork's full record') with the retrieval method ('by ID'). It also explicitly references the sibling tool 'whitney_search_artworks' as the source of the ID, which distinguishes it from other get/search tools without 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 description clearly indicates when to use this tool: when you already have an artwork ID from 'whitney_search_artworks'. It also explains the optional response_format parameter ('markdown' for reading, 'json' for machine processing), and notes the error behavior for a non-existent ID. This gives explicit context for selection and invocation.

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 disclose read-only, idempotent, and non-destructive behavior. The description adds valuable context about the return shape ({ record: {...} }) and states that HTML is stripped, which is not covered by annotations. No contradiction with annotations.

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

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

Extremely concise and well-structured: a one-sentence purpose, a short args list, and a return statement. No filler or redundancy; 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 simple two-parameter read operation with an output schema, the description provides everything needed: the ID source, response_format with default, and a high-level return shape. The existence of an output schema means returndetails need not be spelled out further.

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 id and response_format, so the schema already documents the parameters. The description adds provenance ('as returned by whitney_search_exhibitions') for id, which is helpful but not essential. Baseline 3 is appropriate given the full schema 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?

States the specific action 'Fetch one exhibition record by ID' and clearly identifies the resource and retrieval method. Distinguishes itself from search tools by requiring an ID, and references whitney_search_exhibitions as the source of that ID, making its role 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?

Explicitly instructs that the ID comes from whitney_search_exhibitions, implying this tool is used after a search. It does not list alternatives or state when not to use it, but the ID-based requirement and sibling names make the intended use 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 read-only, idempotent, non-destructive behavior, and the description adds meaningful context: it returns a list or a single-record object when 'id' is supplied, accepts raw predicates, and warns that 'pages' mirrors the Museum's CMS structure and is rarely useful. This goes well 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 well-organized: a one-line purpose statement, a compact Args list, return behavior, and usage guidance. Every sentence earns its place, and the most important scoping information is 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?

For a raw query tool with no output schema, the description provides enough to call it correctly: endpoint options, parameter roles, default values, return shape, and guidance on when to use alternatives. The absence of output schema is compensated by the explicit 'Returns' line.

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 met; the description adds value with a sort example ('popularity desc'), a filters example with a real predicate, and a compact summary of endpoint, id, limit, and response_format semantics. It mostly restates the schema, but the examples and use-case framing give extra orientation.

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 this as an 'escape hatch' for queries the typed tools do not cover, with a specific verb ('Hits') and resource (any of six named API endpoints). It also distinguishes itself from the typed sibling tools by promising arbitrary Ransack predicates and raw API access.

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 explicitly says to 'prefer the typed tools where they fit' and names concrete scenarios for using this tool: discovering field names, combining unusual predicates, and reaching the 'pages' endpoint. The 'pages' caveat also tells the agent when the endpoint is not useful.

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, and non-destructive behavior. The description adds useful context on the return shape (slim records, total/count/page/has_more/next_page) and scope, which goes beyond the annotations without repeating them.

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

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

The description is well-structured and front-loaded: purpose, return shape, parameters, return object, and example. Some redundancy exists with the schema in the Args list, but the example and explicit alternatives earn their place, keeping the overall size reasonable.

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 search tool with 8 optional parameters and an output schema, the description is complete: it lists all parameters, describes the return object, provides a realistic example, and directs to related tools. No critical information for invoking the tool correctly is missing.

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

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

Schema description coverage is 100%, so the input schema fully documents each parameter. The description's Args section largely restates the schema but adds a bit of usage context in the example and mentions the record structure. 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 states the tool searches 7,000+ Whitney artists with a specific scope (collection and exhibitions) and distinguishes itself from related tools by mentioning slim records versus the biography-focused whitney_get_artist. The verb 'Search' and resource 'artists' are immediately 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?

The description explicitly routes to whitney_get_artist for biography and authority IDs, and the example provides a concrete workflow of when to search artists and then call whitney_artist_artworks. This gives clear guidance on alternatives and next steps.

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

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

Beyond the readOnlyHint/idempotentHint annotations, the description discloses return shape (slim records, total/count/page/has_more), pagination behavior, US spelling conventions, free-text date caveats, and exact-match behavior for classification. No contradictions with annotations.

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

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

The description is well-structured with Args, Returns, Examples, and Notes sections, and the key summary is front-loaded. The Args block partly duplicates the already-complete input schema, which prevents a perfect 5, but the added examples and usage notes are otherwise 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?

For an 11-parameter search tool with an output schema and safety annotations, the description is surprisingly complete. It covers return fields, pagination, parameter semantics, edge cases (free-text date, US spelling), and response format selection, so an agent can call it correctly without further inference.

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. The description adds extra semantic value by mapping natural-language examples to parameters (e.g., 'watercolours with flowers' -> title, classification, medium) and by warning about date free-text and US medium spellings. This goes beyond the schema's per-field descriptions.

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

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

The description opens with a specific verb and resource: 'Search the Whitney Museum's online collection of 27,000+ works.' It distinguishes itself from sibling tools by explicitly noting that whitney_get_artwork is for full records, and the title clearly signals this is the artworks search tool.

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

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

The description gives explicit routing guidance: 'Call whitney_get_artwork for the full record including dimensions, credit line, description and all images.' It also provides concrete query examples that show how to translate user requests into parameter values, making when-to-use practical rather than abstract.

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, non-destructive behavior, so the bar is lower. The description adds meaningful behavioral context: coverage back to 2008, generic field passthrough ('As with exhibitions'), pagination semantics via the Returns block, and the effect of response_format. It does not contradict the annotations.

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

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

The description is about 120 words and front-loads the core purpose in the first sentence. The Args and Returns blocks are compact and avoid redundancy, though the phrase 'As with exhibitions' is a reference that may require cross-tool knowledge. Overall it is appropriately sized for an 8-parameter 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?

For a read-only search tool with an output schema, full parameter descriptions, and strong annotations, the description is nearly complete: it states the resource, temporal coverage, filtering dimensions, pagination fields, and a sorting recommendation. The only gap is reliance on an unspecified sibling ('As with exhibitions') and absence of explicit use-case boundaries, but these are minor against the schema and output schema.

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%: every parameter already has a precise description, defaults, and constraints in the input schema. The description's Args section mostly restates these (e.g., 'ISO dates (YYYY-MM-DD)', '1-30, default 10') with only small additions like 'substring match' for title. Therefore it adds marginal value beyond the schema, warranting the baseline 3.

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

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

Description opens with 'Search Museum events' — a specific verb and resource — and elaborates with examples ('talks, tours, public programmes') and temporal scope ('going back to 2008'). This clearly distinguishes it from sibling tools like whitney_search_exhibitions and whitney_search_artworks, which target different resources. The resource and purpose are 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?

The description gives operational advice ('Sort by start_time desc for the most recent programming') and notes the list is 'largely comprehensive', but it does not explicitly say when to choose events over exhibitions, artworks, or guides, nor when not to use it. Alternative tools are only implied via 'As with exhibitions'. No exclusionary usage guidance is 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, openWorldHint, idempotentHint, and destructiveHint false. The description adds substantial behavioral disclosure beyond that: the tool strips HTML, shortens timestamps to dates, drops internal IDs, passes through fields generically because the museum's field set is subject to change, and warns about sparse early records. This fully covers the behavioral profile.

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 organized into clear sections — overview, args, returns, field behavior, and a practical preflight instruction. Every paragraph earns its place; nothing is filler. It is appropriately detailed for an 8-parameter tool and remains scannable.

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

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

With an output schema present and annotations covering safety, the description still completes the picture: it documents return shape, pagination page and limit, filter preflight, data-quality caveats, and field volatility. An agent has enough context to call the tool correctly and 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?

Even though schema coverage is 100%, the description adds key semantics: title is a substring match, filters are raw Ransack predicates for fields not exposed by the tool, date filters are ISO format, limit controls verbose record fetch size, and response_format distinguishes reading vs machine processing. It also explains that exhibition fields are passed through generically, which clarifies why no fixed field parameters exist.

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

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

The description clearly states the tool searches exhibitions mounted by the Whitney, going back to 1931, which is a specific verb+resource combination. It does not explicitly name or differentiate from sibling tools like whitney_search_artworks or whitney_artist_exhibitions, so it stops short of full sibling distinction.

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

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

The description gives strong contextual guidance: records are fuller for recent decades and sparse for early history, and it instructs users to run a limit=1 search before writing raw filters queries. It does not explicitly state when to use this tool over alternatives or when not to use it, 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 cover read-only, idempotent, and non-destructive behavior. The description adds useful context beyond those annotations: guides are limited to those published since 2009, and fetching an individual guide also returns its stops. This gives the agent concrete expectations about scope and result contents.

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

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

The description is compact and well-structured, with the core purpose stated first. The Args and Returns summaries are concise and easy to scan, with no filler or repetition of the schema's full descriptions.

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

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

The description covers the resource, temporal scope, result shape, pagination fields, and parameter defaults, which is sufficient for most search calls. It falls slightly short only on explicit guidance about choosing this tool over sibling searches.

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 six parameters thoroughly, including defaults, ranges, and Ransack syntax. The description's Args list is a useful summary but adds no new semantic information beyond what the schema provides.

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

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

The description states a specific verb and resource: 'Search audio guides', and adds a meaningful scope constraint ('published since 2009'). It is clearly distinguishable from sibling search tools (events, artworks, artists, exhibitions) because the resource type is explicit.

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 makes it clear this tool is for searching audio guides, but it does not explicitly explain when to prefer this over sibling tools like whitney_search_artworks or whitney_query. There are no excluded cases or alternative tool recommendations.

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