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
Label: enhancement
type: Feature
Motivation
Currently, execution in MCIClient is only initiated by tool name lookup. There is demand for a new method,
executeSeparated, which would:executeUse Case
Requirements
executeSeparated(tool: Tool, props: dict, env_vars: dict, validating: bool = False)method to MCIClientvalidatingmode (same restrictions as top-level client)executeAcceptance Criteria
References
Label: enhancement
type: Feature