🇧🇪Belgium @lammensj

Jasper Lammens (@lammensj)
- Resolved a couple of tickets for https://www.drupal.org/project/issues/ai_search_block?categories=All →
- Gave a presentation about AI, ECA and MCP ( https://www.drupal.org/project/ai_initiative/issues/3552852#comment-1630... 📌 Collect and share slides on Drupal AI at DrupalCon Vienna 2025 Active )

ECA, AI and MCP: Connecting Context, Intelligence and Action
Speaker(s): Jasper Lammens (lammensj)
Session link: https://events.drupal.org/vienna2025/session/eca-ai-and-mcp-connecting-c...
Slides: https://docs.google.com/presentation/d/1ZiKLTZFNkw10_Hb5QjT4T3y6gwg51z3Y...

The fact that the Response block can not be found by the controller is normal: the block isn't saved in the database in the "normal" way, its configuration is serialized and put into the entire blob that is the LB-config.

In order to solve this, there are a couple of options:
1. We force the site builders and LB-users to link the two blocks together by an ID that they need to specify. It's the same way how Facets are connected to Views and their exposed filters.
2. We append the response of the LLM directly to the form block.

Don't know what Frederik prefers or how many users are actually placing the two blocks in different regions (instead of just below each other).

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

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

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

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

lammensj → created an issue.

lammensj → created an issue.

lammensj → created an issue.

kristen pol → credited lammensj → .

kristen pol → credited lammensj → .

Hi,

I created two MRs for the 2.x and 2.1.x version of the module.

Important to note that both changesets are the same, and that they include a version bump of the required Drupal version (at least 10.5, see release notes: https://www.drupal.org/project/drupal/releases/10.5.0 → ).

Release note for the change of CKEditor: https://ckeditor.com/docs/ckeditor5/latest/updating/guides/update-to-45....

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

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

Yes, the ECA-submodule of AI will be deprecated in favor of this one.

Hi gbyte,

This module is the successor of the submodule inside the AI module. There are open issues to mark that one as deprecated and provide an upgrade path to this one. We're almost there, just crossing the last t's.

See https://www.drupal.org/project/ai_integration_eca/issues/3505623 💬 Uninstall ai_eca Active

@britt.vdl, thank you for the contribution! I do have a couple of remarks:
- Can you open a MR using Gitlab? There are some checks in place that are being executed on that platform (think phpcs etc.)
- Can you change the version to 3.0.x?
- The proposed changes should be moved to a new submodule, with a dependency on grapqh. It's not my intention to make the main module dependent in it.
- If possible, could you a kernel test?

My 12 points go to:
- Joris Vercammen (borisson_)
- Nico Grienauer (grienauer)

Good luck!

borisson_ → credited lammensj → .

I incorporated the mentioned remarks.

About the need for that second event: when I render the View with one of the default pagination options (mini or extensive), the same "issue" is visible: the next page contains the amount of items that was specified in the settings, and not how what it was actually rendered. This says to me that that setting is not passed between the consequential ajax calls.
Only when disabling ajax, that overwritten amount of items is "retained". I put that between quotes because it's another render event that triggers the build of that View, with that separate value for the amount of items.

So I'm assuming that, even without ECA, you would still have to use the pre-build hook to overwrite the amount of visible items. And some "initial" render code, but that's specific to this implementation. So yes, the change to the "Views"-action of the eca_render-module (specifying the amount of items) could be left out of this PR and replaced with a guideline: "if you want to change the amount of visible items per page, use the pre-build event to specify it".

lammensj → created an issue.

Thank you for the quick resolution! I can confirm that it's fixed on the project that I was working on. See attached screenshot of logs.

The one with red line is wrong, in my opinion; it's showing the context of an action within the eca_views.pre_execute-event, but with the data of the eca_render.entity-event. Both logs within the squares start with "Start [event name]... for event eca_views.pre_execute".

lammensj → created an issue.

Summary of the latest changes:
- [eca_render]: Refactored the way the configuration key is translated to a value (either a token or a regular string)
- [eca_render]: Added update-hook to update existing and their config
- [eca_views]: Added eca_views_set_pagination_values-action to keep the pagination setting across different http-requests. The "issue" mentioned above, with views_infinite_scroll, was not related but did send me in the right direction. Overwriting the pagination via the eca_render_views-action works, but only for the initial rendering. When using ajax pagination, Views falls back to the setting of the View itself.
So I had to tackle this from another angle: hooking into the pre-execute or pre-build event of that View. So I've created a "copy" of the eca_views_set_filter_value-action, and changed it so it sets the pagination- and offset-config.

For my particular use-case (see screenshot) this approach now works: in one model, you render the View and alter it via the pre-build event. There's only one bug, not sure if it is one, and that's data of the event that is available. See separate issue.

vrancje → credited lammensj → .

Thank you for your contribution!

I had to create a new MR because the previous one didn't include the necessary changes to the output schema of the ToolsCall-function.

lammensj → created an issue.

lammensj → created an issue.

lammensj → created an issue.

@flyke, this should indeed be fixed in this module. Do you want to create the patch? I believe you already have a system in place where you could test it, right?

@marcus_johansson, the PRs for the related modules are done. Let me know how you want to address this in terms of timing (when I should create new releases etc.).

lammensj → created an issue.

lammensj → created an issue.

lammensj → created an issue.

Yeah, no problem. I should have thought about that when I registered it in the first place... #facepalm

I have some time tonight, I hope I get it done.

It seems to be more complicated than the providers: I made the mistake of registering a contrib module with the same name as the submodule. When the submodule is enabled, and composer downloads the new one, Drupal automatically uses the contrib one, without uninstalling the original. This means you can't run hook_update from the submodule or hook_install from the contrib one.

Perhaps it's easier if I register a new contrib module, something like "ai_integration_eca" and then apply the provided example...

For reference, this is how the Views Block plugin is overriding the items_per_page config item: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/views.... The ECA Action is doing the same thing.

I've implemented your remarks, thank you for the feedback.

Regarding the items being returned for the second "page", I believe it's an issue coming from Views Infinite Scroll. I'll link the ticket. But this shouldn't stop this particular feature request.

Aha, that's very useful, thank you!
I'll take a look and create something similar.

lammensj → created an issue.

wouters_f → credited lammensj → .

lammensj → created an issue.

However... Testing the change now... When I set the items per page on the View-object, it works when it's rendered initially. But the second page just loads the amount of items that is configured in the View itself...

It depends a bit on how flexible you want it to be. If you search for "function set" on this page: https://api.drupal.org/api/drupal/core%21modules%21views%21src%21ViewExe..., you'll get a list of all the items you can alter/set before executing the View.

For now, I'm just limiting it to the arguments (already there) and the items per page.

lammensj → created an issue.

@tijsdeboeck, could you check if the provided solution works for you?

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

@jurgenhaas, the fix was surprisingly easy! Can you do QA?

@yautja_cetanu, your question regarding the desired schema, that's one for @marcus_johansson, right?

In my opinion, and by my (yet) limited knowledge of the MCP module, I believe a schema needs to be created either way. Whether it's developed for the "separate" implementation of function calling in the AI module, or for MCP, an LLM still needs something that it should adhere to.

To make it more tangible; I'm going to experiment with the Typed Data model I created for the ECA Agent and see how it fits in that MCP plugin type. I believe I can re-use A LOT but just need to split up some things. Like create a separate "tool" for requesting all models, creating a model and editing one. But in the end, the LLM should still generate JSON based on the Schema that I created for the "original" Agent.

I hope this makes sense :)

Hi @socialnicheguru, I'm the maintainer of the standalone contrib module. And yes, it's a duplicate of the submodule, but with extended capabilities (the ECA Agent).
I created/copied it to ensure that the main AI module doesn't need to depend on ECA, because that has its own roadmap with major and minor versions. I'm still in discussion with @marcus_johansson on how we can mark the submodule as deprecated in favor of the contrib one.

I was here (always wanted to write that somewhere :p )

Hi @michaellander, I’m indeed working on an integration for AI, more specifically an AI Agent.
At the moment, it can do 3 things
- Answer questions about existing models and available components (actions, events etc.)
- Create new models
- Edit an existing model
The only thing that’s holding me back of creating a stable release, is one issue where an edit of a model by AI doesn’t result in a valid config item.

Another part are operation types (chat, text_to_image etc.) as Actions.

https://www.drupal.org/project/ai_eca →
https://www.drupal.org/project/ai_eca/issues/3481307 📌 Add AI Agent Active

For the ECA agent, I used the Typed Data API and Schemata for generating a JSON Schema that the AI should follow. Once config validation is in core and there's support for Schema-generation, this becomes obsolete.
For non-entity data structures, something like this approach could be beneficial, no?

JSON Schema generation: https://git.drupalcode.org/project/ai_eca/-/merge_requests/1/diffs#288ae...

lammensj → created an issue.

lammensj → created an issue.

phenaproxima → credited lammensj → .

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