Connect MCP servers to Polyaxon workflows
Design application-owned MCP tools that submit and inspect Polyaxon workflows while preserving authorization, bounded inputs, and run-level evidence.
An MCP server can give an assistant a consistent interface to a useful platform operation: submit an evaluation, inspect its status, or retrieve a sanitized report. The important design choice is what that interface permits—not simply whether the assistant can call it.
For Polyaxon, start with a small application-owned adapter around documented client operations. This is an integration pattern, not a claim that Polyaxon includes a native MCP server.
Keep the protocol and platform roles separate
The MCP architecture separates a host, its client connections, and servers exposing tools, resources, and prompts. The protocol supplies a shared interaction model; your server still needs to implement the requested operation and its access checks.
A Polyaxon adapter might expose three tools:
| Tool | Input | Result |
|---|---|---|
| Submit an approved evaluation | Dataset alias and candidate version | Application request ID and run UUID |
| Inspect evaluation progress | Authorized request ID | Normalized status |
| Read an evaluation summary | Authorized request ID | Redacted result and artifact reference |
Avoid a first version that accepts arbitrary Polyaxonfiles, queue names, or credentials from the model. A narrow contract is easier to authorize and evaluate.
Resolve identity before dispatch
Authenticate the caller using the transport and identity system selected for your MCP deployment. Then map that identity to permitted Polyaxon projects and operations in trusted server code.
The model should not choose a more privileged project by changing a tool argument. Resolve human-friendly dataset aliases to approved versions, reject unknown fields, and cap input size before creating a run.
Use the RunClient interface to submit a reviewed component or inspect its execution. Scope the adapter's platform credentials to the work it is intended to perform. Do not forward unrelated caller tokens into the workload.
Use asynchronous results for substantial work
An evaluation may wait for capacity or take several minutes. Return an application request identifier after successful submission, and let a separate tool inspect progress. This avoids tying a long-running job's lifecycle to one client connection.
Persist the association between the request and run UUID. If the connection drops after submission, a retry should find the existing request rather than create duplicate work. Implement that deduplication in the adapter's durable request store.
Treat Polyaxon terminal status and evaluation quality separately. A job can complete successfully while reporting that a candidate missed the quality threshold. Decide whether your evaluator should exit unsuccessfully for that condition or return a separate promotion decision.
Expose evidence instead of raw execution surfaces
Use tracking and artifacts to preserve the evaluation inputs, metrics, and report. The MCP result can summarize those records without copying a large or sensitive artifact into the model context.
Treat report text and tool output as untrusted content. A retrieved document may contain instructions, but those instructions do not gain authority over the adapter's policy.
If the server itself runs as a Polyaxon service, implement and verify its MCP transport, authentication, and proxy-path behavior in your application. Hosting a service does not automatically make every MCP client compatible.
Begin with a read-only status tool and one bounded submission path. That gives the team a useful integration with a clear review surface before expanding the available capabilities.