FlowCastle

update_task

DestructiveIdempotent

Change one CRM task: its fields, its status, or which contacts it is linked to, in one call. Tasks live in CRM → Tasks. A task may stand alone or be linked to contacts. While leads are on for the workspace, linking parks the contact's open lead until the task is done (parkLeads, default true), and marking the task done brings the linked leads back to Waiting on us so someone tells them the result (Won and Lost leads are left alone unless named in returnContactIds). Deleting a task, or unlinking a contact, brings a lead parked on it back to Waiting on us. A task is internal work for the team: nothing is sent to anyone. Setting status "done" is what brings the linked leads back; it does not message anyone.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "taskId": "<taskId>"
    },
    "name": "update_task"
  }
}

Input Schema

Name	Required	Description
`link`	No	New link; null clears it.
`dueAt`	No	New due date, ISO 8601; null clears it.
`notes`	No	New notes in Markdown; null clears them.
`title`	No	New title.
`status`	No	todo, in_progress or done. Moving a done task back reopens it and changes no lead.
`taskId`	Yes	Required. Task id, as returned by list_tasks or create_task.
`doneNote`	No	With status "done": a note added to the history of the leads that come back, e.g. what was found.
`parkLeads`	No	With linkContactIds: park the newly linked contacts' open leads until the task is done. Defaults to true.
`ownerUserId`	No	New owner (a workspace member); null for nobody.
`applicationId`	No	Application (workspace) id. Optional: an application-scoped key (app_...) defaults to its own application, but a personal key (usr_...) has no default and omitting it fails with MCP_APPLICATION_REQUIRED. Call list_applications to get the id.
`linkContactIds`	No	Contacts to link, as returned by list_contacts. Already linked ones are skipped.
`returnContactIds`	No	With status "done": which linked contacts come back to Waiting on us. Omit for every linked lead that is not Won or Lost. Leads parked on the task that are not named are Resolved.
`unlinkContactIds`	No	Contacts to unlink. A lead parked on this task comes back to Waiting on us.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 3, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the destructiveHint/idempotentHint annotations it explains the lead-parking lifecycle, the default of parkLeads, that unnamed parked leads become Resolved, and that reopening a done task changes no lead. It also correctly discloses that nothing is messaged to anyone, which is essential context for a mutation that touches leads.

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-loaded with the action and scope, then the lead consequences. Slight redundancy: the 'nothing is sent to anyone' point is made twice (once generally, once restated after status 'done'), which costs a sentence without adding information.

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 13-parameter destructive mutation with no output schema, the description covers the risky side effects (lead parking, lead return, Resolved outcomes) thoroughly, with the rest delegated to a fully described schema. Only the routing relative to sibling mutation tools is thin.

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 schema already documents each parameter; the description's added value is cross-parameter behaviour that a flat schema cannot express — parkLeads only matters with linkContactIds, doneNote only with status 'done', and the Resolved outcome for unnamed parked leads.

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 and resource ('Change one CRM task') plus the exact facets it can change — fields, status, contact links — in one call. Combined with 'Tasks live in CRM → Tasks', an agent can tell this apart from create_task, delete_task and the follow-up-task siblings without opening the schema.

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 rich conditional guidance: when to use parkLeads, when to supply returnContactIds, and what happens on delete/unlink. It does not explicitly say 'use X instead when', so the sibling routing (e.g. apply_actions vs update_task) is left implicit.

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

All FlowCastle 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.