ShotPulled

Register an espresso machine

register_machine

Register an espresso or alternative preparation machine. It becomes the active machine only when no machine is in use (none active, or the active one archived); otherwise call set_active with its machine_id to switch to it. The active field of the reply says which.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Machine name/model, e.g. Dedica EC685
`notes`	No
`photo`	No	Photo path or URL
`tools`	No	JSON or comma-separated tools, e.g., paper filters, flow control, metal mesh
`archived`	No	1 if archived, 0 if active
`prep_type`	No	Preparation equipment type. One of: espresso_machine, lever_press, moka_pot, aeropress, french_press, v60_dripper, cold_brew. Lower snake_case.
`catalog_id`	No	Optional — the maintenance catalog model this is (the `id` of a catalog row, e.g. rancilio-silvia), when it was registered from the catalog. Its maintenance then comes from that model's researched record. "none" says it is not in the catalog.
`prep_style`	No	Preparation style. One of: espresso, filter, immersion, percolation. Only "espresso" is diagnosed by the dialing engine (G8) — anything else is recorded but never dialed, so do not guess this field.
`boiler_type`	No
`hardness_dh`	No	Optional — the TOTAL hardness (GH) of the water this machine runs on, in °dH (German degrees; ppm as CaCO3 ÷ 17.85), as a test strip reports it. Picks the band of a maker's hardness table for descaling and filter life
`control_type`	Yes
`connected_device`	No	Metadata mapping to smart hardware APIs
`basket_size_grams`	No
`built_in_grinder_id`	No	id of a grinder built into this machine (bean-to-cup / integrated grinder)

Output Schema

TableJSON Schema

Name	Required	Description	Default
`active`	Yes
`status`	Yes
`message`	Yes
`machine_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 27, 2026

addedOutput schema / properties / active
```
Added value: +{
+  "type": "boolean"
+}
```

changedOutput schema / required

Previous value: -[
-  "status",
-  "machine_id",
-  "message"
-]New value: +[
+  "status",
+  "machine_id",
+  "active",
+  "message"
+]

Changed2 schema fields changedSep 27, 2026

addedInput schema / properties / catalog_id

Added value: +{
+  "description": "Optional — the maintenance catalog model this is (the `id` of a catalog row, e.g. rancilio-silvia), when it was registered from the catalog. Its maintenance then comes from that model's researched record. \"none\" says it is not in the catalog.",
+  "type": "string"
+}

addedInput schema / properties / hardness_dh

Added value: +{
+  "description": "Optional — the TOTAL hardness (GH) of the water this machine runs on, in °dH (German degrees; ppm as CaCO3 ÷ 17.85), as a test strip reports it. Picks the band of a maker's hardness table for descaling and filter life",
+  "type": [
+    "number",
+    "null"
+  ]
+}

Changed3 schema fields changedAug 17, 2026

changedInput schema / properties / prep_style / description

Previous value: -"Preparation style category, e.g., espresso, filter, immersion"New value: +"Preparation style. One of: espresso, filter, immersion, percolation. Only \"espresso\" is diagnosed by the dialing engine (G8) — anything else is recorded but never dialed, so do not guess this field."

changedInput schema / properties / prep_type / description

Previous value: -"Preparation equipment type, e.g., espresso_machine, v60_dripper, French_press"New value: +"Preparation equipment type. One of: espresso_machine, lever_press, moka_pot, aeropress, french_press, v60_dripper, cold_brew. Lower snake_case."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "machine_id": {
+      "type": "integer"
+    },
+    "message": {
+      "type": "string"
+    },
+    "status": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "status",
+    "machine_id",
+    "message"
+  ],
+  "type": "object"
+}

Changed1 schema field changedJul 29, 2026

addedInput schema / properties / built_in_grinder_id

Added value: +{
+  "description": "id of a grinder built into this machine (bean-to-cup / integrated grinder)",
+  "type": "integer"
+}

Changed1 schema field changedJul 19, 2026
- changedInput schema / properties / tools / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
First observedJun 16, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare the safety profile (readOnly=false, destructive=false, idempotent=false), so the bar is lower. The description adds genuine behavioral context beyond that: the conditional activation side-effect (only active when none active or the active one archived) and the resulting need to call set_active otherwise. It does not cover auth or error behavior, but the side-effect disclosure is the important 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?

Three tight, front-loaded sentences with no filler, and the activation condition is stated before the alternative route to set_active. The closing sentence about the reply's 'active' field is mildly redundant given an output schema exists, but it is still useful signaling.

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?

For a 14-parameter write tool with an output schema and annotations, the description supplies the critical missing piece — conditional activation and the set_active fallback — while the schema covers the bulk of parameter documentation. Auth and validation behavior are left implicit, but nothing essential for correct invocation 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 coverage is 71%, so the schema largely documents the 14 parameters itself. The description adds no input-parameter meaning beyond the schema; its only field reference ('active') is an output field. Baseline 3 is appropriate when structured fields carry the parameter load.

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 ('Register') and resource ('espresso or alternative preparation machine'), and distinguishes itself from the sibling set_active by name. An agent can tell it apart from update_machine, register_grinder, and set_active without opening any schema.

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

Usage Guidelines5/5

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

Explicitly states the when ('becomes the active machine only when no machine is in use') and the when-not with a named alternative ('otherwise call set_active with its machine_id to switch to it'). This is textbook routing guidance.

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

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