[McpBundle] Compiler pass for tools

[TomHart]

Q	A
Bug fix?	no
New feature?	yes
Docs?	yes
Issues	N/A
License	MIT

Add a Compiler Pass to find tools and register them in the ToolChain

[chr-hertel]

Thanks @TomHart for working on this - this will def improve the usability with the bundle 👍
i left some comment and i think it would be great to rebase this on #165 - will merge that PR after some tests

[TomHart]

You're welcome @chr-hertel. I believe I've address everything you mentioned if you'd like to take another look whenever you have time.

[OskarStark]

Could be a follow up PR, but I would like to have an attribute for this like in the agent

[TomHart]

@chr-hertel my bad on missing the strict types, updated now and rebased into 1 commit

[stof]

this is not the right recommendation IMO:

• AutoconfigureTag (like all Autoconfigure* attributes) is about defining an autoconfiguration rule applying on all child types (its original intent is to be used on interfaces). Recommending to use it to apply a tag on a service directly is a bad idea, as it can have unintended side effects for non-final classes (as it will also impact autoconfigured services defined with child classes)
• if the goal is to automatically tag autoconfigured services implementing ToolExecutorInterface with the mcp.tool to make it simpler for projects adding a custom tool, the solution is for the MCP bundle to register an autoconfiguration rule for ToolExecutorInterface, so that projects only need to implement the interface and be done with it.

[chr-hertel]

I was thinking of using the attribute because it's currently hard to decide which interface is the right indicator for the tag here

@Nyholm, it would be the Symfony\AI\McpSdk\Capability\Tool\IdentifierInterface, right?

[stof]

you could always define a mcp.tool_chain service using a tagged iterator, and then defining a ToolExecutorInterface alias pointing at it (which projects can still override if they don't want to rely on the tool chain).
There is no need for this compiler pass IMO.

[TomHart]

Sorry for the slow response, I've had tonsillitis so took some time to recover. So if I've understood correct (as some of these things are new to me), I'd create a definition of

    mcp.tool_chain:
        arguments:
            $executors: !tagged_iterator mcp.tool

    Symfony\AI\McpSdk\Capability\Tool\ToolExecutorInterface: mcp.tool_chain

And then apply the AutoconfigureTag attribute to the IdentifierInterface class, providing @Nyholm confirms that's the correct one to target.

is that correct @chr-hertel @stof?

[chr-hertel]

@TomHart no worries at all, hope you're well again 🤞

You are correct here, two things are needed a) registering based on the IndentifierInterface and b) injecting the collection into the chain implementation

For a) we can't simply add the AutoconfigureTag attribute tho, since that class lives in a different lib than the bundle - the trick here could be, to use the registerForAutoconfiguration() method for than in McpBundle, see https://symfony.com/doc/current/service_container/tags.html#autoconfiguring-tags

For b) i think you could just move the service definition from the compiler pass into the bundle class as well and use tagged_iterator('mcp.tool') for injecting the tools

[TomHart]

I've changed it around now. I couldn't get it working with the instanceof autoconfigure, it just never picked anything up for some reason. Could you take another look now and see what you think?

Not sure why PHPUnit is failing, could it be re-tried to just see if it's a blip?

Finally, had to change from array to iterable for tagged_iterator to work, if that's a problem to change I can see if there's any other solutions

[chr-hertel]

Looks good to me now, can you please rebase - I just merged #165

[TomHart]

Amazing! Done!

[chr-hertel]

Looks good & works! :)

[chr-hertel]

Thank you @TomHart.

[TomHart]

@chr-hertel what's the best way to find the best priority issues to work on?

[chr-hertel]

If you're up for something to just on, I'd always point to #16. I think Stores we're quite good progressed lately, but there are quite some Platforms that only are a draft, like OpenRouter or Replicate, but also some missing completely, like Deepseek or Perplexity.

One of my priority topics would be #167 - feel free to have a look at that PR and open PRs against that.

And other than that, the Store component has two extension points that could use some love, especially the Symfony\AI\Store\Document\LoaderInterface could use more implementations. Currently it's only a TextFileLoader, but could also be a PdfLoader, an RssLoader, an HtmlLoader, etc ...

Happy to guide you more if you tell me what's interesting to you :)