Claude
60849f4319
defaultToolCallbacks(ToolCallbackProvider) wires two real stdio MCP servers (the official filesystem server and git server) into ChatClient, contrasted with defaultTools(Object) for a local @Tool method. Every call -- MCP-sourced or local -- is logged through one Micrometer ObservationHandler<ToolCallingObservationContext>; a first version wired that handler two ways at once and every call logged twice, which is now a regression test. No real LLM is used anywhere: every test builds an AssistantMessage.ToolCall by hand and drives it through the real ToolCallingManager bean against real npx/uvx-launched MCP server processes. Co-Authored-By: Claude Sonnet 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01FtpJvZfg4nvLvtzgJTDWpB
12 lines
794 B
Plaintext
12 lines
794 B
Plaintext
# What a failing MCP tool call actually looks like through ToolCallingManager -- read_text_file against a path that does not exist
|
|
|
|
tool: read_text_file
|
|
arguments: {"path":"/home/claude/work/spring-ai-clone/mcp-client/fixtures/workspace/does-not-exist.txt"}
|
|
|
|
response: Error calling tool: [TextContent[annotations=null, text=ENOENT: no such file or directory, open '/home/claude/work/spring-ai-clone/mcp-client/fixtures/workspace/does-not-exist.txt', meta=null]]
|
|
|
|
note: ToolCallingManager does not throw here. The MCP tools/call result came back
|
|
with isError:true (HTTP-equivalent 200-but-failed, same shape documented for the
|
|
server side in the mcp-server article); DefaultToolCallingManager turns that into a
|
|
normal ToolResponseMessage whose responseData is the error text, not an exception.
|