Motivation

Currently, execution in MCIClient is only initiated by tool name lookup. There is demand for a new method, executeSeparated, which would:

• Allow passing a Tool model, a dictionary of props, and a dictionary of env_vars directly
• Use the same execution engine (templating, executor, result formatting) as primary execute
• Return the ExecutionResult object
• Bypass toolset filtering, allowing isolated/dynamic tool testing

Use Case

• Debug/test specific Tool models in memory (e.g., after modifying config, retrieved from DB, or constructed on-the-fly)
• Validate behavior with different props/env_vars without modifying global context or schema
• Used by developers, integration tests, IDE plugins

Requirements

• Add executeSeparated(tool: Tool, props: dict, env_vars: dict, validating: bool = False) method to MCIClient
  • Accepts an instantiated Tool model (from Pydantic)
  • Accepts props and env_vars as dicts
  • Optionally supports validating mode (same restrictions as top-level client)
  • Returns ExecutionResult, same as normal execute
  • Must use same execution and templating logic (call same internal engine/factory as regular execution)
• Document the method and describe when/how to use it (non-persistent, debug, testing only)
• No impact on main tool registry or tool filtering

Acceptance Criteria

• Passing a Tool, props, and env_vars executes independently (no context pollution, uses same adapters as normal)
• Error returned if Tool model is invalid or missing execution config/type
• Unit tests for different execution types
• Clear docstring and API docs

References

• API: Tool execution
• Models: Tool, ExecutionResult
• PRD: Adapter API

Label: enhancement
type: Feature