How do I use spoonacular-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@spoonacular-mcp search for vegan dinner recipes" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

spoonacular-mcp

by ddsky

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Spoonacular MCP Server

A Model Context Protocol (MCP) server that provides access to the Spoonacular Food API. This server enables AI assistants to search for recipes, get nutritional information, find ingredients, and more through the MCP protocol.

npm version npm downloads License: ISC

Features

Recipe Search: Search for recipes by ingredients, diet, cuisine, and other criteria
Recipe Information: Get detailed recipe information including ingredients, instructions, and nutrition
Ingredient Search: Find and explore ingredient information
Nutrition Analysis: Analyze nutrition for ingredient lists
Recipe by Ingredients: Find recipes based on available ingredients
Random Recipes: Get random recipe suggestions with optional filtering

Related MCP server: Mealie MCP Server

Quick Start

Installation

npm install -g spoonacular-mcp

Setup

Get a Spoonacular API key (free at https://spoonacular.com/food-api/console#Dashboard)

Set your API key as an environment variable:

# Windows (PowerShell)
$env:SPOONACULAR_API_KEY="your_api_key_here"

# macOS/Linux
export SPOONACULAR_API_KEY="your_api_key_here"

Usage with MCP Clients

Add this configuration to your MCP client (Claude Desktop, etc.):

{
  "servers": {
    "spoonacular": {
      "command": "spoonacular-mcp",
      "env": {
        "SPOONACULAR_API_KEY": "your_api_key_here"
      }
    }
  }
}

Test the Installation

# Set your API key
export SPOONACULAR_API_KEY="your_key_here"

# Test the server
echo '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}' | spoonacular-mcp

Available Tools

`search_recipes`

Search for recipes with various filters.

Parameters:

query (string): Search query for recipes
number (number, 1-100): Number of results (default: 10)
diet (string, optional): Diet type (vegetarian, vegan, gluten-free, etc.)
intolerances (string, optional): Comma-separated intolerances
includeIngredients (string, optional): Required ingredients (comma-separated)
excludeIngredients (string, optional): Ingredients to exclude (comma-separated)
type (string, optional): Meal type (main course, side dish, dessert, etc.)
cuisine (string, optional): Cuisine type (italian, mexican, chinese, etc.)

`get_recipe_information`

Get detailed information about a specific recipe.

Parameters:

id (number): Recipe ID
includeNutrition (boolean): Include nutrition information (default: false)

`search_ingredients`

Search for ingredients by name.

Parameters:

query (string): Ingredient search query
number (number, 1-100): Number of results (default: 10)
metaInformation (boolean): Include meta information (default: false)

`analyze_nutrition`

Analyze nutrition for a list of ingredients.

Parameters:

ingredientList (string): List of ingredients, one per line
servings (number): Number of servings

`find_recipes_by_ingredients`

Find recipes based on available ingredients.

Parameters:

ingredients (string): Comma-separated list of available ingredients
number (number, 1-100): Number of recipes (default: 5)
ranking (number, 1-2): Ranking strategy (1=maximize used, 2=minimize missing)

`get_random_recipes`

Get random recipes with optional filtering.

Parameters:

number (number, 1-100): Number of random recipes (default: 1)
tags (string, optional): Comma-separated tags for filtering

Development

To run in development mode:

npm run dev

To build:

npm run build

API Rate Limits

The free Spoonacular API plan includes:

150 requests per day
Rate limiting applies

Consider upgrading to a paid plan for production use.

License

ISC

Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

Available Tools

6 tools

analyze_nutritionC

Analyze nutrition information for a list of ingredients

ParametersJSON Schema

Name	Required	Description	Default
`servings`	Yes	Number of servings
`ingredientList`	Yes	List of ingredients, one per line

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It only states 'analyze nutrition information' without detailing expected output, side effects, or data source. The behavioral impact is unclear.

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?

The description is a single concise sentence, front-loaded with the key action. However, it is so brief that it sacrifices completeness; still, no unnecessary words are present.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without output schema or annotations, the description should clarify what constitutes 'nutrition information' and return format. It fails to do so, leaving gaps for a tool with two parameters.

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 coverage is 100% with both parameters having descriptions. The tool description adds no additional meaning beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'analyze' and resource 'nutrition information for a list of ingredients'. It distinguishes from sibling tools, which are recipe-focused, but lacks specificity on what the analysis includes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus siblings like search_ingredients or get_recipe_information. The description does not mention prerequisites, limitations, or alternative tools.

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

find_recipes_by_ingredientsC

Find recipes that can be made with the ingredients you have

ParametersJSON Schema

Name	Required	Description
`number`	No	Number of recipes to find
`ranking`	No	Ranking strategy: 1=maximize used ingredients, 2=minimize missing ingredients
`ingredients`	Yes	Comma-separated list of ingredients you have

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations provided, the description must disclose behavioral traits. It only states the basic function without mentioning what happens with missing ingredients, result limits, or any side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (one sentence) but overly minimal for a tool with 3 parameters. It front-loads the action but lacks necessary details, striking a balance between brevity and adequacy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations and output schema, the description is insufficient. It does not explain the ranking strategy, return format, or behavior when no recipes are found, leaving gaps for the agent.

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?

The input schema covers all parameters with descriptions (100% coverage), so the description adds no extra semantics beyond implying 'ingredients you have' aligns with the ingredients parameter. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: find recipes based on ingredients. The verb 'find' and resource 'recipes' are specific, and the ingredient-based approach distinguishes it from siblings like search_recipes, though not explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives such as search_recipes or get_random_recipes. The description lacks any contextual advice for selection.

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

get_random_recipesA

Get random recipes, optionally filtered by tags

ParametersJSON Schema

Name	Required	Description	Default
`tags`	No	Comma-separated list of tags (diet, meal type, etc.)
`number`	No	Number of random recipes to fetch

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It indicates a read operation but does not disclose any behavioral traits such as rate limits, authentication needs, or whether results are deterministic. The description is minimally adequate for a simple tool.

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?

A single sentence that conveys the core functionality and optional filtering. No unnecessary words or repetition. Appropriate length for a simple tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with two optional parameters, no output schema, and no nested objects, the description is nearly complete. It covers the main purpose and the optional filter. Minor gap: does not describe the return format, but for random recipes it is acceptable.

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% and both parameters have descriptions in the schema. The top-level description mentions the tags filter but does not add significant meaning beyond the schema for either parameter. Baseline 3 is appropriate.

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 verb 'Get' and the resource 'random recipes', and mentions optional filtering by tags. It distinguishes from sibling tools like search_recipes (search vs random) and get_recipe_information (specific vs random).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description implies use when random recipes are desired, but does not explicitly guide when to use this tool over siblings like search_recipes or find_recipes_by_ingredients. No when-not-to-use or alternative tool references.

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

get_recipe_informationA

Get detailed information about a specific recipe by ID

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	The recipe ID
`includeNutrition`	No	Include nutrition information

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description bears full responsibility. It states 'Get detailed information' but does not disclose whether the operation is read-only, potential side effects, authentication requirements, rate limits, or error behavior (e.g., if ID is not found). This is a significant gap for a tool that likely performs a read operation.

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 a single, clear sentence with no unnecessary words. It is front-loaded and directly conveys the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (2 parameters, no output schema, no annotations), and the description is adequate for a basic 'get by ID' pattern. However, it could be improved by mentioning the optional 'includeNutrition' parameter and briefly noting what kind of details are returned (e.g., '...including ingredients, instructions, and nutrition if requested').

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% (both 'id' and 'includeNutrition' have descriptions in the input schema). The description adds no additional meaning beyond what the schema already provides. Per the rubric, with high coverage (>80%), baseline is 3.

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 verb ('Get'), the resource ('detailed information about a specific recipe'), and the input method ('by ID'). It effectively distinguishes itself from sibling tools like 'search_recipes' (search, not specific) and 'get_random_recipes' (random).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description implies usage for when you have a specific recipe ID, but it provides no explicit guidance on when to use this vs alternatives (e.g., 'search_recipes' for finding by criteria, 'find_recipes_by_ingredients' for ingredient-based lookups). No exclusions or context are given.

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

search_ingredientsC

Search for ingredients by name

ParametersJSON Schema

Name	Required	Description
`query`	Yes	The ingredient search query
`number`	No	Number of results to return
`metaInformation`	No	Include meta information

TDQS

C2.9/5.0

Behavior2/5

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

Without annotations, the description must disclose behavioral traits but only states a generic search action. No information is given about return type, pagination, performance, or any side effects, leaving the agent uninformed.

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?

The description is a single concise sentence with no wasted words. It is front-loaded and to the point, though slightly under-specified for a search tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description should explain return values or behavior. It does not, leaving the agent without expectations about the structure of results or error handling.

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 coverage is 100%, so the description adds minimal value beyond the parameter descriptions. It confirms 'by name' aligns with the query field but doesn't clarify the meaning of 'number' or 'metaInformation' beyond defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches for ingredients by name, using a specific verb and resource. However, it does not distinguish itself from siblings like 'find_recipes_by_ingredients' or 'search_recipes', which could cause confusion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. The description lacks any context about when it is appropriate or inappropriate to search by name, or what to use for other search criteria.

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

search_recipesC

Search for recipes based on ingredients, diet, cuisine, and other criteria

ParametersJSON Schema

Name	Required	Description
`diet`	No	Diet type (vegetarian, vegan, gluten-free, etc.)
`type`	No	Meal type (main course, side dish, dessert, etc.)
`query`	Yes	The search query for recipes
`number`	No	Number of results to return (1-100)
`cuisine`	No	Cuisine type (italian, mexican, chinese, etc.)
`intolerances`	No	Comma-separated list of intolerances
`excludeIngredients`	No	Comma-separated list of ingredients to exclude
`includeIngredients`	No	Comma-separated list of ingredients that must be included

TDQS

C2.8/5.0

Behavior2/5

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

No annotations provided. Description does not disclose pagination, sorting, return format, or constraints like rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no wasted words, but could be more informative without being verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

8 parameters, no output schema, no annotations. Description lacks details on result format, default behavior, or how criteria combine.

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 covers all 8 parameters with descriptions. Description adds no extra meaning beyond listing criteria types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description states it searches for recipes by ingredients, diet, cuisine, etc. Clear verb+resource but does not differentiate from sibling find_recipes_by_ingredients or search_ingredients.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives like find_recipes_by_ingredients or get_recipe_information.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv1.0.0Jul 30, 2026
- First observedanalyze_nutrition
- First observedfind_recipes_by_ingredients
- First observedget_random_recipes
- First observedget_recipe_information
- First observedsearch_ingredients
- First observedsearch_recipes

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Disambiguation4/5

Most tools have distinct purposes: search_recipes vs find_recipes_by_ingredients could be confused, but descriptions clarify the different focus (general search vs. ingredient-based). Overall, the set is well-disambiguated.

Naming Consistency4/5

All tool names use snake_case and follow a verb_noun pattern, with slight variation: find_recipes_by_ingredients includes a preposition, and get_recipe_information vs get_random_recipes differ slightly in structure. Minor inconsistencies, but overall consistent.

Tool Count5/5

6 tools cover the core functionalities of a recipe service: searching, getting details, ingredient lookup, nutrition analysis, and random recipes. The count is well-scoped without being too few or too many.

Completeness5/5

The tool set covers essential operations for a recipe discovery and analysis service: search by various criteria, get detailed info, ingredient search, nutrition analysis, and random selection. There are no obvious gaps for its intended domain.

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Spoonacular B
io.github.pipeworx-io
Spoonacular food API: recipes, nutrition, ingredients, meal plans. Free 150/day.
Health & Wellness Search
492
prep-itOAuth
com.recipe-clipper
Search, save, organize, cook, and share recipes with any AI assistant.
Note Taking Search
2
scraps-kitchen-mcp AOAuth
kitchen.scraps.api
Scraps Kitchen gives any AI agent a persistent, household-aware kitchen memory. Unlike generic chatbot recall, Scraps maintains structured cooking data: what's in your fridge (with freshness tracking), who you cook for (with allergens, dietary restrictions, and preferences), your recipe collection (with cook notes and per-diner ratings), your shopping list, and your kitchen equipment. 27 tools across 6 domains let agents read kitchen context, suggest meals that respect dietary safety, update the pantry after cooking, and build a history of what works for your household. Every interaction makes the data richer. Cooking history, preference signals, kitchen awareness = better suggestions next time. All tools work via oAuth and a free scraps.kitchen account.
App Automation Home Automation & IoT Knowledge & Memory
2
Pantry PersonaOAuth
com.pantrypersona
AI-powered kitchen management — pantry, recipes, meal plans, shopping lists
Home Automation & IoT Health & Wellness E-commerce & Retail
2

Related MCP Servers

Kitchen MCP Server
Search Health & Wellness
paulabaal12
F
license
Not graded
quality
D
maintenance
Enables querying food nutritional information, discovering recipes by ingredients or diet type, getting ingredient substitutions, and receiving personalized food recommendations based on mood and season.
Updated a year ago (2025-09-19 20:26 UTC)
-
Mealie MCP Server
Databases Search Home Automation & IoT
that0n3guy
A
license
Not graded
quality
C
maintenance
Enables AI assistants to interact with Mealie recipe databases, allowing users to manage and query their recipes through natural language conversations.
Updated 9 months ago (2025-12-13 20:28 UTC)
27
MIT
mcp-spoonacular
Search Health & Wellness
pipeworx-io
A
license
Not graded
quality
C
maintenance
Provides access to the Spoonacular food API for recipes, nutrition, ingredients, and meal plans.
Updated 11 days ago (2026-08-26 17:42 UTC)
MIT
nutritionix-mcp-server
Health & Wellness Fitness Tracking
MCP-Forge
A
license
Not graded
quality
F
maintenance
Enables AI agents to search foods, get nutritional breakdowns, and estimate exercise calories using the Nutritionix API through natural language input.
Updated a year ago (2025-04-23 13:46 UTC)
3
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/ddsky/spoonacular-mcp'

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