signal-bureau

save_watch

Watches: configure, unfurl and save free. Save a Watch to your key so you can recall it from any door and be told what changed since your last delivery. Saving is free, up to 5 saved Watches per verified email or key (see list_standard_watches terms); past that the answer is cap-reached with the next step (retire one, or ask us), and nothing is saved or charged. Pass watchId to edit a Watch you saved: that is a new version and takes no new place. Either start from a standard Watch (base; these read the Strait of Hormuz record) or name your own domain (domain + topics, from get_quote). For a domain, the coverage check runs again here and only covered topics are kept; no reading builder is published for this domain yet, so its reading is cannot-measure per topic and it is never served a standard Watch's reading. A standard Watch with no reading yet (its reading is not-yet-projected) is saved as pending coverage and takes none of your free places; it becomes a delivered Watch only if you choose. A domain Watch is saved as pending coverage until a reading for it is published; a domain with no covered topic is refused with the reason. Needs your key. Same content as POST /api/v1/watches.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "save_watch"
  }
}

Input Schema

Name	Required	Description
`base`	No	The standard Watch to start from: std.hormuz.maritime-operator, std.hormuz.energy-desk, std.us-iran.geopolitical-analyst. Leave it out when you name a domain.
`label`	No	Your own name for the Watch.
`domain`	No	Your domain in your own words, e.g. Arizona startup ecosystem. Use with topics instead of base.
`topics`	No	The topics your domain splits into (get_quote proposes them), as names or {name, scope}; 1 to 40. Only the ones coverage we keep reads are kept; the rest come back as free coverage requests.
`quoteId`	No	The quoteId get_quote returned. Recorded with the Watch; the coverage is checked again here either way.
`watchId`	No	Edit this saved Watch (a new version) instead of saving a new one.
`coordinates`	No	The coordinates you want to change from the base Watch; every one you leave out takes the base Watch's value. Keys: observer, question, domain, interval, language, depth, cadence, selection, thresholds, permission, delivery. Today the reading honours depth and delivery; the rest are recorded on your Watch and stated as not yet applied.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 6, 2026

changedInput schema / properties / base / description

Previous value: -"The standard Watch to start from: std.hormuz.maritime-operator, std.hormuz.energy-desk, std.us-iran.geopolitical-analyst."New value: +"The standard Watch to start from: std.hormuz.maritime-operator, std.hormuz.energy-desk, std.us-iran.geopolitical-analyst. Leave it out when you name a domain."

addedInput schema / properties / domain

Added value: +{
+  "description": "Your domain in your own words, e.g. Arizona startup ecosystem. Use with topics instead of base.",
+  "type": "string"
+}

addedInput schema / properties / quoteId

Added value: +{
+  "description": "The quoteId get_quote returned. Recorded with the Watch; the coverage is checked again here either way.",
+  "type": "string"
+}

addedInput schema / properties / topics

Added value: +{
+  "description": "The topics your domain splits into (get_quote proposes them), as names or {name, scope}; 1 to 40. Only the ones coverage we keep reads are kept; the rest come back as free coverage requests.",
+  "items": {
+    "anyOf": [
+      {
+        "type": "string"
+      },
+      {
+        "properties": {
+          "name": {
+            "type": "string"
+          },
+          "scope": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "name"
+        ],
+        "type": "object"
+      }
+    ]
+  },
+  "type": "array"
+}

removedInput schema / required
```
Removed value: -[
-  "base"
-]
```

AddedOct 5, 2026

TDQS

A3.6/5.0

Behavior3/5

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

The annotations already declare a non-read-only, non-destructive, non-idempotent write, and the description adds real context beyond that: the 5-per-key cap, cap-reached behavior with nothing saved or charged, watchId edits taking no new place, and pending-coverage Watches not consuming free slots. The depth is strong on quota and persistence, though the jargon (not-yet-projected, cannot-measure, pending coverage) blurs several of these claims.

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?

The action is front-loaded, but the paragraph is dense and jargon-heavy, mixing several unrelated points (quota, editing, coverage checks, pending state) into a single block. "Free" appears twice, and the domain coverage sentence with its embedded clauses is hard to parse; the content is useful, but the structure is not.

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 seven-parameter write with a nested coordinates object and no output schema, the description covers the quota model, the edit path, and the base/domain branches well enough to call it correctly. It could go further by explaining the coordinates patch semantics or what the response returns, but nothing is missing that would cause a failed call.

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 100%, so the schema already documents all seven parameters, making 3 the baseline. The description adds some genuine meaning for watchId (new version, takes no new place) and for base versus domain selection, but it never explains label, quoteId, or the coordinates sub-keys at the level the schema does not already reach.

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?

The description uses a specific verb and resource: "Save a Watch to your key so you can recall it from any door." That tells the agent this is a create-or-update operation on a personal Watch. Sibling tools (recall_watch, list_saved_watches, retire_watch, unfurl_watch) are implicitly distinguished by the save framing and by the watchId edit clause, but the opening phrase "configure, unfurl and save free" bundles three verbs and muddies the action.

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?

It states when to pass watchId (edit an existing saved Watch, which becomes a new version) versus starting fresh from base or naming a domain, and it names the cap condition with a next step (retire one, or ask us). It never explicitly names the alternatives (list_saved_watches to see current saves, retire_watch to free a place, get_quote to obtain topics), leaving the agent to infer them from the sibling names.

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

All signal-bureau 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?