Support for Complex Model Objects with Constructor Dependencies in Tool Parameters

[narodev]

The MCP Server Bundle currently only supports simple DTO objects with public properties as tool parameters, but fails when attempting to use domain model objects that have constructor dependencies or complex initialization logic.

Current Behavior
When defining a tool with a parameter that has:

Constructor parameters with dependency injection (e.g., UserRepository, EntityManagerInterface)
Complex constructor logic
Private/protected properties with getters/setters
The MCP framework fails to deserialize the JSON input to the object, likely due to reflection-based instantiation that cannot handle dependency injection.

Expected Behavior
The MCP Server Bundle should support:

Service-aware parameter binding - Ability to inject services into model constructors during parameter deserialization
Alternative constructors - Support for static factory methods or named constructors that don't require DI
Custom deserializers - Allow developers to register custom parameter deserializers for specific classes

Example
Working (Simple DTO):

<?php
#[OA\Schema(required: ['root', 'estimated'])]
class CreateUserSchema
{
    public string $root;
    public int $estimated;
}

#[AsTool(name: 'create_user')]
class CreateUser
{
    public function __invoke(CreateUserSchema $schema): ToolResult
    {
        // This works fine
    }
}

Not Working (Domain Model):

<?php
#[OA\Schema(required: ['root', 'approx'])]
class AccountSetup
{
    public function __construct(
        public string $root,
        public int $approx,
        public ?string $mediaCallbackUrl = null,
        public ?string $thumbCallbackUrl = null,
        public ?string $apiKey = null,
        private ?UserRepository $userRepository = null,  // ← DI dependency
        private ?EntityManagerInterface $entityManager = null, // ← DI dependency
    ) {}
}

#[AsTool(name: 'create_account')]
class CreateUser
{
    public function __invoke(AccountSetup $accountSetup): ToolResult
    {
        // This fails during parameter binding
    }
}

Current Workaround
Currently, developers must:

Create separate DTO classes for MCP tools
Manually map DTOs to domain models inside tool methods
Duplicate validation logic and OpenAPI schemas

Impact
This limitation forces developers to:

Maintain duplicate data structures (DTOs vs Domain Models)
Increase code complexity and maintenance burden
Break domain-driven design principles
Duplicate validation and documentation logic
Additional Context
This issue is particularly problematic in DDD-oriented applications where domain models contain business logic and require proper initialization through constructors with dependencies.