Skip to main content
Glama

op_search_work_packages

Search OpenProject work packages by subject, synonyms, project, status, type, assignee, or custom filters. Returns compact JSON results with matched terms and fallback to description search.

Instructions

Поиск задач (work packages) в OpenProject.

Поиск по теме выполняется по синонимам: передавайте сразу несколько вариантов формулировки в subject (строка или список). Пример: subject=["баг", "ошибка"]. Не добавляйте перевод/транслитерацию автоматически — только если пользователь явно попросил.

Логика поиска по subject:

  1. Ищем по теме задачи (фильтр subject ~) по очереди для каждого синонима, результаты объединяем (логическое ИЛИ), дедуплицируем по id.

  2. Если по теме ничего не найдено — автоматически повторяем поиск по описанию задачи (фильтр description ~), если сервер его поддерживает.

Прочие параметры (project_id, status, type_id и т.д.) сужают область поиска (объединение И с условием по теме/описанию).

Если совпадений нет, возвращается пустой список с подсказкой переформулировать запрос — полный список задач НЕ выдаётся.

Args: subject: Тема задачи или список синонимов (строка либо список строк). Поиск по части темы (оператор содержания '~'), объединение ИЛИ между синонимами. Пример: "баг" или ["баг", "ошибка", "дефект"]. project_id: Фильтр по проекту; если задан — поиск ведётся в рамках проекта. status: Семантический статус: 'open' (открытые), 'closed' (закрытые), 'all'. type_id: Фильтр по типу задачи (например '1' для Task, '2' для Bug). assignee_id: Фильтр по исполнителю (ID пользователя или 'me'). priority_id: Фильтр по приоритету. filters: Произвольный JSON-массив фильтров API, например [{"status_id":{"operator":"o","values":null}}]. Объединяется (AND) с другими параметрами. Используется, когда не задан subject (поиск без текста), либо как доп. ограничение. page_size: Размер страницы (по умолчанию 20, максимум 100). При поиске по subject применяется к каждому синониму отдельно. offset: Номер страницы, начиная с 1. При поиске по subject игнорируется (возвращаются все найденные совпадения, дедуплицированные). sort_by: JSON-массив сортировки, например [["status","asc"],["id","desc"]].

Returns: JSON со списком задач (компактный вид) и сводкой. При поиске по синонимам добавляются поля searched_field (subject/description), matched_terms (сработавшие синонимы) и fallback_used. При пустом результате — список [] и note с подсказкой.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
offsetNo
statusNo
filtersNo
sort_byNo
subjectNo
type_idNo
page_sizeNo
project_idNo
assignee_idNo
priority_idNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

With no annotations provided, the description fully carries the behavioral disclosure burden. It details the OR-merge logic for synonyms, deduplication by id, automatic fallback to description search, page_size applied per synonym, offset ignored in synonym search, and special return fields (searched_field, matched_terms, fallback_used). This is exceptionally 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 numbered logic, parameter list, and return details. Every sentence adds value and there is no fluff. The front-loaded purpose, clear sections, and concrete examples make the length justified.

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?

Given the tool's complexity (10 parameters, no annotations), the description is remarkably complete. It covers return values, empty-result behavior, fallback logic, pagination nuances, and even explains what fields are added in synonym mode. The presence of an output schema does not reduce the need for behavioral context, and this description provides it fully.

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?

Schema description coverage is 0%, and the description compensates thoroughly. Every parameter is explained with semantics beyond the schema: status values ('open'/'closed'/'all'), type_id examples, filters JSON example, sort_by JSON array format, and specific behavior of page_size/offset during subject search. This is exemplary.

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 the tool's purpose: searching work packages in OpenProject. It specifies the resource (work packages), the verb (поиск/search), and the unique synonym-based search behavior, distinguishing it from siblings like op_get_work_package (single fetch) and op_list_projects (list projects).

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

Usage Guidelines4/5

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

The description provides clear context on how to use the tool: pass multiple synonym variants, avoid auto-translation, and how other parameters narrow the search. It also explicitly states that the full list is NOT returned when there are no matches, which is a usage exclusion. However, it does not explicitly name alternative sibling tools for when to use them instead.

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

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