OrgLines

Update task

update_task

Destructive

Edit fields of one of the caller's tasks (title, description, priority, due_date) by id — beyond just status. Only the caller's own task is reachable. NOTE: a personal task's priority scale (low/normal/high) is deliberately a DIFFERENT scale from a CRM lead's priority (low/medium/high/hot) — separate domains, not to be conflated. CONFIRMATION: this tool runs immediately when the caller asks for it — it writes only their own record, and they can undo it from this same surface, so the request is taken as the instruction. You get an ordinary result, not a plan_token. Everything destructive, outbound or financial still proposes and waits.

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": {
      "task_id": "<task_id>"
    },
    "name": "update_task"
  }
}

Input Schema

Name	Required	Description	Default
`title`	No
`task_id`	Yes
`due_date`	No
`priority`	No
`description`	No
`is_agent_directive`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4/5.0

Behavior3/5

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

Adds real context beyond the annotations: writes are limited to the caller's own record, are undoable from the same surface, and return an ordinary result rather than a plan_token, while genuinely destructive/outbound/financial actions still propose and wait. That said, the annotations already flag destructiveHint=true and openWorldHint=false, and the description never explains what failure modes look like or what the is_agent_directive flag changes about execution.

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?

Purpose and scope are front-loaded, then the priority-domain note, then confirmation semantics. The prose is dense but each paragraph carries information an agent needs; the confirmation section is somewhat long relative to the rest.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no output schema, it covers scope, undoability, and execution semantics well. However, the undocumented is_agent_directive parameter and the absence of any error/validation behavior leave an agent with gaps in a 6-parameter write tool.

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 0%, so the description carries the burden; it explains task_id, title, description, due_date, and the priority enum, including the deliberate scale difference from CRM lead priority (low/normal/high vs low/medium/high/hot). The one gap is is_agent_directive, which is undocumented in both the schema and the description.

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 plus resource and enumerates the editable fields ('title, description, priority, due_date') by id, and explicitly contrasts scope with the sibling update_task_status ('beyond just status'). An agent can route between the two without opening either 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 clear context: only the caller's own task is reachable, and field edits (not status changes) belong here. It also explains the confirmation model (runs immediately when the caller asks). It stops short of an explicit 'when not to use' for other siblings such as bulk_update_leads, though the domain note partially covers that.

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

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