Skip to main content
Glama

Update project

update_project

Update an OpenProject project's name, description, status, visibility, parent, or archived state. Validated partial updates avoid overwriting unrelated fields.

Instructions

Change a project's name, description, visibility, parent, status or archived state.

Use it to record a status change with its explanation ("at_risk because the vendor slipped"), to rename or re-parent a project, to publish it, or to archive it with active=false. The change is validated through POST /projects/{id}/form first, so rejected values come back as violations naming the attribute.

Only the parameters you pass are sent — omitted fields are never rewritten, so two agents editing different fields do not clobber each other. Projects carry no lockVersion upstream, so there is no version to echo and no lock parameter here.

Returns the updated project in the same shape as get_project.

Pitfalls: description and status_explanation REPLACE the stored text rather than appending to it. active=false archives, which is not deletion but does hide the project and freeze its work packages. Changing identifier is deliberately not offered — it breaks every existing link to the project.

Cross-references: get_project to read the current values first; delete_project to remove a project for good; list_projects(active=false) to find archived ones.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoNew display name. Omit to leave the name alone.
activeNofalse ARCHIVES the project — it disappears from normal listings and everything in it becomes read-only, including its subprojects. true restores it. Omit to leave it alone. Archiving is usually admin-only.
publicNoTrue publishes the project to every logged-in user, false makes it members-only. Omit to leave the visibility alone.
parent_idNoMove the project under another one: numeric id or identifier of the new parent. Pass null to detach it and make it top-level. Omit the parameter entirely (the default) to leave the hierarchy untouched.__unchanged__
descriptionNoNew description in markdown; it REPLACES the existing text, so read the current one with get_project first if you mean to extend it. Pass an empty string to clear it. Omit to leave it alone.
status_codeNoNew project status: on_track, at_risk, off_track, not_started, finished or discontinued. Only these codes are accepted. Omit to leave the status alone.
id_or_identifierYesNumeric project id or URL identifier of the project to change; both are accepted and come from list_projects or get_project.
status_explanationNoMarkdown note explaining the status, e.g. why the project is at risk. Replaces the previous explanation; pass an empty string to clear it.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoNumeric project id; accepted by every project_id parameter.
nameNoDisplay name.
activeNoFalse for archived projects (read-only in the UI).
parentNoParent project, when this is a subproject.
publicNoTrue when visible to users without a membership.
created_atNoISO 8601 UTC timestamp.
identifierNoURL slug from /projects/<identifier>; also accepted wherever an id is.
updated_atNoISO 8601 UTC timestamp.
descriptionNoDescription as markdown (raw); html is dropped.
status_codeNoProject status code, one of: on_track, at_risk, off_track, not_started, finished, discontinued. A code, never a translated label; null means no status has been set.
workspace_typeNoWorkspace kind: 'project', 'program' or 'portfolio'. Pre-17 instances only have 'project'; on 17.x project listings mix all three kinds, so check this before treating a row as a plain project.
status_explanationNoFree-text explanation of status_code, markdown (raw).
Behavior5/5

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

Description discloses validation via 'POST /projects/{id}/form' and violations, partial-update semantics ('Only the parameters you pass are sent — omitted fields are never rewritten'), absence of lockVersion, and pitfalls around REPLACE semantics and archiving. Annotations are minimal, so this context is vital and highly transparent.

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 long but well-structured with sections for use cases, validation, partial updates, return type, pitfalls, and cross-references. Every sentence adds unique value, so it earns its length; the core purpose is front-loaded in the first line.

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

Completeness5/5

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

Covers validation, partial-update behavior, return shape (via get_project reference), side effects of archiving, and intended alternatives. With an output schema present, no further return documentation is needed, and the description fully prepares an agent for correct invocation.

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 already documents all 8 parameters at 100% coverage, so baseline is 3. Description adds crucial operational meaning: 'Only the parameters you pass are sent' clarifies null/default semantics, and pitfalls like 'active=false archives' and 'description REPLACES' enrich the parameter behavior beyond schema descriptions.

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 opens with 'Change a project's name, description, visibility, parent, status or archived state', a specific verb+resource+fields. It clearly distinguishes from siblings like update_work_package, create_project, and delete_project by naming project-specific attributes and the archived state.

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

Usage Guidelines5/5

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

Explicitly states when to use: 'Use it to record a status change... to rename or re-parent a project, to publish it, or to archive it'. It also provides exclusions: 'Changing ``identifier`` is deliberately not offered' and cross-references get_project/delete_project/list_projects for related tasks.

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/kar-thik/openproject-mcp'

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