You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Enforce episode step and time limits for direct MCP tool calls #1507
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.
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:
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?
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.
Activity
leninworld commentedon Oct 28, 2026
I'd like to help with this follow-up. On
mainat3dfda7df, direct MCP tool dispatch can bypass the environment'sstep/step_asyncoverrides; inposttrain_env, those overrides perform episode accounting and attach the final reward andservice_spendobservation. This is a source trace, not a runtime reproduction.Before implementation, to coordinate with RFC 014:
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?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.