Detail: We do not really rely on APIv3 to offer the MCP server, however it's correct that we reuse the APIv3 format for MCP. Small wording suggestion to better reflect that:

Additionally I want to give some feedback on the first sentence:

that lays the foundation for robust integrations between OpenProject and external intelligent agents, automation tools, or systems that use the Model Context Protocol (MCP).

Semantically: I don't understand the or enumeration here. The MCP server is only intended for "systems that use the Model Context Protocol". Automation tools and agents need to implement/have access to an MCP client to make use of this. So maybe this could be phrased in a way of "systems that use the Model Context Protocol, such as ..."

"intelligent agent": Do we know what we mean with this term? I needed to look it up and wasn't sure if it's made up, but apparently it exists: https://en.wikipedia.org/wiki/Intelligent_agent
However, this existing term seems to be very generic/broad, so I am not sure if this is what we were aiming for here.
Do we want to indicate that "your favorite large language model" can be hooked up to this? I think in this case we should use the term "LLM" or "large language model". An example (combined with the proposals above:

Technicality to my suggestion above: The LLMs usually run on a platform where they have access to an MCP client, but don't implement the MCP client as part of the model. I think the proposal above reflects this enough by saying "use the Model Context Protocol", but in case you want to reformulate my suggestion, I'd not write something that implies an LLM is an MCP client.

I think something that we can brag about more openly, is that as a consequence on how we built this, it also integrates cleanly with external authentication providers (think of Keycloak):

and response formats can be adjusted based on your preferences

I believe that this sentence was born out of https://community.openproject.org/wp/71978, which I consider to be a pretty niche (as in small, not "nice") setting. We built this after we observed for one MCP client that it passed too much data on to the LLM and thus decreased model performance. Other MCP clients didn't seem to make the same mistake and thus don't require any fiddling with this setting at all.

I think it's good that we included the setting, because maybe someone will find it useful, but it's also a good candidate for a feature to be removed, once we see that it's not really needed. I'd try to not advertise it too strongly. My suggestion would be to drop the quoted half-sentence

With session-cookie and bearer-token support, the MCP Server acts as a secure bridge between your OpenProject instance and external systems that operate via MCP.

Again, session-cookie support was something that we added late into the process because it might be valuable in niche use-cases, but it's nothing that deserves spotlight IMO.

I think the Bearer token and OAuth-support do deserve spotlight. For security on the one side (even though I have to admit that I find this a weird one to point out too strongly, because no one would ever admit that they built something insecurely), but also for compatibility/interoperability on the other side. As I indicated above, support for OAuth (in the way we did it), means that we support external IDPs out of the box.

Red flag when reading this:

Increased security [is an] Enterprise add-on

I think it's a fair limitation for the feature in question, but it could be misread as "if you really want to have a secure product, you have to pay".

Maybe Oliver or Klaus can refresh my memory on how the login actually improves the security here, but I think the intent was to make sure that users are aware that they receive an email generated by OpenProject that directs them to an external destination. The login requirement probably makes spamming links less effective, because only logged in users will see them, but not search engines / anonymous users? (I am not entirely sure about the attack vector here)

Factually wrong. Correct:

Something that was developed in the scope of the MCP Epic, but actually works independently of it might deserve some attention here (I assume it does, because we even highlight renamings of config options here):

**API tokens usable as Bearer token**
Newly generated API tokens can directly be used as Bearer tokens and do not need to be presented as basic auth credentials with the username `apikey`. This is intended to make usage of our APIs easier. The previously existing basic auth flow is still supported.

via: https://community.openproject.org/wp/71147