Skip to main content
Glama
soil-dev

capsulemcp

update_project

Update fields on an existing project: reassign party, owner, team, stage, or set custom fields. Use status='CLOSED' to close a project.

Instructions

Update fields on an existing project, including the parent-reference field partyId to reassign the project to a different primary party. ownerId, teamId, and stageId all accept null to unassign (the latter removes the project from all stages — verified empirically in v1.6.5 wire-trace). Constraint: a project must always have at least one of {owner, team} set, so teamId: null on a project with no owner returns 422. Only the fields you provide are changed. Use status='CLOSED' to close a project. CLOSED projects remain fully editable — Capsule does not enforce closed-record immutability. Stage moves and description edits on a CLOSED project are accepted without warning. Capsule requires every project to have a party — passing partyId: null is rejected with 422 'party is required' (Unlike update_task.partyId which IS nullable — tasks can be orphaned in Capsule's model).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNo
nameNo
descriptionNo
statusNo
partyIdNoReassign the project to a different primary party. Capsule requires every project to have a party — passing `null` is rejected with 422 'party is required' (verified empirically in v1.6.3 wire-trace). Discover ids via search_parties / filter_parties. NOTE: parent-ref nullability differs by entity — `update_task.partyId` IS nullable (orphan task), but opportunities and projects must always have a parent party. The same applies to `update_opportunity.partyId`.
ownerIdNoReassign owner: pass a user ID to set, or `null` to unassign (matches the 'Unassign' option in Capsule's web UI). When you supply `ownerId` and omit `teamId` and/or `stageId`, the connector fetches the project's current omitted fields and includes them in the PUT body — this preserves them across the owner change (without it, Capsule's PUT would clear team; stage carry is defensive against the symmetric clear). Supply `teamId` and/or `stageId` explicitly on the same call to change them instead. `teamId: null` clears the team as part of an owner change. Constraints (Capsule enforces, 422 on violation): owner must be a member of the team if both are set; a project must always have at least one of {owner, team} set (cannot clear both).
teamIdNoReassign team: pass a team ID (discover via list_teams) to set, or `null` to unassign. Capsule preserves the existing owner across a team change (server-side), so `update_project { teamId }` alone is safe — the owner is carried through. Owner must be a member of the new team or Capsule returns 422 'owner is not a member of the team'. A project must always have at least one of {owner, team} set — `teamId: null` on a project whose owner is already null returns 422 'owner or team is required'.
stageIdNoMove the project to this stage (board column), or `null` to remove from all stages (verified empirically in v1.6.5 wire-trace — Capsule accepts `stage: null` on PUT /kases/:id and the project no longer appears on any board). Discover IDs via list_stages. Owner and team are preserved across stage-only updates (Capsule's PUT semantic). WARNING (cross-board): Capsule does NOT validate that the new stage belongs to the project's current board — passing a stageId from a different board silently relocates the project across boards. Team and other board-derived defaults are NOT updated to match the new board. Verify against the project's current board (read the project first, list its board's stages) before passing a cross-board id.
expectedCloseOnNoYYYY-MM-DD
fieldsNoSet custom field values on this record. PARTIAL UPDATE: only the definitions you list are touched; any field NOT in this array is left unchanged. Discover available definitions via list_custom_fields; read current values via get_project with embed='fields'. Project-specific: setting a field whose definition lives under a 'data tag' populates the row's internal tagId but does NOT auto-add the data tag to the project's tags array — use add_tag explicitly if you want it visible via embed=tags.
Behavior5/5

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

The description reveals numerous behavioral traits beyond annotations, including that CLOSED projects remain editable, stage moves can silently cross boards, partyId is required (unlike tasks), custom fields partial update behavior, and nullability constraints. It also notes empirical verification for stageId null and partyId rejection.

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 lengthy but front-loaded with the main purpose and every sentence adds value, covering edge cases and empirical notes. It could be slightly more structured (e.g., bullet points) but remains informative without waste.

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?

Given the complexity (10 parameters, no output schema), the description covers parameters and constraints well but lacks explanation of return values or typical success responses. It does not specify that the tool returns the updated project object, which is a gap for a tool without an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds significant meaning beyond the input schema for most parameters, such as partyId nullability differences, ownerId/teamId preservation logic, stageId cross-board warning, and custom fields quirks (BOOLEAN two-state, NUMBER read-back as string). This compensates for the 60% schema description coverage.

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 fields on an existing project', specifying the verb and resource. It distinguishes from sibling tools by explicitly comparing partyId nullability with update_task and update_opportunity, and mentions handling of stageId cross-board behavior not present in other tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

While the description provides detailed constraints and behaviors (e.g., partyId required, owner/team constraints), it does not explicitly state when to use this tool versus alternatives like batch_update_project or update_opportunity. Usage context is implied through examples but not explicitly compared to siblings.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/soil-dev/capsulemcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server