php-sdk

Closes #177 Introduce four new interfaces for runtime-defined MCP elements: for dynamic tool registration and execution for dynamic prompt handling for dynamic resource management for URI template-based resources These interfaces enable CMS plugins, database-driven tools, and proxy servers to expose MCP elements without reflection-based parameter mapping. Motivation and Context Framework integrations (Drupal, Symfony, Laravel) need to register capabilities from runtime sources (config entities, database records, external services). The current reflection-based approach requires handlers with positional method arguments, forcing integrators into fragile workarounds. Dynamic providers solve this by separating concerns: / / etc. for capability listing / / etc. for routing / / etc. for execution How Has This Been Tested? Unit tests for all four provider interfaces Unit tests for result formatters Unit tests for completion handler with resource templates All existing tests pass Breaking Changes ~None. This is additive functionality. Existing registration patterns continue to work unchanged.~ RegistryInterface is modified, this is a BC break. Types of changes [x] New feature (non-breaking change which adds functionality) Checklist [x] I have read the MCP Documentation [x] My code follows the repository's style guidelines [x] New and existing tests pass locally [x] I have added appropriate error handling [x] I have added or updated documentation as needed Additional context New builder methods:

Is your feature request related to a problem? Please describe. The PHP MCP SDK supports sampling but lacks elicitation. Without this, servers cannot ask for confirmations, collect configuration, or gather credentials through secure flows. Describe the solution you'd like Implement elicitation per MCP spec (2025-11-25) with two modes: Form Mode: Collect JSON Schema-validated input directly through the client URL Mode: Redirect to external URLs for sensitive data (OAuth, SSO) Relationship to MCP Sampling Elicitation mirrors sampling architecturally—both are server-initiated requests to the client that suspend execution via Fibers until a response arrives. Abstractions Leveraged (no changes): — Fiber-based request/response handling pattern — composition-based tool integration registration — message type discovery Schema base classes — , , Newly Introduced 🆕: — nested capability object (form/url granularity) enum — accept/decline/cancel responses enum — form vs url mode selection Architecture Opportunities Interactive tool workflows (wizards, confirmations) Secure credential collection via URL mode Schema-validated input before tool code runs Describe alternatives you've considered None. Additional context Form schemas limited to flat objects with primitives (per spec) Actions: , , — all must be handled Form mode: no sensitive data; URL mode: no credentials in URLs Error signals URL mode required before retry

Hi! I've been working with Symfony's integration of this SDK through . I think it lacks event support (like a , , ... you get the point). These events would greatly improve observability on the MCP servers, for example to have custom logging or logic triggered by the developers who use the MCP Server. Of course, I thought about implementing this only on the Symfony bundle's side, but then I thought it could be great for the official SDK to have support for a callback logic when something happens; making it easier for implementations of the SDK to introduce events in their ecosystem (EventDispatcher with Symfony as an example). Is this something that can we want to do on the SDK's side? I would be willing to provide an implementation if this issue would be validated.

Add Server Lifecycle Events This PR introduces a comprehensive PSR-14 compatible event system for the MCP PHP SDK, allowing developers to hook into the server's lifecycle for tools, prompts, resources, ping, and initialize operations. This will fix https://github.com/modelcontextprotocol/php-sdk/issues/169 Motivation and Context Currently, there's no standardized way to observe or react to server operations like tool calls, prompt retrievals, or resource reads. How Has This Been Tested? Unit tests added for all new event classes Tests for event dispatching in all handlers (CallToolHandler, GetPromptHandler, ReadResourceHandler, InitializeHandler, PingHandler) Tests cover request events, result events, and exception events All existing tests continue to pass Breaking Changes None. This is a purely additive change. The event dispatcher is optional - servers without an event dispatcher configured will continue to work as before. Types of changes [ ] Bug fix (non-breaking change which fixes an issue) [x] New feature (non-breaking change which adds functionality) [ ] Breaking change (fix or feature that would cause existing functionality to change) [x] Documentation update Checklist [x] I have read the MCP Documentation [x] My code follows the repository's style guidelines [x] New and existing tests pass locally [x] I have added appropriate error handling [x] I have added or updated documentation as needed Additional context New Event Classes Server Events: Fired when client sends initialize request Fired when client sends ping request Tool Events: Before tool execution After successful execution On uncaught exception Prompt Events: Before prompt execution After successful execution On uncaught exception Resource Events: Before resource read After successful read On uncaught exception Full documentation available in .