Pass the middlware auth user id into the Tool

[nadar]

I have installed the dev-main because of middlware function, because we need auth in order to change the tools response.

d2c5833

Using StreamableHttpServerTransport with PSR-7 middleware that sets:

class AuthMiddleware
{
    public function __invoke(ServerRequestInterface $request, callable $next)
    {
        // here how can i access this user_id inside a tool?
        $request = $request->withAttribute('user_id', $mySuperDuperUserId);

        $result = $next($request);
        
        return match (true) {
            $result instanceof PromiseInterface => $result->then(fn($response) => $this->handle($response)),
            $result instanceof ResponseInterface => $this->handle($result),
            default => $result
        };
    }

What’s the supported approach to read this user_id inside a Tool handler?

Constraints

• (a) Constructor/DI injection won’t work because the PSR-7 request is per-request and can’t be bound at configuration time.
• (b) Adding a ServerRequestInterface parameter to the handler also won’t work because it becomes part of the Tool’s schema (clients would have to pass it).

[nadar]

@CodeWithKyrian ist this still maintained? if no time or whatever, no problem, just let me know.

[CodeWithKyrian]

Hey @nadar, just replied on #59, that should give some context regarding maintenance and direction moving forward.

About your original question: the dev-main branch already includes a Context object you can inject into tool handlers. That was one of the last features I started working on before shifting focus to the official SDK. If you type-hint the Context in your handler, it won’t appear in the generated JSON schema and it’ll be injected automatically per request, so you have access to the session and the PSR-7 request (for HTTP transports). I don't think I documented it just yet though so my bad!

That should give you a clean path to access user_id or any other request-bound data.

Thanks again for the patience 🙏🏽

[nadar]

@CodeWithKyrian thanks for the response and glad to here the great work continues, even at another place :-)

I did inject the Context object into my tool but get

Tool execution failed: Failed to resolve dependency 'PhpMcp\Server\Context' for 'elements\Content' parameter $context: Failed to resolve dependency 'PhpMcp\Server\Contracts\SessionInterface' for 'PhpMcp\Server\Context' parameter $session: Class 'PhpMcp\Server\Contracts\SessionInterface' is not instantiable (e.g., abstract class or interface without explicit binding).

so this is what i did in the Tool:

class Content
{
    public function __construct(private Context $context)
    {

    }

Do i need to bind it first somewhere?

$container = new BasicContainer();

          $this->server = Server::make()
              ->withServerInfo('MCP', '1.0.0')
              ->withContainer($container)
              ->build();

          // Attribute discovery
          $this->server->discover(
              basePath: __DIR__,
              scanDirs: ['../elements']
          );

          $middlewares = [
              new AuthMiddleware(),
          ];

[CodeWithKyrian]

The type hint goes in the handler method itself, not the constructor.

Thinking about it, I now realize it would be nice to allow constructor injection too (for class-based tools), but for that to work we’d need a way to bind the Context into the container first which currently isn’t wired up. So for now, method-level injection is the supported approach.

Here’s an example using a class-based handler:

use PhpMcp\Server\Context;

class ExampleTool
{
    #[McpTool('example')]
    public function execute(string $title, int $count, Context $context)
    {
        $request = $context->request;
        $userId = $request?->getAttribute('user_id');

        return "User {$userId} sent {$title} ({$count})";
    }
}

And same idea if you’re registering tools via a closure:

$server->withTool(function (string $name, Context $context) {
    return "Hello {$name}, session: " . $context->session->getId();
}, 'another_example');

[nadar]

@CodeWithKyrian this wont work, as the arguments are likely "reserved for the mcp defintion" generator. So if i do the above:

tools won't show up anymore because they can not be registered (at least this is what i think happens, debuging is very hard 😄 )

[CodeWithKyrian]

It should work...give it a try first and let me know if you run into anything.

During schema generation for MCP clients, that parameter gets stripped out, so it won’t appear in the expected properties when the tool is called. When the tool actually runs, we inject that parameter along with whatever other arguments are passed in.

[nadar]

i tested already here the function (stripe not needed infos)

class Content
{
    public function __construct(private Application $app)
    {

    }

    #[McpTool(
        name: 'content.search',
        description: "Search content entries across by (partial) title. Supports pagination via limit/offset.
        Example:
        content.search({ \"query\": \"dog\", \"limit\": 10, \"offset\": 0 })"
    )]
    public function searchContent(
        #[Schema(type: 'string', description: 'Free-text query to search for (matches title).')]
        string $query,
        #[Schema(type: 'integer', description: 'Maximum number of results to return (1–100).', minimum: 1, maximum: 100)]
        int $limit = 20,
        #[Schema(type: 'integer', description: 'Number of results to skip (for pagination).')]
        int $offset = 0,
        Context $context
    ): array {
        


        return ['dummy array of content']
    }

and here now i can connect but i don't see tools anymore, if just remove the context param from function it will all work again:

all hint i get is this invalid message syntax when hitting run

so all i added is this context param it nothing works anymore :-/ i use attribute discovery, maybe that changes things?

// Attribute discovery
$this->server->discover(
basePath: DIR,
scanDirs: ['../elements']
);

[nadar]

Spent some more hours on this. using

->withTool([Content::class, 'searchContent'])

it seems to work, also error handing is better. because in this case context must be optional attribute because of attribute ordering:

public function searchContent(
        #[Schema(type: 'string', description: 'Free-text query to search for (matches title).')]
        string $query,
        #[Schema(type: 'integer', description: 'Maximum number of results to return (1–100).', minimum: 1, maximum: 100)]
        int $limit = 20,
        #[Schema(type: 'integer', description: 'Number of results to skip (for pagination).')]
        int $offset = 0,
        ?Context $context = null
    ): array {

[nadar]

@CodeWithKyrian so injecting into constructor would be very nice indeed, also when bundling tools into a single php file to group them.