Fold Laboratories Art Catalogue

search_artworks

Search original artworks by natural-language description of what the buyer wants — subject, mood, palette, texture, period, scale. Matches on MEANING rather than keywords, so "a moody blue seascape" finds work no keyword search would. IMPORTANT: the query text is matched on meaning ONLY. A budget written into it — "under 20k" — is NOT applied; pass min_price_usd and max_price_usd instead, or you will get results outside the buyer’s range and not know it. The same is true of provenance strength (trust_tier). Returns only works that are actually purchasable unless include_sold is set. Attributes such as medium and year are as stated by the seller; a null means the seller did not specify it. IMPORTANT: check the completeness field before telling a buyer this is everything available — "partial" means more may exist beyond what was scanned.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Maximum results. Default 10, hard cap 100.
`query`	Yes	What the buyer is looking for, in natural language.
`trust_tier`	No	Restrict by provenance strength. verified_digital_coa is the strongest; unverified works are listed honestly but carry no certificate.
`include_sold`	No	Include works that are already sold. Off by default.
`max_price_usd`	No	Highest acceptable price.
`min_price_usd`	No	Lowest acceptable price.
`seller_stated_tags_only`	No	When true, match only tags the seller asserted, excluding model-generated ones. Use when the buyer needs the seller to have made the claim themselves.

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description carries the full burden, and it delivers: it discloses meaning-only matching, that budget/provenance text is ignored, that sold items are excluded unless include_sold is set, that seller attributes may be null, and that the completeness field may be 'partial'. This is exceptional transparency.

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

Conciseness5/5

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

The description is long but every clause earns its place: core purpose first, then critical behavioral caveats in explicit IMPORTANT blocks. The warnings are necessary because the failure mode is silent and costly, and the structure makes them easy to parse.

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

Completeness5/5

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

Given no output schema and no annotations, the description covers the essential runtime behaviors an agent needs: return scope (purchasable-only default), the meaning-matching caveat, how to encode filters, null attribute semantics, and the completeness field. Nothing critical is missing for correct selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds real semantics by explaining how the query parameter behaves (meaning-only, no numeric or provenance filtering) and how min_price_usd/max_price_usd and trust_tier relate to it. This elevates the value beyond the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Search'), a specific resource ('original artworks'), and a distinctive mechanism ('natural-language description', 'matches on MEANING rather than keywords'). This separates it from the sibling tools and any plain keyword search without opening schemas.

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

Usage Guidelines4/5

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

Provides clear context: this tool handles natural-language intended-meaning queries, and explicitly warns that price and provenance constraints belong in the dedicated params, not in the query text. It does not explicitly name alternative tools or state when not to use it, so it falls just short of a 5.

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

All Fold Laboratories Art Catalogue tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0

Disambiguation5/5

Each tool targets a distinct stage: search_artworks discovers works, get_artwork provides full detail including impressions, and check_availability verifies current purchasability. There is no functional overlap between them.

Naming Consistency5/5

All three tool names follow the same verb_noun snake_case pattern: search_artworks, get_artwork, check_availability. The naming is uniform and predictable.

Tool Count5/5

Three tools is minimal but each one earns its place: search is needed for discovery, get for detail, and check_availability for the critical pre-purchase verification. The scope is tight and well-defined.

Completeness4/5

The set covers the essential discovery-to-detail-to-availability workflow with no dead ends for the stated pre-purchase purpose. Minor gaps like an explicit list-all endpoint or purchase integration exist, but these appear intentionally outside the server's scope.

Resources

Need Help?