Loafy: Sourdough Bread Baking

Add a starter to Loafy

add_starter

Add a sourdough starter to the baker's Loafy account: its name, the day it was started, notes and its story. Returns it with its id and a link, where photos are added. A name the baker already uses is not added again; that starter comes back, and update_starter changes it. 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": {
      "name": "<name>"
    },
    "name": "add_starter"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	The starter's name.
`notes`	No	Notes on the starter, e.g. its flour and how it is fed.
`story`	No	Where the starter comes from, in the baker's words.
`birthday`	No	The day the starter was started, as YYYY-MM-DD; today if left out.

Output Schema

Name	Required	Description
`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.
`saved`	No	What was saved, in one sentence.
`starter`	No	One of the baker's starters.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 18, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "description": "The starter as saved.",
+  "properties": {
+    "input": {
+      "description": "The arguments as the tool used them, after any correction.",
+      "properties": {},
+      "type": "object"
+    },
+    "note": {
+      "description": "A remark on the whole result, such as why nothing was found.",
+      "type": "string"
+    },
+    "notes": {
+      "description": "What was corrected or left out, such as a value outside its range.",
+      "items": {
+        "description": "A correction or remark.",
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "saved": {
+      "description": "What was saved, in one sentence.",
+      "type": "string"
+    },
+    "starter": {
+      "description": "One of the baker's starters.",
+      "properties": {
+        "age_days": {
+          "description": "Its age in days.",
+          "type": "integer"
+        },
+        "bakes": {
+          "description": "How many bakes it went into.",
+          "type": "integer"
+        },
+        "birthday": {
+          "description": "The day it was started, YYYY-MM-DD.",
+          "type": "string"
+        },
+        "id": {
+          "description": "The starter's id, which update_starter takes.",
+          "type": "string"
+        },
+        "last_baked_on": {
+          "description": "Its last bake, YYYY-MM-DD.",
+          "type": "string"
+        },
+        "name": {
+          "description": "Its name.",
+          "type": "string"
+        },
+        "notes": {
+          "description": "Notes on it.",
+          "type": "string"
+        },
+        "story": {
+          "description": "Its story.",
+          "type": "string"
+        },
+        "url": {
+          "description": "The starter on loafy.ai.",
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "tool": {
+      "description": "The tool that answered.",
+      "type": "string"
+    },
+    "url": {
+      "description": "The same answer, recipe or entry on loafy.ai.",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedOct 17, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already cover the safety profile (non-read-only, non-destructive, non-idempotent), so the bar is lower. The description adds genuinely useful context beyond them: the return value (id and link for adding photos) and the duplicate-name semantics where an existing starter is returned instead of creating a new one.

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 definition is front-loaded with the core action and keeps each sentence purposeful, covering fields, return, duplicate handling, and prerequisites without filler. It is slightly dense but well-structured.

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 an output schema present, return values need not be detailed, yet the description still notes the id/link return and duplicate-name behavior. Prerequisites and the update_starter route are covered, leaving little an agent needs that is missing.

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 schema already documents all four parameters including the YYYY-MM-DD birthday default. The description echoes the field set but adds no syntax or format detail beyond the schema, matching the baseline 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 opens with a specific verb and resource: 'Add a sourdough starter to the baker's Loafy account,' and enumerates the fields it carries (name, start day, notes, story). It also distinguishes itself from the sibling update_starter, so an agent can tell the two apart without opening either 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?

It gives a clear when-not case ('A name the baker already uses is not added again') and names the alternative (update_starter) for that scenario. The prerequisite 'Needs the baker's Loafy account' is stated, though general positive guidance for when to reach for this vs other add_* siblings is only implied.

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?