Skip to main content
Glama

Save a query

save_query

Persist a filter set as a team-wide OpenProject view, validating filters before saving and returning the view ID for later execution.

Instructions

Save a filter set as a reusable OpenProject view the whole team can open.

Use it when a filter combination is worth keeping — "Overdue in Platform", "My open bugs" — instead of rebuilding it every session: the saved view shows up in the OpenProject UI as well, and run_query reproduces it exactly. Prove the filters with list_work_packages first; whatever works there works here.

The call runs POST /queries/form before committing, so an invalid filter name, an operator the filter does not support, or a project-scoped filter on a global view comes back as violations naming the attribute — nothing is saved. Returns the stored definition: {id, name, project, public, starred, filters (as readable sentences), group_by, sort_by, display_sums, updated_at, notes}. Keep the id: it is what run_query takes.

Pitfalls. Filter values are ids, not names — 'Grace Hopper' is not a value, 12 is. star=true is a second request after the query exists; if it fails the query is still saved and notes says so, so never re-save on a starring failure. If OpenProject keeps fewer filters than were sent, notes says that too — read filters rather than assuming the view matches the request. Custom-field filters (customField12) are sent as plain values because a list-typed one cannot be told apart from a text one without asking the instance; if such a filter makes the call fail, nothing was saved — save that view in the UI. Editing and deleting saved views is deliberately not offered here: change or remove them in the OpenProject UI.

Cross-references: list_queries lists what already exists (and gives ids); run_query(query_id=...) runs this view; list_work_packages is the ad-hoc equivalent and the place to validate filters first; list_projects supplies project_id.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesName the view is saved under, e.g. 'Overdue in Platform'. Names are not unique upstream, so a second save with the same name creates a second view.
starNoAlso star (favorite) the view for the authenticated user, so it appears in their sidebar. Done as a second call after the query exists; if it fails the query is still saved and 'notes' says so.
publicNotrue shares the view with everyone who can see the project; false (default) keeps it private to the authenticated user. Sharing usually needs the 'manage public queries' permission.
filtersYesThe filters to store, in the same shape run_query's override_filters and list_work_packages' raw_filters take — e.g. [{'name': 'status', 'operator': 'o', 'values': []}, {'name': 'assignee', 'operator': '=', 'values': ['12']}]. Values are ids (or 'me'), not display names. Pass [] deliberately for a view that filters nothing: unlike a listing, a stored query with no filters shows every status.
sort_byNoStored sort order, e.g. [['due_date', 'asc'], ['id', 'desc']]. Keys are the snake_case work-package columns list_work_packages sorts by; unknown keys are rejected locally with the allowed set listed. Omit for the default.
group_byNoColumn to group the results by, e.g. 'status', 'assignee', 'type' or 'version'. Grouping is what makes run_query return 'groups' with per-group counts. Omit for a flat list.
project_idNoNumeric project id the view belongs to, from list_projects. Omit for a global (cross-project) view — but project-scoped filters such as version, category or subprojectId are then rejected.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoQuery id — pass it to run_query as query_id.
nameNoQuery name as its author saved it.
notesNoWhat happened beyond the create itself: a failed star, filters OpenProject did not keep. Empty when everything landed as asked.
publicNoTrue when shared with everyone who can see the project; false when private to its owner.
filtersNoThe stored filters as readable sentences, e.g. 'Status open' or 'Assignee is (OR) Grace Hopper'. Empty when the query filters nothing.
projectNoOwning project, or null for a global (cross-project) query.
sort_byNoStored sort order, e.g. ['Finish date asc'].
starredNoTrue when the current user starred (favorited) it.
group_byNoColumn the results are grouped by, when the query groups.
updated_atNoISO 8601 UTC timestamp.
display_sumsNoTrue when the query asks for totals; then the result 'sums' is populated.
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true, etc.), the description discloses the internal POST /queries/form validation call, the failure mode returning violations with nothing saved, the two-step star behavior, filter-count mismatch handling, and custom-field limitations. This gives the agent a realistic model of side effects and failure.

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 structured: purpose, usage, behavior, pitfalls, cross-references. Each section adds essential operational knowledge, and the use of a 'Pitfalls' paragraph front-loads critical warnings. No wasted sentences.

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?

The description covers purpose, usage, behavior, return format, error handling, side effects, and relationships to sibling tools. Combined with the exhaustive schema and output schema, the agent has everything needed to invoke this tool correctly.

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 input schema already covers 100% of parameters with detailed descriptions, so baseline is 3. The description adds value by highlighting semantic pitfalls (values are ids not names, customField12 handling, empty filters meaning 'show every status') that are not fully covered in the schema. However, much of the parameter detail overlaps with the 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 a clear verb-object: 'Save a filter set as a reusable OpenProject view the whole team can open.' It distinguishes from siblings by explicitly contrasting with run_query, list_queries, and list_work_packages, and notes editing/deleting is intentionally not offered.

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?

The description explicitly states when to use ('when a filter combination is worth keeping'), recommends validating with list_work_packages first, and names alternatives (list_queries, run_query, list_work_packages, list_projects) with specific roles. It also tells when not to use it (editing/deleting should be done in the UI).

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