modelcontextprotocol / modelcontextprotocol/php-sdk

[Server] Expose request-level metadata (e.g., securitySchema) to tool handlers

Offen
#159 1 Kommentar 1 Reaktion 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Server
Vorherrschende Sprache
PHP
Sterne
1.6k
Forks
173
Ø Merge
2 T. 49 Min.
Gemergte PRs (30 T.)
23

Beschreibung

Is your feature request related to a problem? Please describe.
Tool handlers currently receive only the parameters defined for the tool call.
Metadata included in the request envelope (for example a securitySchema) is not available inside the handler.
This makes it impossible to perform logic that depends on contextual information from the request itself.

Describe the solution you’d like
A way for tool handlers to access the metadata from the incoming request envelope.
This could be done by injecting either the full request object or just the meta section into the handler method.
Having this information available would allow tools to perform authorization checks, tenant selection, and similar context-dependent actions.

Describe alternatives you’ve considered
The only workaround at the moment is extracting envelope metadata before the request reaches the tool dispatching layer and storing it somewhere manually.
Once inside the handler, that information can no longer be accessed in a clean or reliable way.

Additional context
A common use case is reading a securitySchema sent by the client.
This information is part of the envelope, not part of the tool parameters, and is therefore currently inaccessible inside tool logic.

What tool handlers currently look like

use MCP\Server\Attributes\McpTool;

final class ExampleTools
{
    #[McpTool(name: 'example_action')]
    public function exampleAction(string $input): array
    {
        // Only defined parameters are available.
        // Envelope metadata (e.g., securitySchema) cannot be accessed here.

        return ['result' => 'ok'];
    }
}

Proposed Option A — Inject full request object

use MCP\Server\Attributes\McpTool;
use MCP\Types\CallToolRequest;

final class ExampleTools
{
    #[McpTool(name: 'example_action')]
    public function exampleAction(
        string $input,
        CallToolRequest $request,
    ): array {
        $meta = $request->meta ?? null;
        $schema = $meta['securitySchema'] ?? null;

        return [
            'result' => 'ok',
            'securitySchema' => $schema,
        ];
    }
}

Proposed Option B — Inject only the meta section

use MCP\Server\Attributes\McpTool;

final class ExampleTools
{
    #[McpTool(name: 'example_action')]
    public function exampleAction(
        string $input,
        array $meta = [],
    ): array {
        $schema = $meta['securitySchema'] ?? null;

        return [
            'result' => 'ok',
            'securitySchema' => $schema,
        ];
    }
}

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

  1. Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
  3. Forke das Repository und arbeite in einem Branch.
  4. Öffne einen Pull Request, der die Issue-Nummer nennt.

Rechercherichtung

Beginne damit, die Tool-Dispatching-Schicht des Servers nachzuverfolgen und zu untersuchen, wie das eingehende Request-Envelope die Tool-Handler erreicht; das Issue nennt keine bestimmten Dateien oder Tests. Vergleiche das Injizieren von CallToolRequest mit dem Injizieren des meta-Abschnitts und füge anschließend Tests hinzu, die zeigen, dass ein Handler securitySchema lesen kann und dass bestehende Handler, die nur Parameter verwenden, weiterhin funktionieren.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Bewertung

Tech-Stack
php
Bereich
api, backend
Issue-Typ
Feature
Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Aktivitätsstatus
Veraltet
Klarheit
Größtenteils klar
Anfängerfreundlichkeit
35/100

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.