Skip to main content
Glama
dev-in-black

OpenProject MCP Server

by dev-in-black

update_work_package

Modify existing work packages by updating subject, description, status, priority, or assignee in OpenProject project management.

Instructions

Update an existing work package.

Args:
    work_package_id: Work package ID
    lock_version: Current lock version (get from work package first)
    subject: New subject/title
    description: New description in markdown
    status_id: New status ID
    priority_id: New priority ID
    assignee_id: New assignee user ID (use 0 to unassign)
    notify: Whether to send notifications (default: True)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
work_package_idYes
lock_versionYes
subjectNo
descriptionNo
status_idNo
priority_idNo
assignee_idNo
notifyNo

Implementation Reference

  • Core implementation of the update_work_package tool: constructs payload with optional fields and performs PATCH request to OpenProject API.
    async def update_work_package(
        work_package_id: int,
        lock_version: int,
        subject: str | None = None,
        description: str | None = None,
        status_id: int | None = None,
        priority_id: int | None = None,
        assignee_id: int | None = None,
        notify: bool = True,
    ) -> dict[str, Any]:
        """Update an existing work package.
    
        Args:
            work_package_id: Work package ID
            lock_version: Current lock version (get from work package first)
            subject: New subject/title
            description: New description in markdown
            status_id: New status ID
            priority_id: New priority ID
            assignee_id: New assignee user ID (use 0 to unassign)
            notify: Whether to send notifications (default: True)
    
        Returns:
            Updated work package object
        """
        client = OpenProjectClient()
    
        try:
            payload: dict[str, Any] = {
                "lockVersion": lock_version,
                "_links": {},
            }
    
            if subject is not None:
                payload["subject"] = subject
    
            if description is not None:
                payload["description"] = build_formattable(description)
    
            if status_id is not None:
                payload["_links"]["status"] = build_link(f"/api/v3/statuses/{status_id}")
    
            if priority_id is not None:
                payload["_links"]["priority"] = build_link(
                    f"/api/v3/priorities/{priority_id}"
                )
    
            if assignee_id is not None:
                if assignee_id == 0:
                    payload["_links"]["assignee"] = None
                else:
                    payload["_links"]["assignee"] = build_link(
                        f"/api/v3/users/{assignee_id}"
                    )
    
            params = {"notify": str(notify).lower()}
    
            result = await client.patch(
                f"work_packages/{work_package_id}?notify={params['notify']}", data=payload
            )
            return result
        finally:
            await client.close()
  • MCP tool registration using @mcp.tool() decorator. Defines input schema via type annotations and delegates to the core handler.
    @mcp.tool()
    async def update_work_package(
        work_package_id: int,
        lock_version: int,
        subject: str | None = None,
        description: str | None = None,
        status_id: int | None = None,
        priority_id: int | None = None,
        assignee_id: int | None = None,
        notify: bool = True,
    ):
        """Update an existing work package.
    
        Args:
            work_package_id: Work package ID
            lock_version: Current lock version (get from work package first)
            subject: New subject/title
            description: New description in markdown
            status_id: New status ID
            priority_id: New priority ID
            assignee_id: New assignee user ID (use 0 to unassign)
            notify: Whether to send notifications (default: True)
        """
        return await work_packages.update_work_package(
            work_package_id=work_package_id,
            lock_version=lock_version,
            subject=subject,
            description=description,
            status_id=status_id,
            priority_id=priority_id,
            assignee_id=assignee_id,
            notify=notify,
        )
Behavior2/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 states this is an update operation (implying mutation) and mentions a lock_version mechanism for concurrency control, which is valuable context. However, it fails to disclose critical behavioral traits: whether this requires specific permissions, what happens on success/failure, if changes are reversible, rate limits, or error conditions. For a mutation tool with 8 parameters, this leaves significant gaps.

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 appropriately sized and well-structured: a clear purpose statement followed by a bullet-point-like parameter explanation. Every sentence earns its place by adding value. It could be slightly more front-loaded with usage context, but the structure efficiently conveys necessary information 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 tool's complexity (mutation with 8 parameters, no annotations, no output schema), the description is partially complete. It excels at parameter semantics but lacks behavioral context, usage guidelines, and output information. For a mutation tool, this creates significant gaps in understanding how to use it safely and effectively, though the parameter explanations prevent it from being completely inadequate.

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 provides excellent parameter semantics beyond the input schema, which has 0% description coverage. It explains each parameter's purpose: work_package_id identifies the target, lock_version requires fetching first, subject is title, description uses markdown, status_id and priority_id are IDs, assignee_id uses 0 to unassign, and notify has a default. This fully compensates for the schema's lack of descriptions and adds crucial context like the unassign convention.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/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 an existing work package.' This is a specific verb+resource combination that distinguishes it from siblings like 'create_work_package' and 'delete_work_package'. However, it doesn't explicitly differentiate from other update tools like 'update_comment' or 'update_project' beyond the resource name.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing to fetch the work package first for lock_version), when not to use it, or how it differs from similar update operations on other resources. The only implicit guidance is the parameter list, which doesn't constitute explicit usage instructions.

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/dev-in-black/openproject-mcp'

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