Parent issue
strands-agents/sdk-typescript#1104
Scope
Write integration tests validating Python-defined tools crossing the WASM boundary:
@tool decorator with various type annotations (str, int, list, dict, Optional, etc.)
@tool with Google-style docstrings for schema generation
Tool class (manual tool definition with name, description, schema, invoke callback)
PydanticTool (Pydantic model-based tool definition)
- Tool invocation via natural language (model decides to call)
- Direct tool invocation via
agent.tool.tool_name(param=value)
- Multi-tool invocation (model calls multiple tools in one turn)
- Tool error handling (exceptions in Python tool code)
Context
This tests the host→guest tool-provider import boundary. When the TS SDK agent loop needs to call a tool, it crosses back into Python via the WIT call-tool import. Results flow back as tool-event-stream resources.
Key areas of concern:
- Type serialization/deserialization across the boundary
- Error propagation from Python → WASM guest
- Stream events for tool execution (tool_use, tool_result)
Done when
Parent issue
strands-agents/sdk-typescript#1104
Scope
Write integration tests validating Python-defined tools crossing the WASM boundary:
@tooldecorator with various type annotations (str, int, list, dict, Optional, etc.)@toolwith Google-style docstrings for schema generationToolclass (manual tool definition with name, description, schema, invoke callback)PydanticTool(Pydantic model-based tool definition)agent.tool.tool_name(param=value)Context
This tests the host→guest
tool-providerimport boundary. When the TS SDK agent loop needs to call a tool, it crosses back into Python via the WITcall-toolimport. Results flow back astool-event-streamresources.Key areas of concern:
Done when
@tooldecorator works with common Python typesToolclass works for manual definitionsPydanticToolworks for Pydantic model-based toolsagent.tool.name()) works