mcp-wikibooks-cookbook

Search the Cookbook

search_recipes

Read-onlyIdempotent

Search the Wikibooks Cookbook for recipes by dish or ingredient. Text search finds dishes from ingredients; title search matches page names. Results include recipes and reference pages.

Instructions

Search the Wikibooks Cookbook for a recipe, by dish name or by an ingredient it uses. 'text' searches the whole of each page, which is what finds a dish from an ingredient inside it; 'title' matches the page name only, which is exact and misses a dish the Cookbook names differently. The Cookbook also holds reference pages on ingredients, techniques and cuisines, and those rank alongside recipes: a row is a page, and only get_recipe can say whether it carries an ingredient list. A full-text row can be a page that merely names the dish: when the titles do not say the words searched for, the notes say so, because the Cookbook links to dishes it does not hold. On a title search the same rows are pages the Cookbook files under another name, such as 'Eggplant' for 'aubergine', since that search opens no page. 'total_available' is null because the search route reports no total and offers no second page. Narrow the query rather than asking for more. Every row carries an 'id', which get_recipe takes.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No
`query`	Yes	A dish, such as 'carbonara', or an ingredient, such as 'guanciale'.
`search`	No	'text' reads the whole page; 'title' matches the page name only.	text

Output Schema

TableJSON Schema

Name	Required	Description
`notes`	Yes
`query`	Yes
`source`	Yes
`results`	Yes
`result_count`	Yes	Rows returned by this call.
`total_available`	Yes	Always null: the search route publishes no total and no paging.

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv2.1.0Sep 11, 2026
- removedOutput schema / properties / results / items / properties / description / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / results / items / properties / description / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / results / items / properties / excerpt / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / results / items / properties / excerpt / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / results / items / properties / image_url / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / results / items / properties / image_url / type
```
Added value: +[
+  "string",
+  "null"
+]
```
Changed1 schema field changedv1.2.0Aug 7, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
First observedv1.0.0Aug 5, 2026

TDQS

A4.8/5.0

Behavior5/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 substantial beyond-annotation context: text search scans full pages, title search matches names only, reference pages compete with recipes, full-text rows may merely name a dish, title results can be aliases like 'Eggplant' for 'aubergine,' total_available is null, and there is no pagination. These are valuable operational traits that the schema and annotations do not convey.

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 lengthy but earns most of its length by explaining nontrivial search quirks (aliases, non-recipe pages, null total). It is logically structured: search modes, result semantics, caveats, then pagination guidance. Some phrases, such as 'since that search opens no page,' are slightly opaque and could be tightened, but overall the density is justified.

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 the presence of an output schema IA and rich annotations, the description covers the remaining operational concerns: result ranking, full-text versus title semantics, absence of total and pagination, and the link to get_recipe via 'id'. An agent has everything needed to decide when to call this toolhive, set parameters correctly, and interpret the returned pages without further spelunking.

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 67%, with descriptions for 'query' and 'search'; the description enriches both by explaining the real-world consequences of text versus title search and by framing 'query' as a dish or ingredient. The 'limit' parameter is not explicitly described in the schema, but the phrase 'offers no second page' implies limit is the only way to control result volume Chebyshev. This is helpful, though not fully explicit about limit being a maximum count.

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 opens with a specific verb and resource: 'Search the Wikibooks Cookbook for a recipe,' and immediately enumerates the two search dimensions, dish name and ingredient. It distinguishes itself from siblings by noting that 'only get_recipe can say whether it carries an ingredient list,' and it clarifies that reference pages rank alongside recipes. The purpose is unambiguous, specific, and clearly differentiated.

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?

The description explicitly contrasts 'text' versus 'title' search and tells which to use: 'text' finds a dish from an ingredient inside it; 'title' is exact and misses differently named dishes. It also gives direct advice for behavior: 'Narrow the query rather than asking for more' and states 'Every row carries an id, which get_recipe takes,' routing the agent to the right next step. This is explicit when-to-use guidance with no gaps.

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

Deploy Server