Loafy: Sourdough Bread Baking

Change a container in Loafy

update_container

DestructiveIdempotent

Change one of the baker's containers, by its id from list_my_containers: only the name, weight or notes given change, and a text given replaces the old text. No container is deleted. 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": {
      "id": "<id>"
    },
    "name": "update_container"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	The container's id, from list_my_containers or add_container.
`name`	No	The container's name, e.g. "Glass bowl".
`notes`	No	Notes on the container.
`weight_grams`	No	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.3/5.0

Behavior5/5

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

Annotations declare destructiveHint=true and idempotentHint=true, and the description adds the crucial nuance: only supplied fields change, a supplied text overwrites the old text, and no container itself is deleted. It also states the authentication requirement (the baker's Loafy account), which annotations do not cover.

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?

Compact and front-loaded, leading with the verb and the id source before the update semantics. The phrasing of 'a text given replaces the old text' is slightly clumsy, but every clause carries 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?

With an output schema present and annotations covering safety hints, the description supplies what remains: partial-update behavior, overwrite semantics, no-deletion guarantee, and auth needs. The mild tension between 'No container is deleted' and destructiveHint=true could have been disambiguated further (e.g., that notes text is the thing lost).

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 real semantics beyond the field list: unspecified fields are left untouched and supplied text replaces existing text. It maps loosely to name/weight/notes ('weight' for weight_grams), though it never gives id or unit/range detail beyond the schema.

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 ('Change') and resource ('one of the baker's containers'), and scopes it by id sourced from list_my_containers. The partial-update phrasing ('only the name, weight or notes given change') and 'No container is deleted' clearly separate it from add_container and any delete semantics.

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?

Usage is implied rather than stated: use this to modify an existing container whose id comes from list_my_containers or add_container. There is no explicit when-not guidance and no alternative named (e.g., add_container for new containers), so the agent must infer the boundary.

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?