Skip to main content
Glama
Sign In

Mundane

by market.mundane
OverviewDiscussionsAdmin

add_checkpoint

Put a big button on the worker's page for a moment you care about. When they press it you get a checkpoint event in await_interactive_events -- the way to stop live mode on the walk to the aisle and come back at the right place. Up to 6 armed at once; each fires once.

For a question, arm one button per answer in the same group. When the worker has pressed picks of them, the others clear from their page (status cleared, listed in the event's cleared), so they don't linger beside your next question. An answered group can't be reused: give the next question its own.

Input Schema

NameRequiredDescriptionDefault
colorNogreen, red, blue, yellow, purple or orange.green
groupNoName the question this button answers ('persimmon firmness') and give every answer button the same group: once the worker picks, the rest of the group leave their page. 1-40 characters. Omit for a standalone button.
labelYesThe button's text, as the worker should press it: 'I see the avocados', 'I'm at the ground beef'. 1-60 characters.
picksNoHow many of the group's buttons answer it, 1-6: 1 for a single choice. Every button in a group says the same. Needs a group.
go_liveNoPressing it also puts the worker live, so frames start. False just tells you.
task_idYesThe interactive task.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / group
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Name the question this button answers ('persimmon firmness') and give every answer button the same group: once the worker picks, the rest of the group leave their page. 1-40 characters. Omit for a standalone button.",
+  "title": "Group"
+}
    • addedInput schema / properties / picks
      Added value: +{
+  "default": 1,
+  "description": "How many of the group's buttons answer it, 1-6: 1 for a single choice. Every button in a group says the same. Needs a group.",
+  "title": "Picks",
+  "type": "integer"
+}
  2. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare mutation (readOnlyHint=false), non-idempotency and non-destructiveness. The description adds real operational context beyond them: a 6-button cap, each button fires exactly once, sibling buttons auto-clear with status `cleared` reported in the event, and a used group cannot be reused. It stops short of error/lifecycle edge cases (what happens past the cap, how a checkpoint is later removed).

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?

Purpose is front-loaded in the first clause and the group mechanics are cleanly separated into a second paragraph. The conversational framing ('Put a big button', 'the walk to the aisle') is padding, but it stays under ~130 words and every paragraph carries usable information.

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

Completeness5/5

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

For a 6-parameter mutation tool with full schema coverage and no output schema, the description covers what the agent must know: what is created, where the resulting event shows up, the cap, group clearing, and non-reuse of groups. The one omission — whether the call returns an identifier needed by cancel_checkpoint — is minor given the sibling tool's own documentation.

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 description coverage is 100%, so the baseline is 3 and the schema already carries per-field syntax. The description still adds framing the schema lacks: the multi-button 'one button per answer in the same group' pattern, the group-wide consistency of `picks`, and the instruction to give each follow-up question a fresh group.

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 concrete verb on a concrete resource ('Put a big button on the worker's page') and names the mechanism/tool through which the result arrives ('you get a `checkpoint` event in await_interactive_events'). An agent can tell this apart from sibling tools like await_interactive_events or cancel_checkpoint from the text alone.

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 a clear use case ('the way to stop live mode on the walk to the aisle and come back at the right place') and a second, more specific one for question/answer groups. It does not state when NOT to use it (e.g., vs. cancel_checkpoint or show_worker_image), so it falls short of explicit alternatives/exclusions.

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

All Mundane 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