Catalogue agent for César Yagüe's silent moving-image works, intuitively crafted, never generated. 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 8 tools
Most tools have clearly distinct roles: read tools (get_artwork, search_artworks, rank_artworks, recommend_for_space) split by operation, and the inquiry flow splits cleanly into a draft step (request_inquiry) and a send step (confirm_inquiry). The main soft spot is browse_collections vs catalog_overview vs search_artworks, which all survey the catalogue at different granularities; the descriptions disambiguate them but an agent could still hesitate over which to call first.
All eight names use lowercase snake_case and are highly readable. Seven follow a verb_noun pattern (browse_collections, get_artwork, rank_artworks, etc.), with catalog_overview the lone noun_phrase outlier, a minor deviation rather than a break in convention.
Eight tools is well-scoped for a curated artwork catalogue: four discovery/query tools, one collection browser, one catalogue summary, and a two-step inquiry flow. Each tool earns its place and none appears redundant or padded.
The surface covers discovery (search, browse, overview), inspection (get_artwork), analysis (rank_artworks), matching (recommend_for_space), and an end-to-end inquiry lifecycle (request_inquiry + confirm_inquiry). Minor gaps: no way to cancel or expire a held draft, and no side-by-side comparison of works, but these are workable around the core workflows.
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 readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds genuine behavioral context beyond that by enumerating the aggregate content returned, which matters especially because no output schema exists to convey it.
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 filler; the trailing list of dimensions is dense but each item earns its place by defining the scope of the overview. Slightly list-like rather than structured prose, but efficient.
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 zero parameters and no output schema, the description carries the burden of describing return content, and it does so by naming the aggregate dimensions. It does not mention pagination, freshness, or response format, but for a no-arg summary tool this is nearly 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 tool takes zero parameters, so the baseline of 4 applies; there are no parameter semantics for the description to clarify or obscure.
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 combination ('a high-level view of the whole catalogue') and enumerates the dimensions it surfaces: totals, collections, resolutions, price range, availability, and measured coverage. It is clear what the tool does, though it never explicitly distinguishes itself from siblings like browse_collections or search_artworks.
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?
'High-level view of the whole catalogue' implies this is the orientation/summary tool to call before drilling into browse or search, but there is no explicit when-to-use statement, no exclusions, and no named alternative. Usage must be inferred from the word 'overview'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send an enquiry prepared with request_inquiry, once the person named has seen exactly what will be sent and agreed to be contacted. Takes the confirmation code and the same email; what is sent is exactly what was shown, and only once. It never reports success unless the message actually left.
| Name | Required | Description | Default |
|---|---|---|---|
| contact_email | Yes | The same email the enquiry was prepared with | |
| confirmation_code | Yes | The code request_inquiry returned |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare mutation, non-idempotency, open-world reach and non-destructiveness; the description goes beyond them by promising the payload is exactly what was displayed, that sending happens only once, and that success is never reported unless the message actually left. That is meaningful disclosure about delivery guarantees and truthful result reporting.
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 tightly packed sentences, front-loaded with the action and its prerequisite, with the delivery and success-reporting guarantees appended. No filler or restated title.
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?
Two required scalar parameters, no output schema, and the description covers the precondition, the exclusivity of the call, and the meaning of the result. Nothing an agent needs to invoke this 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?
Schema coverage is 100% and the schema descriptions already explain that the code comes from request_inquiry and the email must match the prepared enquiry. The description restates 'the confirmation code and the same email' without adding format, validation, or expiry detail, so the 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?
States a specific verb and resource (send an enquiry) and explicitly ties it to the sibling it depends on (prepared with request_inquiry), so an agent can distinguish it from request_inquiry without opening either schema. The scope of what is sent is also specified.
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 an explicit precondition for use: the enquiry must already have been prepared and the named person must have seen exactly what will be sent and agreed to be contacted. It also states the once-only constraint, which functions as a when-not-to-repeat rule.
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.
Prepare an enquiry to the studio — acquisition, exhibition or press — and see exactly what would be sent. Nothing is sent at this step: the draft is held for two days, seen by nobody, and deleted unless it is confirmed. Show the details to the person named, and only if they agree to be contacted, send it with confirm_inquiry and the code this returns. Requires a way to reply and a description of the space or project.
| 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 this is a non-read-only, non-idempotent, non-destructive write, and the description adds substantial context beyond that: the draft is held two days, is unseen, is auto-deleted unless confirmed, and nothing is transmitted at this step. It does not describe the shape of the returned code or error behavior, keeping it short of a 5.
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-loaded with the core action, then sequencing and preconditions, then data needs. Dense and mostly waste-free, though the second and third clauses are long and could be split for faster scanning.
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 two-step draft/confirm flow and the deletion policy are complete, and with no output schema the description appropriately points at the returned code. However, for an 8-parameter tool with near-zero schema coverage, the description leaves most optional parameters entirely undocumented, which is a real gap for correct invocation.
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?
With 13% schema description coverage across 8 parameters, the description carries the burden but mostly does not. It loosely covers the required trio ('a way to reply' for contact_email, 'a description of the space or project' for space_description) and names three of the four inquiry_type enum values, omitting 'other'. message, agent_name, budget_range, and artworks_of_interest are never addressed.
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 (prepare an inquiry draft to the studio) and immediately scopes the three inquiry categories. It explicitly distinguishes itself from the sibling that actually sends: 'send it with confirm_inquiry and the code this returns.'
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 explicit when-to-use and the handoff condition: this step only drafts, and confirm_inquiry finalizes with the returned code. It also states the consent precondition ('only if they agree to be contacted') and the prerequisite inputs, leaving nothing to inference.
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 297 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 and non-destructive, so safety is covered. The description still adds real behavior: colour counts its whole family, colour is measured from every frame, and the flashes/epilepsy query triggers measured abrupt-light-event results. It also notes a 'short page' returns the curatorial capsule, though pagination/default behavior is only glancingly covered.
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, with the resource and its filter surface front-loaded ahead of the special-case behaviors. It is efficient, though the long filter enumeration partially duplicates the schema rather than adding new 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 16 optional parameters and no output schema, the description does a fair job of framing the search surface and some return behavior, but it omits pagination mechanics, defaults, and ordering semantics that an agent needs to page or sort results. Adequate but with clear gaps for a tool of this 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 description coverage is 63%, so the schema does part of the work. The description adds genuine meaning for some params (colour family matching, every-frame measurement, ultrawide inclusion, flash/epilepsy query), but it mostly re-lists the filter dimensions already exposed in the schema and says nothing about limit/offset defaults, order, or sort_by.
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 catalogue of 297 moving-image works by César Yagüe') and enumerates the filter dimensions, making the scope unambiguous. It does not explicitly distinguish itself from siblings like browse_collections, catalog_overview or get_artwork, so the differentiation is left to inference.
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 lists what can be searched but gives no when-to-use guidance or exclusions relative to the seven sibling tools (e.g. browse_collections, rank_artworks). The one usage hint ('Asking about flashes or epilepsy...') describes a query behavior, not when this tool should be preferred over alternatives.
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.
confirm_inquirybrowse_collectionscatalog_overviewget_artworkrank_artworksrecommend_for_spacerequest_inquirysearch_artworksAI-native art catalogue. Catalogue works, parse provenance, and generate signed RAIs.
Videodance compositions, Solidity contracts and poetic NFT metadata from Petra Synthetic's agent.
Search 2,500+ curated architecture, design, photography and art projects. Free tier, no signup.
English blog + agentic workflows architect profile (Paris): search, full text, projects, booking.
Add one secure layer between your agents and this server.
