Pandough is a flour-first dough engine exposed as a remote MCP server. Agents call plan_bake with a real flour, kitchen temperature, and oven; the engine returns ingredient grams, computed yeast, a proofing schedule, and a calculator link.
Scored across 7 tools
Each tool targets a distinct resource and action: flour search vs. flour details, oven search, recipe style listing, bake planning, active bakes, and troubleshooting. Descriptions explicitly clarify boundaries, such as list_recipes warning not to confuse recipe styles with flour names.
Most tools follow a verb_noun snake_case pattern (search_flours, list_active_bakes, plan_bake). The main deviation is 'troubleshoot,' which is a bare verb rather than verb_noun, but the overall naming remains predictable and readable.
Seven tools is well-scoped for a baking assistant: flour discovery, oven lookup, recipe style lookup, bake planning, current bakes, and troubleshooting. Each tool has a clear purpose and none feel redundant or extraneous.
The core workflow is covered: search flours and ovens, get flour details, list recipes, create a bake plan, list active bakes, and troubleshoot. Minor gaps exist, such as no dedicated get_oven_details or explicit bake update/cancel actions, but agents can work around these with the existing tools.
Get detailed information about a specific flour by its slug. Returns full profile including protein, W strength, hydration curve, maturation profiles, and description.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Flour slug (e.g. 'caputo-pizzeria', 'manitoba-oro') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, and the description adds meaningful context about what the call returns: protein, W strength, hydration curve, maturation profiles, and description. This goes beyond the annotation's safety signal and gives the agent a concrete expectation of the response. No contradictions are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly-worded sentence with the key action and object front-loaded. Every phrase earns its place, and it avoids redundant or padded language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only lookup tool, the description is complete: it names the input (slug), the action, and the expected output fields. Since there is no output schema, the explicit list of return content compensates well, and the readOnlyHint annotation covers the behavioral safety profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already documents the slug parameter with format guidance and examples. The description only repeats 'by its slug,' adding no new parameter semantics beyond what is already structured in the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Get detailed information') on a specific resource ('a specific flour by its slug'), and lists the returned data fields, making the tool's purpose immediately obvious. It does not explicitly name or differentiate from the sibling search_flours tool, but the 'by its slug' qualifier implies a direct-lookup use case that is distinct from searching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: when you already know a flour's slug and need detailed data. However, it does not explicitly state when not to use it or mention search_flours as the alternative for discovering slugs, so usage guidance is mostly inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the signed-in baker's scheduled and active bakes plus live temperature-sensor readings when a device is reporting. The first call prompts the chat app to authorize a Pandough account (OAuth scope bakes:read). Needs Pro (or cancelled-Pro). Returns ids, flour, hydration, schedule, a calculator session link, and probe temps (air around the dough, not dough core).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description reveals an important side effect: the first call triggers an OAuth authorization prompt. It also clarifies that probe temps measure air around the dough, not the dough core, and lists what will be returned, giving the agent a solid behavioral model.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact but information-dense: it front-loads the core purpose, then adds the auth side effect, entitlement requirement, and return contents. Every sentence contributes new, actionable information without repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description enumerates the returned fields (ids, flour, hydration, schedule, calculator session link, probe temps) and covers the two key contextual constraints: OAuth authorization and Pro entitlement. This is sufficient for an agent to decide when and how to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty and parameter count is 0, so there are no parameter semantics to explain. The description instead focuses on return value details, which is appropriate; baseline 4 applies for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('List'), a specific resource ('the signed-in baker's scheduled and active bakes'), and adds the live temperature-sensor dimension. This clearly distinguishes it from sibling tools like list_recipes, which target recipes rather than bakes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to call this tool: when the user needs their bakes and live probe readings, and it notes the Pro entitlement requirement and first-call OAuth prompt. It does not explicitly name alternatives or exclusions, but the sibling set makes the intended scope evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the dough recipe styles plan_bake supports. Call this when a user names a style (Neapolitan, classica, focaccia, bread, baguette) so you pass the correct recipeSlug instead of guessing — and so you never confuse a style word like 'classica' with a flour whose name contains it.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 context about the purpose (returning correct recipeSlug values and preventing style/flour confusion) but does not disclose return format, ordering, or other behavioral details. This is a reasonable read-only lookup tool, so the added context earns a 3 but no higher.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence that front-loads the core action ('List the dough recipe styles plan_bake supports') before giving usage guidance. The extra clause about disambiguation is meaningful and not filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only list tool, the description gives enough context: what the tool returns conceptually (recipe styles and slugs) and when to use it. There is no output schema, so a slightly more explicit statement of return format would improve completeness, but the current wording is sufficient for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and the schema already covers everything by having no properties. No deduction needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and names a concrete resource: the dough recipe styles that plan_bake supports. It clearly distinguishes this from flour/oven lookups by explaining the tool is about recipeSlug-to-style mapping, so an agent can tell it apart from siblings like search_flours without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to call the tool: when a user names a style such as Neapolitan, classica, focaccia, bread, or baguette. It gives clear context and even warns against confusing style words with flour names, but it does not explicitly state when not to use it or name a specific alternative, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a bake plan with ingredient calculations. Returns exact ingredient amounts in grams, an auto-sized yeast amount, a fermentation schedule, dough warnings, and a calculator URL the user can open in Pandough with all parameters prefilled. Before calling this, gather the inputs that actually determine a good plan (skip any the user already volunteered): (1) Strongly ask which oven model they use — call search_ovens and pass ovenSlug. If it is unlisted, ask for ovenType plus ovenMaxCelsius. Oven capability materially changes the hydration band and bake feasibility; if the user declines, proceed but say the result is not oven-adapted. (2) Which flour(s) do they have? — call search_flours to resolve a flourSlug (or pass flourBlend for a 2–5 flour cut, e.g. a Pulcinella base with 30% Manitoba); this is what makes hydration and warnings flour-aware. (3) Their room temperature and fridge temperature — pass roomTempCelsius/fridgeTempCelsius; temperature is the dominant driver of yeast amount and timing. (4) How they mix/knead (by hand, stand mixer, no-knead) — plan_bake does not return technique guidance, so pair it with a troubleshoot call for method advice. (5) Do they want a preferment? — pass preferment for a biga, poolish, tiga, cold/long biga, or a natural sourdough starter. The yeast figure accounts for the preferment, and the calculator link opens with the build already set up, so recommending a biga in prose without passing this param hands the user a direct dough. Don't interrogate a user who already gave a full brief.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | UI locale for the returned calculator link (e.g. 'en', 'pl', 'it'). Defaults to 'en'. | |
| bakeTime | No | Target bake time as an ISO 8601 datetime (e.g. '2026-06-10T18:00:00Z'). Must be in the future. | |
| ovenSlug | No | Exact oven model slug from search_ovens. Strongly preferred: the engine uses the model's real ceiling and oven class to adapt hydration and bake feasibility. Mutually exclusive with manual ovenType/ovenMaxCelsius. | |
| ovenType | No | Oven class for an unlisted model. Pass together with ovenMaxCelsius; prefer ovenSlug when search_ovens finds the model. | |
| servings | No | Number of portions/pizzas (1–50, default: 4) | |
| flourSlug | No | Flour slug from search_flours (e.g. 'caputo-pizzeria'). For a single flour. Mutually exclusive with flourBlend. | |
| flourBlend | No | A weighted flour blend (2–5 flours summing to 100%), e.g. [{flourSlug:'caputo-pizzeria',percent:70},{flourSlug:'manitoba-oro',percent:30}]. Mutually exclusive with flourSlug. | |
| preferment | No | Plan the bake around a preferment (biga, poolish, tiga, sourdough…). The yeast figure returned accounts for it, and the calculator link opens with the build already set up. | |
| recipeSlug | Yes | Recipe type slug. Supported: neapolitan-pizza, classica-pizza, focaccia, artisan-bread, baguette (call list_recipes for the full list). When the user names a style like 'classica', pass that style here — do NOT confuse it with a flour whose name happens to contain the word. | |
| roomTempHours | No | Room-temperature fermentation hours (0–168). Pass BOTH this and fridgeTempHours to lock the split; naming only a total lets the engine choose. Room legs above 14h are clamped with a warning. | |
| ovenMaxCelsius | No | The real maximum temperature in °C for an unlisted oven (100–600). This is what constrains hydration and bake time. | |
| ovenMinCelsius | No | Optional minimum set temperature in °C for an unlisted oven. | |
| fridgeTempHours | No | Cold fermentation hours (0–168). Pass BOTH this and roomTempHours to lock the split. | |
| roomTempCelsius | No | The user's real kitchen temperature in °C (2–40). The single biggest driver of yeast amount and timing — ask the user for it. | |
| hydrationPercent | No | Target hydration percentage (40–110) | |
| fridgeTempCelsius | No | The user's real fridge temperature in °C (0–12). Ask the user for it when a cold ferment is involved. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, which aligns with the compute-and-return nature of the tool (no persistence claimed, so no contradiction). The description adds meaningful behavioral context beyond annotations: the fallback behavior when the user declines the oven ('proceed but say the result is not oven-adapted'), clamping with a warning for room legs above 14h, and that the yeast figure accounts for the preferment. This is rich context, though it doesn't cover every edge case.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but structured: a front-loaded purpose/return sentence, followed by a numbered decision list with clear sub-clauses. For a 16-parameter tool with nested objects, the length is justified and every sentence carries actionable guidance. It is dense rather than padded, though a tighter lead-in could trim a few words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (16 params, nested flourBlend and preferment objects, no output schema), the description is thorough: it explains return values (which matters because there is no output schema), fallback behaviors, mutual-exclusion hints, and decision logic. It does not exhaustively document error conditions, but covers what an agent needs to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds genuine semantic value beyond the schema by explaining why parameters matter — 'Oven capability materially changes the hydration band and bake feasibility' and 'temperature is the dominant driver of yeast amount and timing' — and clarifying the preferment's effect on the returned yeast figure. This elevates it above the schema-only baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource ('Create a bake plan with ingredient calculations') and enumerates the exact return payload (gram amounts, auto-sized yeast, fermentation schedule, dough warnings, calculator URL). It clearly distinguishes itself from siblings by naming which tools to call instead (search_ovens, search_flours, troubleshoot), so an agent can tell it apart immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit pre-call protocol: a numbered list of five inputs to gather, each naming the sibling to call (search_ovens, search_flours) and what to pass. It also states exclusions — 'plan_bake does not return technique guidance, so pair it with a troubleshoot call' — and a stopping condition ('Don't interrogate a user who already gave a full brief'). This is explicit when-to-use/when-not-to guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Pandough flour database. Returns flour names, protein %, W strength, hydration ranges, and types. Use this to help users find the right flour for their bake.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Filter by tag (e.g. 'pizza', 'bread', 'pastry') | |
| query | No | Search term (name, brand, or type) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the safety profile, and the description adds useful return-field context. However, it does not disclose matching semantics, how tag and query interact, ordering, or result limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core search action and followed by useful return-value and use-case information. No filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two optional parameters and no output schema, the description adequately explains the return values and the intended use case. It could be more complete by clarifying how filters combine or what happens with no parameters, but it is sufficient for a simple search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds a high-level list of returned fields but does not enrich the meaning of the tag or query parameters beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search the Pandough flour database') and the resource, and lists the returned flour attributes. It does not explicitly contrast with the sibling get_flour_details, though the 'search vs details' distinction is implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use this to help users find the right flour for their bake' provides a clear when-to-use context. It does not mention exclusions or alternatives, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Pandough oven database. Returns oven specs (max temperature, type, fuel) plus recommended bake settings — top/deck heat, bake time, and deck material — computed for a Neapolitan pizza by the same heat engine the site uses.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Oven type filter (e.g. 'pizza-oven', 'home-oven', 'outdoor') | |
| query | No | Search term (oven name, brand) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds meaningful behavioral context: it returns not only raw specs but computed recommendations produced by the same heat engine as the site. The read-only safety profile is reinforced, and the computational nature of the output is disclosed beyond what the schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single well-structured sentence front-loads the core action and resource, then efficiently lists what is returned. Every phrase earns its place; no filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two optional parameters, no output schema, and read-only annotations, the description is nearly complete: it identifies the search target and enumerates the return groups (specs, bake settings, deck material). A small gap is the lack of any note about empty results or how type/query interact, but this is not essential for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both 'type' and 'query' are already documented in the input schema. The description does not add parameter-level nuance, but it does provide useful top-level framing ('oven database'). Baseline 3 is appropriate because the schema carries the full parameter burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search') and resource ('Pandough oven database'), and enumerates the concrete return contents: oven specs and recommended bake settings. This clearly distinguishes it from sibling tools like search_flours and get_flour_details, which target a different resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: call this when you need oven specs and Neapolitan-specific bake settings. However, there is no explicit guidance about when to prefer plan_bake or troubleshoot, and no exclusionary 'use this instead of X' note. The context is clear but alternatives are not compared.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Pandough baking knowledge base for troubleshooting advice, technique guides, and flour science. Returns curated expert content about common baking issues.
| Name | Required | Description | Default |
|---|---|---|---|
| issue | Yes | The baking issue or question (e.g. 'sticky dough', 'no oven spring', 'cold proof technique') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint already signals a safe read operation, and the description's 'Search...Returns' aligns with that. It adds useful context that results are curated expert content, but it does not disclose return format, result size, or pagination, which is a minor gap for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, tightly packed with the action, resource, content scope, and result type. There is no wasted wording, and the most important information appears first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only search tool with no output schema, this is mostly complete: the agent knows what to search, where, and what kind of content will come back. The main omission is the exact shape of the returned content, which keeps it from being fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single issue parameter with an example and length constraints, so the description does not need to add syntax-level detail. The description's mention of troubleshooting advice, technique guides, and flour science gives some semantic color to what kinds of issues are supported, but it does not go beyond the 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (Search) and resource (Pandough baking knowledge base) with a clear content focus: troubleshooting advice, technique guides, and flour science. It does not explicitly distinguish itself from sibling search tools, so it falls just short of full clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use it: whenever the agent needs baking troubleshooting advice, technique guides, or flour science from the knowledge base. It does not name alternatives or provide exclusions, but it establishes a clear usage context for a single-purpose search tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
plan_bake1 field changedInput schema / properties / locale / enumPrevious value: -[
- "en",
- "pl",
- "de",
- "es",
- "it",
- "nl",
- "fr",
- "ja",
- "ko",
- "sv",
- "pt"
-]New value: +[
+ "en",
+ "pl",
+ "de",
+ "es",
+ "it",
+ "nl",
+ "fr",
+ "ja",
+ "ko",
+ "sv",
+ "pt",
+ "hu"
+]get_flour_detailslist_active_bakeslist_recipesplan_bakesearch_flourssearch_ovenstroubleshoot
Add one secure layer between your agents and this server.