RunWhen Platform MCP

Update Chat Command

update_chat_command

Modify an existing RunWhen workspace chat command by ID: change its name, content, scope, schedule, or run limits while leaving omitted fields unchanged.

Instructions

Update an existing chat command by ID.

Omitted fields are left unchanged. Schedule fields (cron_schedule, sink_configs, run_as_user, assistant_name, etc.) follow the same partial-update semantics as the PAPI. Use clear_max_runs=True to remove an existing run cap (MCP cannot send bare null for max_runs).

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	New command name.
`max_runs`	No	Replace the run budget (must be >= 1 when scheduling).
`scope_id`	No	New scope ID.
`is_active`	No	Set active/inactive.
`command_id`	Yes	The command ID to update.
`scope_type`	No	New scope type.
`description`	No	New description.
`run_as_user`	No	Replace the run-as user email.
`sink_configs`	No	Replace delivery targets for scheduled runs.
`cron_schedule`	No	New cron expression, or empty string to clear scheduling.
`assistant_name`	No	Replace the persona for scheduled runs (workspace prefix optional).
`clear_max_runs`	No	When true, remove the run budget cap (unlimited scheduled runs).
`workspace_name`	Yes	The workspace the command belongs to (e.g. 't-oncall').
`command_content`	No	New markdown content.
`schedule_paused`	No	Pause or resume the cron schedule.
`reset_runs_completed`	No	When true, reset runs_completed to 0 (e.g. after raising max_runs).
`auto_approve_readonly`	No	Toggle auto-approve for read-only tasks on scheduled runs.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Jul 7, 2026

TDQS

A3.8/5.0

Behavior4/5

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

No annotations exist, so the description carries the full behavioral burden, and it does disclose the crucial partial-update contract ("Omitted fields are left unchanged") plus a real MCP-level constraint on clearing max_runs. It omits authorization requirements, reversibility, and side effects on in-flight scheduled runs, and defers schedule semantics to an opaque external "PAPI" reference.

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 short sentences, front-loaded with the core action, then the update contract, then the one non-obvious workaround. The "etc." tail on the schedule-field list and the unexplained "PAPI" reference are the only wasted/opaque bits.

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 17-parameter mutation tool with 100% schema coverage and an output schema, the description covers the essential partial-update semantics an agent needs. It is thin only on permissions and scheduling side effects, which limits it below a top score.

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 the per-field descriptions already explain each parameter (baseline 3). The description adds real value beyond the schema by explaining the interaction between max_runs and clear_max_runs and by grouping the schedule-related fields under a shared partial-update rule.

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?

States a specific verb and resource ("Update an existing chat command by ID") and the schema/name make it trivially distinguishable from create_chat_command and get_chat_command. It stops short of explicitly routing against siblings, but the purpose is unambiguous.

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

Usage Guidelines3/5

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

Gives conditional guidance for one parameter path (use clear_max_runs=True to remove a run cap, since MCP can't send bare null for max_runs), which is genuinely useful. However it never says when to choose update vs. create/get/delete, nor any prerequisites such as required permissions or whether the command must exist.

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

Deploy Server