🇬🇪Georgia @lekso surameli

lekso surameli → created an issue.

@afoster Thank you for the excellent debugging work! Your investigation really helped us get to the bottom of this issue.

Root Cause Identified

After some more investigation, we have found that this issue comes from Cursor itself since it's not sending headers from config in requests.

The standard Cursor configuration:

{
 "mcpServers": {
   "mcp-server-drupal": {
     "type": "streamable-http",
     "url": "https://your-drupal-site.com/mcp/post",
     "headers": {
       "Authorization": "Basic BASE64_ENCODED_CREDENTIALS"
     }
   }
 }
}

Because of that, our custom authentication provider is failing since there is no Authorization header in the request headers.

I wasn't able to replicate that issue in VS Code using this configuration:

{
    "servers": {
        "mcp-server-drupal": {
            "type": "http",
            "url": "https://your-drupal-site.com/mcp/post",
            "headers": {
                "Authorization": "Basic BASE64_ENCODED_CREDENTIALS"
          }
        }
    }
}

Workaround for Cursor

For Cursor, there is one workaround: configure MCP with the mcp-remote package using config like this:

{
  "mcpServers": {
    "mcp-server-drupal": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://your-drupal-site.com/mcp/post",
        "--transport",
        "http-only",
        "--header",
        "Authorization: Basic BASE64_ENCODED_CREDENTIALS",
        "-y"
      ]
    }
  }
}

Note: For mcp-remote, if you are using a local MCP server, make sure to use the http protocol instead of https and add the --allow-http flag to args.

This should resolve the authentication issues you're experiencing with AI Agents when using Cursor.

First off, thank you so much for the incredibly detailed report and your continued interest in the MCP module. Your thorough testing and clear documentation are deeply appreciated - it really helps move the project forward.

Quick Responses to Your Points

1. Content Tool

You're absolutely right to suspect something is off with the request parameters. The error is caused by the missing sort field in the tool call. Currently, MCP expects this field to be explicitly defined. It should look like:

{
  "field": "<field_machine_name>", 
  "order": "DESC" or "ASC"
}

We have a small bug that doesn't handle empty sort data gracefully, which is causing the "Unknown field" error. We'll:

• Fix the bug to allow empty sort parameters
• Improve error logging to provide clearer messages about required parameters
• Update documentation to clarify the expected format

2. Resource Template

The completion/complete method isn't currently supported in our MCP implementation, which is why you're seeing errors when autocomplete is triggered in the input fields. We're planning to add support for this method in the near future to improve the user experience.

3. AI Agent Permission Requirements

For both the custom agent and taxonomy agent errors, the issue stems from the list_config_entities function call in the ai_agents → module, the exact location of the exception . This function requires the user to have "Administer roles and permissions" permission to execute successfully.

After testing with the STDIO transport using a user with "Administer roles and permissions" permission, I can confirm that these requests work without errors when the proper permissions are in place.

@mpotter Thank you for catching this inconsistency and for providing a clean, well-structured patch!

We’ve reviewed your changes and really appreciate the effort. A MR has been opened and the patch has now been merged into the dev branch.

lekso surameli → made their first commit to this issue’s fork.

lekso surameli → created an issue.

lekso surameli → created an issue.

Hey there,

Thanks a ton for reaching out and for taking the initiative with your Google Sheets integration—sounds great! I’m still committed to the Google Sheets module, even if progress has been a bit slower than I’d like.
Let’s pick this up on Drupal Slack so we can hash out a plan together. You can find me as @Lekso Surameli . Happy to sync up, look over your code, and figure out the best way to move forward - whether that’s collaborating on the existing project or working out another approach that suits us both

Looking forward to chatting

Merged 🎉

Thanks for the review and suggestions @vasike

lekso surameli → created an issue.

Looks Awesome!

Thanks for the contribution @vasike

Thanks for the note @vasike, I have updated both task title and description

Merged 🎉

@vasike thanks for the MR
@a.dmitriiev thanks for the review

lekso surameli → made their first commit to this issue’s fork.

LGTM

@vasike thanks for the MR
@a.dmitriiev thanks for the review

Thank you all for your effort on this merge request

After reviewing the changes, I’ve concluded that the current approach isn’t entirely valid or functioning as intended.

The issue lies in the use of the variant prop. This prop is designed to control the display mode of the ProjectIcon component, but it’s currently being repurposed to represent the type of recipe. This approach doesn’t align with its intended purpose and leads to unintended side effects.

Additionally, the variant prop currently supports two values: project-listing and module-details, each with separate associated CSS classes for styling. Overloading this prop with additional responsibilities could interfere with its primary purpose and the related styles.

For example with these changes the tooltip for the icon looks like this:

Because the value of variant prop is module-details.

To address this, I recommend introducing a new prop specifically for controlling the type of recipe. This would make the component’s API more explicit and maintain the clarity and integrity of the existing variant prop.

Let me know if you’d like to discuss this further

I'm also changing the status of this ticket to Needs work

Hey everyone, I'm going to review this MR as part of the ContributionWeekend2025

Thank you for the work

After reviewing the code, I noticed that recipes are currently being sorted by machine_name rather than the human-readable name of the recipe. Sorting by name might provide a more user-friendly experience, as it's generally what end-users would expect to see

In this example bellow you can see how the Website feedback contact form appears before the Full HTML editor, this happens because the machine name of the first recipe is feedback_contact_form

@vishalkadam Thank you for reporting this issue! It has been addressed in the latest 1.0.0-alpha2 release.

In the meantime, support for Drupal 11 has been temporarily removed as we await the stable release of the webform module for Drupal 11.

lekso surameli → changed the visibility of the branch 3502222-add-module-logo to hidden.

lekso surameli → created an issue.

lekso surameli → made their first commit to this issue’s fork.