Skip to main content
Glama

Random Meal

random_meal
Read-onlyIdempotent

Get a random meal recipe with full ingredients and cooking instructions. Use when you need recipe inspiration without a specific search.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesTheMealDB meal ID
areaYesCuisine area/region (e.g., Italian, Indian)
nameYesMeal name
tagsYesList of meal tags/keywords
categoryYesMeal category (e.g., dessert, seafood)
source_urlYesSource website URL
ingredientsYesList of ingredients with measurements
youtube_urlYesYouTube video URL for recipe
instructionsYesStep-by-step cooking instructions
thumbnail_urlYesURL to meal thumbnail image

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "area": {
      +      "description": "Cuisine area/region (e.g., Italian, Indian)",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "category": {
      +      "description": "Meal category (e.g., dessert, seafood)",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "id": {
      +      "description": "TheMealDB meal ID",
      +      "type": "string"
      +    },
      +    "ingredients": {
      +      "description": "List of ingredients with measurements",
      +      "items": {
      +        "properties": {
      +          "ingredient": {
      +            "description": "Ingredient name",
      +            "type": "string"
      +          },
      +          "measure": {
      +            "description": "Measurement quantity and unit",
      +            "type": "string"
      +          }
      +        },
      +        "required": [
      +          "ingredient",
      +          "measure"
      +        ],
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "instructions": {
      +      "description": "Step-by-step cooking instructions",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "name": {
      +      "description": "Meal name",
      +      "type": "string"
      +    },
      +    "source_url": {
      +      "description": "Source website URL",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "tags": {
      +      "description": "List of meal tags/keywords",
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "thumbnail_url": {
      +      "description": "URL to meal thumbnail image",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "youtube_url": {
      +      "description": "YouTube video URL for recipe",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    }
      +  },
      +  "required": [
      +    "id",
      +    "name",
      +    "category",
      +    "area",
      +    "instructions",
      +    "thumbnail_url",
      +    "youtube_url",
      +    "source_url",
      +    "tags",
      +    "ingredients"
      +  ],
      +  "type": "object"
      +}
  2. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
      +  {}
      +]
  3. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds context about the output content ('full ingredients and cooking instructions'), which is useful beyond the annotations. No contradiction.

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 concise—two sentences, front-loaded with the core function, followed by a clear usage instruction. Every word earns its place with no redundancy.

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?

Given no parameters, an output schema, and a clear description of the result ('random meal recipe with full ingredients and cooking instructions'), the description is complete. It also differentiates from meal-related sibling tools.

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?

The tool has zero parameters, and schema coverage is 100% (trivially). The description appropriately focuses on the output instead of parameters, matching the baseline for no-param tools.

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 clearly states the tool's function: 'Get a random meal recipe with full ingredients and cooking instructions.' The specific verb 'Get' and resource 'random meal recipe' with details on contents distinguishes it from sibling tools like search_meals and get_meal.

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 provides explicit when-to-use guidance: 'Use when you need recipe inspiration without a specific search.' This implies when not to use it (when a specific search is needed), though it does not name alternative sibling tools directly.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0
Disambiguation5/5

Each tool has a highly specific purpose with detailed descriptions, making them easily distinguishable. Overlaps are minimal; for instance, Pipeworx and Polymarket tools have distinct roles within their domains.

Naming Consistency4/5

Most tools follow a consistent snake_case pattern (e.g., ask_pipeworx, compare_entities), but a few single-word names (e.g., forget, recall) deviate slightly, causing minor inconsistency.

Tool Count2/5

The server is named 'recipes' but contains only 4 recipe-related tools out of 34. The majority cover unrelated domains like finance, betting, and data queries, making the scope overly broad and misaligned with the server name.

Completeness2/5

For the 'recipes' domain, essential CRUD operations and features like meal planning are missing. While the general tool set is extensive, it lacks critical recipe-related functionality, leaving significant gaps for the intended purpose.