Skip to main content
Glama

mcp-coreclaw

update_worker_task

Idempotent

Update a saved CoreClaw worker task's metadata and schedule. Partial update: omit fields to keep their current values.

WHEN TO USE: Use when the user wants to change a task's title, description, or schedule settings. 中文触发: 当用户要在 CoreClaw 中查询、运行、重跑、停止、导出或查看对应 worker/run/task 数据时使用。

WHEN NOT TO USE: Do not use public web search or code search for private CoreClaw platform data. Do not call excluded internal worker-version or internal-detail APIs.

RETURNS: JSON success envelope data, often null.

WORKFLOW: Call after get_worker_task to confirm current settings. Use update_worker_task_input to update the task's input payload separately.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleNoTask title. Example: "Daily Amazon Price Check". Optional on update; omitted fields are preserved. (optional)
descriptionNoTask description. (optional)
schedule_dayNoDay of month for monthly schedule (1-31). (optional)
schedule_timeNoSchedule time in HH:mm format. Example: "09:00". (optional)
schedule_typeNoSchedule type: 1=daily, 2=weekly, 3=monthly, 4=once. (optional)
worker_task_idYesSaved worker task slug. Example: "task_daily_demo". Obtain from list_worker_tasks.
schedule_enabledNoSchedule switch: 0 disabled, 1 enabled. (optional)
schedule_weekdayNoDay of week for weekly schedules: 1=Monday … 7=Sunday. (optional)
schedule_once_dateNoOnce schedule date in YYYY-MM-DD format. Example: "2026-12-25". (optional)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / title / description
      Previous value: -"Task title. Example: \"Daily Amazon Price Check\"."New value: +"Task title. Example: \"Daily Amazon Price Check\". Optional on update; omitted fields are preserved. (optional)"
    • changedInput schema / required
      Previous value: -[
      -  "worker_task_id",
      -  "title"
      -]New value: +[
      +  "worker_task_id"
      +]
  2. Added

TDQS

A3.6/5.0
Behavior4/5

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

The description reveals that omitted fields are preserved via partial update, which is important behavioral context. It also discloses return format as 'JSON success envelope data, often null' and suggests calling after get_worker_task. Annotations already include idempotentHint=true, but the description adds workflow and partial-update semantics without contradiction.

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 description is structured with headers and front-loaded with the key statement. However, the Chinese trigger appears to be an irrelevant copy-paste error and the WHEN NOT TO USE section references unrelated APIs, adding noise without value. Overall it is moderately concise but contains extraneous content.

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?

The description provides a clear workflow, return behavior, and when-to-use guidance. Combined with the 100%-detailed schema, the agent has most context needed to call it correctly. The misleading Chinese trigger and vague exclusion about internal APIs slightly reduce completeness, but the core guidance is present.

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 covers 100% of parameters with detailed descriptions and examples, so the baseline is 3. The description's general 'omit fields to keep current values' reinforces what the schema says for title, and all parameters are already well-documented. No additional parameter-specific semantics are needed.

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?

The opening sentence 'Update a saved CoreClaw worker task's metadata and schedule' clearly identifies the verb, resource, and scope. It distinguishes the tool from siblings like run_worker_task and update_worker_task_input, and the partial-update note adds useful precision.

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?

The English 'WHEN TO USE' correctly scopes the tool to changing title, description, or schedule. However, the Chinese trigger states to use this tool when the user wants to query, run, rerun, stop, export, or view task data, which directly contradicts the tool's purpose and overlaps with many sibling tools. This misleading guidance undermines usage clarity.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources