[MCP Bundle] Migrate from symfony/mcp-sdk to official mcp/sdk

[camilleislasse]

Q	A
Bug fix?	no
New feature?	yes
Docs?	yes
Issues	Fix #526
License	MIT

Summary

This PR migrates the MCP Bundle from the internal symfony/mcp-sdk to the official mcp/sdk package and completely removes the internal MCP SDK component.

Changes

Remove Internal MCP SDK

• Deleted entire src/mcp-sdk/ directory
• Removed dependency from symfony/mcp-sdk to mcp/sdk
• Updated all references in documentation and configuration files

MCP Bundle Migration

• Dependency change: symfony/mcp-sdk → mcp/sdk in composer.json
• Server creation: Refactored to use Server::make() builder pattern
• Service configuration: Simplified using official SDK patterns

New MCP Capabilities Support

• Attribute-based discovery: Added support for #[McpTool], #[McpPrompt], #[McpResource], #[McpResourceTemplate]
• Compiler passes: Created McpToolPass, McpPromptPass, McpResourcePass, McpResourceTemplatePass
• Autoconfiguration: Automatic service tagging and registration

Bundle Enhancements

• EventDispatcher integration: Added Symfony EventDispatcher for MCP SDK events
• Dedicated logger: Added monolog.logger.mcp service
• Configuration options: Added pagination_limit and instructions parameters
• Route loading: Fixed RouteLoader registration for SSE transport

Demo Application Updates

• Added new MCP examples:
  • CurrentTimePrompt.php - Prompt capability
  • CurrentTimeResource.php - Resource capability
  • CurrentTimeResourceTemplate.php - Resource template capability
• Updated tool implementation: Migrated CurrentTimeTool.php from interface to attribute
• Enhanced configuration: Added pagination_limit, instructions

Documentation

• rewrite of doc/index.rst with examples for all capability types
• Event system documentation with listener examples
• Logging configuration guide
• Updated README and CHANGELOG to reflect official SDK usage

Testing

• Added tests for all compiler passes
• Updated bundle tests for new configuration options
• Added EventDispatcher test coverage

Breaking Changes

• Tool definition: Use #[McpTool] attribute instead of implementing interfaces
• Dependency: Replace symfony/mcp-sdk with mcp/sdk in composer.json

Code Examples

Before (interface-based):

class Tool implements MetadataInterface, ToolExecutorInterface {
    public function call(ToolCall $request): ToolCallResult {
        return new ToolCallResult($result);
    }
    public function getName(): string { return 'tool-name'; }
}

After (attribute-based):
class Tool {
    #[McpTool(name: 'tool-name')]
    public function execute(string $param): string {
        return $result;
    }
}

New capabilities:
#[McpPrompt(name: 'analysis')]
public function getPrompt(): array { ... }

#[McpResource(uri: 'data://current', name: 'current-data')]
public function getResource(): array { ... }

#[McpResourceTemplate(uriTemplate: 'data://{id}', name: 'data-by-id')]
public function getTemplate(string $id): array { ... }

[chr-hertel]

Awesome, thanks for working on this - minor comment for now - on top I wonder about registering the capabilities correctly to the registry via DIC - but I'm only on my phone - could be a follow up anyways 👍

[camilleislasse]

@chr-hertel What do you think of this approach:

// Interface
interface McpToolInterface {}

// Autoconfiguration  
$container->registerForAutoconfiguration(McpToolInterface::class)->addTag('mcp.tool');

// CompilerPass
$taggedServices = $container->findTaggedServiceIds('mcp.tool');
foreach ($taggedServices as $id => $tags) {
    $container->getDefinition($id)->setPublic(true);
}

In SDK's ReferenceHandler::getClassInstance()

  private function getClassInstance(string $className): object
  {
      if (null !== $this->container && $this->container->has($className)) {
          return $this->container->get($className); 
      }

      return new $className();  
  }

Our CompilerPass makes services public so the SDK's ReferenceHandler can use Symfony's DIC.

[chr-hertel]

Goal would be to use the attributes, that are already around in the SDK - and we can use a service locator to skip making the public

[camilleislasse]

Goal would be to use the attributes, that are already around in the SDK - and we can use a service locator to skip making the public

I'm not entirely sure we need to go through the mcp.tool tag intermediate step.

Currently the flow is:

1. #[McpTool] attribute → auto-tagged as mcp.tool
2. Compiler pass finds tagged services → creates Service Locator

We could potentially scan for #[McpTool] attributes directly in the compiler pass instead of using tags.

Pros

• Separation of concerns between autoconfiguration and service locator creation
• Allows manual tagging if needed
• Built-in debuggability with debug:container --tag=mcp.tool

Pros of direct attribute scanning:

• One less intermediate step
• More direct connection between attribute and service locator

[OskarStark]

I started some work here #460 (mostly vibe coding, so maybe ignore the code changes), but check the docs and namespace changes, maybe it can help you.

[OskarStark]

You should also remove the symfony/mcp-sdk completely here in this PR

[OskarStark]

is this the right class?

[camilleislasse]

Better to use maybe Symfony\Component\Routing\Exception\LogicException ?

In CLAUDE.MD :

Use project specific exceptions instead of global exception classes like \RuntimeException, \InvalidArgumentException etc.

[camilleislasse]

15792ed

[camilleislasse]

Could you please do a complete review? I've added in addition to the tool :

• prompts, resources, resourceTemplates support (but resourceTemplates not implemented yet in sdk)
• dedicated MCP logger
• Symfony event integration
• pagination/instructions configuration

Feels like I'm going in all directions 😅 I'm not really sure what the bundle should handle vs what the SDK should handle.

[chr-hertel]

Two things, besides the rebase, make sense still:

• Replacing SSE with HTTP, since we merged [Server] Rework transport architecture and add StreamableHttpTransport modelcontextprotocol/php-sdk#49
• the setContainer in the passes always replaces the container - does it work to have prompts and tools in parallel?

[camilleislasse]

a34e6c4

[chr-hertel]

Thanks @camilleislasse for kicking this off - will merge it now and we can iterate for leveling up 👍

[chr-hertel]

Okay, we'll need to wait for modelcontextprotocol/php-sdk#79, but let's work with new PRs on top of this - instead of making this bigger.

[chr-hertel]

Thank you @camilleislasse.