Aviado AI

Find a supplement

search_supplements

Read-onlyIdempotent

Find the Aviado id for a supplement name, exactly (no fuzzy matching). Answers with matches[0] = the identity: vocabulary_exact, or user_intent for salt/form names ('magnesium citrate' -> magnesium, with a form note). A name Aviado does not hold may be answered with a naming-model suggestion (match_type naming_slm_suggestion, identity false); confirm it with the user before using its id. Family names ('lithium') and confirm-only names return needs_confirmation with the members or candidates in candidates. Each match carries entity_type, regulatory_status and recommendable. Use mode='supplement_retail' only for raw retail product titles. Pass the confirmed canonical_id to the other supplement tools.

Input Schema

Name	Required	Description	Default
`mode`	No	Explicit routing mode; retail titles require supplement_retail	identity
`query`	Yes	Supplement identity or raw retail product title

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedJul 26, 2026

addedInput schema / properties / mode

Added value: +{
+  "default": "identity",
+  "description": "Explicit routing mode; retail titles require supplement_retail",
+  "enum": [
+    "identity",
+    "supplement_retail"
+  ],
+  "type": "string"
+}

changedInput schema / properties / query / description

Previous value: -"Search query (e.g., 'fish oil', 'CoQ10', 'NAC')"New value: +"Supplement identity or raw retail product title"

Changed2 schema fields changedJul 20, 2026
- addedInput schema / properties / query / maxLength
```
Added value: +512
```
- addedInput schema / properties / query / minLength
```
Added value: +1
```
First observedJun 30, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations cover read-only/idempotent/openWorld, and the description goes well beyond them: exact-only matching, the three match_type outcomes (vocabulary_exact, user_intent, naming_slm_suggestion with identity=false), that family/confirm-only names return needs_confirmation with candidates, and which fields each match carries. It discloses failure and ambiguity behavior, which is exactly what an agent needs before trusting an id.

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

Conciseness4/5

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

Information-dense and front-loaded: the matching semantics come first, then the alternative outcomes, then the mode rule and hand-off. The parenthetical examples ('magnesium citrate' -> magnesium) earn their space, though the run of match_type tokens makes it feel packed rather than clean.

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?

With no output schema, the description carries the full return-value burden and does so: matches[0] identity, match_type values, identity=false for suggestions, candidates for family names, and per-match fields (entity_type, regulatory_status, recommendable). Nothing needed to consume the response is missing.

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 coverage is 100%, so the baseline is 3, but the description adds real semantics: 'query' accepts salt/form names, family names, and retail product titles (not just 'identity'), and it pins down when mode must flip to supplement_retail. It does not add syntax constraints such as the 512-char limit, which the schema already carries.

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+resource ('find the Aviado id for a supplement name') and immediately constrains scope ('exactly, no fuzzy matching'), which distinguishes it from the get_* siblings that consume a canonical_id. An agent can tell what this tool returns (an identity, not supplement data) without opening the schema.

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

Usage Guidelines5/5

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

Gives explicit routing rules: mode='supplement_retail' only for raw retail titles, and 'pass the confirmed canonical_id to the other supplement tools', plus the instruction to confirm naming_slm_suggestion ids with the user. It also names the situations that yield needs_confirmation. This is when/when-not guidance with the consumer tools identified.

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

All Aviado AI 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?