Enables AI assistants to interact with OpenProject work packages, projects, and time tracking, including tools for creating, updating, and listing work packages, managing project statuses, and logging time entries.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@OpenProject MCP Server list my open work packages for the Website Redesign project"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Model Context Protocol (MCP) server for OpenProject API integration. Enables AI assistants to interact with OpenProject work packages, projects, and time tracking.
npm install -g openproject-mcpnpm install openproject-mcpRelated MCP server: OpenProject MCP Server
Log into your OpenProject instance
Go to My Account → Access tokens
Create a new API token
Copy the token
Add to .kiro/settings/mcp.json:
{
"mcpServers": {
"openproject": {
"command": "npx",
"args": ["-y", "openproject-mcp"],
"env": {
"OPENPROJECT_URL": "https://your-openproject-instance.com",
"OPENPROJECT_API_KEY": "your-api-key-here"
}
}
}
}Or if installed globally:
{
"mcpServers": {
"openproject": {
"command": "openproject-mcp",
"env": {
"OPENPROJECT_URL": "https://your-openproject-instance.com",
"OPENPROJECT_API_KEY": "your-api-key-here"
}
}
}
}Tool | Description |
| List all projects |
| Get work package details by ID |
| List work packages with filters |
| Get child work packages of a parent |
| List all available statuses |
| List all work package types (Feature, Task, Bug, etc.) |
| Get user information |
| Create a new work package |
| Update an existing work package |
| Log time entry for a work package |
| Make a raw API call to any endpoint |
get_children({ parentId: 211 })create_work_package({
subject: "Implement token budget management",
parentId: 538,
assigneeId: 10,
startDate: "2026-01-15",
dueDate: "2026-01-15"
})list_work_packages({ assigneeId: "me" })update_work_package({
id: 123,
statusId: 12, // Status ID from list_statuses
estimatedTime: "PT2H" // 2 hours in ISO 8601 format
})log_time({
workPackageId: 123,
hours: 2.5,
comment: "Implemented feature X",
spentOn: "2026-01-23"
})Variable | Required | Description |
| Yes | Your OpenProject instance URL |
| Yes | API key from OpenProject |
Node.js >= 18.0.0
OpenProject instance with API access
MIT
Contributions are welcome! Please open an issue or submit a pull request.
Create a new work package (Task)
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | No | Project ID or slug | |
| subject | Yes | Work package title/subject | |
| description | No | Work package description | |
| typeId | No | Type ID (1=Task, 4=Feature, 5=Bug) | |
| parentId | No | Parent work package ID | |
| assigneeId | No | Assignee user ID | |
| versionId | No | Sprint/Version ID | |
| startDate | No | Start date (YYYY-MM-DD) | |
| dueDate | No | Due date (YYYY-MM-DD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool creates a work package but doesn't cover critical aspects like required permissions, whether it's idempotent, what happens on failure, rate limits, or the format of the response. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, and the parenthetical adds useful specificity without verbosity. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a 9-parameter mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral traits, error handling, or response format, leaving the agent with insufficient context to use the tool effectively beyond basic parameter mapping.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 9 parameters. The description adds no parameter-specific information beyond implying 'Task' as a default type (which aligns with the schema's default for 'typeId'). With high schema coverage, the baseline is 3, as the description doesn't compensate with additional semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('new work package'), with the parenthetical '(Task)' providing additional specificity about the default type. It distinguishes this from sibling tools like 'update_work_package' or 'list_work_packages' by focusing on creation, though it doesn't explicitly differentiate from other potential creation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 a project ID), when not to use it, or how it relates to siblings like 'update_work_package' or 'log_time'. Usage is implied only through the tool name and action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get child work packages of a parent
| Name | Required | Description | Default |
|---|---|---|---|
| parentId | Yes | Parent work package ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'gets' children, implying a read operation, but doesn't describe return format (e.g., list structure, fields included), pagination, error conditions, or authentication needs. This leaves significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word contributes directly to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'child work packages' entail (e.g., their attributes or relationship details), how results are returned, or potential limitations. For a tool with 1 parameter but lacking structured context, more detail is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'parentId' documented as 'Parent work package ID'. The description adds minimal value beyond this, only implying that 'parentId' identifies the parent whose children are retrieved. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('child work packages'), specifying that it retrieves children of a parent work package. It distinguishes from siblings like 'get_work_package' (single package) and 'list_work_packages' (general list), but doesn't explicitly contrast them. This makes the purpose clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 a valid parent ID), exclusions, or comparisons to siblings like 'list_work_packages' or 'get_work_package'. Usage is implied by the description but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get user information
| Name | Required | Description | Default |
|---|---|---|---|
| userId | Yes | User ID or 'me' for current user |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get user information' implies a read-only operation, but it doesn't specify whether this requires specific permissions, rate limits, error conditions, or what the response format looks like (e.g., JSON structure). For a tool with no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, which is front-loaded and wastes no space. However, it borders on under-specification given the lack of context, slightly reducing its effectiveness despite the brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, 100% schema coverage) but lack of annotations and output schema, the description is incomplete. It doesn't explain what 'user information' entails, potential use cases, or behavioral aspects like authentication needs, making it insufficient for an agent to fully understand the tool's context and limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'userId' parameter clearly documented as 'User ID or 'me' for current user'. The description adds no additional parameter details beyond what the schema provides, so it meets the baseline of 3 for adequate but minimal value addition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get user information' clearly states the verb ('Get') and resource ('user information'), which is better than a tautology. However, it's somewhat vague about what specific information is retrieved (e.g., profile details, permissions, activity) and doesn't distinguish this tool from potential sibling tools like 'get_work_package' or 'raw_api_call' in terms of scope or data type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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., authentication needs), context for 'userId' parameter usage, or how it differs from other user-related operations that might exist in the system. This leaves the agent with minimal direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific work package by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Work package ID |
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 'Get' which implies a read operation, but doesn't clarify if it's safe, requires authentication, has rate limits, or what happens with invalid IDs. This is inadequate for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it efficient and easy to parse. Every part of the sentence contributes directly to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't address behavioral aspects like safety or error handling, nor does it explain return values. For a tool with zero annotation coverage and no output schema, more context is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'by ID', which aligns with the single parameter 'id' in the schema. Since schema description coverage is 100%, the schema already documents the parameter fully, so the description adds minimal value beyond restating the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('a specific work package by ID'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'list_work_packages' or 'get_children' beyond the 'by ID' specification, which is why it doesn't reach a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 siblings like 'list_work_packages' for multiple packages or 'get_children' for related items, nor does it specify prerequisites such as needing a valid ID. This leaves usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all projects in OpenProject
| Name | Required | Description | Default |
|---|---|---|---|
| pageSize | No | Number of results per page |
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 it's a list operation, implying it's read-only, but doesn't mention any behavioral traits like pagination behavior (though hinted by the 'pageSize' parameter), rate limits, authentication requirements, or what the output looks like. For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core purpose ('List all projects in OpenProject'), making it immediately understandable. Every word earns its place, and there's no unnecessary elaboration or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter) and lack of annotations or output schema, the description is incomplete. It doesn't explain what 'projects' entail in OpenProject, how results are structured, or any limitations (e.g., does it list all projects or only accessible ones?). For a list tool with no output schema, more context on return values would be helpful, making this description insufficient for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'pageSize' fully documented in the schema. The description adds no additional parameter information beyond what the schema provides, such as default behavior or constraints. Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't need to compensate but also adds no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('projects in OpenProject'), making the purpose immediately understandable. It distinguishes from some siblings like 'create_work_package' or 'update_work_package' by being a read operation, but doesn't explicitly differentiate from other list tools like 'list_statuses' or 'list_work_packages' 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.
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 when to use 'list_projects' instead of other list tools like 'list_work_packages' or 'list_statuses', nor does it provide context about prerequisites, typical use cases, or limitations. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available statuses
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 'List all available statuses,' which implies a read-only operation, but doesn't specify whether it requires authentication, returns paginated results, or has rate limits. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded and directly states the tool's purpose, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema), the description is minimally adequate. However, with no annotations and no output schema, it lacks details on behavioral traits like authentication or response format, which could be helpful for a read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't mention parameters, which aligns with the schema. A baseline of 4 is applied since it doesn't add unnecessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all available statuses' clearly states the verb ('List') and resource ('statuses'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_projects' or 'list_types' beyond the resource name, which keeps it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, context, or how it relates to sibling tools like 'list_work_packages' or 'get_work_package', leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all work package types (Feature, Task, Bug, etc.)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read-only operation by using 'List', but doesn't disclose behavioral traits such as whether it requires authentication, has rate limits, returns paginated results, or what format the output takes (e.g., list of strings, objects with IDs). For a tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('List all work package types') and provides clarifying examples in parentheses. There is zero waste—every word contributes to understanding the tool's scope without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks context on usage, behavioral details, or output format. Without annotations or output schema, the description should ideally cover more about the operation's behavior and results to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (since there are no parameters to describe). The description doesn't need to add parameter semantics, so it meets the baseline of 4 for zero-parameter tools. It appropriately focuses on the tool's purpose without unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all work package types') with specific examples (Feature, Task, Bug). It distinguishes from siblings like list_projects or list_work_packages by focusing on types rather than projects or packages themselves. However, it doesn't explicitly contrast with list_statuses, which is a similar enumeration tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, context for usage, or compare with siblings like get_work_package (which might return type info for a specific package) or raw_api_call (which could achieve similar results). The description only states what it does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List work packages with optional filters
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | No | Project ID or slug | |
| parentId | No | Parent work package ID to list children | |
| assigneeId | No | Assignee user ID or 'me' | |
| status | No | Status filter | |
| pageSize | No | Number of results |
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 the tool lists work packages but doesn't mention critical behaviors like whether it's read-only, pagination details (implied by 'pageSize' but not explained), rate limits, authentication needs, or what the output looks like. This leaves significant gaps for a tool with multiple parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 no output schema, the description is incomplete. It doesn't explain the return format, pagination behavior, or error conditions, which are essential for an agent to use the tool effectively. The mention of 'optional filters' is too vague to cover these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'optional filters' which aligns with the parameters in the schema, but adds no specific meaning beyond what the schema already provides (schema description coverage is 100%). Since the schema fully documents the parameters, the baseline score of 3 is appropriate, as the description doesn't compensate with additional insights.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('list') and resource ('work packages'), making the purpose understandable. However, it doesn't distinguish this tool from potential sibling tools like 'get_work_package' or 'get_children' that might also retrieve work packages in different contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'optional filters' but provides no guidance on when to use this tool versus alternatives like 'get_work_package' (for a single package) or 'get_children' (for child packages). It lacks explicit when-to-use or when-not-to-use instructions, leaving the agent to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Log time entry for a work package
| Name | Required | Description | Default |
|---|---|---|---|
| workPackageId | Yes | Work package ID | |
| hours | Yes | Hours spent (e.g., 2 for 2 hours, 0.5 for 30 minutes) | |
| comment | No | Comment for the time entry | |
| spentOn | No | Date spent (YYYY-MM-DD), defaults to today | |
| activityId | No | Activity type ID (1=Development) |
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 the action ('log time entry') which implies a write operation, but doesn't mention permissions required, whether the entry is editable/deletable, error conditions, or what happens on success (e.g., returns an ID). This leaves significant 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and efficiently communicates the core functionality, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It lacks behavioral details (e.g., side effects, return values), usage context, and doesn't compensate for the absence of structured metadata. This makes it inadequate for safe and effective use by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so all parameters are documented in the schema. The description adds no additional parameter information beyond what's in the schema (e.g., no examples or constraints). This meets the baseline for high schema coverage, but doesn't enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('log time entry') and the target resource ('for a work package'), making the purpose immediately understandable. It doesn't distinguish from siblings like 'create_work_package' or 'update_work_package', but it's specific enough to avoid confusion with other time-related operations that might exist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 an existing work package), exclusions, or related tools like 'update_work_package' for modifying time entries. Usage is implied by the name but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make a raw API call to any OpenProject endpoint
| Name | Required | Description | Default |
|---|---|---|---|
| endpoint | Yes | API endpoint (e.g., /api/v3/work_packages) | |
| method | No | HTTP method | GET |
| body | No | Request body for POST/PATCH |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool makes API calls but doesn't describe authentication needs, rate limits, error handling, or response formats. For a raw API tool with zero annotation coverage, this is a significant gap in behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to understand quickly. Every word earns its place, achieving optimal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a raw API tool with no annotations and no output schema, the description is incomplete. It doesn't explain return values, error cases, or behavioral traits like authentication. For a tool that can perform various operations, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, documenting all parameters (endpoint, method, body) with clear descriptions. The description adds no additional parameter semantics beyond what the schema provides, such as endpoint format examples or method constraints. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Make a raw API call to any OpenProject endpoint.' It specifies the verb ('Make a raw API call') and resource ('any OpenProject endpoint'), but doesn't explicitly distinguish it from sibling tools like 'get_work_package' or 'update_work_package' which are specific API calls. The purpose is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 the specific sibling tools (e.g., 'create_work_package', 'get_work_package'). It implies usage for any API endpoint but doesn't mention alternatives, prerequisites, or exclusions. Without explicit when/when-not instructions, it offers minimal usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing work package
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Work package ID | |
| subject | No | New subject | |
| description | No | New description | |
| statusId | No | New status ID | |
| assigneeId | No | New assignee ID | |
| versionId | No | Sprint/Version ID | |
| estimatedTime | No | Estimated time in ISO 8601 duration format (e.g., PT2H for 2 hours, PT30M for 30 minutes) |
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 'Update an existing work package,' implying a mutation operation, but lacks details on permissions required, whether changes are reversible, error handling, or side effects. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded and to the point, though it could benefit from more detail given the tool's complexity. It earns a high score for brevity but loses a point for potential under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, mutation operation), lack of annotations, and no output schema, the description is incomplete. It doesn't explain return values, error conditions, or behavioral nuances, leaving gaps for an AI agent to infer usage. More context is needed for a mutation tool with multiple inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all 7 parameters documented in the input schema. The description doesn't add any parameter-specific information beyond what's in the schema, such as examples or constraints. Baseline is 3 since the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing work package' clearly states the action (update) and resource (work package), but it's generic and doesn't differentiate from sibling tools like 'create_work_package' or specify what aspects can be updated. It's a basic statement of purpose without specificity about scope or fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 an existing work package ID), exclusions, or comparisons to siblings like 'create_work_package' for new entries or 'get_work_package' for reading. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have distinct purposes targeting specific resources like work packages, projects, users, and statuses. However, 'list_work_packages' and 'get_work_package' could potentially be confused with 'get_children' for hierarchical queries, but descriptions clarify their scopes. The 'raw_api_call' tool stands out as a catch-all that might overlap with others but serves a different low-level purpose.
All tool names follow a consistent verb_noun pattern with clear, descriptive actions like 'create_work_package', 'list_projects', and 'update_work_package'. There are no deviations in style or convention, making the set predictable and easy to parse for an agent.
With 11 tools, the count is well-scoped for managing work packages and related entities in OpenProject. Each tool serves a clear function, such as CRUD operations for work packages and supporting queries for projects, statuses, and types, without feeling bloated or insufficient.
The toolset provides strong coverage for core work package operations, including create, get, update, list, and hierarchical queries, along with essential supporting functions like logging time and listing projects, statuses, and types. A minor gap exists in the lack of delete operations for work packages or other entities, which agents might need to work around using 'raw_api_call'.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Create and manage MeisterTask projects, tasks, and notes from your AI assistant.
Manage Avaza projects, tasks, timesheets, expenses, invoices, and scheduling from AI assistants.
Manage projects, tasks, time tracking, and team collaboration through natural language.
Manage tasks, Focus Zone, notes, projects, and task history from compatible AI assistants.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/cyborgx0x/mcp-openproject'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
