Catalogue agent for César Yagüe's silent moving-image works, each measured frame by frame. Search the catalogue, read a work in full with its curatorial capsule, rank works on a measured axis, get recommendations for a described space, and open an enquiry with the studio. No authentication.
Scored across 7 tools
Most tools have clearly distinct roles: get_artwork retrieves one work, rank_artworks sorts by a measured axis, recommend_for_space matches works to a described space, and request_inquiry opens an enquiry. There is mild overlap between search_artworks, browse_collections and catalog_overview (all surface catalogue contents), but the descriptions draw usable boundaries between full-text search, collection listing, and aggregate stats.
The set follows a clean verb_noun snake_case pattern (browse_collections, get_artwork, rank_artworks, recommend_for_space, request_inquiry, search_artworks). Only catalog_overview breaks the verb_ prefix convention by using a noun, a minor deviation that remains readable.
Seven tools is well-scoped for a curated catalogue: discovery (search, browse, overview), detail (get_artwork), analysis (rank_artworks), recommendation (recommend_for_space), and a transaction (request_inquiry). Each tool earns a distinct place with no obvious redundancy.
The surface covers the full lifecycle for a read-oriented catalogue server: overview, browsing, search, single-item detail, ranking, space-based recommendation, and enquiry submission. Since this is a curated read-only collection with an inquiry channel, no create/update/delete operations are expected, leaving no dead ends.
List the 15 collections plus Singles, each with the number of works it holds. Ask for one by name to get its works in full. Each collection includes its curatorial capsule alongside the works it contains.
| Name | Required | Description | Default |
|---|---|---|---|
| collection | No | Omit to list them all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is fully covered. Beyond that, the description adds return-content context: counts per collection and the curatorial capsule bundled with the works. It stops short of describing pagination or ordering, but for this tool the annotations plus the content hints are sufficient.
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, front-loaded with the no-argument behavior and followed immediately by the argument behavior. The final sentence is mildly redundant with the earlier mention of works, 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?
No output schema exists, so the description must convey the return shape, and it does so partly (counts, curatorial capsule, full works when named). For a simple one-optional-parameter browse tool with full annotation coverage, this is complete enough to invoke 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 coverage is 100%, so baseline is 3, but the description genuinely adds meaning beyond the schema's terse 'Omit to list them all': it explains that supplying a name yields the collection's works in full, which clarifies the consequence of the parameter rather than its mere presence.
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+resource (list collections with work counts) and a query mode (ask for one by name to get its works). The scope ('the 15 collections plus Singles') is concrete. It does not explicitly differentiate itself from catalog_overview, which is the closest sibling and could plausibly be confused with it.
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 describes the two modes and the condition that selects between them: omit the name to list all, supply a name to get that collection's works in full. That is clear usage context, though it names no alternative tool and gives no exclusions vs catalog_overview.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A high-level view of the whole catalogue: totals, collections, resolutions, price range, what is available, and how much of it has been measured.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare it read-only, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds value by enumerating the facets returned (totals, collections, resolutions, price range, availability, measured coverage) - useful since there is no output schema - though it says nothing about payload size or 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?
A single front-loaded sentence with no wasted words, and the scope enumeration is placed immediately after the framing phrase.
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 parameters, the description's enumeration of returned facets is what makes the tool callable with confidence. It is nearly complete; a one-clause pointer to the sibling tools for follow-up exploration would close the remaining 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?
Zero parameters, so per the rubric the baseline is 4; there is nothing parameter-level for the description 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?
States a specific resource (the whole catalogue) and enumerates its scope (totals, collections, resolutions, price range, availability, measurement coverage). It reads as a summary/aggregate tool, distinguishable from browse_collections and search_artworks, though it never names those 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?
Usage is only implied: 'a high-level view' suggests an entry point before drilling into collections or search, but the description never states when to prefer this over browse_collections or search_artworks, nor any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve one artwork in full: technical specification, availability, price, the physics measured from its master, and, when available, the curatorial capsule. Accepts the identifier or the title — and when a title belongs to more than one work, it returns them all rather than guessing.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Artwork identifier, or its name. An ambiguous name returns every candidate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds real behavioral context on top: an ambiguous title returns every candidate instead of guessing, and it discloses the response payload shape (spec, price, physics, capsule availability).
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?
Front-loads the verb and payload in one sentence, then uses the second clause for the ambiguity rule. Dense but every clause earns its place; the parenthetical 'when available' qualifier is slightly buried but not wasteful.
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 must carry return-value information, and it does — it names the payload components and flags that the curatorial capsule is conditional. Combined with the ambiguity contract, an agent has enough to call and interpret it 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% for the single 'name' parameter, so the baseline is 3. The description restates the identifier-or-title duality and the multi-candidate behavior, which largely duplicates what the schema already says rather than adding syntax or format detail.
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 ('Retrieve one artwork in full') and enumerates exactly what comes back: technical specification, availability, price, master-derived physics, and curatorial capsule. An agent can distinguish it from search_artworks and browse_collections, which query many works rather than resolving one.
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 clarifies the lookup key (identifier or title) and the ambiguity path, which is genuine usage guidance. But it never says when to prefer this over search_artworks or browse_collections, nor when it should not be used, so routing to the correct sibling is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Order the catalogue by one measured axis — rhythm of change, luminance, peak brightness, colour travel, empty space, and the rest — from lowest to highest or the reverse, and read where each work sits on the catalogue's own scale. Use it for questions like "the stillest work you have" or "the brightest, in this collection". Every number comes from the master, frame by frame; nothing here is described.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | ||
| order | No | asc = lowest first (the stillest, the darkest); desc = highest first | |
| metric | Yes | The measured axis to order by | |
| collection | No | Restrict to one collection | |
| availability | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so safety is covered. The description adds genuinely new behavioral context: the numbers are measured frame-by-frame from the master asset rather than from descriptive metadata, which tells the agent what kind of values to expect. It omits pagination/count behavior and default ordering details.
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, front-loaded with the action and axis, with the example questions placed after the mechanics. The closing flourish ('nothing here is described') is slightly literary but does carry meaning about provenance, so 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?
With five parameters and no output schema, the description should say more about what a call returns (e.g., a ranked list with per-work scores) and what count defaults to. It implies a ranked readout ('read where each work sits') but leaves the response shape and count semantics to inference.
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 60% and three parameters carry enums, so the schema does much of the work. The description names several metric axes (rhythm, luminance, peak brightness, colour travel, empty space) and paraphrases the order semantics, but these largely restate the enum values and add nothing for count, collection, or availability. Baseline 3 fits.
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 (Order/rank) and resource (the catalogue) plus the axis of ordering, which clearly separates it from browse_collections or search_artworks. It does not name a sibling or explicitly disclaim other tools, but the ranking framing 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?
It gives concrete trigger questions ('the stillest work you have', 'the brightest, in this collection') that map cleanly onto the arguments, so an agent knows what kind of request this serves. It stops short of stating when NOT to use it or pointing at search_artworks for keyword/filter queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describe a space and receive the works that fit it, each with the measurement behind the suggestion and its curatorial capsule. Room light, viewing distance, screen size, attention and movement are measured; collection, resolution, orientation, colour and budget are hard limits, and a work that may be rotated counts for the other orientation. If nothing fits, it says which requirement leaves nothing instead of offering the nearest thing.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | ||
| colour | No | ||
| movement | No | Very still, or full of life? Measured rhythm, on the catalogue scale | |
| screen_m | No | Screen diagonal in metres | |
| attention | No | Should it accompany, or hold the eye? | |
| budget_max | No | ||
| collection | No | Recommend only from this collection | |
| distance_m | No | Metres from viewer to screen | |
| resolution | No | Only works native to this resolution label (HD, 4K, 8K, 16K…; square works carry their own, such as 2K) | |
| room_light | No | ||
| orientation | No | ultrawide = at least twice as wide as tall (21:9 and wider); landscape includes it | |
| space_description | Yes | The room in your own words |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds real behavioral context beyond them: which inputs are soft measurements versus hard filters, the rotation rule, that each result carries its measurement and curatorial capsule, and the failure mode of naming the blocking requirement instead of returning a near match. This is notably more than the annotations convey.
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 dense sentences, front-loaded with the core action and return value, then the constraint model, then the failure behavior. No filler and every clause carries 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 12 parameters, no output schema, and only 67% schema coverage, the description does the needed work by describing the return contents (measurement plus capsule) and the no-match behavior. The undocumented 'count' parameter is the only notable omission.
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 67%, and the description supplements it meaningfully by partitioning parameters into measured soft factors (room light, viewing distance, screen size, attention, movement) versus hard limits (collection, resolution, orientation, colour, budget) and clarifying the rotation/orientation rule. It does not explain 'count', which keeps it short of a 5.
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 (recommend) and resource (works fitting a described space) and describes both the input gesture and the returned artifact (works plus the measurement and curatorial capsule). It is clearly distinct from search_artworks and rank_artworks by being space-driven, but it never names a sibling to route against 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: describe a space when you want fittings rather than to browse or query. The description does not state when to prefer this over search_artworks or rank_artworks, nor any prerequisites, so guidance stays at the inferred level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a real enquiry with the studio: acquisition, exhibition or press. Requires a way to reply and a description of the space or project. It never reports success unless the message actually left.
| Name | Required | Description | Default |
|---|---|---|---|
| message | No | ||
| agent_name | No | The agent sending this on behalf of a client | |
| budget_range | No | ||
| contact_name | Yes | ||
| inquiry_type | No | ||
| contact_email | Yes | ||
| space_description | Yes | ||
| artworks_of_interest | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=false, openWorld=true, idempotent=false, destructive=false. The description adds a genuinely non-obvious behavioral trait: it only reports success when the message actually left, which tells the agent how to interpret the response. It does not cover duplicate-submission risk beyond the idempotency hint already in 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?
Three short sentences, each earning its place: purpose, prerequisites, and response semantics, front-loaded with the action.
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 write tool with no output schema, the description covers the intent, the required inputs, and the success-reporting contract. The remaining gap is the under-documented optional parameters (budget_range, artworks_of_interest), which leaves the agent guessing at expected formats.
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% (just agent_name), so the description must compensate and does so only partially: 'a way to reply' maps to contact_email and 'a description of the space or project' to space_description, and the inquiry types are echoed. Nothing is said about budget_range, artworks_of_interest, message, or contact_name.
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 ('Open a real enquiry with the studio') and enumerates the inquiry domains (acquisition, exhibition, press). It is unmistakably distinct from the read-only catalog 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?
Gives clear context plus prerequisites ('Requires a way to reply and a description of the space or project'), which tells the agent what must be supplied before calling. It stops short of naming alternatives or stating when not to use it, but the siblings are unrelated read tools so that omission is minor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the catalogue of 296 moving-image works by César Yagüe by free text, collection, resolution, orientation (including ultrawide), colour measured from every frame (a basic colour counts its whole family), price, year, loop length, rotation and availability. A short page brings each work's curatorial capsule. Asking about flashes or epilepsy returns the works with measured abrupt light events.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Year the work was created | |
| limit | No | ||
| order | No | ||
| query | No | Free text across titles, descriptions and curatorial notes | |
| colour | No | Dominant colour by name (gold, teal, crimson…) or hex. Measured from every frame. | |
| offset | No | Skip this many results, to read the next page | |
| sort_by | No | ||
| rotation | No | Whether the work must keep its orientation or may be rotated 90 degrees | |
| max_price | No | ||
| min_price | No | ||
| collection | No | Collection name | |
| resolution | No | The resolution label each work shows, matched exactly: HD, 4K, 5K, 8K, 10K, 12K, 16K; square works carry their own, such as 2K or 3K. An unknown label returns the list in use. | |
| max_seconds | No | Longest loop length, in seconds | |
| min_seconds | No | Shortest loop length, in seconds | |
| orientation | No | ultrawide = at least twice as wide as tall (21:9 and wider); landscape includes it | |
| availability | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety bar is covered. The description adds genuinely useful non-obvious behavior: colour families are collapsed ('a basic colour counts its whole family'), ultrawide is nested inside landscape, pages are short and return a curatorial capsule, and flash/epilepsy questions trigger a special abrupt-light-event result set.
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 dense sentences front-load the scope and facet list, then cover return shape and the special flash query. Efficient with no filler, though the facet enumeration is packed tightly enough to be slightly list-like.
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 16-parameter, zero-required search tool with no output schema, the description covers scope, filterable dimensions, return shape ('a short page brings each work's curatorial capsule'), and one non-obvious query mode. Nothing essential to calling it correctly 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?
At 63% schema coverage across 16 params, the description has to compensate and largely does: it names nearly every filterable dimension (colour semantics, loop length, rotation, availability, orientation hierarchy) and clarifies behaviour the schema does not, such as colour family grouping and ultrawide inclusion. It still leaves a few parameters (limit/order/sort_by nuances) to 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?
States a specific verb (Search) and resource (the catalogue of 296 moving-image works by César Yagüe) and then enumerates the exact facets that make this a search tool — free text, collection, resolution, orientation, colour, price, year, loop length, rotation, availability. An agent can distinguish this from get_artwork (single fetch), browse_collections (collection taxonomy), and catalog_overview without opening a schema.
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: the enumeration of queryable facets tells the agent this is the retrieval tool for filtered/free-text queries, and the flash/epilepsy sentence hints at a special query mode. But it never explicitly says when to prefer this over browse_collections or get_artwork, and gives no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
browse_collectionscatalog_overviewget_artworkrank_artworksrecommend_for_spacerequest_inquirysearch_artworks
Add one secure layer between your agents and this server.