Artnap

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds nothing beyond that on behavior — no error handling for unknown ids, no note that the image is a 2,500 px asset served how, no auth or rate-limit context. With annotations carrying the load, 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?

A single front-loaded sentence with zero filler; the id-based scope and the payload contents are delivered immediately without repetition of the title or annotations.

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 correctly takes on the burden of telling the agent what comes back, listing the eight payload elements. It stops short of describing the shape or types (e.g., whether the 2,500 px image is a URL or binary, whether museum record is a link), which is a minor remaining gap for a tool with no 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%, and the schema even supplies an example value ("aic-56905"), so the parameter is fully documented in structured data. The description only restates 'by its Artnap id' without adding format or sourcing guidance, 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 verb (retrieve one artwork) and resource, scoped by 'its Artnap id', and enumerates the returned fields (title, artist, year, museum, license, image, page, museum record). That makes it clearly distinct from the sibling 'search_artworks' (plural/multi-result) and the list_* tools, though it never names 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 rather than stated: 'by its Artnap id' tells the agent this is a direct-key lookup, which contrasts implicitly with search_artworks. There is no explicit 'use this when you already have the id' instruction or warning that the id must be obtained elsewhere first, so the agent must infer the selection 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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds real value beyond that by disclosing the return content — a license line limited to PD/CC0/CC BY plus where to verify it at the holding museum — which tells the agent what it will actually get.

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 compact sentence with no wasted words, and the key noun (license line for one artwork) is front-loaded. It is slightly terse and reads as a fragment rather than an actionable statement, which keeps it from a 5.

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 its part by explaining what the return contains (license line plus museum verification location). For a simple one-param read tool with full annotation coverage, 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?

There is a single parameter with 100% schema description coverage, so the schema already documents 'id' as the Artnap artwork id. The description adds no format or constraint detail beyond that, matching the baseline 3 for high-coverage schemas.

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 it returns (the license line for one artwork) and the license scope (public domain, CC0, CC BY), which is enough for an agent to tell it apart from get_artwork or search_artworks. It lacks an explicit verb ('get'/'retrieve'), reading as a noun phrase, so it falls short of the 5 criterion.

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: pass a single artwork id to get its license line and verification pointer. There is no explicit when-to-use statement, no exclusion, and no reference to the sibling tools it overlaps with (e.g. get_artwork).

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 and closed-world behavior, so the bar is lower. The description adds genuinely useful return content (dates, number of works, Artnap page), but says nothing about matching semantics (case sensitivity, word-splitting), result ordering, or what happens 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?

A single compact sentence with no filler, and the resource plus match criterion are front-loaded. It reads as a phrase rather than a complete sentence, but nothing 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?

With no output schema, the description helpfully enumerates the returned fields, which is the right call. However, for a search tool it omits result-cap behavior and matching rules, so an agent cannot fully predict the shape or size of results without trial and error.

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 only 50%: q is documented in the schema as 'part of the artist name', and the description's 'matches the words given' adds little beyond that. The limit parameter – which caps results at 50 with a default of 20 – is never mentioned in the description, so the pagination/result-size behavior is only inferable from type constraints.

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 concrete resource (artists in the Artnap archive) and the selection criterion (name matches the given words), and it names the fields returned (dates, work count, Artnap page). It distinguishes itself from siblings like search_artworks and get_artwork by being artist-only, though it is phrased as a noun fragment rather than a verb+resource 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?

There is no explicit guidance on when to use this versus search_artworks (which presumably also accepts a query string) or list_museums. The only implied cue is 'name matches the words given,' from which an agent must infer substring name search. No exclusions or alternatives 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=false, and destructiveHint=false, so safety behavior is covered. The description adds useful context that libraries are included alongside museums and what each entry contains, but it does not disclose ordering, completeness, or pagination 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?

A single compact sentence front-loads the resource scope and efficiently includes the return fields. There is no redundant or filler language.

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 rich annotations and no output schema, the description conveys the returned entities and their fields well enough. A minor gap is the absence of any statement about ordering or whether the list is 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?

The tool has zero parameters, so the baseline is 4. The description appropriately does not discuss parameter semantics, as there are none to explain.

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 resources (museums and libraries) and the data returned for each (number of works and Artnap page). It distinguishes itself from siblings like list_artists by resource scope, though it does not explicitly use a verb like 'list'.

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: call this to see which institutions contribute collections and how many works each has. There is no explicit guidance on when to use this versus searching or getting artwork details, and 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, idempotentHint, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds public-domain scope and a useful return summary, but omits ordering, pagination, rate limits, and auth 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, front-loaded with purpose, and the return-field summary earns its place. There is no redundant or filler text.

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 five optional parameters, full schema coverage, and rich annotations, the description covers purpose and returned data adequately. The main minor gap is that it does not mention result ordering or pagination, though the schema's limit parameter partially covers quantity.

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 five parameters are already documented in the schema. The description adds no parameter-specific semantics beyond the general search scope, making the baseline 3 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 and resource: search the Artnap archive of paintings, drawings, prints and posters, with the return fields listed. It implicitly separates itself from get_artwork and the list_* tools by resource and action, but never explicitly names a sibling or draws 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?

Usage is implied by 'Search' and the filter-oriented schema, but the description gives no explicit when-to-use guidance, no exclusions, and no comparison to get_artwork or list_artists/list_museums for resolving names.

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