Skip to main content
​
v4.14.0 Beta
Hand an agent one endpoint instead of a list of MCP Servers, and decide centrally which tools it is allowed to reach. The MCP Gateway fronts any number of MCP Servers as a single governed endpoint, so approval, access, and audit are settled once for the workspace rather than per agent.MCP Gateway overview with tool call, success, and error counters above a call outcome chart and a leaderboard of the most used tools
  • One package of approved tools: Link several MCP Servers to one gateway and expose all of their tools, only the ones selected, or none. Exposure is per server, can be marked read only, and colliding tool names are prefixed with the server key.
  • Scoped to selected projects: A gateway is shared with every project in the workspace or only with selected projects, and new projects can be granted access automatically as they are created.
  • Every tool call is recorded: Each call is logged with its exposed and upstream tool name, status, latency, and the token behind it. Denied calls are stored as denied, so a refusal is auditable instead of invisible.
  • One URL for any client: /v3/mcp/{workspace_key}/{gateway_key}/mcp serves coding agents and production agents alike. Code Mode gives a compact discovery and execution surface for large catalogues, and Direct Mode exposes each upstream tool as it is.
Set up a gateway from the MCP Gateway guide.
​
v4.14.0
Stop configuring an entire workspace for the sake of one project. A Routing rule now carries the controls that used to be workspace-wide switches, so redaction, scrubbing, caching, and tracing apply to exactly the traffic a rule matches and to nothing else.Create Routing Rule form with a load balancing strategy, an enable cache option, and Response Healing and PII Redaction listed as plugins
  • Enforce plugins on matched traffic: Attach PII redaction, trace scrubbing, or response healing to a rule. Redaction takes the entities to mask, a confidence threshold, and whether a failure blocks the request or lets it through.
  • Match on what the request carries: Build conditions from Header, Model, Identity, Metadata, and Project, nested into groups joined with and or or. Rules are evaluated in priority order, and a rule is either workspace-wide or scoped to a single project.
  • Load balancing is optional: A rule no longer has to name models, so a rule that exists only to enforce a plugin or a cache needs nothing more. When it does route, pick fallback, latency based, weighted, or round robin.
  • Tracing per rule: Decide whether matched requests are traced rather than tracing all traffic or none of it.
Build rules from the Routing rules guide.
​
v4.14.0
Check whether a response actually followed the instructions it was given, and see exactly which tool an Agent reached for. Evaluators gain a set of input.* and output.* variables that address individual messages, tool calls, and retrievals.Evaluator prompt editor listing each input and output variable with its description, beside a panel showing the variable source as JSON
  • Evaluate against the instructions: {{input.system_instructions}} gives the judge the instructions the run actually used, so “did it follow its instructions” becomes a question an Evaluator can answer. There was no way to ask it before.
  • Check the tool, its arguments, and its result: {{output.tools_called[0].name}}, {{output.tools_called[0].arguments}}, and {{output.tools_called[0].output}} single out one call, so a judge can confirm an Agent picked the right tool and passed the right values.
  • Reach any message in the conversation: {{input.all_messages[0].content}} and {{input.all_messages[-1].role}} address messages by position, and the list now includes the turn being evaluated rather than stopping short of it.
  • Ground answers in what was retrieved: {{input.retrievals}} and {{input.retrievals[0]}} put retrieved context in front of the judge for faithfulness checks, and custom values passed into a run arrive under their own name.
Existing log.* variables keep working, so Evaluators built before this release are unaffected. See the Evaluators page for each variable’s nested structure.
​
v4.14.0
  • MCP Portal: MCP Servers and MCP Gateway share one area in Studio with tab navigation. The earlier MCP Tool type is retired, so an MCP connection is managed from the portal rather than from a tool.
  • Guardrail and Evaluator indicators in Traces: Every Trace screen shows which Guardrails and Evaluators ran on a span.
  • Time range selector in Traces: Pick a quick range or set explicit start and end dates when narrowing down a window.
  • OpenAI Codex sessions as Traces: Codex sessions are captured as Traces, and Python Vercel AI instrumentation is supported alongside them.
  • CLI onboarding in Studio: The getting started flow offers a CLI path in addition to the in-product one.
  • Search by id: Entity search resolves a raw id, so an id pulled from a log or a Trace leads straight to the entity.
​
v4.14.0
  • Model Garden: The intelligence index is a visible column and a filterable attribute, and models can be filtered by price.
  • Evaluators: An invalid Python evaluator reports its error location inline instead of failing only at run time.
  • Management keys reach MCP: A management key can be granted access to MCP Servers and MCP Gateway.
  • Account safety rails: A member cannot change their own role or remove themselves from a workspace, enforced in the API rather than only hidden in the UI.
  • Identities across the platform: Identities are shown consistently wherever an entity is attributed to one.
​
v4.14.0
New additions to the Model Garden. Browse details on the Supported Models page.Every model NVIDIA serves is free to call. DeepSeek V4 gains time-based pricing variants.
​
v4.14.0
  • Router streaming and responses: Tool call id and function name are sent once rather than repeated on every delta, which unblocks OpenAI-spec stream parsers, and /v3/router/responses reports the model that actually answered after a fallback fires rather than the failed primary.
  • Documents survive multi-turn calls: A URL-source document is persisted on a stored conversation instead of being dropped on the second turn, and /v1/messages keeps URL-source document blocks instead of rejecting the request.
  • Knowledge Bases: Hybrid search no longer scores keyword-only hits at exactly 0, search inherits the configured retrieval type when search_type is omitted, filter_by with exists works in both directions, rerank_config bounds are enforced on update as well as create, agentic_rag_config is persisted, and a missing BYOK key produces a clear message instead of a vague “Invalid embedding model”.
  • Datasource ingestion unblocked: File-based datasources leave the queued state, and the Datasources page reports accurate pagination and chunk status.
  • API key scope: Memory store listing respects the API key’s project scope, and Trace query endpoints require a permission that can be granted from the API Keys UI.
  • Evaluators: Playground runs generate a Trace, a PATCH with null categorical labels no longer wipes them, and responses include output_type and categorical_labels.
  • Experiments: Agent instructions stay visible in the review pane, total tokens and presence penalty render without a page refresh, and cache_control on a prompt or model column reaches the provider, so a long static prompt is cached across an experiment run on models that support manual cache control.
  • Onboarding and sign-in: Threads and Traces generate for new workspaces, SSO admits pre-existing accounts that are not yet workspace members, duplicate SSO configurations are rejected, and entering a login code shows a loading indicator.
  • Prompts and Datasets: Prompts can be duplicated again, an output guardrail no longer silently disables model fallbacks, CSV import works, and deleting the last row on a page no longer strands the user on an empty page.