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

With no annotations, the description carries the behavioral disclosure burden. The verb 'Get' implies a read-only operation, and the description lists what data will be returned. However, it does not mention behaviors such as error handling for invalid IDs, response structure, or potential rate limits, leaving some ambiguity.

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

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

The description is a single sentence that front-loads the core purpose and packs the key return categories into a compact list. Every word earns its place, and there is no repetition of schema or annotation 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?

With one simple parameter and no output schema, the description provides a solid summary of what the agent will receive. It could be slightly more explicit about response format or when to prefer this over search_artworks, but for a single-ID lookup the described context is largely sufficient.

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

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

Schema coverage is 100%, so the schema already fully documents the single 'id' parameter. The description confirms that the ID is a 'Mia object ID' but adds no additional semantic detail beyond the schema's examples.

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 ('Get') and resource ('a specific artwork by its Mia object ID'), and enumerates the returned content categories. This clearly distinguishes it from sibling tools like search_artworks or get_artworks_batch, which operate over sets rather than a single known ID.

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 phrase 'for a specific artwork by its Mia object ID' clearly indicates when to use this tool: when the agent already knows the ID and needs full metadata. It does not explicitly name alternatives or exclusions, but the intended context is easy to infer from the sibling tool names.

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 annotations provided, the description carries the full burden of behavioral disclosure. It states 'fetch' implying read-only, but gives no details on batch size limits, error handling, response format, or whether the results are ordered as requested. For a batch endpoint, this is a significant gap.

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

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

The description is a single concise sentence with no wasted words, but it is under-specified. The brevity works for clarity but not for completeness, so it misses the 'appropriately sized' element. It could be longer to include essential usage notes while remaining focused.

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 batch operation with no output schema and no annotations, the description is thin. It lacks details on maximum batch size, response ordering, error behavior, and any rate limits. Given the complexity of a batch fetch, this is insufficient for an agent to call it correctly without guessing.

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 'ids' parameter is well documented in the schema. The description adds no extra meaning beyond restating that it fetches by IDs. Baseline of 3 is appropriate since the schema fully covers the parameter 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?

The description clearly states the action (Fetch) and resource (multiple artworks by object IDs). It distinguishes itself from siblings like 'get_artwork' by emphasizing the batch nature, though it doesn't explicitly name alternatives. The verb and resource are specific and 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 tool versus the sibling 'get_artwork' for a single artwork. The description implies batch fetching but does not mention that this is the preferred choice for multiple IDs or any exclusions. An agent would need to infer the use case from the name and parameters.

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?

No annotations are provided, so the description carries the burden of behavioral disclosure. It discloses the filtering behavior (by room or floor) but doesn't mention pagination behavior, default result ordering, or whether the results are limited to currently on-view works only. The description adds some behavioral context beyond the schema but leaves gaps.

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 with no waste. The core purpose is front-loaded, and the filtering options are stated concisely. Every word 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 filtered list tool with 100% schema coverage, the description is largely complete. It could mention that results are limited to currently on-view works and that pagination is available, but the schema already covers pagination parameters. The lack of an output schema is not a major gap for a list 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 all four parameters. The description adds context by explaining that 'room' and 'floor' are gallery-specific filters, but doesn't add meaning beyond what the schema provides. 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's purpose: finding artworks currently on physical exhibition in museum galleries. It specifies the resource (artworks), the action (find), and the key constraint (currently on physical exhibition), which distinguishes it from sibling tools like search_artworks or get_artwork.

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 when to use this tool: when looking for artworks currently on display in physical galleries, as opposed to searching the broader collection. It doesn't explicitly name alternatives or exclusions, but the 'currently on physical exhibition' phrasing provides clear context that this is for on-view works only.

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 annotations, the description carries the behavioral burden. It conveys that this is a read-only lookup and usefully lists returned fields (Wikidata, Wikipedia biography link, museum IDs). However, it does not mention error behavior, missing data, or whether external identifiers are always present.

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 one front-loaded sentence containing only essential information: action, resource, lookup key, and notable return contents. There is no fluff or repetition.

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

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

This is a low-complexity tool with one parameter, no output schema, and no annotations. The description adequately covers what the tool returns and when to call it, leaving no material gap for correct invocation.

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

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

The schema already fully documents the single id parameter with type and an example, so the description adds no additional semantic value. With 100% schema description coverage, 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 uses a specific verb ('Look up'), names the resource ('artist or constituent information'), and specifies the lookup key (ID). It also lists concrete content returned, which clearly distinguishes it from the sibling artwork-focused 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?

The description clearly communicates the usage context: call this when you need person/constituent data by ID. It does not explicitly name alternatives or exclusions, but the sibling tools are all artwork operations, so the distinction is easy for an agent to 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It states it returns random artworks and optional filters, but doesn't mention potential side effects (likely none), rate limits, or data source specifics beyond the museum. It doesn't describe response format or pagination, but for a simple retrieval, this is acceptable; a higher score would require more explicit 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?

The description is a single, clear sentence that is front-loaded with the main purpose and then lists filter options efficiently. No wasted words; every phrase contributes to understanding the 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 tool with two optional parameters and no nested objects, the description adequately covers the core functionality and gives query examples. It doesn't explain the return format, but since there is no output schema and the tool is a simple retrieval, the absence is not a major gap. The description is sufficient for an agent to decide when to use it and how to specify filters.

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 parameters. The description adds example filter syntax (e.g., 'room:G3*'), which is valuable beyond the schema's generic descriptionsunci, but since both are fully described in the schema, the added value is marginal, keeping the baseline at 3.

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

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

The description clearly states the tool retrieves random artworks from a specific museum, distinguishing it from search or specific-lookup siblings. It mentions optional filters, which gives a sense of scope. However, it doesn't explicitly name or contrast with sibling tools to prevent confusion, though the core action 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?

The description implies use when randomness is desired, as opposed to search_artworks or get_artwork, but doesn't explicitly state when to use this tool versus the siblings. It gives examples of filter queries, which helps usage, but no explicit 'use this for...' guidance or exclusions.

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?

No annotations are provided, so the description carries the full burden. It discloses that the tool supports Elasticsearch syntax, filters, pagination, and sorting, and gives example queries. However, it does not mention return format, error behavior, rate limits, or that it is a read-only operation. These are gaps for a tool with zero annotation coverage.

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, dense sentence front-loads the core purpose and then packs capabilities efficiently. It is concise with no filler, though the dense list of examples could be slightly better organized (e.g., bullet points). Still, it 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?

Given the tool's complexity (Elasticsearch syntax, multiple filter fields, pagination, sorting) and lack of an output schema, the description should explain what the response looks like. It does not mention that results are a list of artwork objects or how errors are handled. The essentials for calling are present, but the absence of return-format details leaves a 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. The description adds value by illustrating Elasticsearch field syntax (e.g., artist:"Claude Monet") and listing sort fields, but the schema already includes similar examples. The added context is helpful but not substantial beyond reinforcing what the schema documents.

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 ('Search') and resource (Mia collection of 90,000+ artworks), and the mention of Elasticsearch syntax, filters, pagination, and sorting clearly distinguishes it from sibling tools like get_artwork (single item) and get_random_artwork (random). The 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?

The description clearly implies use for general collection search and provides concrete examples of how to construct queries (e.g., artist:"Claude Monet"). However, it does not explicitly state when NOT to use it or name alternatives, leaving some inference to the agent based on sibling names.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It says 'discover' but does not explain query matching, pagination behavior, whether results are sorted, or what a response contains. The read-only nature must be inferred from the tool name and general semantics.

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

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

The description is a single sentence with no filler or duplicated schema content. It front-loads the core scope efficiently, though it lacks the extra behavioral detail that would make the concision more 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?

With no output schema and no annotations, the description leaves important operational details undocumented: what a successful call returns, how pagination works, and how the optional query filters results. An agent could make a basic call, but not with full confidence about behavior or 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 parameters from, size, and query are already documented in the schema. The description adds no parameter-level detail, but under the high-coverage baseline of 3 this is acceptable.

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 tool's scope: discovering curated highlights in the Minneapolis Institute of Art permanent collection. It distinguishes the focus from general artwork searches, though 'discover' is a softer verb than 'search' or 'list' and the distinction from sibling tools is not 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?

No guidance is provided about when to use this tool instead of search_artworks or get_random_artwork. The only implied context is the name and the 'highlights' scope; there are no exclusions, prerequisites, or alternative routing cues.

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