Skip to main content
Glama

find_product

Find a product's ID in the health catalog by name or brand to prepare for logging food; omit the query to list the entire catalog.

Instructions

Search the Catalog by name or brand (substring match). Omit query to list the whole Catalog. Call this before log_food against a Catalog Product — the result's id is the product_id log_food expects.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

With no annotations, the description carries the behavioral disclosure burden. It discloses substring matching, the option to list the whole catalog when query is omitted, and the id relationship with log_food. It does not explicitly mention read-only status, match limits, or case sensitivity, but covers key invocation-relevant behaviors.

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 two sentences with no filler. The first sentence defines the tool's core action, and the second provides essential usage and integration context, with the most important information front-loaded.

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?

The tool is simple, has an output schema, and a single optional parameter. The description gives the query behavior, the optional full-list behavior, and a concrete pointer to log_food, making it sufficiently complete for correct invocation.

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

Parameters5/5

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

The schema provides only a titled 'query' with no description (0% coverage). The description fully compensates by explaining that the query matches by name or brand via substring and that omitting it lists the entire catalog, making the parameter's semantics clear.

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?

The description uses a specific verb ('Search') and resource ('Catalog') with search criteria ('name or brand (substring match)'), clearly distinguishing it from sibling tools. It also states the optional full-catalog listing behavior, further clarifying scope.

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?

It provides clear context for use: 'Call this before log_food against a Catalog Product' and explains how the result's id maps to the expected product_id. It does not explicitly mention when not to use it or compare alternatives, but the integration guidance is strong.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/danielv27/health-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server