We separated projects from portfolios and programs conceptually.
While older APIs can return mixed results for backwards-compatibility
purposes, the MCP API already purely returns projects from the search_projects
tool, thus we need additional tools for results of other types.
Allowing to search for users, e.g. to allow queries like
"find work packages assigned to Maria".
Allowing to find the current user, to enable classic use cases
like "find work packages assigned to me".
Instead of defining the mcp tools as static classes, we are now
using the Mcp::Tool.define flow to build them. This allows us to
change their description on every call and thus define it through
the configuration stored in the database.
So far the MCP server only offers a single tool, but authentication
and integration is already built in a way that's intended to last.
Ideally extensions to this happen by adding additional tools or resources,
but will not require further architectural changes, though realistically we'll
probably identify more potential for reuse, once we added a few more tools.
The exact representation of results is still slightly to-be-discussed. Right
now we are using vanilla APIv3 representation, which might be enough, but possibly
we want to represent linked resources differently, so that they can be recognized
to be fetchable via MCP resources more easily.
Eric Schubert