openproject-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource and action: searching work packages, listing projects, retrieving a work package, adding comments/attachments, time tracking activities, logging time, listing time entries, searching users, and checking connection. No two tools have overlapping responsibilities; even the time-related tools are clearly separated between activity catalog, entry creation, and reporting.
Naming Consistency5/5
All tools share the 'op_' prefix and follow a consistent verb_noun pattern: search_work_packages, list_projects, get_work_package, add_comment, add_attachment, list_time_entry_activities, log_time, list_time_entries, list_users, check_connection. The naming is uniform and predictable, with no mixed conventions.
Tool Count5/5
With 10 tools, the server is well-scoped for OpenProject operations. It covers the core areas (projects, work packages, comments, attachments, time tracking, users, connection) without unnecessary bloat or thin coverage. Each tool earns its place.
Completeness3/5
The set covers searching/reading work packages, adding comments/attachments, and time tracking well, but lacks work package creation, update, deletion, and status/type management. This creates notable gaps for full workflow coverage, though the available operations form a coherent internal surface.
Average 4.5/5 across 10 of 10 tools scored. Lowest: 3.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It states the tool verifies connection and token, and describes the return format. However, it does not mention potential side effects (likely none) or behavior like network timeouts, making it adequate but not deeply 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 two sentences: the first states the purpose, the second outlines the return JSON. This is concise, well-structured, and front-loaded with no unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters) and the presence of an output schema, the description is reasonably complete. It explains the output format and the purpose, but could additionally mention that it is a safe read-only check, which would enhance completeness.
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 tool has zero parameters, so the empty schema requires no description. The description appropriately focuses on purpose and return values, achieving the baseline for a no-parameter tool.
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 function: verifying the connection to OpenProject and API token validity. This is distinct from sibling tools which handle work packages, projects, comments, etc., making the purpose unambiguous.
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. There is no mention of using it before other operations or as a diagnostic step, leaving the usage context implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description outlines the return structure (full task fields plus optional comments/attachments), which adds useful context. However, without annotations, it does not explicitly state that this is a read-only operation, nor does it mention permissions, error handling, or side effects. The focus is on the data returned rather than behavioral guarantees.
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 well-structured: a single-sentence purpose, followed by a concise Args section and a Returns section. Every sentence contributes necessary information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool, the description covers purpose, parameters, and return value. The existence of an output schema is noted, and the description additionally enumerates return fields, which is helpful. It lacks explicit error case details, but this is not critical for such a straightforward read operation.
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 clear explanations for all three parameters in the Args section, including the effect of include_comments and include_attachments. Since the schema has no descriptions for its parameters, this fully compensates for the missing schema coverage.
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 function: to get detailed information about a task by its ID. It uses a specific verb and resource, and the mention of 'by ID' distinguishes it from sibling tools like op_search_work_packages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool should be used when the agent already has a task ID, as indicated by 'by its ID.' However, it does not explicitly mention when not to use it or point to alternative tools for searching or other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It explains the multipart format and the default file_name behavior, which adds valuable context. However, it does not mention permissions, error conditions, or side effects beyond the upload, leaving gaps for a mutation tool.
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 well-structured with sections for operation, technical context, args, and returns. Every sentence serves a purpose, and the technical note about multipart/form-data is concise and informative without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the operation's purpose, required multipart format, all parameters, and return format. With an output schema present, the return explanation is a bonus. It lacks explicit usage exclusions or error semantics, but for a simple file upload tool, it is reasonably complete.
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 schema has 0% description coverage, but the description compensates with an Args section that explains each parameter clearly, including the default derivation for file_name. This goes beyond the schema's bare type declarations, though it does not specify constraints like file size or allowed characters.
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 the specific action 'Загрузить файл как вложение к задаче' (upload file as attachment), clearly distinguishing it from sibling tools like op_add_comment or op_get_work_package. It uses a specific verb and resource, leaving no ambiguity about the tool's purpose.
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 first line provides a clear use case for the tool. It also includes a technical requirement for multipart/form-data, which implicitly advises on the expected input format. However, it does not explicitly mention alternatives or when-not-to-use, though the sibling tools are functionally distinct and not competing for the same action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility. It discloses the behavior of the 'internal' flag, notes the permission requirement ('add_internal_comments'), and describes the return format (JSON with id, text, author, date). This covers key behavioral traits, though it does not mention potential side effects or visibility rules beyond the permission note.
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 structured into a one-line summary, an 'Args' list, and a 'Returns' section. It is front-loaded, concise, and contains no fluff. Every sentence serves a purpose—introduction, parameter explanations, and return format—making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has an output schema (so return values need minimal explanation), and the description covers all parameters and the key behavioral nuance (internal permission). It could go further by clarifying ownership or posting context, but for a straightforward add-comment operation, it provides sufficient context.
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 schema provides only types and titles (0% description coverage), so the description must add meaning. It does so for all three parameters: work_package_id (task ID), comment (text), and internal (internal comment with permission requirement). This fully compensates for the schema's lack of 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 begins with a clear, specific verb and resource: 'Add a comment (note) to a task.' This directly distinguishes it from sibling tools that search, list, get, attach, or log time. It unambiguously states the tool's action and target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('add a comment to a task') but does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or competing tools. Since the siblings are functionally distinct, the lack of explicit comparison is acceptable but still leaves room for guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the 404/empty list behavior and that activities may be mandatory, which adds useful context beyond a bare list call. However, it does not discuss other behaviors like authentication, rate limits, or response format beyond the basic list structure.
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 compact and well-structured: purpose, usage hint, error condition, and return format are each briefly covered. Every sentence earns its place 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?
For a simple zero-parameter list tool with an output schema, the description covers the essential context: what it lists, how to use the results, and what to do if it fails. It is sufficiently complete for an AI agent to select and invoke the 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 tool has zero parameters, so schema coverage is 100% by default. The description adds value by explaining the output elements (id, title) and how they relate to op_log_time's activity_id parameter, which is more than necessary for a parameter-less tool.
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 starts with a clear verb+resource: 'Get the list of available time tracking activities.' It explicitly distinguishes itself from siblings by focusing on activities rather than time entries or logging, and directly references its output being used by op_log_time.
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?
Provides clear context on when to use the tool: before logging time, to fetch valid activity IDs for op_log_time. Also explains the 404/empty list scenario, indicating the module is not enabled. Does not explicitly list when not to use alternatives, but the reference to op_log_time gives sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It mentions permission requirements ('Требует прав на чтение списка пользователей') and error behavior ('вернёт ошибку с подсказкой'), plus how filters combine with query (AND). It also describes the return format, including pagination summary. Missing details like rate limits or exact error types, but substantial context is provided.
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 well-structured with an intro, Args, and Returns sections. It earns its length by explaining purpose and parameter semantics. The opening sentence about 'Люди обращаются друг к другу по именам' adds context but is slightly verbose; still, it's not excessive.
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 (4 parameters, output schema exists), the description covers all critical aspects: purpose, parameter behavior, filter semantics, pagination, permissions, error handling, and return shape. It is a self-contained reference sufficient for correct invocation.
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 schema provides 0% coverage for parameter descriptions, but the description fully compensates. Each parameter is explained: query (substring of name/login), filters (JSON array, combined via AND), page_size (default 50), and offset (page number starting at 1). This adds complete semantic meaning beyond the bare schema.
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 function: 'Поиск пользователей по имени или логину' (Search users by name or login). It goes further to explain the practical use case—finding a user ID to pass to op_list_time_entries—which distinguishes it from sibling tools like op_list_projects or op_list_time_entries.
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 when to use the tool: 'Помогает найти ID пользователя... для передачи в op_list_time_entries параметром user_id'. It explains the search semantics (name and login) and mentions required permissions. However, it doesn't explicitly discuss alternatives or negative usage cases, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses pagination behavior (page_size, offset, incomplete totals when page size is insufficient), default sorting, inclusive date boundaries, filter combination (AND), and the effect of include_comments. This is thorough and goes well beyond basic descriptions.
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 structured with a summary paragraph, an Args list, and a Returns section. It is front-loaded with the main purpose, and every sentence adds value. While lengthy, the length is justified by the complexity (10 parameters) and the dense technical details.
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 and the presence of an output schema, the description covers all necessary context: input parameters, grouping/summing behavior, pagination caveats, and the shape of the returned JSON. It also provides a natural-language example, making it complete for an agent to select and invoke correctly.
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%, but the description compensates fully. It explains each parameter: user_id accepts 'me', date boundaries are inclusive, filters are arbitrary JSON combined with AND, page_size affects total accuracy, sort_by has allowed fields, and include_comments controls comment output. This adds critical meaning beyond the bare schema.
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 produces a time entry report grouped by project with hour sums and totals. It uses a specific verb ('Отчёт'/'Возвращает записи сгруппированными') and resource ('записи времени'), and the example use case distinguishes it from sibling tools like op_log_time or op_list_time_entry_activities.
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 gives a concrete usage example: 'покажи время по мне за июль, сгруппированное по проектам'. This clearly indicates when to use the tool. It does not explicitly mention alternatives or exclusions, but the sibling tools are sufficiently different that no confusion is likely. Lacks explicit 'when-not-to-use' guidance, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 details the acceptance of human-readable time formats, the optional nature of activity_id and its fallback to default activity, the behavior when activities are mandatory and not configured, the default date for spent_on, and the return format. This is comprehensive and 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 well-structured with an initial purpose line, prerequisites, a clear Args list, and a Returns section. It covers necessary detail without unnecessary verbosity; the time format examples are useful and every sentence contributes to understanding the tool.
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 has 5 parameters, no annotations, and an output schema, the description covers all required aspects: purpose, prerequisites, all parameters with defaults and formats, potential server rejection scenarios, and a summary of the return value. It is complete enough for an agent to select and invoke the tool correctly.
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%, so the description must compensate. It does so thoroughly: each parameter is explained with meaning beyond the schema. For example, hours includes specific accepted formats, activity_id references another tool and explains default behavior, and spent_on specifies format and default. This adds substantial value over the bare schema.
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 function: 'Записать затраченное время к задаче (time entry)' (Log time spent to a task). It uses a specific verb and resource, and it is easily distinguished from sibling tools like op_list_time_entries which lists time entries rather than creating them.
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 usage context by listing prerequisites: the 'Time and costs' module must be enabled and the user must have 'Log time' permission. It also references op_list_time_entry_activities as a source for activity_id. However, it does not explicitly name alternatives or state when not to use the tool, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: synonym OR-merge and dedup by id, fallback to description search, in-memory tree building via _links.parent, pagination constraints, and the empty-result note. It also states that as_tree ignores name and pagination, making side effects explicit.
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 with clear sections and bullets. The one-line summary is front-loaded, and every detail—mode logic, parameter semantics, return format—serves a distinct purpose without fluff.
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 10 parameters, no schema descriptions, and no annotations, the description comprehensively covers all modes, edge cases (fallback, empty results), and return shapes, including extra fields for synonym search and tree output. It leaves no significant gaps.
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 schema has 0% description coverage, but the Args section defines every parameter's meaning, default, and interactions—e.g., parent_id uses 'ancestor' or 'parent_id' filters, filters is an arbitrary JSON array combined with AND, and sort_by lists allowed fields. The description fully compensates for the schema's lack of 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 'Получить список проектов и подпроектов в OpenProject', using a specific verb (get list) and resource (projects/subprojects). It clearly differentiates this list tool from sibling tools focused on work packages, time entries, and users.
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 'Режимы работы' section explicitly explains when to use parent_id, direct_children_only, as_tree, and name search, including parameter interactions like 'Игнорируется при as_tree=True'. It also gives instructions such as not auto-adding translations, providing clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![openproject-mcp MCP server](https://glama.ai/mcp/servers/sergeyfedyakov/openproject-mcp/badges/card.svg)](https://glama.ai/mcp/servers/sergeyfedyakov/openproject-mcp)

Score Badge

Copy to your README.md:

[![openproject-mcp MCP server](https://glama.ai/mcp/servers/sergeyfedyakov/openproject-mcp/badges/score.svg)](https://glama.ai/mcp/servers/sergeyfedyakov/openproject-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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