Skip to main content
Glama
Sign In

Foodbe

by io.github.bleemohr
OverviewDiscussionsAdmin

foodbe_compare

Read-only

Call when a user asks which of two foods is better, healthier or different, or asks you to compare two foods. Send two food names. Foodbe finds both in its stored food data and scores each one on measures such as seasonality, planet, brain, gut and protein. Returns outcome "served" with a verdict naming the winner, one sentence on which food leads on which measure, and a card for each food with its scores. Every field comes from stored data, never from a model, so the same two foods always return the same answer. If either food is not found, or the two names are the same food, it returns outcome "not_found".

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "item_a": "<item_a>",
      "item_b": "<item_b>"
    },
    "name": "foodbe_compare"
  }
}

Input Schema

NameRequiredDescriptionDefault
item_aYesThe first food, for example salmon.
item_bYesThe second food, for example chicken.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare read-only, non-destructive, closed-world behavior, so the bar is lower; the description still adds substantial context beyond them: return outcomes 'served' vs 'not_found', the verdict-plus-card response shape, and the guarantee that scores come from stored data so identical inputs always yield identical answers. It also discloses failure conditions — unknown food or identical names — which is exactly the behavioral detail an agent needs to handle errors.

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 call trigger is front-loaded in the first sentence, followed by input shape, output shape, and failure modes in a logical order. With no output schema, the sentences describing the return value each earn their place, and there is no redundant phrasing.

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?

No output schema exists, so the description carries the job of explaining returns — and it does, naming both outcome values, the verdict format, and the per-food cards. Combined with the 100%-covered two-parameter schema and safety annotations, nothing essential for correct invocation 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; the description adds a constraint the schema does not capture — that each argument must be a food name and that passing the same food twice returns 'not_found'. That is meaningful input semantics beyond the two plain string properties.

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 states a specific verb and resource ('compare two foods') and names the exact measures scored (seasonality, planet, brain, gut, protein), which no sibling tool covers. An agent can distinguish it from foodbe_query, foodbe_ingredient, or foodbe_recipe_finder without opening any schema.

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 gives explicit trigger conditions — 'which of two foods is better, healthier or different' or an explicit comparison request — which is clear usage context. It does not name an alternative sibling to redirect to (for example single-food lookups), so it stops short of the full when/when-not framing.

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

All Foodbe toolsInspect
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