Plane MCP Server

update_customer_request

Update customer request details using customer ID and request ID. Change name, description, or link fields as needed.

Instructions

Update a customer request. Only the fields you pass are changed.

Work item links cannot be changed here — use manage_customer_work_items with this request_id as customer_request_id.

Args: customer_id: UUID of the customer request_id: UUID of the customer request name: Request name description_html: HTML description link: URL associated with the request

Returns: The updated CustomerRequest

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": {
      "customer_id": "<customer_id>",
      "request_id": "<request_id>"
    },
    "name": "update_customer_request"
  }
}

Input Schema

Name	Required	Description	Default
`link`	No
`name`	No
`request_id`	Yes
`customer_id`	Yes
`description_html`	No

Output Schema

Name	Required	Description	Default
`id`	No
`link`	No
`name`	Yes
`created_at`	No
`description`	No
`work_item_ids`	No
`attachment_count`	No
`description_html`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.11Aug 7, 2026

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the partial update behavior ('Only the fields you pass are changed'), a key side-effect trait, and notes an important limitation (work item links cannot be changed). It also states the return type. However, it does not clarify whether explicitly passing null clears a field or is treated as 'not provided,' which is a meaningful behavioral gap for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-structured: a one-sentence function statement, a brief behavioral note, a redirect to an alternative tool, an Args list, and a Returns line. Every sentence adds value, and the information is front-loaded. No unnecessary jargon or repetition.

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 covers the core operation, partial update behavior, the only explicit exclusion (work item links), all parameters, and the return type. Given the presence of an output schema, the return value is sufficiently described. The main completeness gap is the ambiguity around null parameter handling and potential format constraints (e.g., link URL validation, HTML restrictions), which are not mentioned.

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?

Since the schema description coverage is 0%, the description compensates by listing each parameter with a concise semantic annotation: customer_id (UUID of the customer), request_id (UUID of the customer request), name (Request name), description_html (HTML description), link (URL associated with the request). These add meaning beyond the raw schema property names. However, it does not explain the null default behavior or whether fields can be explicitly reset to null, which would be useful.

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 description clearly states the tool's purpose: 'Update a customer request' with a specific verb and resource. It further clarifies the scope with 'Only the fields you pass are changed,' distinguishing it from full-replacement update operations. The sibling context includes other customer request tools (create, retrieve, delete, list), so this unequivocally identifies the update operation.

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?

The description explicitly names an alternative for a specific excluded case: 'Work item links cannot be changed here — use manage_customer_work_items with this request_id as customer_request_id.' This is clear guidance on when not to use this tool and which sibling to use instead. However, it does not provide broad scenarios for when to use this tool versus other customer request operations, though that is reasonably implied.

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

Deploy Server