Loafy: Sourdough Bread Baking

Find a flour in Loafy's list

find_flours

Read-onlyIdempotent

Find the exact flour a baker used, by brand and name or its barcode, among the flours of Loafy's list and the baker's own: each with its grain, how whole it is, its strength, the word on its bag and the token log_bake and update_bake take in flours ("flour: 400"). A flour nobody listed is logged as its grain with the word on the bag, such as "whole rye 100". Needs the baker's Loafy account.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "find_flours"
  }
}

Input Schema

Name	Required	Description
`grain`	No	Only flours of this grain.
`limit`	No	How many flours at most.
`query`	Yes	Brand and name as on the bag, such as "Caputo Pizzeria" or "King Arthur bread flour", or its barcode.

Output Schema

Name	Required	Description
`own`	No	The baker's own flours that match.
`url`	No	The same answer, recipe or entry on loafy.ai.
`note`	No	A remark on the whole result, such as why nothing was found.
`tool`	No	The tool that answered.
`input`	No	The arguments as the tool used them, after any correction.
`notes`	No	What was corrected or left out, such as a value outside its range.
`flours`	No	The best matches first: sold where the baker lives, Loafy's picks.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already establish read-only, idempotent, closed-world behavior, and the description adds real value on top: it discloses the authentication requirement (a Loafy account), that results merge two sources (Loafy's list and the baker's own), and the fallback behavior for an unlisted flour (logged as grain plus bag wording, e.g. "whole rye 100"). It does not discuss pagination or what happens when nothing matches, which keeps it short of a 5.

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 purpose is front-loaded, but the central clause is a dense colon-list ("its grain, how whole it is, its strength, the word on its bag and the token...") that is hard to parse and largely restates what the output schema already returns. Trimming that enumeration would sharpen the definition without losing information.

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 read-only lookup with a full schema and an output schema, the description covers the remaining gaps an agent needs: auth requirement, the two data sources searched, and the exact token format to carry forward. The only shortfall is that it spends words re-describing return fields the output schema already defines.

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 schema already documents query, grain, and limit with an enum and bounds. The description only reinforces the query form (brand and name or barcode), which the schema states anyway, and never mentions the grain filter or the limit cap. Baseline 3 is appropriate when the schema carries parameter meaning.

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 names a specific verb (find) and resource (flour), states the lookup keys (brand and name, or barcode), and delimits the search scope to Loafy's list plus the baker's own flours. It also names the downstream siblings (log_bake, update_bake) whose token format this produces, so an agent can tell what this tool is for without opening the schema.

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?

Usage context is clear: the result is the token that log_bake and update_bake accept, which implies calling this before logging or updating a bake. There are no explicit exclusions or named alternatives, but no sibling tool competes for this job, so the guidance is sufficient without being exhaustive.

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

All Loafy: Sourdough Bread Baking tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?