Skip to content

Enforce episode step and time limits for direct MCP tool calls #1507

Open

Description

@burtenshaw

Episode step and wall-clock limits currently apply through the Gym/WebSocket step path, but direct tool calls through /mcp bypass that accounting. In posttrain_env, repeated call_tool calls leave step_count at zero, and do not deliver the final step observation carrying reward and service_spend. The broker budget still applies.

Requested by @sergiopaniego in #1500 (review) (point 5). The experimental env remains private and documents step(CallToolAction(...)) as its orchestration path.

Follow-up scope:

  • Define and enforce consistent episode step/time limits for direct MCP and step-driven tool calls, without double counting step dispatch.
  • End the episode and clean up live work when a limit is reached; preserve final reward/spend reporting for orchestration.
  • Add regression coverage for direct MCP, step dispatch, and calls after episode end, without real provider spend.
  • Keep reset/state/simulation controls outside the agent MCP surface.

This is episode lifecycle enforcement, separate from request rate limiting and IP filtering in #1360. No core change is proposed in #1500; coordinate the design with RFC 014 before implementation.

Activity

  1. leninworld commented on Oct 28, 2026

    @leninworld

    I'd like to help with this follow-up. On main at 3dfda7df, direct MCP tool dispatch can bypass the environment's step/step_async overrides; in posttrain_env, those overrides perform episode accounting and attach the final reward and service_spend observation. This is a source trace, not a runtime reproduction.

    Before implementation, to coordinate with RFC 014:

    1. Should direct MCP calls and step(CallToolAction(...)) share one environment-owned lifecycle path, counting each tool call once and enforcing both step and wall-clock limits, including cleanup and calls after episode end?
    2. How should orchestration receive the terminal observation when a direct MCP call ends the episode? Should the MCP tool result retain its existing shape, with the final observation retained for infrastructure, or is another contract preferred? I would keep reset/state/simulation controls off the agent MCP surface.

    The validation plan would cover direct MCP, step dispatch, no double counting, both limits, cleanup and post-end calls, using real local client/server transport and offline fixtures without provider spend. Nothing is implemented or tested yet. Happy to follow your preferred design.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions