Loafy: Sourdough Bread Baking

Add a container to Loafy

add_container

Add a container to the baker's Loafy account with its empty weight in grams, so Loafy can take it off when dough is weighed in it. Returns it with its id and a link. A name the baker already uses is not added again; that container comes back, and update_container 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>",
      "weight_grams": "<weight_grams>"
    },
    "name": "add_container"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	The container's name, e.g. "Glass bowl".
`notes`	No	Notes on the container.
`weight_grams`	Yes	The empty container's weight in grams.

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.
`container`	No	One of the baker's containers.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 18, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "description": "The container as saved.",
+  "properties": {
+    "container": {
+      "description": "One of the baker's containers.",
+      "properties": {
+        "id": {
+          "description": "The container's id, which update_container takes.",
+          "type": "string"
+        },
+        "name": {
+          "description": "Its name.",
+          "type": "string"
+        },
+        "notes": {
+          "description": "Notes on it.",
+          "type": "string"
+        },
+        "url": {
+          "description": "The container on loafy.ai.",
+          "type": "string"
+        },
+        "weight_grams": {
+          "description": "Its empty weight, in grams.",
+          "type": "number"
+        }
+      },
+      "type": "object"
+    },
+    "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"
+    },
+    "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?

Goes beyond the annotations by disclosing the name-collision dedup behavior (existing container is returned instead of a duplicate being created) and the auth prerequisite. Annotations already cover the safety profile (readOnly=false, destructive=false, openWorld=false). The dedup-on-name detail is a genuine behavioral nuance, though it sits in slight tension with idempotentHint=false.

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?

Roughly four short sentences, front-loaded with the core action and purpose, then the return value, then the dedup/alternative behavior. Mostly earns its place, though the "so Loafy can take it off..." clause is somewhat verbose.

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?

Covers the action, auth requirement, dedup edge case, and routing to update_container; return details are backed by an output schema so need not be restated. Adequate for a low-complexity 3-param tool, with only minor room for richer context.

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 name, notes, and weight_grams with units and ranges. The description reinforces the meaning of the weight (empty weight subtracted when dough is weighed) but adds no syntax or format detail beyond the schema. Baseline 3 is appropriate.

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 and resource ("Add a container to the baker's Loafy account") and clarifies its purpose (recording empty weight so Loafy can subtract it during dough weighing). It also explicitly distinguishes itself from the sibling update_container for changing an existing container.

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?

Explains the condition for use and the key when-not case: a name the baker already uses will not be added again, and update_container is named as the alternative for changing an existing container. Prerequisite ("Needs the baker's Loafy account") is also stated. Lacks a broader statement of when a container should be registered versus other workflows.

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?