ShotPulled

Register a scale

register_scale

Input Schema

Name	Required	Description
`name`	Yes	Scale name/model, e.g. Acaia Lunar, Timemore Black Mirror Basic 2
`notes`	No	Additional notes
`power`	No	How it is powered or recharged
`depth_mm`	No	Platform depth in mm
`width_mm`	No	Platform width in mm. Measure your drip tray
`auto_tare`	No	1 if it zeroes itself when a vessel is set down, 0 if not, null if unstated
`height_mm`	No	Overall height in mm: the dimension that decides whether it fits under a group head
`auto_timer`	No	1 if the timer starts on first flow, 0 if not, null if unstated
`capacity_g`	No	Maximum weight in grams. The cup or portafilter counts against it
`scale_type`	Yes	What the scale is built for: espresso (drip-tray footprint), brew (pour-over platform), dual (both modes), connected (app/controller integration), dosing (gravimetric dispensing), training, bench (high capacity, coarse)
`connectivity`	No	How the scale talks to an app or a machine controller
`resolution_g`	No	Finest published readability in grams. Leave null unless the maker states it
`water_resistance`	No	IEC 60529 ingress code as published, e.g. IPX4, IPX6, IP67, or none
`flow_rate_display`	No	1 if the scale shows live flow rate in g/s, 0 if it does not, null if the maker never said
`resolution_banded`	No	1 when resolution_g only holds in the lowest weight band and coarsens with load. Put the ladder in notes

Output Schema

Name	Required	Description	Default
`status`	Yes
`message`	Yes
`scale_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 22, 2026

changedInput schema / properties / height_mm / description

Previous value: -"Overall height in mm — the dimension that decides whether it fits under a group head"New value: +"Overall height in mm: the dimension that decides whether it fits under a group head"

changedInput schema / properties / resolution_banded / description

Previous value: -"1 when resolution_g only holds in the lowest weight band and coarsens with load — put the ladder in notes"New value: +"1 when resolution_g only holds in the lowest weight band and coarsens with load. Put the ladder in notes"

changedInput schema / properties / width_mm / description

Previous value: -"Platform width in mm — measure your drip tray"New value: +"Platform width in mm. Measure your drip tray"

Changed1 schema field changedAug 17, 2026

changedOutput schema / (root)

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

AddedAug 7, 2026

TDQS

C2.8/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the description only needs to add context beyond that, and it adds almost none. It does not say what happens on a duplicate name, whether the call fails or merges, or what the response contains. The phrase about weighing dose and yield is a definition, not behavior.

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

Conciseness3/5

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

A single front-loaded sentence with no waste, but it is undersized for a 15-parameter creation tool; the brevity is under-specification rather than economy. Nothing in the sentence is wasted, yet it does not use its position to route the agent anywhere.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 15-param create tool with a rich sibling set, the description omits duplicate handling, the update_scale alternative, and any note about which fields matter most (despite the schema hinting at fit under a group head). An output schema and annotations exist, so return values need not be explained, but the calling context is thin.

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% and the 15 parameters are richly documented inline, including enum meanings and null conventions, so the schema does the heavy lifting. The description adds no parameter meaning at all. Baseline 3 applies.

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?

Names a specific verb and resource (register a scale) and glosses the resource as the weighing instrument for dose and yield, which distinguishes it from register_grinder/register_machine. It does not explicitly separate it from update_scale, but the create-vs-update distinction is carried by the verb 'register'.

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?

There is no when-to-use guidance at all: no mention of using update_scale for an existing scale, no pointer to list_scales to check for duplicates, and no prerequisites. The only signal is the implicit 'register = new record' reading of the verb.

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?