Consume Platform-governed MCP skill endpoints as Maestro tool sources

[haasonsaas]

From the Maestro/platform integration review using gh on 2026-04-22.

Reviewed heads:

• ae6e88a
• evalops/platform@7b003938349939052f90ae41241599993a7c06c9

Problem

Maestro can bridge MCP tools locally, while Platform is growing agent-mcp, governed skill bundles, policy checks, and metering. Platform has issues for exposing skills as policy-gated MCP endpoints, but Maestro does not yet have a consumption issue that turns those endpoints into the default controlled tool plane.

Scope

• Add Platform MCP registry/endpoint discovery to Maestro's MCP/tool registration path.
• Register selected Platform skill endpoints as namespaced Maestro tools with stable capability metadata, skill ids, versions, and provenance.
• Forward EvalOps workspace/session/run headers while preserving upstream-owned Mcp-Session-Id semantics.
• Surface policy, approval, auth, and rate-limit denials as structured tool results and events rather than generic tool crashes.
• Attach skill/tool identifiers to tool telemetry, wide turn events, meter payloads, and future maestro.events.skill.* / maestro.events.tool_call.* events.
• Keep existing local MCP configuration working for non-Platform users.

Acceptance Criteria

• A Maestro config can load at least one Platform-governed MCP skill endpoint and invoke it through the normal tool path.
• The invocation carries workspace/session/run correlation fields into Platform agent-mcp.
• Denied or approval-required tool calls are visible in Maestro UI/headless output and publish correlated telemetry/events.
• Tests cover local MCP only, Platform endpoint success, and Platform endpoint denied/unavailable cases.

Related: evalops/platform#717, evalops/platform#740, evalops/platform#748, evalops/platform#763, evalops/platform#765, #49, #73.

[haasonsaas]

Cross-linking from the integration tracker:

• Platform skill endpoints: evalops/platform#717
• Platform agent-mcp hosting backend: evalops/platform#740
• Policy decisions and denials: Route Maestro approvals, sandbox, and firewall decisions through Platform policy services #73 and evalops/platform#748
• Tool/skill call event fields and subscribers: evalops/platform#762, Publish Maestro telemetry as typed CloudEvents onto platform's event bus #49, evalops/platform#763
• Prompt/skill outcome loop that should consume these skill ids and results: Close the Platform prompt and skill learning loop in Maestro #75

Implementation note: preserve upstream-owned Mcp-Session-Id; forward EvalOps correlation via EvalOps headers/session metadata.

[haasonsaas]

Cross-linking from the hosted remote-server hardening pass:

• Bind headless remote sessions to explicit workspace sandboxes #77 should provide the session workspace/sandbox root that governed MCP skill tools must inherit, rather than allowing tool/context resolution from the Maestro server process cwd.
• Make headless runtime fleet-safe across Maestro web replicas #78 matters for long-lived remote MCP/tool sessions because runtime ownership and event/callback routing need to be stable across replicas.
• evalops/platform#780 should pass the same workspace/run/principal correlation into Maestro headless when it drives these tools from Platform.

This issue remains the Platform-governed tool-source work; #77/#78 define the hosted remote execution boundary it should respect.

[haasonsaas]

Stale triage (2026-07-19): platform MCP/skill consumption path still open (architecture-review). Keep as integration backlog.