beyond-wine

Search claims

search_claims

Read-only

Find published claims with their source provenance. To answer about a specific drink or producer, supply BOTH entity_type and its exact returned entity_slug. For a sourced statement, these two filters are normally sufficient: omit claim_type and reliability_class unless needed. claim_type is a record format (atomic_fact, structured_fact, editorial_claim), not a topic such as ingredients or collaboration. Inspect provenance.sources and preserve requires_independent_confirmation and source-reliability warnings. Follow meta.has_more pagination before making negative findings about the queried records and filters. Limit those findings to sources actually inspected; completing pagination does not establish that evidence is absent elsewhere. Confidence is not proof or independent verification. Preserve the source's exact alcohol wording. 0% and 0.0% are different wording, but that difference does not by itself establish different measured trace-alcohol thresholds. 'Below 0.5%' is an upper-bound declaration; these declarations do not by themselves prove measurement or laboratory testing. Do not infer that alcohol is absent from ingredients or production methods.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`page`	No
`limit`	No
`claim_type`	No
`entity_slug`	No
`entity_type`	No
`reliability_class`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 13, 2026
- addedInput schema / properties / claim_type / enum
```
Added value: +[
+  "atomic_fact",
+  "structured_fact",
+  "editorial_claim"
+]
```
- removedInput schema / properties / claim_type / minLength
```
Removed value: -1
```
First observedMay 28, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Annotations only cover the safety profile (readOnly, non-destructive, open-world). The description goes well beyond that, disclosing pagination semantics (follow meta.has_more before negative findings), fields to inspect (provenance.sources, requires_independent_confirmation, source-reliability warnings), and explicit interpretation limits ('Confidence is not proof', confidence does not establish measurement).

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

Conciseness3/5

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

Purpose and the core filter rule are front-loaded well, but the text runs long and drifts into niche result-interpretation caveats ('0% and 0.0% are different wording', trace-alcohol threshold semantics) that are only marginally about selecting or invoking the tool, making the middle dense and repetitive.

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?

For a 6-parameter, 0%-coverage, no-output-schema tool, this covers the important ground: what the result contains (provenance.sources), pagination field (meta.has_more), and the epistemic limits of the returned evidence. An agent has enough to call it and interpret results responsibly.

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 0%, so the description must compensate, and it does for the key filters: it explains entity_type/entity_slug pairing, when to use or omit claim_type, and when to omit reliability_class. It leaves page and limit unexplained beyond the generic pagination remark, so it is strong but not complete.

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

Purpose4/5

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

States a specific verb and resource ('Find published claims') and adds the value-add of returning source provenance. It is clearly distinguishable from get_claim (single-claim retrieval) and from search_beverages/search_producers, though it never names a sibling tool explicitly.

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?

Gives concrete filter guidance: supply BOTH entity_type and entity_slug for drink/producer questions, omit claim_type and reliability_class unless needed, and treat claim_type as a record format rather than a topic. It does not, however, say when to prefer this tool over get_claim or the other search_* siblings.

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

All beyond-wine tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?