> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.nvidia.com/nemo/gym/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.nvidia.com/nemo/gym/_mcp/server.

# Resources Server

> Understand how Resources Servers define environment tools, state, and verification logic.

The Resources server is the "world" the agent interacts with. It defines the task, the tools and actions available to the agent, and the verification logic that evaluates performance and returns reward signals for training.

```python
# Resources Server - pseudocode
class MyResourceServer(SimpleResourcesServer):
    
    # Initialize the "sandbox" for this specific rollout
    async def seed_session(self, session_id, task_data):
        self.state[session_id] = initialize_environment(task_data)

    # Define tool implementations
    async def my_tool(self, session_id, tool_args):
        result = execute_action(self.state[session_id], tool_args)
        return result

    # Define verification logic
    async def verify(self, session_id, response, ground_truth):
        # 1. Extract what the agent actually did
        actual_outcome = self.state[session_id].get_final_state()
        
        # 2. Reward if the actual outcome matches expected outcome
        if actual_outcome == ground_truth:
            return reward(1.0)
        return reward(0.0)
```

## Session Management

NeMo Gym uses a `session_id` to maintain isolated state for every parallel rollout. This ensures that concurrent rollouts never interfere with each other, and for multi-step environments, preserves state across steps within a single rollout.

## Tool Implementations

Tools are exposed as HTTP endpoints that the Agent server calls during a rollout. Each tool receives the `session_id` to access the correct rollout state, executes an action, and returns the result as an observation back to the model. Tools may also mutate the session state (e.g., updating a database), which the verifier can later inspect to evaluate performance.

## Verification Logic

Every Resources server implements a `verify()` function that evaluates the result of a rollout and returns a reward signal for training.

For semantic or rubric-based scoring, `verify()` can call a **second language model** (LLM-as-Judge). For configuration, deployment, and implementation patterns, refer to [LLM-as-Judge](/build-verifiers/verification-patterns/llm-as-judge).

## Examples

See [Example Resources Servers](/resources-server/example-resources-servers) for concrete Resources Servers and the task, action, and verification patterns they demonstrate.

## Server Configuration

[Resources Server Fields](/reference/configuration#resources-server-fields) for server configuration syntax and fields.