NVIDIANVIDIA-Certified Professional: Agentic AI2026-102.3 Build and connect custom tools, APIs, and functions for external system interaction.
Publish and select remote MCP tools
Completed by the knowledge check
Learning objective
Expose and consume tools through MCP servers and clients.
Core idea
Model Context Protocol (MCP) gives a host application a standard way to discover and invoke tools supplied by a server. The host decides which capabilities the agent can use; the server owns their implementation and downstream access. Discovery makes a capability visible, not automatically trustworthy or authorized.
See 1.3.1 for choosing MCP rather than A2A, and 2.3.1–2.3.2 for interface design and adapter enforcement. Here the decision is how to publish and consume that interface across a process or network boundary. You must align the exposed tool set, transport, authentication support, and protocol revision on both sides.
How it works
Publish a deliberate subset
NVIDIA NeMo Agent Toolkit’s MCP integration requires the nvidia-nat-mcp package; the documented optional installation is uv pip install "nvidia-nat[mcp]". For the MCP SDK server runtime, nat mcp serve --config_file WORKFLOW_CONFIG publishes functions from a workflow. Replace WORKFLOW_CONFIG with the path to the configuration you intend to expose.
The documented server defaults are localhost, port 9901, and the /mcp endpoint using streamable-http. These are local integration defaults, not a production access-control policy. Both the workflow and its tools are published: exposing the agent as one coarse tool also exposes its internal LLM loop, token cost, and latency. Choose that delegation intentionally, or use --tool_names to publish only individual functions.
nat mcp serve has no built-in server authentication, including over Streamable HTTP. For a protected shared deployment, put it behind an authenticating reverse proxy with HTTPS and prevent callers from bypassing that proxy. Client credentials alone do not protect an unconfigured server. The alternative FastMCP runtime supports server_auth bearer-token validation, but its nvidia-nat-fastmcp package depends on beta FastMCP3 and NVIDIA does not recommend it for production.
Discover before configuring the consumer
Use nat mcp client tool list --url http://localhost:9901/mcp to inspect the published names. Add --tool TOOL_NAME to inspect a particular tool’s description and input schema, replacing TOOL_NAME with an actual discovered name. The toolkit’s example publishes names such as calculator__multiply: do not assume a Python callable name is the exact remote identifier.
At the protocol level, revision 2026-07-28 uses tools/list for discovery and tools/call with name and arguments for invocation. Tool definitions carry inputSchema and may carry outputSchema.
An ordinary completed result carries resultType: "complete", with structured data in structuredContent. If a tool publishes outputSchema, its server must return conforming structured results, and clients should validate them. These are protocol requirements; verify the deployed integration’s supported revision before depending on them.
Consume tools as a function group
The toolkit represents a remote tool set with function_groups and _type: mcp_client. This configuration fragment selects a local illustrative server’s lookup tool:
function_groups:
catalog_tools:
_type: mcp_client
server:
transport: streamable-http
url: "http://localhost:9901/mcp"
include:
- lookup_material
tool_call_timeout: 5lookup_material is an application-defined example; replace it with the server’s discovered tool name. A compatible agent workflow includes catalog_tools in its tool_names. The include list narrows which discovered capabilities the group exposes. The client also documents exclude and tool_overrides, including aliases and replacement descriptions.
Aliases and descriptions change the agent-facing interface; client filters do not enforce server authorization.
Align transport and failure handling
The client supports stdio for local subprocess communication, streamable-http for HTTP access, and sse for compatibility. For stdio, configure server.command and its arguments. For HTTP transports, configure server.url. NVIDIA documents server.auth_provider only for streamable-http. For user-facing protected services, its recommended pattern is per_user_mcp_client with a per-user workflow such as per_user_react_agent, using an authentication entry with _type: mcp_oauth2. Point server.auth_provider to that entry. For headless backend workflows, choose _type: mcp_service_account instead. These are client-side mechanisms; the Authentication Provider API is experimental and may introduce breaking changes.
When discovery fails, check that the server is reachable and that client and server transports match. If the toolkit reports missing MCP client functionality, install the MCP optional package. If a tool is absent, inspect the server’s --tool_names filter and the client’s include/exclude lists before changing the agent’s prompt.
The client defaults to tool_call_timeout: 60 seconds, max_sessions: 100 concurrent session clients, and session_idle_timeout of one hour. Budget session resources alongside per-user instances and tune idle cleanup under load. A five-second lookup needs a shorter call timeout; timing out does not prove a mutation failed to commit.
The protocol distinguishes JSON-RPC errors, such as an unknown tool, from tool execution errors returned with isError: true. Receiving a well-formed result does not mean the business operation succeeded. Make the host inspect the error outcome before presenting the returned text as a completed task.
After discovery, the host distinguishes what one tools/call returns: a JSON-RPC error, a tool execution error, or an ordinary completed result.
Key distinctions and trade-offs
Choose the transport by its communication and support boundary:
| Transport | Deciding condition | Toolkit mechanism | Cost or limitation |
|---|---|---|---|
| Standard I/O | Host starts a local tool process | server.transport: stdio, server.command | Host owns process deployment and lifecycle |
| Streamable HTTP | Shared or protected remote service | server.transport: streamable-http, client server.auth_provider, HTTPS authenticating proxy before nat mcp serve | Client credentials require server-side validation; transport alone supplies none |
| HTTP+SSE compatibility transport | Existing integration requires that transport | server.transport: sse, matching server transport | No toolkit SSE authentication; deprecated since MCP 2025-03-26 |
Tool exposure, tool selection, and permission are different controls. --tool_names limits server publication; include limits client registration; downstream authorization determines what the authenticated caller can actually do. A server-provided description or annotation is not a substitute for that authorization.
Architecture / decision scenario
A construction firm’s materials assistant must share a catalog service across six estimating applications. Its local prototype exposes 40 workflow tools, including purchase-order creation. Production estimating needs only three read capabilities and has a five-second lookup budget; purchasing belongs to a separately authorized workflow.
The platform owner puts nat mcp serve behind an HTTPS authenticating reverse proxy that validates OAuth2 credentials, with no direct client access to the backend. It publishes only the three catalog functions with --tool_names, excluding the whole agent. Each user-facing application pairs per_user_react_agent with per_user_mcp_client, an explicit include list, and a server.auth_provider referencing an _type: mcp_oauth2 entry; the proxy validates the presented credential. A three-second tool timeout leaves two seconds for host processing. The downstream catalog identity has read access.
The tempting alternative is to expose all 40 tools directly and treat client authentication settings as server protection. That leaves the server unprotected and purchasing reachable. The owner accepts the experimental client API only after compatibility testing, budgets session capacity across all six applications, and verifies that the proxy rejects an unauthorized call before it reaches the tool server.
Common exam traps
- Assuming remote discovery automatically exposes only safe tools.
- Guessing a tool name instead of inspecting the published list.
- Treating
includeas authorization enforced by the server. - Configuring
server.auth_providerfor a toolkit transport that does not support it. - Reading
isError: trueas a successful business result because JSON-RPC succeeded. - Expecting a
2026-07-28server to accept the2025-06-18initialization handshake.
Where the exam guide differs
The September 2025 study guide’s suggested readings name “NVIDIA Agent Intelligence Toolkit”; the product documentation uses NeMo Agent Toolkit. The guide names no MCP revision and was written while 2025-06-18 was the published revision. This lesson’s protocol statements use 2026-07-28, whose changelog removes the initialization handshake and protocol-level sessions and requires resultType on results. HTTP+SSE was already deprecated in 2025-03-26, before the guide was written; 2026-07-28 reclassifies it under the feature-lifecycle policy. NVIDIA’s client page documents session-management options; that page alone does not establish support for the later revision. For exam items, distinguish discovery and invocation from revision-specific lifecycle behavior; for deployment, check the actual client/server revision pairing.
What to remember
Publish only intended tools, inspect their names and schemas, and select an explicit consumer subset. Match transport, authentication support, and deadlines. Check protocol compatibility separately from toolkit configuration, and distinguish a valid tool response from a successful authorized operation.
Knowledge check
A platform team runs nat mcp serve over streamable-http so six internal applications can share a catalog service in production. Each consuming workflow sets server.auth_provider to an mcp_oauth2 entry. The team must retain this MCP SDK server runtime. Which addition enforces authentication at the server boundary?
server.auth_provider configurationsse transport on both the server and its clientsserver_auth token validationnat mcp serve has no built-in server authentication, so a protected production deployment validates credentials in an authenticating proxy that no caller can route around. Client credentials protect nothing if the server never checks them, SSE has no toolkit authentication, and the FastMCP runtime depends on beta FastMCP3, which NVIDIA does not recommend for production.A workflow holds 40 tools, including one that creates purchase orders. Its MCP server must expose three catalog lookups and nothing else, even to a client configured by another team. Which control meets this?
include list in each consumer’s mcp_client grouptool_overrides alias renaming the purchase tool to internal_purchase--tool_names option on nat mcp serve--tool_names limits what the server publishes, so no client can discover the purchase tool. A client’s include list narrows only that client’s registration, an override changes the agent-facing name or description, and the workflow published as a tool still runs the purchase tool inside its own loop.A consumer’s function group lists lookup_material under include, but its agent never gets that tool. nat mcp client tool list against the server shows catalog__lookup_material. The group must expose only that one tool. What should the team change?
include list so every discovered tool is registeredinclude entry with the discovered tool nametool_call_timeout above its default of 60 secondsinclude list matches published names, and the published name is catalog__lookup_material , not the Python callable’s name; the fix is to use the name discovery reports. Removing the filter registers every tool, which the requirement forbids, and neither the prompt nor a timeout makes an unregistered tool available.A host and supplier server use MCP revision 2026-07-28. The host calls a supplier tool with tools/call. The JSON-RPC response carries resultType: "complete", isError: true and a text block reporting that the supplier rejected the order. How should the host treat this result?
isError: true , apart from JSON-RPC errors such as an unknown tool. A well-formed response does not mean the business operation succeeded, and the supplier’s rejection is not a connection fault that rediscovery or an immediate retry would fix.A nightly backend workflow with no user present calls a protected MCP service over streamable-http through the NeMo Agent Toolkit client. Which client authentication setup fits it?
mcp_client with an mcp_service_account providerper_user_mcp_client with an mcp_oauth2 providermcp_client over sse with server.auth_provider setmcp_client over streamable-http with no providermcp_service_account for headless backend workflows, while mcp_oauth2 with a per-user client is the pattern for user-facing access, where a person completes the authorization. server.auth_provider is supported only on streamable-http , and a protected service rejects a client that presents no credential.References
- NVIDIA, NeMo Agent Toolkit as an MCP Server
- NVIDIA, NVIDIA NeMo Agent Toolkit as an MCP Client
- NVIDIA, NeMo Agent Toolkit as an MCP Server using FastMCP
- NVIDIA, MCP Authentication
- NVIDIA, MCP Service Account Authentication
- NVIDIA, Authentication Provider API
- Model Context Protocol, Tools — revision 2026-07-28
- Model Context Protocol, Key Changes — revision 2026-07-28
- NVIDIA, NVIDIA-Certified Professional: Agentic AI Exam Study Guide