Basecamp MCP Server

Update Kanban Card

basecamp_update_kanban_card

Update a kanban card's title, content, steps, assignees, or due date in Basecamp.

Instructions

Update a kanban card including its steps. At least one field (title, content, partial content operations, or steps) must be provided. Use partial content operations when possible to save on token usage.

HTML rules for content:

Allowed tags: p, span, h2, h3, h4, br, strong, em, strike, code, a (with href attribute), pre, ol, ul, li, blockquote, mark, figure, figcaption, table, tbody, tr, th, td, div, bc-attachment.
Use for paragraphs. Use for empty line spacing between paragraphs.
Headings: use , , as appropriate.
Inline code: text. Preformatted blocks: text.
Ordered lists: .... Unordered: ....
Tables: Heading...Cell...
To mention people:
Single image:
Image gallery: wrap multiple in a .
Basecamp auto-enriches bc-attachment tags after saving (adds url, href, filename, content-type, etc.) — you never need to write those.
When you see an existing, already-enriched tag (e.g. from a previous list/get call), leave its inner HTML alone. Before any content_append/content_prepend/search_replace runs, it is automatically collapsed back to its minimal form (sgid, presentation, caption, and content-type for mentions) — you don't need to strip it yourself, and doing so manually is unnecessary and risks mismatched find strings.
Background highlights: ...
Text color highlights: ...
For both, N is 1 (yellow), 2 (amber), 3 (red), 4 (pink), 5 (purple), 6 (blue), 7 (teal), 8 (near-white), or 9 (light gray).

Input Schema

TableJSON Schema

Name	Required	Description
`steps`	No	Complete array of desired steps. Array order defines position. Steps not in array will be deleted.
`title`	No	New card title
`due_on`	No	Due date (YYYY-MM-DD format) or null to clear
`card_id`	Yes	Basecamp resource identifier
`content`	No	If provided, replaces entire HTML content. Cannot be used with content_append, content_prepend, or search_replace.
`assignee_ids`	No	Array of user IDs to assign to the card
`content_append`	No	Text to append to the end of current content. Cannot be used with content.
`search_replace`	No	Array of search-replace operations to apply to current content. Cannot be used with content.
`content_prepend`	No	Text to prepend to the beginning of current content. Cannot be used with content.

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedv1.2.1Jun 19, 2026
- addedInput schema / properties / assignee_ids / items / $ref
```
Added value: +"#/properties/card_id"
```
- removedInput schema / properties / assignee_ids / items / type
```
Removed value: -"number"
```
- removedInput schema / properties / bucket_id
```
Removed value: -{
-  "description": "Basecamp resource identifier",
-  "type": "number"
-}
```
- removedInput schema / properties / card_id / $ref
```
Removed value: -"#/properties/bucket_id"
```
- addedInput schema / properties / card_id / description
```
Added value: +"Basecamp resource identifier"
```
- addedInput schema / properties / card_id / type
```
Added value: +"number"
```
- removedInput schema / properties / notify
```
Removed value: -{
-  "description": "Whether to notify assignees of the update",
-  "type": "boolean"
-}
```
- addedInput schema / properties / steps / items / properties / assignee_ids / items / $ref
```
Added value: +"#/properties/card_id"
```
- removedInput schema / properties / steps / items / properties / assignee_ids / items / type
```
Removed value: -"number"
```
- addedInput schema / properties / steps / items / properties / id / $ref
```
Added value: +"#/properties/card_id"
```
- removedInput schema / properties / steps / items / properties / id / type
```
Removed value: -"number"
```
- changedInput schema / required
```
Previous value: -[
-  "bucket_id",
-  "card_id"
-]New value: +[
+  "card_id"
+]
```
Addedv1.0.0Jan 4, 2026

TDQS

A3.6/5.0

Behavior1/5

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

The description discloses many behaviors, such as steps deletion, partial operations, and HTML auto-enrichment. However, it contradicts the destructiveHint=false annotation by stating 'Steps not in array will be deleted', which indicates destructive behavior. This is a clear contradiction, so the description fails to align with annotations.

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?

The description is long but well-structured, starting with the core operation and key constraints, then providing necessary HTML formatting rules. It is front-loaded with the token-saving tip and required-field note. The length is justified by the complexity of the content format, so it is appropriately sized.

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?

The description covers essential aspects: required fields, mutual exclusions, steps deletion, and HTML rules. However, it does not explicitly state that this tool is for updating existing cards only, and the destructiveHint contradiction creates confusion about destructive behavior. It also lacks error or permission notes, but given the complexity, it is fairly complete but not flawless.

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?

The description adds significant meaning beyond the schema by detailing allowed HTML tags and formatting rules for content, which the schema does not provide. It also reinforces mutual exclusions and partial operations. With schema coverage at 100%, the baseline is 3, but the HTML rules and auto-enrichment details add substantial value, raising the score.

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 'Update a kanban card including its steps', specifying the action and resource. It distinguishes from siblings like create_kanban_card and update_todo by being specific to kanban cards. It also notes the required-field constraint, adding clarity.

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 advises using partial content operations to save tokens, which is a helpful usage guideline within the tool. However, it does not explicitly differentiate from alternatives like create_kanban_card or update_todo; the differentiation is implied by the name and purpose rather than stated.

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

Deploy Server

Update Kanban Card

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools