Skip to main content
Glama

Execute custom action

execute_custom_action

Trigger an admin-defined one-click action on a work package, applying several field changes simultaneously to speed up repetitive workflows.

Instructions

Run an instance-defined one-click action on a work package.

Custom actions are shortcuts an administrator configured — "Accept and assign to me", "Reject", "Move to review" — that apply several field changes at once, sometimes under conditions (role, status, project). Use one when get_work_package(include=['custom_actions']) offers it, instead of reproducing its effects field by field. Returns the updated work package row (subject, type, status, priority, assignee, project, dates, percentage_done, updated_at).

Pitfalls. The action decides what changes; this tool cannot influence it, and OpenProject does not report which fields it touched — compare the returned row with what you read before, or call get_work_package again for the full detail (including the new lock_version for your next update). Availability is per work package: an action listed on one ticket may 403 on another because its conditions no longer hold, and a 422 usually means the resulting work package would be invalid (a required field the action leaves empty). Writes are never retried automatically — a conflict comes back with the fresh lock_version so you can re-read and decide.

Cross-references: get_work_package(include=['custom_actions']) produces the ids and says which are available right now; update_work_package is the explicit alternative when you know exactly which fields to set; list_work_package_comments shows what the action recorded in the journal.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
lock_versionNoThe work package's current lockVersion, from get_work_package. Omit it and the current value is read first — safe, one extra request. A stale value returns a conflict carrying the fresh one.
work_package_idYesWork package to run the action on. It must be the one the action was listed for; conditions are re-checked server-side.
custom_action_idYesId of the custom action to run. Get it from get_work_package(id=..., include=['custom_actions']), which lists the actions this instance defines AND this work package currently qualifies for — the names are instance-specific, so never guess an id.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoWork package id.
typeNoWork package type.
statusNoStatus.
projectNoOwning project.
subjectNoSubject line.
assigneeNoAssigned user or group.
due_dateNoISO date (YYYY-MM-DD).
priorityNoPriority.
display_idNoHuman-facing id as the instance renders it. Matches the numeric id unless the instance uses semantic identifiers (17.x, e.g. 'PROJ-42'); null when the instance predates it.
start_dateNoISO date (YYYY-MM-DD).
updated_atNoISO 8601 UTC timestamp.
percentage_doneNoProgress, 0-100.
Behavior5/5

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

Beyond annotations (readOnlyHint=false, destructiveHint=false), the description reveals critical behavioral traits: the action determines changes and does not report which fields it touched, availability varies per work package (403/422 errors), writes are never auto-retried, and conflicts return a fresh lock_version. This adds substantial context beyond the structured metadata and matches the annotations (no contradiction).

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 moderately long but every sentence carries weight: it defines the tool, gives examples, explains pitfalls, and offers cross-references. It is front-loaded with the core behavior and then organized into a clear pitfalls section, making it scannable and dense without redundancy.

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?

With an output schema present, the description still adds essential context: it summarizes what the return row contains, explains error conditions (403, 422), concurrency behavior, and how to recover from conflicts. It also references related tools for obtaining IDs and reading journal entries, making it complete for an agent to safely execute the action in real scenarios.

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 coverage is 100%, so baseline is 3. The description adds extra meaning for custom_action_id ('never guess an id', tells where to get it) and reinforces lock_version behavior, going beyond the schema's descriptions. It doesn't add much for work_package_id but the schema already covers it adequately. Thus a 4 is justified.

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 uses a specific verb ('Run') and names the resource ('instance-defined one-click action on a work package'), immediately clarifying what the tool executes. It also distinguishes itself from update_work_package and get_work_package by referencing them as alternatives, so the agent can tell them apart.

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?

It explicitly says when to use the tool: 'Use one when get_work_package(include=['custom_actions']) offers it, instead of reproducing its effects field by field.' It also names the alternative tools (update_work_package, get_work_package) and explains when those are preferred, giving clear usage boundaries.

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