brewmark

Grinder settings chart

get_grinder_chart

Read-onlyIdempotent

Grind settings for one grinder across every brew method. Use this for any question of the form "what grind should I use for my ", "what setting for French press on a ", or "how do I dial in my ". Returns the recommended setting and usable range for espresso, moka pot, AeroPress, pour over, siphon, steep-and-release (Clever Dripper, Hario Switch), drip, cupping, Chemex, French press and cold brew. When the user names a brew method, pass it as method: the answer then leads with that method, plus a starting recipe (ratio, dose, water temperature, time). The grinder can be named however the user said it.

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": {
      "grinder": "<grinder>"
    },
    "name": "get_grinder_chart"
  }
}

Input Schema

Name	Required	Description
`roast`	No	Optional roast level of the coffee the user is brewing. If they name a coffee rather than a roast ("Stumptown Hair Bender", "Lavazza Super Crema"), use what you know of it; leave out when unsure. Lighter roasts move the starting setting finer, darker ones coarser.
`method`	No	Optional brew method the user asked about, as they said it: "V60", "pour over", "French press", "espresso", "AeroPress", "cold brew", "Chemex", "drip", "moka pot", "siphon", "Clever Dripper", "cupping"
`grinder`	Yes	Grinder name as the user said it, e.g. "Fellow Ode", "Baratza Encore", or a slug

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 22, 2026

changedInput schema / properties / method / description

Previous value: -"Optional brew method the user asked about, as they said it: \"V60\", \"pour over\", \"French press\", \"espresso\", \"AeroPress\", \"cold brew\", \"Chemex\", \"drip\", \"moka pot\""New value: +"Optional brew method the user asked about, as they said it: \"V60\", \"pour over\", \"French press\", \"espresso\", \"AeroPress\", \"cold brew\", \"Chemex\", \"drip\", \"moka pot\", \"siphon\", \"Clever Dripper\", \"cupping\""

Changed2 schema fields changedOct 22, 2026

addedInput schema / properties / method

Added value: +{
+  "description": "Optional brew method the user asked about, as they said it: \"V60\", \"pour over\", \"French press\", \"espresso\", \"AeroPress\", \"cold brew\", \"Chemex\", \"drip\", \"moka pot\"",
+  "type": "string"
+}

addedInput schema / properties / roast

Added value: +{
+  "description": "Optional roast level of the coffee the user is brewing. If they name a coffee rather than a roast (\"Stumptown Hair Bender\", \"Lavazza Super Crema\"), use what you know of it; leave out when unsure. Lighter roasts move the starting setting finer, darker ones coarser.",
+  "enum": [
+    "light",
+    "medium-light",
+    "medium",
+    "medium-dark",
+    "dark"
+  ],
+  "type": "string"
+}

First observedOct 22, 2026

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare this a read-only, idempotent, non-destructive, closed-world call, so the safety profile is covered. The description contributes the return shape (recommended setting plus usable range per method, and a starting recipe when method is given), but says nothing about lookup failure or what happens when the grinder is unknown.

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?

Front-loaded with the core purpose, then usage patterns, then the method behavior. The list of brew methods is long but earns its place by telling the agent the coverage boundary.

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 no output schema, the description does the work of describing what comes back and how the method parameter reshapes the answer. What's missing is error/fallback behavior for unrecognized grinders or methods.

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 baseline is 3. The description goes beyond the schema by explaining the effect of `method` on the response ordering and the added starting recipe, plus the 'name it however the user said it' leniency for `grinder`.

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?

States a specific verb+resource: grind settings for one grinder across every brew method, and enumerates the covered methods. It stops short of explicitly distinguishing itself from the sibling dial_in, whose name overlaps with the 'how do I dial in my <grinder>' phrasing quoted here.

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?

Gives concrete question shapes that select this tool and tells the agent when to pass `method`. It never names when to use convert_grind_setting, find_grinder or dial_in instead, so routing between overlapping siblings is left to inference.

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

All brewmark 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?