PaKi Curator

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

With no annotations, the description carries the behavioral disclosure burden, and it does so well: it states the fixed scope of 15 collections, the per-collection work counts, the optional drill-down to full works, and the conditional curatorial capsule. It does not detail error behavior or response structure, but the main behavioral traits are disclosed.

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 deliver the primary behavior, the parameter behavior, and the conditional detail, in order of importance. There is no filler 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?

For a one-optional-parameter tool, the description covers both invocation modes and what to expect in each, including the conditional capsule. No output schema is supplied, but the description gives enough return-context for an agent to use 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?

Input schema covers the single optional parameter at 100% with 'Omit to list them all.' The description adds the key semantic that the parameter is a collection name and that supplying it returns the works in full, which is useful beyond the bare schema text.

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 begins with a specific verb and resource: 'List the 15 collections and singles, each with the number of works it holds,' and further explains the drill-down behavior of requesting a collection by name. It is clear on its own, though it does not explicitly contrast itself with siblings such as search_artworks or catalog_overview.

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 how to use the tool: browse the full list, or ask for one collection by name to see its works. It does not state when to prefer this over sibling tools or when not to use it, leaving the routing decision 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It communicates that this is an overview-style read operation ('view') and reveals what data categories are included, such as totals, price range, and measured items. However, it does not explicitly state side-effect safety, return shape, or any limitations beyond being high-level, so it is adequate but not richly transparent.

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, well-structured sentence that front-loads the core purpose ('high-level view of the whole catalogue') and then efficiently enumerates the included data dimensions. Every part of the sentence provides useful information and there is no filler or redundancy.

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

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

This is a simple, parameterless overview tool with no output schema. The description sufficiently explains what the agent will get—totals, collections, resolutions, price range, availability, and measurement progress—so an agent can correctly decide to invoke it and know what to expect. Nothing essential is missing for this level of 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?

The tool has zero parameters and schema coverage is 100%, so the schema already fully describes the parameter surface. The description adds no parameter semantics, but the baseline for a zero-parameter tool is 4, and there is no gap to compensate for.

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 as providing a high-level view of the entire catalogue and lists concrete contents: totals, collections, resolutions, price range, availability, and measurement status. It does not use an explicit verb like 'gets' or 'returns', but the scope and contents are specific enough to distinguish it from collection browsing, searching, ranking, and recommendation 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 implies this is for an overall catalogue summary but gives no explicit guidance on when to use it versus alternatives like browse_collections or search_artworks. There is no 'use this when' or 'for detailed views use X instead' guidance, leaving the agent to infer the appropriate context.

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 present, so the description carries the behavioral disclosure burden. It makes the read-only nature clear through 'Retrieve' and importantly discloses the key quirk: an ambiguous title returns all matching works instead of guessing. It does not cover not-found or authentication behavior, but the core retrieval behavior is transparent for a simple get-style 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?

One dense, well-structured sentence front-loads the action and result, then folds in the ambiguity rule without filler. Every phrase contributes useful 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?

Given only one required parameter and no output schema, the description is largely complete: it states what is returned and how ambiguous titles behave. The main omission is explicit handling of not-found cases, but that is a minor gap for a simple retrieval 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 coverage is 100% because the single parameter 'name' is already described as 'Artwork identifier, or its name. An ambiguous name returns every candidate.' The description repeats that input mode and ambiguity behavior, so it adds no significant parameter meaning 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 description opens with a specific verb and object—'Retrieve one artwork in full'—and lists the exact content area of the result: technical specification, availability, price, curatorial capsule, and physics. This clearly distinguishes it from the catalog/browse/search sibling tools, which would not return a single full artwork record.

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 right usage context—when a complete single artwork record is needed—and clarifies that it accepts either an identifier or a title. However, it does not explicitly state when to prefer this over search_artworks or browse_collections, and it names no alternatives 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?

With no annotations, the description carries the burden. It usefully discloses that all values are measured frame-by-frame from the master and that 'nothing here is described', signaling objective ranking. It omits details on output format, side effects, or scope limitations, though the read-only nature is reasonably inferable.

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 reasonably compact, front-loaded with the main action, and supported by illustrative examples. The 'frame by frame' phrase is slightly opaque and the poetic closing adds mild flourish, but overall every section 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?

The core ranking behavior and typical use cases are covered, but with no output schema and no annotations, the description leaves count and availability unexplained and gives no concrete idea of return structure. It is adequate for a simple ordering tool but not fully complete.

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 documents order, metric, and collection, and the description adds natural-language meaning to the metric examples and collection scoping. However, count and availability have no schema description and are not explained in the description, leaving meaningful coverage gaps at 60%.

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: ordering the catalogue by a measured axis, with concrete example questions like 'the stillest work' or 'the brightest'. It implicitly differentiates from search_artworks by emphasizing numeric measurement over description, making its role 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?

It gives clear usage context with example user queries and signals that this is for ranked, measurement-based questions. However, it does not explicitly state when not to use it or name alternative tools such as search_artworks, so routing guidance is incomplete rather than fully 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?

With no annotations, the description carries the full burden, and it discloses important behavior: each suggestion includes its measurement, and an empty result returns a clear 'nothing fits' statement instead of a forced nearest item. It stops short of describing how all optional parameters affect behavior, but the key non-obvious traits are surfaced.

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 tight sentences: the first states the action and outcome, the second names the key decision factors, and the third handles edge-case behavior. Every sentence earns its place with no 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?

For a tool with 10 parameters and no output schema, the description gives a viable call path and explains the return will include measurements and a no-match case. It is enough for a first call, but it leaves the semantics of several optional params and the exact response structure undocumented.

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?

Most parameters have descriptions in the schema, and the description reinforces orientation, room light, distance, and screen size as decision factors. It doesn't add meaningful semantics for count, colour, movement, attention, or budget_max beyond what the schema already provides. This is adequate but not compensating beyond the schema 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 clearly states what the tool does: given a space description, it returns works that fit, each with a measurement. It also distinguishes itself by promising an explicit 'nothing fits' answer rather than a nearest match. It doesn't explicitly name sibling alternatives, but the space-based framing is distinctive enough.

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 it: when the input is a free-text space description, and it calls out key deciding factors like orientation, room light, viewing distance, and screen size. It does not explicitly say when to prefer it over siblings such as search_artworks or rank_artworks, nor does it give 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?

With no annotations provided, the description carries the behavioral disclosure burden. It adds a meaningful behavioral guarantee: 'It never reports success unless the message actually left.' This reduces hallucination risk and clarifies that the tool performs a real external side effect, though it does not cover failure modes or rate limits.

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 concise sentences with no filler. The action is front-loaded, followed by prerequisites and a key behavioral caveat. 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 an 8-parameter tool with no output schema or annotations, the description covers the purpose, prerequisites, and success semantics well. It does not specify the exact return format, but the final sentence implies a success/failure report, which is likely sufficient for an agent to invoke 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 description coverage is only 13%, so the description must compensate. It adds semantic meaning for inquiry_type ('acquisition, exhibition or press'), contact_email ('a way to reply'), and space_description, but leaves several optional parameters like budget_range, artworks_of_interest, and message without explanation beyond their names.

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 ('Open a real enquiry with the studio') and a specific resource, with explicit types ('acquisition, exhibition or press'). It clearly distinguishes this from all sibling tools, which are browse/catalog/get/rank/recommend/search operations.

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 clear context for when to use the tool: when a genuine inquiry needs to be sent to the studio. It also states prerequisites ('Requires a way to reply and a description of the space or project'), though it does not explicitly name alternatives or say when not to use it.

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 does add meaningful context beyond the schema by explaining that dominant colour is 'measured from every frame of the master rather than described' — a non-obvious behavior. However, it is silent on other behavioral aspects such as read-only nature, default ordering, pagination, or rate limits. For a search tool these are less critical, but the lack of any safety/performance context keeps this at a mid score.

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, well-organized sentence that front-loads the core action ('Search the catalogue...') and then lists the key filter dimensions. It avoids redundancy with the schema and is efficient. The only slight issue is that it does not use bullets or other structure to parse the list of filters, but given the moderate length, it remains readable and earns a 4.

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 (11 parameters, no output schema, no annotations), the description covers the main search and filter capabilities but omits important execution details: how results are ordered by default, how limit works, what the return payload looks like, and whether filters are combined with AND or OR. It is adequate for guiding an agent to the right tool, but not complete enough for a complex search endpoint.

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 45%, so the description must compensate for the many undocumented parameters (limit, order, sort_by, min_price, max_price). It does add some meaning by grouping filters ('price' covers the min/max range) and clarifying the colour parameter's measurement method. But it does not explain sorting options, limits, or the semantics of order asc/desc. It partially bridges the gap, but not enough to earn a 4.

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 catalogue of 296 moving-image works by César Yagüe.' It then enumerates the filter dimensions (collection, orientation, resolution, availability, price, free text, dominant colour), which clearly distinguishes it from sibling tools like browse_collections (browsing) or get_artwork (retrieving a single record). An agent can immediately tell this is the search/filter 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 clearly implies when to use this tool: when you need to find works by filtering on any of the listed attributes. It does not explicitly name alternatives or state when not to use it, but the filter-focused language makes the use case obvious. There are no exclusions or misleading cues, but the lack of explicit comparison to siblings like 'rank_artworks' or 'recommend_for_space' costs the fifth point.

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