ZeroWidth

Create a routine

routines_create

Create a routine: something you keep doing for the user on a schedule, one turn per run ("every morning, read these forums, add new questions to the Questions table, and post the count in #support"). Each run has full workspace context and your machine where the workspace has machines. Use a routine when nobody but you acts on each run. Use a Task instead (workbench_tasks_create) when a person acts on each item before anything else happens, or the work is a process mapped in Compass. Name in writes the tools each run writes with on its own; other writes wait for approval on every run. A site read_webpage can't get needs routines_set_sites after this. Write the instruction in second person, as a directive to you on a future run. To run a specific built Workbench flow on a schedule, use workbench_flows_schedule instead: a routine runs an instruction, not a flow.

Input Schema

Name	Required	Description
`name`	Yes	Short display name.
`roomId`	No	With delivery "room": the room to post in (rooms_list gives ids).
`writes`	No	Tools each run writes with on its own, without asking: the ones the job needs every time, like ["napkin_tables_add_records"]. The person approves this list once, with this call. Any other write waits for approval on every run, and emails, invites, shares, publishing, schedules, deletes and starting other work always wait, even when listed.
`actsFor`	No	Visibility: "workspace" (everyone sees it) or "personal" (just the owner). Default workspace.
`delivery`	No	Where each run's briefing lands (default notification). "room" posts it in a team room for everyone there; pass roomId. The user must be in the room if it's private, and a "personal" routine can post only in a private room. Use it when the user names a room ("…and post it in #claims") or asks from inside one for the room.
`interval`	No	Plain cadence. Omit when passing recurrence.
`workspace`	No	Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.
`approvalId`	No	Approval id from a prior needs_confirmation envelope.
`recurrence`	No	When it runs, like a calendar event repeats; use it for anything beyond a plain hourly/daily/weekly at one time (then omit interval). {"freq":"hourly"\|"daily"\|"weekly"\|"monthly"\|"yearly","every":N,"times":["HH:MM"],"weekdays":[0=Sun…6=Sat],"monthDays":[1…31,-1=last],"nthWeekdays":[{"nth":1…5\|-1,"weekdays":[…]}],"months":[1…12],"minutes":[…],"hours":{"from","to"},"timezone":"<IANA>","starts","ends","skip":["YYYY-MM-DD"]}. Examples: weekdays at 8 → {"freq":"weekly","weekdays":[1,2,3,4,5],"times":["08:00"],"timezone":"America/Chicago"}; the last business day of the month → {"freq":"monthly","nthWeekdays":[{"nth":-1,"weekdays":[1,2,3,4,5]}],"timezone":"…"}; every other Friday → {"freq":"weekly","every":2,"weekdays":[5],"starts":"<a Friday>","timezone":"…"}. null clears it.
`instruction`	Yes	What to do on each run, as a directive.
`scheduleTime`	No	Wall-clock "HH:MM" anchor (default 09:00).
`scheduleTimezone`	No	IANA timezone for the anchor (default UTC).
`scheduleDayOfWeek`	No	Weekly only: 0=Sunday … 6=Saturday (default Monday).

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 22, 2026

addedInput schema / properties / interval / description

Added value: +"Plain cadence. Omit when passing recurrence."

addedInput schema / properties / recurrence

Added value: +{
+  "anyOf": [
+    {
+      "properties": {
+        "ends": {
+          "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+          "type": "string"
+        },
+        "every": {
+          "default": 1,
+          "maximum": 366,
+          "minimum": 1,
+          "type": "integer"
+        },
+        "freq": {
+          "enum": [
+            "hourly",
+            "daily",
+            "weekly",
+            "monthly",
+            "yearly"
+          ],
+          "type": "string"
+        },
+        "hours": {
+          "properties": {
+            "from": {
+              "pattern": "^([01]\\d|2[0-3]):[0-5]\\d$",
+              "type": "string"
+            },
+            "to": {
+              "pattern": "^([01]\\d|2[0-3]):[0-5]\\d$",
+              "type": "string"
+            }
+          },
+          "required": [
+            "from",
+            "to"
+          ],
+          "type": "object"
+        },
+        "minutes": {
+          "items": {
+            "maximum": 59,
+            "minimum": 0,
+            "type": "integer"
+          },
+          "maxItems": 12,
+          "minItems": 1,
+          "type": "array"
+        },
+        "monthDays": {
+          "items": {
+            "maximum": 31,
+            "minimum": -1,
+            "type": "integer"
+          },
+          "maxItems": 31,
+          "minItems": 1,
+          "type": "array"
+        },
+        "months": {
+          "items": {
+            "maximum": 12,
+            "minimum": 1,
+            "type": "integer"
+          },
+          "maxItems": 12,
+          "minItems": 1,
+          "type": "array"
+        },
+        "nthWeekdays": {
+          "items": {
+            "properties": {
+              "nth": {
+                "maximum": 5,
+                "minimum": -1,
+                "type": "integer"
+              },
+              "weekdays": {
+                "items": {
+                  "maximum": 6,
+                  "minimum": 0,
+                  "type": "integer"
+                },
+                "maxItems": 7,
+                "minItems": 1,
+                "type": "array"
+              }
+            },
+            "required": [
+              "nth",
+              "weekdays"
+            ],
+            "type": "object"
+          },
+          "maxItems": 5,
+          "minItems": 1,
+          "type": "array"
+        },
+        "skip": {
+          "items": {
+            "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+            "type": "string"
+          },
+          "maxItems": 100,
+          "type": "array"
+        },
+        "starts": {
+          "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+          "type": "string"
+        },
+        "times": {
+          "items": {
+            "pattern": "^([01]\\d|2[0-3]):[0-5]\\d$",
+            "type": "string"
+          },
+          "maxItems": 24,
+          "minItems": 1,
+          "type": "array"
+        },
+        "timezone": {
+          "maxLength": 64,
+          "minLength": 1,
+          "type": "string"
+        },
+        "weekdays": {
+          "items": {
+            "maximum": 6,
+            "minimum": 0,
+            "type": "integer"
+          },
+          "maxItems": 7,
+          "minItems": 1,
+          "type": "array"
+        }
+      },
+      "required": [
+        "freq",
+        "timezone"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "When it runs, like a calendar event repeats; use it for anything beyond a plain hourly/daily/weekly at one time (then omit interval). {\"freq\":\"hourly\"|\"daily\"|\"weekly\"|\"monthly\"|\"yearly\",\"every\":N,\"times\":[\"HH:MM\"],\"weekdays\":[0=Sun…6=Sat],\"monthDays\":[1…31,-1=last],\"nthWeekdays\":[{\"nth\":1…5|-1,\"weekdays\":[…]}],\"months\":[1…12],\"minutes\":[…],\"hours\":{\"from\",\"to\"},\"timezone\":\"<IANA>\",\"starts\",\"ends\",\"skip\":[\"YYYY-MM-DD\"]}. Examples: weekdays at 8 → {\"freq\":\"weekly\",\"weekdays\":[1,2,3,4,5],\"times\":[\"08:00\"],\"timezone\":\"America/Chicago\"}; the last business day of the month → {\"freq\":\"monthly\",\"nthWeekdays\":[{\"nth\":-1,\"weekdays\":[1,2,3,4,5]}],\"timezone\":\"…\"}; every other Friday → {\"freq\":\"weekly\",\"every\":2,\"weekdays\":[5],\"starts\":\"<a Friday>\",\"timezone\":\"…\"}. null clears it."
+}

addedInput schema / properties / writes

Added value: +{
+  "description": "Tools each run writes with on its own, without asking: the ones the job needs every time, like [\"napkin_tables_add_records\"]. The person approves this list once, with this call. Any other write waits for approval on every run, and emails, invites, shares, publishing, schedules, deletes and starting other work always wait, even when listed.",
+  "items": {
+    "pattern": "^[a-z][a-z0-9_]{1,79}$",
+    "type": "string"
+  },
+  "maxItems": 20,
+  "type": "array"
+}

changedInput schema / required

Previous value: -[
-  "name",
-  "instruction",
-  "interval"
-]New value: +[
+  "name",
+  "instruction"
+]

First observedOct 7, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Adds substantial context beyond annotations: the writes list grants unilateral write permission, all other writes require per-run approval, and emails/invites/shares/publishing/schedules/deletes/starting other work always wait even if listed. It also notes the read_webpage -> routines_set_sites caveat. Annotations only say not read-only and not destructive; the description adds the real approval model.

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?

Front-loads the core definition and example before the decision routing, with no filler. It is dense and long-ish, but given the tool's complexity and the number of sibling alternatives, most sentences earn their place.

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 13-parameter scheduling tool with no output schema, the description covers purpose, alternatives, approval semantics, delivery expectations, and a gotcha about site pages. The remaining recurrence/delivery mechanics are well documented in the schema, so nothing critical is missing.

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 coverage is 100%, so baseline is 3, but the description adds semantic meaning to key params: it explains that 'name in writes' governs autonomous writes and why, and that instruction must be written in second person as a directive for a future run. That is genuine value beyond the schema.

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+resource (create a routine) and immediately defines what a routine is with a concrete example. It explicitly distinguishes from workbench_tasks_create and workbench_flows_schedule, so an agent can identify it without opening schemas.

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?

Gives explicit when-to-use rules: routine when nobody but you acts on each run; Task when a person acts on each item; Compass for mapped processes; workbench_flows_schedule for a built flow. Names the alternatives and the conditions that select them.

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

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