Contrib.social

Allow simple creation of tools (discuss)

Open on Drupal.org →
Created on 9 April 2025, 3 months ago

Problem/Motivation

This one might be very controversial at first glance, but I think in the new world of MCP this might be a good way of getting Drupal usage up, without necessarily needing to know PHP or Drupal. This issue is very much just for discussion at this time, since MCP is nowhere near production ready.

With MCP (see https://www.drupal.org/project/mcp → ) interoperabiility might actually be a solved concept, because it opens up for business processes (like ECA) and agents (like AI Agents) to talk directly to tools on other systems. So if a company for instance has a Python application that has self documentation, but are using Drupal for documentation, before MCP you could either manually publish updates or create some API on the Python side and some pull mechanism on the Drupal side. While some of this can be done with Feeds/Site Buidling, there might be some generic detail where you need to code and know Drupal.

With MCP you could just generate a tool for it.

MCP in Python for instance does this if you want a multiplcation tool:

@mcp.tool()
def add(a: int, b: int, sidenote: str) -> int:
    """
    Adds two numbers.
    """
    return a + b

MCP tools in nodejs does this

server.tool("add", "Add two numbers", { a: z.number(), b: z.number() }, async ({ a, b }) => ({
  content: [{ type: "text", text: String(a + b) }],
}))

Both are not super simple, but can be setup by someone with rudimental knowledge.

However Drupal tools uses the plugin system at the current time and its quite complex to know where to put files. Say that you want to create a multpilcation tool, you would need to create the file src/Plugin/AiFunctionCall/Multiplicator.php with code like this (and note that this does not do Dependency Injection that makes it way harder):


namespace Drupal\my_module\Plugin\AiFunctionCall;

use Drupal\ai\Attribute\FunctionCall;
use Drupal\Core\Plugin\Context\ContextDefinition;

#[FunctionCall(
  id: 'my_module:multiplicator',
  function_name: 'my_module_multiplicator',
  name: 'Multiplicator',
  description: 'This function adds two numbers together',
  group: 'some_group',
  module_dependencies: [],
  context_definitions: [
    'number_a' => new ContextDefinition(
      data_type: 'integer',
      label: new TranslatableMarkup("Number A"),
      description: new TranslatableMarkup("The first number."),
      required: TRUE,
    ),
    'number_b' => new ContextDefinition(
      data_type: 'integer',
      label: new TranslatableMarkup("Number B"),
      description: new TranslatableMarkup("The second number."),
      required: TRUE,
    ),
  ),
)]
class Multiplicate extends FunctionCallBase implements ExecutableFunctionCallInterface {

  /**
   * The result.
   *
   * @var string
   */
  protected string $result;

  /**
   * {@inheritdoc}
   */
  public function execute() {
    $number_a = $this->getContextValue('number_a');
    $number_b = $this->getContextValue('number_b');
    $this->result = $number_a + $number_b;
  }

  /**
   * {@inheritdoc}
   */
  public function getReadableOutput(): string {
    return (string) $this->result;
  }

}

What if we instead could create the file tools/multiplicator.tool.php

with the following code


/**
  * This tools multiplies two numbers.
  *
  *  @param int $number_a
  *   The first number to multiply.
  *  @param int $number_b
  *    The second number to multiply.
  *
  *  @return string
  *    The returned value.
  */
function my_module_multiplicator(int $number_a, int $number_b): string {
  return $number_a + $number_b
}

The phpdoc might not be obvious to people at the beginning, but it should be easy enough to log when its not following correct standards, so people know why there tool does not show up.

We could make sure that these files are not in the autoloader and only included when used. Discovery would happen on cache similar to plugin system and they would have their own linter system. Multiple tools could be added in one file. They should be able to use Drupal static class abstraction, so do \Drupal::entityTypeManager->... etc.

It would use a Plugin Decorator to actually create the correct plugin code.

This would open up a new world for people that wants to add some smaller logic to Agents or ECA without having to know the whole of Drupal.

Thoughts?

🌱 Plan
Status

Active

Version

1.1

Component

AI Core module

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 3 months ago →
    🇩🇪Germany marcus_johansson
  • Comment 3 months ago →
    🇩🇪Germany marcus_johansson
  • Comment 3 months ago →
    🇩🇪Germany marcus_johansson
  • Comment 3 months ago →
    🇬🇧United Kingdom MrDaleSmith

    TBH I would advise against this: plugins are the Drupal way of doing this and allowing code to be discovered and used by any module that wants to. That you find the system complicated is more of an issue with Drupal than it is with the AI module, and anything you do to "improve" it will be non-standard and therefore confusing to people who are familiar with Drupal.

    I think if you wanted to, a decent compromise would be to have an implementation of the existing plugins that could discover your simplified tools and run them. Otherwise you risk redesigning Drupal from inside contrib and causing unintended issues everywhere.

  • Comment 2 months ago →
    🇦🇹Austria roromedia Linz

    Maybe a bit off topic: From an end-user experience it would be great to have tools which are exposed through a GUI tool browser which would enable non-coders to download pre-made tools similar to the project browser. In an ideal world you could just download the multiplicator tool and enable it through an interface similar to the "Extend" feature for modules.
    My view on this is: If you are able to code a bit - or at least able to code together with an AI-tool you should be able to use a scaffolding code to whip up a simple tool any way - even the Drupal way looks a bit more intimidating than the Python or JS counterparts. For non-coders the GUI-approach would open a whole new world of functionality to them.

  • Comment 2 months ago →
    🇧🇬Bulgaria valthebald Sofia

    PHP port of python MCP SDK https://packagist.org/packages/logiscape/mcp-sdk-php allows something similar:

    https://github.com/logiscape/mcp-sdk-php/blob/5885e4cad09eae9662f9c8e3b7...

     // Create schema with properties and required fields
    $inputSchema = new ToolInputSchema(
        properties: $properties,
        required: ['num1', 'num2']
    );

    // Create calculator tool
    $calculator = new Tool(
        name: 'add-numbers',
        description: 'Adds two numbers together',
        inputSchema: $inputSchema
    );

$server->registerHandler('tools/call', function($params) {
    $name = $params->name;
    switch ($name) {
        case 'add-numbers':
...
  • Comment about 2 months ago →
    🇧🇬Bulgaria valthebald Sofia

    I was thinking... can we combine the best of 2 worlds?
    How hard would it be to create a form for dynamically creating a tool as a Drupal plugin?
    Conceptually, this could be similar to what XB does with the option to create a component on the fly, only much-much simpler.
    The form in question could contain a dynamic list of parameters (name/type/description) + the body field
    The body could include PHP code (simple but potentially dangerous option) or some form of pseudo code - twig/ECA model

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024