PaKi Curator — Visual Medicine Art Catalog

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

With no annotations, the description carries the full burden for behavioral disclosure. The verb 'browse' implies a read-only operation, and it adds context about collection contents ('unique curatorial essence, profile, and recommended viewing context'). However, it doesn't explicitly state that no modifications occur, nor does it clarify the return format or pagination behavior. This is moderate transparency, earning a 3.

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

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

The description is two sentences, highly concise, and front-loaded with the key action ('Browse all 13 collections and singles'). Every word adds value, and there is no redundant or vague phrasing.

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 low complexity (one optional parameter, no output schema, no annotations), the description provides sufficient context: it states the scope (13 collections and singles) and hints at the kind of information available. It doesn't explain every edge case, but for a simple listing/browsing tool, this is adequately 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 fully documents the single optional parameter 'collection' with a clear description. The tool description adds minimal extra meaning (e.g., mentioning curatorial essence), but this is not necessary for understanding the parameter. With 100% schema coverage, the baseline is 3, and the description doesn't significantly enhance it.

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 clear purpose: 'Browse all 13 collections and singles in César Yagüe's catalog.' It uses a specific verb ('browse') and resource (collections/singles), making its function understandable. However, it does not explicitly differentiate from sibling tools like search_artworks or catalog_overview, so it earns a 4 rather than a 5.

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

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

The description implies usage—browsing collections—but provides no explicit guidance on when to choose this tool over alternatives. For instance, it doesn't say 'use this to get an overview of all collections' or 'for specific artwork details, use get_artwork.' This is clear context without exclusions, aligning with an implied usage score of 3.

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. It clearly discloses the return contents (total works, collections, price range, resolutions, availability stats) and an introduction to Visual Medicine, implying a read-only operation. However, it doesn't mention data freshness or any limitations.

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 main purpose and then lists data points. Every element adds value, though the long enumeration could be slightly more structured.

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 read-only overview, the description provides a thorough account of expected return data. Since there is no output schema, this description fully compensates by listing all key outputs.

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 schema is already fully covered. The description adds value by detailing the output scope, which is a useful complement to the empty 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 uses the specific verb 'Get' and clearly identifies the resource as 'high-level overview of the entire art catalog', enumerating its contents. This distinguishes it from sibling tools that focus on specific artworks, collections, or recommendations.

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 usage for a broad catalog summary, but it doesn't explicitly state when to use this tool versus searching for specific artworks or browsing collections. No exclusions or alternative tool mentions are provided.

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

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

The description lists the specific attributes returned, which helps set expectations. However, it doesn't clarify how partial name matches are handled (e.g., multiple results) or whether the operation is strictly read-only, which is important since there are no 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?

Single sentence, front-loaded with the primary action, no filler. 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 simple single-parameter lookup, the description covers the output fields and the lookup mechanism. The lack of an output schema and annotations means the description carries weight, and it does a good job, though partial-match behavior remains unclear.

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 only parameter 'name' is fully described in the schema with examples. The description adds no additional semantic detail beyond restating that lookup is by name, so it doesn't exceed the 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 it retrieves complete details for a specific artwork by name, listing the specific types of details returned. This distinguishes it from siblings like search_artworks (search) and browse_collections (browse) 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 phrase 'by name' and the inclusion of partial name matching provide clear context for when to use this tool—when the agent has an artwork identifier. It doesn't explicitly mention when not to use it, but the context is sufficient.

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 more responsibility. It adds value by revealing that recommendations are driven by curatorial criteria (vibrational frequency, audience type, artistic essence), which sets expectations. Yet it does not mention output format, empty-result behavior, or how optional filters interact with curation.

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 the primary purpose. Every phrase contributes meaning; there is no filler, redundancy, or unnecessary detail.

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 core use case and decision logic, and the schema thoroughly documents all five parameters. It falls slightly short on return-format details due to the lack of an output schema, but the purpose and criteria are sufficiently clear 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 100%, so the baseline is 3. The description reinforces space_description as the central input and introduces the curatorial criteria, but it doesn't enhance understanding of count, budget_max, resolution, or orientation beyond what the schema already 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 opening phrase 'Get art recommendations for a specific space or environment' uses a clear verb-object structure. It differentiates itself from sibling search/browse tools by centering on space-aware curation rather than direct querying.

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 tells users to 'Describe the space' to trigger recommendations, which implies the tool is appropriate when there is a physical or environmental context to curate for. However, it doesn't explicitly state when to prefer this over search_artworks or browse_collections, so no alternative exclusion is given.

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

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

With no annotations, the description carries the full transparency burden. It discloses that this sends a 'real inquiry' and that PaKi will notify César via Telegram and follow up personally, making clear this triggers actual human communication rather than being a simulation.

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

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

Three sentences, each serving a distinct purpose: what the tool does, how the inquiry is handled, and when to use it. No redundant phrases or unnecessary details, and the most critical information is placed first.

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 realistic action tool with no output schema and 8 parameters, the description adequately explains the purpose, process (Telegram notification, personal follow-up), and target audience. It doesn't specify response times or reversibility, but the process description provides a reasonable level of completeness.

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 provides 100% coverage for all 8 parameters, each with its own description. The tool description adds overall context (acquisition vs collaboration) but does not clarify parameter-specific syntax or formats beyond what the schema already contains, so it stays at the 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 uses a specific verb 'Send' and names the recipients (PaKi and César Yagüe) and purposes (acquiring artworks, collaboration, other matters). It clearly distinguishes from sibling tools like search_artworks and recommend_for_space by being the action-oriented inquiry submission 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 final sentence provides explicit usage context: 'Use this when a client, architect, gallery, hotel, or collaborator expresses genuine interest.' This clearly indicates appropriate scenarios, though it does not explicitly name alternatives or exclusion conditions beyond the 'genuine interest' qualifier.

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. It adds useful context by describing the nature of the artworks ('contemplative moving art works') and the return content ('curatorial descriptions'). For a search operation, this is sufficient transparency; side effects are absent and defaults are left to the schema.

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

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

Two focused sentences: the first states the purpose, the second enumerates filters and the return value. No wasted words, and the most critical 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?

Given the tool's complexity (11 optional parameters, no output schema), the description adequately covers the core purpose, filter options, and return value. It could mention default ordering or pagination, but the schema handles those details. It is complete enough for an agent to understand the tool's role without confusion.

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 input schema provides 100% coverage with detailed descriptions for all 11 parameters, making the baseline 3. The description adds an aggregated summary of filter types (keywords, collection, resolution, price range, orientation, space type) but does not add new semantics beyond what the schema already 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?

The description uses a specific verb ('Search') and identifies the resource ('César Yagüe's art catalog of contemplative moving art works'), clearly differentiating it from siblings like browse_collections and get_artwork. It also lists the primary filter dimensions, making the tool's function immediately 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 this is the tool for searching and filtering the catalog by keywords, collection, resolution, etc. While it doesn't explicitly state when-not-to-use or name alternative tools, the context is clear and the filter list effectively defines its use case.

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