Skip to main content
Glama
Sign In

LastList

by com.lastlistapp
OverviewDiscussionsAdmin

Search recipes

search_recipes
Read-only

Search LastList's recipe catalog by name, cuisine, dietary preference, and kitchen equipment. Returns a short list of matching recipes the user can choose from, each with the tools it needs. If the user is asking 'what can I make' without naming a recipe, prefer match_recipes_to_inventory over a blind search.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "search_recipes"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMax recipes to return. Default 10, cap 20.
queryNoFree-text search across recipe titles. Optional.
toolsNoOnly return recipes that use at least one of these kitchen tools, e.g. ['slow cooker'], ['air fryer', 'instant pot']. Use when the user asks what they can make with a specific appliance.
cuisineNoFilter by cuisine, e.g. 'Italian', 'Mexican', 'Thai'. Case-insensitive.
dietaryNoFilter by dietary tags, e.g. ['vegetarian'], ['gluten-free', 'dairy-free']. Returns only recipes that match ALL specified tags.
maxIngredientsNoOnly return recipes with at most this many ingredients.
noSpecialtyToolsNoWhen true, only return recipes achievable with everyday equipment (nothing tagged as a specialty tool). Use for 'I don't have any fancy equipment'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful behavioral context by saying it returns a short list of matching recipes, each with the tools it needs, though it does not describe ranking, pagination, or empty-result behavior.

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 three tight sentences: purpose first, return shape second, and alternative routing guidance third. Each sentence carries distinct value, and the guidance is front-loaded enough to be actionable.

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 7-parameter search tool with 100% schema coverage and readOnly annotations, the description supplies the key missing context: what kind of result to expect and when to prefer a sibling tool. No output schema exists, but the description explains the return shape at an appropriate level.

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

Parameters3/5

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

Schema description coverage is 100%, so all seven parameters are already documented in the schema. The description names several filter dimensions but does not add syntax, defaults, or constraints beyond what the schema provides, which is the expected baseline when schema coverage is complete.

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: search LastList's recipe catalog, with named filter dimensions (name, cuisine, dietary preference, kitchen equipment). It also distinguishes the tool from match_recipes_to_inventory in the key 'what can I make' scenario, so an agent can identify its role 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 Guidelines4/5

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

The description gives explicit routing guidance: if the user asks 'what can I make' without naming a recipe, prefer match_recipes_to_inventory over a blind search. It does not explicitly contrast with get_recipe or my_recipes, so usage is clear but not fully exhaustive across siblings.

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

All LastList 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