Content
View differences
Updated by Jan Sandbrink about 1 month ago
**As** an OpenProject developer
**I want to** provide a compliant MCP HTTP endpoint inside OpenProject
**so that** MCP clients can discover and communicate with OpenProject’s available tools, resources, and prompts through a single standard interface
**Acceptance criteria**
* A new endpoint `/mcp` namespace /mcp/\* exists within OpenProject
* The MCP server responds to:
* Server metadata includes:
* `GET /mcp/metadata:` returns server name
* version
* description
* name, version, description, supported endpoints and configuration.
* MCP server supports `tools/list`, `resources/list` and `prompts/list` requests
* `GET /mcp/list_tools, GET /mcp/list_resources, GET /mcp/list_prompts:` minimal stubs return empty or demo data until respective features are implemented.
<br>
* `metadata` output follows the Model Context Protocol spec for HTTP transport.
* Endpoint available in development and production modes behind feature flag `mcp_server` and enterprise feature `mcp_server`. `mcp_enabled`.
* Health check logs confirm valid MCP responses.
<br>
**Technical notes**
* Implement using the [Ruby MCP SDK](https://github.com/modelcontextprotocol/ruby-sdk).
* The metadata /metadata endpoint includes:
* server\_name, version, auth\_method: oauth2\_pkce,
* arrays for available tools, resources, prompts,
* optional admin\_customization: true flag.
<br>
**Permissions and visibility considerations**
* Visible only when `mcp_server` mcp\_enabled feature flag is active.
* Requires authenticated OAuth access token (public apps with PKCE allowed).
* Metadata hides any disabled tools/resources per admin configuration.
**Out of scope**
* Implementing actual tool or resource logic (covered in later features).
* WebSocket or streaming transport.
* UI components for admin configuration (handled in separate features).
<br>
**I want to** provide a compliant MCP HTTP endpoint inside OpenProject
**so that** MCP clients can discover and communicate with OpenProject’s available tools, resources, and prompts through a single standard interface
**Acceptance criteria**
* A new endpoint `/mcp`
* The MCP server responds to:
* Server metadata includes:
*
* version
* description
*
*
* `metadata` output follows the Model Context Protocol spec for HTTP transport.
* Endpoint available in development and production modes behind feature flag `mcp_server` and enterprise feature `mcp_server`.
* Health check logs confirm valid MCP responses.
<br>
**Technical notes**
* Implement using the [Ruby MCP SDK](https://github.com/modelcontextprotocol/ruby-sdk).
* The metadata
* server\_name, version, auth\_method: oauth2\_pkce,
* arrays for available tools, resources, prompts,
* optional admin\_customization: true flag.
<br>
**Permissions and visibility considerations**
* Visible only when `mcp_server`
* Requires authenticated OAuth access token (public apps with PKCE allowed).
* Metadata hides any disabled tools/resources per admin configuration.
**Out of scope**
* Implementing actual tool or resource logic (covered in later features).
* WebSocket or streaming transport.
* UI components for admin configuration (handled in separate features).
<br>