Use MCP and function calling in Polyaxon agents
Choose direct function tools or MCP adapters for Polyaxon agents based on reuse, authorization, lifecycle, and execution contracts.
Function calling and MCP answer different questions. Function calling lets a model propose a named operation with structured arguments. MCP provides a protocol through which applications can discover and interact with external capabilities.
Neither choice determines where the work executes. A direct function tool and an MCP tool can both call the same trusted adapter and submit the same Polyaxon workload.
Share one execution contract
Suppose an assistant needs to evaluate a candidate model on an approved dataset. Define an application-level request containing a candidate version, dataset alias, evaluation profile, and request identifier.
Keep the Polyaxon project, queue, credentials, and underlying component selection under server control. The caller requests an approved capability; it does not construct an unrestricted workload.
Both integrations should produce the same result contract: accepted request ID, associated run UUID, normalized status, and a safe summary when the evaluation finishes. This lets you change the tool transport without rewriting the evaluator.
Choose the integration boundary deliberately
| Situation | Practical starting point |
|---|---|
| One application owns the model loop and tools | Direct function-tool adapter |
| Several assistants need the same capability | Shared MCP server |
| Work must survive client disconnection | Durable request service behind either interface |
| A tool needs a long-running workspace | Adapter managing a Polyaxon sandbox service |
| A task is a fixed batch evaluation | Adapter submitting a Polyaxon job |
The MCP specification describes hosts, client connections, and servers with negotiated capabilities. That interoperability can be useful, but it does not remove the need for application-specific authorization or job management.
There is no requirement to route every internal function through MCP. A mixed design can keep local calculations simple while exposing stable shared tools through a server.
Preserve authorization across both paths
The same user should receive the same access decision regardless of transport. Centralize project mapping, permitted dataset resolution, parameter validation, and request limits in the shared adapter.
Use Polyaxon permissions and appropriately scoped credentials for platform access. Check the caller's right to inspect an existing request before returning its run status or artifacts.
Do not allow a tool description, model-generated argument, or retrieved document to replace those decisions. Tool schemas constrain shape; they do not establish ownership.
Keep retries out of the model's guesswork
Persist a request identifier before dispatch and record the resulting run UUID. If submission has an uncertain outcome, reconcile it before creating another run.
For sandbox commands, distinguish a process failure from a transport interruption. Repeating a read-only calculation may be acceptable; repeating a database write requires stronger idempotency guarantees.
Expose explicit outcomes such as rejected, pending, running, failed, and completed. Include evaluation quality separately when a technically successful job produces an unacceptable candidate.
Compare integrations using the same evidence
Run the same tool scenarios through both adapters: valid requests, denied datasets, malformed arguments, cancellation, and lost connections. Record dispatch latency, duplicate submissions, and result correctness with Polyaxon tracking.
These measurements tell you whether the added integration layer improves reuse without obscuring failures. The best choice is the one that preserves a clear execution contract for your application—not the one with the most elaborate protocol diagram.