Skip to main content
Glama

ShotPulled

by com.shotpulled
OverviewDiscussionsAdmin

List locked recipes

list_recipes
Read-onlyIdempotent

List recipes (all or filtered by equipment and status). The id on each row is the number this account knows that record by, counting from 1 — safe to show, and what other tools expect back.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
statusNoFilter by status: current, archived, or all. Defaults to current.
bean_idNo
grinder_idNo
machine_idNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
recipesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedOutput schema / properties / recipes / items / properties / grind_reading / properties / epoch_tasks
      Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedOutput schema / properties / recipes / items / properties / grind_reading / properties / untranslatable
      Added value: +{
+  "type": "boolean"
+}
  2. Changed2 schema fields changed
    • addedOutput schema / properties / recipes / items / properties / roaster_name
      Added value: +{
+  "type": "string"
+}
    • changedOutput schema / properties / recipes / items / required
      Previous value: -[
-  "id",
-  "bean_id",
-  "grinder_id",
-  "machine_id",
-  "program_id",
-  "status",
-  "grind_label",
-  "grind_position_value",
-  "dose_g",
-  "target_yield_g",
-  "target_time_s",
-  "finish_action",
-  "drink_intent",
-  "profile",
-  "locked_at",
-  "bean_name",
-  "grinder_name",
-  "machine_name",
-  "grind_reading"
-]New value: +[
+  "id",
+  "bean_id",
+  "grinder_id",
+  "machine_id",
+  "program_id",
+  "status",
+  "grind_label",
+  "grind_position_value",
+  "dose_g",
+  "target_yield_g",
+  "target_time_s",
+  "finish_action",
+  "drink_intent",
+  "profile",
+  "locked_at",
+  "bean_name",
+  "roaster_name",
+  "grinder_name",
+  "machine_name",
+  "grind_reading"
+]
  3. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already carry readOnly, idempotent, and non-destructive hints, and the description adds useful behavior beyond those: each returned id is the account-relative sequence number, safe to display, and is what sibling tools expect as input. This helps an agent understand the contract for chaining calls. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler: the first sentence is front-loaded with the call's action and filters, and the second sentence explains the critical id semantics. Every word contributes.

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, the description need not explain return values, and annotations cover the safety profile. The missing equipment-to-parameter mapping is a gap, but the description's id contract plus the schema make the tool callable and reliable enough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 25%: status is the only parameter with a definition, while bean_id, grinder_id, and machine_id are bare integer names. The description mentions 'equipment' but never maps it to those three IDs, so it fails to compensate for the low schema coverage.

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 clear verb-resource pair, 'List recipes', and immediately states the scoping options: all or filtered by equipment and status. That level of specificity is enough for an agent to distinguish it from the other list_* siblings without opening their schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance says when to choose list_recipes over alternatives such as list_shots or lock_recipe, and no exclusions or prerequisites are stated. The closest signal is the mention of 'all or filtered by equipment and status,' which only implies a general querying context.

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

All ShotPulled toolsInspect
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