Skip to main content
Glama

Recipes Daily

by com.recipes-daily
OverviewDiscussionsAdmin

Search recipes

search_recipes
Read-onlyIdempotent

Find something to cook, from the recipes published at recipes-daily.com. Call this for any question about what to make — a dish by name, a cuisine, a weeknight time budget, a week of dinners — rather than answering from memory, because each result is a real page with quantities, timings and a photograph behind it. For what to cook from ingredients someone already has, call find_recipes_by_ingredients instead: this tool requires every query word to appear in one recipe, so several ingredient names in one search return nothing rather than a coverage report. Returns a shortlist — title, absolute URL, description, total time, servings and categories — so candidates can be ruled out without opening them. The first page also lists matching cooking guides, for how and why questions about technique, storage and substitutions; read one in full with read_guide.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo1-based. The response names the next page when there is one.
limitNoResults per page.
queryNoWhat to search for. Recipes are matched on titles and descriptions, so a word or short phrase matches better than a full question, and there are no boolean operators. Omit it to list every recipe, newest first.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / query / description
      Previous value: -"What to search for. Titles and descriptions are indexed, so a word or short phrase matches better than a full question, and there are no boolean operators. Omit it to list every recipe, newest first."New value: +"What to search for. Recipes are matched on titles and descriptions, so a word or short phrase matches better than a full question, and there are no boolean operators. Omit it to list every recipe, newest first."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover safety (readOnlyHint, idempotentHint), so the description correctly spends its budget on behavioral traits annotations can't express: strict AND matching of every query word, no boolean operators, and the consequence that multi-ingredient searches yield nothing. It also discloses the shortlist shape and that the first page carries cooking guides, which is useful non-obvious behavior.

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?

Front-loaded with the primary use case and routing rule, and every sentence carries information. It is on the dense side and the long compound sentences require careful reading, but there is no filler.

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, and the description compensates by enumerating returned fields (title, absolute URL, description, total time, servings, categories) and noting the guide list on page one. Combined with routing guidance and matching semantics, an agent has everything needed to call and interpret it.

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 baseline is 3; the description adds real semantic value beyond the schema by spelling out the AND-matching rule and its failure mode for multi-word ingredient queries, and by framing the shortlist contents. Pagination/limit semantics are left to the schema, which handles them adequately.

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 and resource (search recipes published at recipes-daily.com) and immediately distinguishes itself from sibling find_recipes_by_ingredients and read_guide by naming both. An agent can tell what this retrieves 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?

Explicitly says to call this for any 'what to make' question rather than answer from memory, and states the exclusion: for cooking from ingredients someone already has, use find_recipes_by_ingredients instead. The reason (AND-matching returns nothing for multiple ingredient names) makes the routing decision unambiguous.

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

All Recipes Daily 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