Contrib.social

Create Base Tools

Open on Drupal.org →
Created on 7 June 2025, 29 days ago

Problem/Motivation

Right now its very hard to make a generic tool that isn't a big security risk, when used wrong, which will be prone to happening. That's why we put some of the current tools in an experimental module.

ECA will be used and a very powerful way of creating extremely busines specific tools, but there are also tools where we know what it should be, but it needs an configuration.

Think of the following tool - the content entity seeder. Its a tool that can be used to create or edit any content entity. This is fine if you use the features to lock it down via forced parameters, however there will be someone who sets it up without it. They might prompt that it should be used to be able to save comments via the chatbot. However via simple prompt injection you would then be able to create a user with administration rights. In this case the entity type (and bundle) should be required to fill in.

The second problem is that we might want to make generic versions of some functionality that is for instance missing a clear permission system. Say that we want a plugin manager definition listing tool - to load the definitions, you usually don't need an permissions - its the code using it that should set that. But with an agent you might want to for instance have an agent that can show field types on a websites when you have specific roles, but otherwise not. The permissions should in that case be required that you lock in to a permission.

So what we need is a system where you can create deriatives from a base tool and the tool creator can pick what are parameters the AI can answer and what are parameters that are configured.

Proposed resolution

  • Create an extension of ExecutableFunctionCallInterface that is called BaseFunctionCallInterface, that extends PluginFormInterface and ConfigurableInterface.
  • By default, any parameter that the FunctionCallInterface sets as context values, can be configured for a deriative.
  • Add a method called disallowedParameters that return an array of Context keys. Anything set there should not be able to be configured.
  • All the inherited configuration methods should be used to set up any required settings - in the case of the Content Entity Seeder, that would be at least the entity. With the Plugin Manager Definition Tool that would be the permissions (at least).
  • For the buildConfigurationForm and submitConfigurationForm they should build and save the form for the Context parameters so its there by default and also can be inherited via parent.
  • Create a PluginDeriative that makes these available and make the configuration available when you run the execute function.
  • Create a configuration entity that stores the different configurations.
  • Make a listings page for deriative tools from base tools.
  • Make a form where you can setup the tools based on a base tool - this could just be a list of base tools and then have ajax load the buildConfigurationForm.
  • Make it possible to delete deriative tools.

Remaining tasks

After this is done, we need to look into the UI/UX, so its easy to create this tools.

User interface changes

API changes

Data model changes

✨ Feature request
Status

Active

Version

1.2

Component

Code

Created by

🇩🇪Germany marcus_johansson

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @marcus_johansson
  • Comment 28 days ago →
    🇩🇪Germany marcus_johansson

    The kicker standout with such a tool will be the Views base tool - no other CMS, CMS, framework or AI workflow runner will have anything close to it in case of adaptability, security and flexibility.

  • Comment 20 days ago →
    🇮🇳India anjaliprasannan
  • Comment 17 days ago →
    🇮🇳India anjaliprasannan
  • Comment 12 days ago →
    🇩🇪Germany marcus_johansson

    So here are four examples of what this should/could solve:

    Rag Search

    Everytime someone adds a RAG index, it will automatically create a tool for that index with a default value of finding 10 items over 0.3 min score with entity permissions enabled.

    But you should also be able to setup versions of this where you:

    • pick the index (required)
    • pick how many items to choose (optional - LLM will pick otherwise)
    • pick the min score (optional - LLM will pick otherwise)
    • turn of entity permissions (optional - will be on by default, with clear description when it makes sense to turn it off for performance reasons)

    Entity Creation/Update

    This should probably not be generated automatically, but need a active decision, where you:

    • pick the entity type (required)
    • pick the bundle (required if bundelable)
    • pick the operations create and/or edit (required)
    • pick the fields (required, but has to show required fields, on create)

    This means that you can create an entity publisher, or an entity change one specific flag tool, but also a full entity creation tool.

    Plugin Definitions

    This should not be generated automatically, but needs an active decision, where you:

    • pick the plugin manager (required)
    • pick the permissions (required) - this might need flexibility to say for instance, that any "Change fields on entity type X" is approved
    • pick the attributes to show (required)
    • pick the output method like csv, yaml (required)

    Flush the cache(s)

    This should not be generated automatically, but needs an active decision, where you:

    • pick the cache buckets or all (required)
    • pick the permissions (required)
  • Comment 11 days ago →
    🇬🇧United Kingdom yautja_cetanu

    I think the important thing with entities is that it should be very obvious when you create a new content type and bundle that you can make a tool for it with a permission. Something like

    - Create an AI Tool for Agents to interact with this entity.

  • Comment 11 days ago →
    🇩🇪Germany marcus_johansson

    @yautja_cetanu - yup, but I think for 1.2.0 we should ship the functionailty with a plain form and in 1.3.0 fix the UX/UI for it?

    Otherwise it will take a long time to get a release out, and having the possibility for more advanced developers to already start shipping tools rather soon, would be nice.

  • Comment 6 days ago →
    🇺🇸United States Kristen Pol Santa Cruz, CA, USA

    We are doing some issue management housekeeping and adding/removing components.

    We are removing the "Code" component and want people to categorize issues with the best module/submodule component.

    Moving this issue to "...to be triaged" to decide on priority, etc.

    See 📌 Update AI module project components Active for more details.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024