Skip to main content
Glama

Pandough.app

by app.pandough
OverviewDiscussionsAdmin

Server Details

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.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
100.0% over 46 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.1/5.0

Scored across 7 tools

Disambiguation5/5

Each tool targets a distinct action-resource pair: flour detail vs. search, oven search, recipe listing, bake planning, active bake listing, and troubleshooting. Descriptions explicitly disambiguate overlapping areas, such as list_recipes warning against confusing style words with flour names, so an agent should select correctly.

Naming Consistency4/5

Mostly consistent snake_case verb_noun pattern: get_flour_details, list_active_bakes, list_recipes, plan_bake, search_flours, search_ovens. However, troubleshoot breaks the pattern as a lone verb without a noun, a minor deviation that remains readable.

Tool Count5/5

Seven tools is well-scoped for a baking assistant. Each tool has a clear role in searching, planning, or troubleshooting, and none feels redundant or extraneous.

Completeness4/5

The surface covers flour/oven search, recipe styles, bake planning, active bake listing, and troubleshooting. It lacks bake lifecycle mutations (create/schedule, update, cancel) and a get_bake_details operation, but these are minor gaps an agent can work around by directing users to the Pandough app.

Available Tools

7 tools
get_flour_detailsA
Read-only
Inspect

Get detailed information about a specific flour by its slug. Returns full profile including protein, W strength, hydration curve, maturation profiles, and description.

ParametersJSON Schema
NameRequiredDescriptionDefault
slugYesFlour slug (e.g. 'caputo-pizzeria', 'manitoba-oro')

TDQS

A3.9/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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_active_bakesA
Read-only
Inspect

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).

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.7/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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_recipesA
Read-only
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.2/5.0
Behavior3/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 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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

plan_bakeA
Read-only
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
localeNoUI locale for the returned calculator link (e.g. 'en', 'pl', 'it'). Defaults to 'en'.
stagesNoThe full main-dough fermentation schedule as ordered stages (1–6), e.g. [{durationHours:1,tempCelsius:22},{durationHours:21,tempCelsius:4},{durationHours:2,tempCelsius:22}] for 1h at room temperature, 21h in the fridge, then a 2h warm-up. Use it when the user describes more than a room leg and a fridge leg, an order other than room then fridge, or a stage at its own temperature. The stages are the whole schedule: nothing is added (include the warm-up after the fridge yourself) and the calculator link opens on exactly these stages. Mutually exclusive with roomTempHours / fridgeTempHours. Room-temperature stages above 14h are clamped with a warning.
bakeTimeNoTarget bake time as an ISO 8601 datetime (e.g. '2026-06-10T18:00:00Z'). Must be in the future.
ovenSlugNoExact 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.
ovenTypeNoOven class for an unlisted model. Pass together with ovenMaxCelsius; prefer ovenSlug when search_ovens finds the model.
servingsNoNumber of portions/pizzas (1–50, default: 4)
flourSlugNoFlour slug from search_flours (e.g. 'caputo-pizzeria'). For a single flour. Mutually exclusive with flourBlend.
flourBlendNoA 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.
prefermentNoPlan 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.
recipeSlugYesRecipe 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.
roomTempHoursNoRoom-temperature fermentation hours (0–168). Pass BOTH this and fridgeTempHours to lock the split; naming only a total lets the engine choose. These hours are the bulk before the fridge: when the fridge leg is above 0 the plan adds the recipe's final proof at room temperature after the fridge (a warm-up) on top of them, and says so. Room legs above 14h are clamped with a warning.
ovenMaxCelsiusNoThe real maximum temperature in °C for an unlisted oven (100–600). This is what constrains hydration and bake time.
ovenMinCelsiusNoOptional minimum set temperature in °C for an unlisted oven.
fridgeTempHoursNoCold fermentation hours (0–168). Pass BOTH this and roomTempHours to lock the split. A locked fridge leg above 0 is followed by a warm-up at room temperature (the recipe's final proof), shown as its own schedule line.
roomTempCelsiusNoThe user's real kitchen temperature in °C (2–40). The single biggest driver of yeast amount and timing — ask the user for it.
hydrationPercentNoTarget hydration percentage (40–110)
fridgeTempCelsiusNoThe user's real fridge temperature in °C (0–12). Ask the user for it when a cold ferment is involved.

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true, yet the description goes well beyond that: it explains that room-temperature stages above 14h are clamped with a warning, that preferments alter the returned yeast figure, that the calculator link is prefilled with exactly the supplied stages, and that omitting `preferment` yields a direct dough. It also discloses an important non-capability (no technique guidance) so the agent knows to pair with troubleshoot.

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 purpose and return contract are front-loaded, and the intake checklist is enumerated rather than prose, so it scans well. It is nonetheless long (~400 words) for a description, with some rationale clauses that could be tightened without losing the routing signal.

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 17-parameter tool with nested objects and no output schema, the description carries the needed completeness: it explains the return payload in lieu of an output schema, covers the stages-vs-roomTempHours/fridgeTempHours trade-off, the warm-up auto-insertion, nomenclature gotchas ('classica' vs. a flour name), and the cross-tool workflow. Nothing material is missing for correct invocation.

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 100%, so the baseline is 3, but the description adds genuine meaning beyond the schema: why temperature is 'the dominant driver of yeast amount and timing', that recommending a biga in prose without passing the param hands the user a direct dough, that a 2–5 flour blend is meaningfully different from a single flour, and the mutually-exclusive pairings. The distinction between resolution (ovenSlug via search_ovens) and manual fallback is also clarified.

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?

States a specific verb+resource ('Create a bake plan with ingredient calculations') and then enumerates exactly what is returned: grams, auto-sized yeast, fermentation schedule, dough warnings, and a prefilled calculator URL. An agent immediately knows this is a deterministic planning/calculation tool and can distinguish it from lookup siblings like search_flours or get_flour_details.

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?

Provides explicit pre-call routing with five numbered intake items, naming the alternative tools to call first (search_ovens, search_flours, troubleshoot) and the condition that selects each. It also states when NOT to gather inputs ('Don't interrogate a user who already gave a full brief') and gives a fallback when the user declines the oven question.

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

search_floursA
Read-only
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
tagNoFilter by tag (e.g. 'pizza', 'bread', 'pastry')
queryNoSearch term (name, brand, or type)

TDQS

A3.8/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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_ovensA
Read-only
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
typeNoOven type filter (e.g. 'pizza-oven', 'home-oven', 'outdoor')
queryNoSearch term (oven name, brand)

TDQS

A4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

troubleshootA
Read-only
Inspect

Search the Pandough baking knowledge base for troubleshooting advice, technique guides, and flour science. Returns curated expert content about common baking issues.

ParametersJSON Schema
NameRequiredDescriptionDefault
issueYesThe baking issue or question (e.g. 'sticky dough', 'no oven spring', 'cold proof technique')

TDQS

A3.8/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • Changedplan_bake4 fields changed
      • changedInput schema / properties / fridgeTempHours / description
        Previous value: -"Cold fermentation hours (0–168). Pass BOTH this and roomTempHours to lock the split."New value: +"Cold fermentation hours (0–168). Pass BOTH this and roomTempHours to lock the split. A locked fridge leg above 0 is followed by a warm-up at room temperature (the recipe's final proof), shown as its own schedule line."
      • changedInput schema / properties / preferment / properties / stages / maxItems
        Previous value: -4New value: +6
      • changedInput schema / properties / roomTempHours / description
        Previous value: -"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."New value: +"Room-temperature fermentation hours (0–168). Pass BOTH this and fridgeTempHours to lock the split; naming only a total lets the engine choose. These hours are the bulk before the fridge: when the fridge leg is above 0 the plan adds the recipe's final proof at room temperature after the fridge (a warm-up) on top of them, and says so. Room legs above 14h are clamped with a warning."
      • addedInput schema / properties / stages
        Added value: +{
+  "description": "The full main-dough fermentation schedule as ordered stages (1–6), e.g. [{durationHours:1,tempCelsius:22},{durationHours:21,tempCelsius:4},{durationHours:2,tempCelsius:22}] for 1h at room temperature, 21h in the fridge, then a 2h warm-up. Use it when the user describes more than a room leg and a fridge leg, an order other than room then fridge, or a stage at its own temperature. The stages are the whole schedule: nothing is added (include the warm-up after the fridge yourself) and the calculator link opens on exactly these stages. Mutually exclusive with roomTempHours / fridgeTempHours. Room-temperature stages above 14h are clamped with a warning.",
+  "items": {
+    "properties": {
+      "durationHours": {
+        "description": "Length of this stage in hours",
+        "maximum": 168,
+        "minimum": 0.25,
+        "type": "number"
+      },
+      "tempCelsius": {
+        "description": "Temperature of this stage in °C (the fridge temperature for a cold stage)",
+        "maximum": 35,
+        "minimum": 0,
+        "type": "number"
+      }
+    },
+    "required": [
+      "durationHours",
+      "tempCelsius"
+    ],
+    "type": "object"
+  },
+  "maxItems": 6,
+  "minItems": 1,
+  "type": "array"
+}
  2. 1 tool update
    • Changedplan_bake1 field changed
      • changedInput schema / properties / locale / enum
        Previous value: -[
-  "en",
-  "pl",
-  "de",
-  "es",
-  "it",
-  "nl",
-  "fr",
-  "ja",
-  "ko",
-  "sv",
-  "pt",
-  "hu"
-]New value: +[
+  "en",
+  "pl",
+  "de",
+  "es",
+  "it",
+  "nl",
+  "fr",
+  "ja",
+  "ko",
+  "sv",
+  "pt",
+  "hu",
+  "cs"
+]
  3. 1 tool update
    • Changedplan_bake1 field changed
      • changedInput schema / properties / locale / enum
        Previous 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"
+]
  4. 7 tool updates
    • First observedget_flour_details
    • First observedlist_active_bakes
    • First observedlist_recipes
    • First observedplan_bake
    • First observedsearch_flours
    • First observedsearch_ovens
    • First observedtroubleshoot

Related MCP Servers

  • Adology by adologyai

    Adologyofficial

    adologyai
    A
    license
    Not graded
    quality
    B
    maintenance
    Perplexity for social: ask what competitors are running across social and get answers grounded in real ad and creative data, not guesses.
    2
    Apache 2.0

  • Citesurf MCP

    citesurf
    A
    license
    A
    quality
    C
    maintenance
    Enables brand visibility monitoring across major AI platforms like ChatGPT, Claude, Gemini, and Perplexity. It allows users to track visibility scores, analyze competitor data, and receive actionable insights to improve AI-generated brand recommendations.
    16
    11 npm
    1
    MIT
  • industrylens-mcp by IndustryLensOp

    industrylens-mcpofficial

    IndustryLensOp
    A
    license
    Not graded
    quality
    B
    maintenance
    Browse IndustryLens's published competitive-intelligence reports and head-to-head competitor comparisons from any AI agent — real, source-backed data.
    MIT
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources