PaKi Curator — Visual Medicine Art Catalog

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

With no annotations, the description must cover behavioral traits, but it only implies a read-only browse operation and does not disclose permissions, side effects, or return format details such as pagination.

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 provide clear purpose and additional context without redundancy, making the description concise and front-loaded with essential 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?

The description outlines key return aspects (essence, profile, context) despite no output schema, but could be more complete by mentioning listing behavior or the structure of a collection overview.

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 description adds meaning beyond the schema by explaining that collections have 'curatorial essence, profile, and recommended viewing context', enriching the understanding of the optional 'collection' parameter's return data.

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 'browse' and the resource 'all 13 collections and singles in César Yagüe's catalog', distinguishing it from sibling tools like 'get_artwork' or 'search_artworks' which focus on individual artworks or searches.

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 on when to use this tool versus alternatives like catalog_overview or search_artworks. The description lacks explicit context about appropriate use cases 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 what data is returned (total works, price ranges, Visual Medicine intro), adding valuable behavioral context. However, it lacks explicit safety information (read-only status, idempotency, side effects) that would be necessary for a complete behavioral profile without 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 core action. Every clause serves a purpose: the action ('Get a high-level overview'), the scope ('entire art catalog'), and the specific return values (colon-separated list). Zero 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?

Given zero parameters and no output schema, the description compensates adequately by enumerating the expected return values (stats, ranges, intro). For a simple aggregate retrieval tool, this is sufficient, though an output schema would improve completeness 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?

The input schema contains zero parameters. According to calibration guidelines, 0 params = baseline 4. The description correctly provides no parameter details since none exist, and no compensation is needed.

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 ('Get') and resource ('high-level overview of the entire art catalog') and clearly distinguishes this from siblings by emphasizing 'overview' versus their specific retrieval functions (browse, get, search, recommend). It enumerates specific data points returned (total works, collections, price range, resolutions, availability stats).

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?

While the description does not explicitly state 'use this when...' or name alternatives, the phrase 'high-level overview of the entire art catalog' provides clear contextual differentiation from siblings that target specific artworks, collections, or searches. The scope is unambiguously broad/summary-level.

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 disclosing what the tool returns. It comprehensively lists return fields (curatorial essence, vibrational frequency, pricing, etc.) which is critical given the lack of output schema. However, it omits safety context (read-only nature) and error behavior (e.g., partial name matching 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?

Single sentence structure front-loads the action ('Get complete details') and efficiently enumerates return fields without filler. Every clause earns its place by conveying either the operation or return value specifics.

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 simple single-parameter input and lack of output schema, the description appropriately compensates by detailing return fields. However, it lacks error-handling context (what happens when partial matches return multiple results or no matches) given the 'partial name' capability in the 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% with the 'name' parameter already documented with examples and partial-name semantics. The description mentions 'by name' but adds no additional syntax, validation rules, or format details beyond the schema. Baseline 3 is appropriate when schema is complete.

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 specific verb 'Get' with resource 'artwork' and clarifies scope ('complete details'). It implicitly distinguishes from sibling tools: 'specific artwork by name' contrasts with 'search_artworks' and 'browse_collections', while the detailed field list differentiates from '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 usage context ('by name') suggesting use when the artwork name is known, but lacks explicit when-to-use guidance or contrast with 'search_artworks' for fuzzy discovery versus exact retrieval.

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, description carries full burden. It adds valuable context about recommendation logic ('vibrational frequency', 'ideal spaces', 'audience type') but omits safety profile (read-only vs. destructive), idempotency, or error conditions. No contradiction with annotations (none provided).

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 efficient sentences with zero waste. Front-loaded with action ('Get art recommendations'), followed by mechanism ('PaKi will suggest...based on...'). Every clause 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?

Adequate for the input side given 100% schema coverage, but lacking return value description and safety/disposition details. Without output schema or annotations, the description should ideally disclose what the recommendations look like (format, content richness).

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%, establishing baseline 3. Description mentions 'Describe the space' which aligns with the required parameter, but adds no syntax, format constraints, or semantic details 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?

Clear specific verb ('Get') and resource ('art recommendations') with explicit scope ('for a specific space or environment'). The mention of 'curatorial criteria' and 'PaKi' distinguishes this from sibling search/browse tools by emphasizing contextual curation over simple retrieval.

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?

Provides clear context distinguishing it from siblings—focusing on spatial/environmental recommendation versus general search or browsing. However, lacks explicit 'when not to use' guidance or direct comparison to alternatives like search_artworks.

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 provided, so the description carries full burden. It discloses that PaKi will notify César via Telegram and follow up personally, and for licensing it routes to César directly. This provides useful behavioral context beyond just the function.

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?

Description is concise, with 3 sentences front-loading the core purpose. Every sentence adds value: action, recipients, purpose, usage guidance, and behavioral context. No 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?

Given 8 parameters (3 required), full schema coverage, and no output schema, the description covers the tool's purpose, usage, and behavior. It could specify return values, but the real-world action (notification sent) is implied. Mostly complete for its 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?

Schema coverage is 100% and parameter descriptions are detailed (e.g., inquiry_type enum with explanations). The tool description does not add additional meaning to parameters beyond what the schema already provides, so 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 sends a real inquiry to specific artists (PaKi and César Yagüe) for acquiring artworks, proposing collaborations, or other matters. It distinguishes from siblings (browse, search, recommend) which do not send inquiries.

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 says 'Use this when a client, architect, gallery, hotel, or collaborator expresses genuine interest.' While it doesn't list explicit alternatives, the context makes it clear when to use it versus the other browse/search tools.

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 states the tool returns matching artworks with curatorial descriptions, which is appropriate. However, it doesn't disclose pagination behavior (beyond the limit parameter), sorting, or any side effects. As a search, it's fairly transparent but could mention that it is read-only.

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 clear sentences: the first describes the action and scope, the second lists filters and return value. No redundant words, front-loaded with 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?

With 9 optional parameters and no output schema, the description could be more complete. It doesn't explain the structure of returned artworks (beyond 'curatorial descriptions'), nor clarify that it covers 'moving art' (video). It should note that results include matching artworks, but lacks detail on fields like images, dimensions, etc.

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 description adds limited new meaning. It groups filter types but doesn't explain parameter usage beyond what schema provides. For example, 'space_type' is listed but not elaborated. 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 a specific catalog (César Yagüe's art catalog) with a distinct focus ('contemplative moving art works / Visual Medicine') and lists filterable attributes. It distinguishes from sibling tools like browse_collections and get_artwork by specifying search functionality.

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 indicates when to use (search with filters) but lacks explicit guidance on when not to use or alternatives. For example, it doesn't mention that catalog_overview might be better for a broad introduction or recommend_for_space for space-specific recommendations.

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