Problem/Motivation

Task is to migrate and merge the mcp module plugin system (especially tools) into the mcp_server module.

Proposed resolution

Introduce a dedicated Tool plugin system in the mcp_server module and migrate all existing mcp tools to it, integrating with configuration pages and making sure it is compatible with new features like LLM Sampling.

Remaining tasks

  1. Create a Tool (wording can be suggested as there is already a Tool plugin provided by the Tool API module) plugin attribute, with a plugin interface and plugin base.
  2. Migrate all existing mcp module tools to the newly created plugin system.
  3. Integrate this plugin system with the config pages.
  4. Make sure that the new plugin system is compatible with new features, like LLM Sampling.
  5. Add possible migration, if necessary.
  6. Add tests.

User interface changes

There are no user interface changes.

API changes

The Tool plugin gives the user the possibility to define custom MCP tools without defining the Tool API tools. This gives us more flexibility over time, so we are not completely dependent on the Tool API.

Issue fork mcp_server-3560497

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

gagosha created an issue. See original summary.

e0ipso’s picture

e0ipso
Primary language Catalan
Location Can Picafort
commented

Voice transcription, apologies for any mistakes.

One of the things that I believe it's important to have in order to comply with the industry standards is keeping MCP tool authorization to OAuth scopes. This is because we will present them (during the authorization) to the user, so they can allow the MCP client. Note that we are exposing scopes, not permissions. So even though we will have tool plugins checking for permissions, as usual, we need to be able to know which scopes the authorization system needs.

Right now the authorization goes like this:

  1. Whenever the server is exposing the authorization metadata for the client to read, we loop over all of the existing config entities.
  2. We collect the scopes that each tool needs, so we aggregate them in a big collection of scopes
  3. Then, when the MCP client has this information (via a metadata endpoint) it writes a special URL that contains all of the scopes
  4. A browser window opens and the user is invited to log in
  5. When they have logged in, they are asked to validate: Do you want to give this MCP client access to all these scopes?
  6. If the user accepts, a token that contains the scopes that the user accepted is generated in the server and then sent back to the client
  7. The client stores it.
  8. On subsequent tool calls (and any other MCP interaction) the client will attach that token that has access to those scopes
  9. When Drupal sees a request with an auth token it will create a virtual user (that has the same user id) but is limited in permissions to the permissions that those roles have configured

As you can see in order to have the user access the tools with normal permissions, first we need to ensure that tools have the scopes associated to them that will provide those permissions. A big wrinkle in all this is that scopes are entities and entities exist per site. This means that an MCP tool developer cannot know what will be the scopes available in the site. This is why we need a site builder to make that connection between the scopes (that they created earlier) and the permissions the tools need to operate.

gagosha opened merge request !3

e0ipso’s picture

e0ipso
Primary language Catalan
Location Can Picafort
commented

I haven't looked into this yet, but I noticed a test failure:

https://git.drupalcode.org/project/mcp_server/-/jobs/7493279

gagosha’s picture

gagosha commented
Status: Needs work » Fixed

Merged the changes. The plugin discovery system was migrated from the mcp module to mcp_server, with one plugin that exposes the Drupal Tool API tools as MCP tools.

I will create a separate ticket to migrate the existing mcp module plugins and UX.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

gagosha’s picture

gagosha commented
Status: Fixed » Closed (fixed)