Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@cmd/gomodel/docs/swagger.json`:
- Around line 1796-1798: The OpenAPI schema currently declares the tool_choice
property as type: object but runtime accepts both strings like "auto" and
objects; update the schema for the tool_choice property (both occurrences) to
allow string-or-object values by replacing the single type with a union (e.g.,
type: ["string","object"] or an anyOf/oneOf combining {type: "string"} and
{type: "object"}) so generated SDKs/validators accept both forms; ensure the
same change is applied to the second occurrence of tool_choice referenced in the
spec.

In `@internal/guardrails/provider.go`:
- Around line 316-321: The Message construction copies the ToolCalls slice
header only, risking shared-mutability; in the adapter(s) that build messages
(the code assigning Message{Role:, Content:, ToolCalls:, ToolCallID:} and the
other similar adapter) clone m.ToolCalls before assigning it (e.g., assign a new
slice copy via append([]ToolCall(nil), m.ToolCalls...) or allocate and copy) so
each Message gets its own backing array and race/mutation issues are eliminated.

In `@internal/providers/anthropic/anthropic_test.go`:
- Around line 892-927: The test
TestConvertFromAnthropicResponse_WithToolUseStopReason only asserts FinishReason
and ToolCalls[0].ID, which can miss regressions that drop the tool name or
arguments; update the test that calls convertFromAnthropicResponse to also
assert the converted tool call's Name (e.g.,
result.Choices[0].Message.ToolCalls[0].Name or Function.Name) and its
Arguments/Inputs (e.g., result.Choices[0].Message.ToolCalls[0].Arguments or
Function.Arguments contain the original {"city":"Warsaw"}), so the non-streaming
tool-use payload is fully validated.

In `@internal/providers/anthropic/anthropic.go`:
- Around line 465-475: The parseToolCallArguments function currently swallows
JSON unmarshal errors and returns an empty object, which changes the tool
invocation; change parseToolCallArguments to return (any, error) and stop
returning a default {} on parse failure so callers can detect malformed JSON;
update callers (the request conversion flow that calls parseToolCallArguments)
to check the error and return an invalid-request error (or propagate the parse
error) instead of substituting {}; keep the function name parseToolCallArguments
and ensure all call sites are updated to handle the returned error and fail fast
on malformed tool_call.function.arguments.
- Around line 1032-1058: The streaming path currently assigns tool-call
output_index values before reserving any assistant message item, causing
streamed indexes to drift versus the final convertAnthropicResponseToResponses
output; modify the streaming logic to emit or reserve the assistant message
output item (same shape as the non-stream branch: a ResponsesOutputItem with
Type "message", Role "assistant", and Content containing an "output_text") when
content != "" (or when there are zero toolCalls) before assigning tool-call
indexes so that nextOutputIndex and later calls to
providers.ResponsesFunctionCallCallID / providers.ResponsesFunctionCallItemID
produce the same ordering as the final output; ensure the reserved item
increments nextOutputIndex consistently and is emitted/serialized in the stream
in the same position convertAnthropicResponseToResponses will place it.
- Around line 757-762: normalizeAnthropicStopReason currently only maps
"tool_use" and lets Anthropic-specific values leak into finish_reason; update
normalizeAnthropicStopReason to map all known Anthropic stop reasons to
OpenAI-compatible values (at minimum: "tool_use" -> "tool_calls", "end_turn" ->
"stop", "stop_sequence" -> "stop", "max_tokens" -> "length") and leave unknown
values unchanged, then ensure convertFromAnthropicResponse and the streaming
path both call this updated normalizeAnthropicStopReason so finish_reason is
always OpenAI-compatible.

In `@internal/providers/responses_adapter.go`:
- Around line 53-67: The ConvertResponsesInputToMessages function currently
ignores inputs of type []map[string]any because that concrete slice type doesn't
match the []interface{} case; add an explicit branch for []map[string]any before
the []interface{} case (e.g., case []map[string]any:), convert each map element
to interface{} (or directly build core.Message items) and pass them into
convertResponsesInputItems (or replicate its logic) so such inputs produce the
expected []core.Message; reference ConvertResponsesInputToMessages and
convertResponsesInputItems when making the change.
- Around line 24-33: The ChatRequest construction in ResponsesViaChat is missing
the new fields so req.Reasoning and req.StreamOptions are dropped; update the
core.ChatRequest literal in ResponsesViaChat to set Reasoning: req.Reasoning and
StreamOptions: req.StreamOptions (ensure the names/types match
core.ChatRequest's fields) so reasoning effort and streamed-response options
(e.g., include_usage) are preserved when forwarding to provider implementations.

In `@internal/providers/responses_converter.go`:
- Around line 56-63: The writeEvent method on OpenAIResponsesStreamConverter
currently swallows JSON marshal failures and returns an empty string, which
allows callers to unknowingly append empty data; change writeEvent to return
both the formatted string and an error (e.g., (string, error)) so callers can
handle failures, update callers to check the error before appending, and
propagate or log the error appropriately; keep the existing slog.Error call but
surface the error to callers by returning it from writeEvent (update function
signature and all call sites that use writeEvent).

In `@tests/e2e/mock_provider.go`:
- Around line 156-191: The streaming branch currently returns before handling
forced tool calls, so when forcedToolName(req) != "" the SSE path still emits
plain text chunks; add a new helper (e.g., handleStreamingToolResponse)
alongside handleStreamingResponse that mirrors the non-streaming tool-call
response: stream JSON deltas for Message.ToolCalls (emitting incremental
tool-call argument chunks or a single tool_call delta), ensure the final chunk
sets finish_reason to "tool_calls" and includes the same core.ToolCall structure
(ID, Type="function", Function{Name: toolName, Arguments}), and update the
streaming branch to call handleStreamingToolResponse(req, w, toolName) when
forcedToolName(req) returns a name so streaming tests receive proper tool-call
events.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@cmd/gomodel/docs/swagger.json`:
- Around line 1796-1805: The swagger.json currently uses the OpenAPI 3.x-only
"oneOf" for the tool_choice schema (symbol: "tool_choice") while the document
declares "swagger": "2.0"; replace the oneOf usage with a Swagger 2.0-compatible
approach (either change the tool_choice schema to a typeless schema (no "type")
and expand the description to note "string or object", or migrate the overall
spec to OpenAPI 3.x and remove the "swagger": "2.0" header), update the source
annotation that generated this schema so the generator emits the corrected
definition, and then regenerate the generated artifacts
(cmd/gomodel/docs/swagger.json and cmd/gomodel/docs/docs.go) to reflect the fix.

In `@internal/providers/anthropic/anthropic_test.go`:
- Around line 1614-1627: The SSE fixture in anthropic_test.go currently mixes a
preamble text_delta with a tool_use block both using index:0; fix it by making
the preamble its own content block (add a content_block_start and
content_block_stop wrapping the initial text_delta with index:0) and bump the
tool_use block and its input_json_delta events to index:1 so each content block
has a unique index; update the corresponding test assertions in the same test to
reflect the two-block structure (preamble block then tool_use block) per the
other Anthropic SSE fixtures.
- Around line 363-364: The test currently sets foundArgumentsDelta true when any
fragment of function.arguments arrives, allowing partial data to pass; update
the test in anthropic_test.go to accumulate/buffer all emitted
function.arguments fragments (e.g., collect the string parts emitted for the
"function.arguments" role) and only assert equality against the full expected
JSON ({"city":"Warsaw"}) after the stream completes (when foundFinish is true),
replacing the single-fragment flip logic (foundArgumentsDelta) with a
join-and-compare check; apply the same buffering-and-join fix to the other
occurrences flagged (the similar assertions around the blocks noted at the other
locations).
- Around line 845-874: Update the two tests (e.g.,
TestConvertToAnthropicRequest_InvalidToolArguments and its companion around
lines 1918-1940) to also assert the HTTP mapping: after confirming the error is
a *core.GatewayError and its Type is core.ErrorTypeInvalidRequest, call
gatewayErr.HTTPStatusCode() and assert it equals http.StatusBadRequest; keep the
existing checks for error type and use the same gatewayErr variable for this new
assertion so the test fails if the invalid_request_error is mapped to the wrong
HTTP status.

In `@internal/providers/anthropic/anthropic.go`:
- Around line 374-452: The helpers convertOpenAIToolsToAnthropic and
convertOpenAIToolChoiceToAnthropic must fail fast on malformed inputs instead of
silently continuing; change their signatures to return an error (e.g.,
([]anthropicTool, error) and (*anthropicToolChoice, bool, error) or equivalent)
and validate strictly: in convertOpenAIToolsToAnthropic, treat missing/empty
function name or a non-object/invalid "parameters" as an invalid_request_error
and return an error immediately rather than continuing/using a default
inputSchema; in convertOpenAIToolChoiceToAnthropic, treat unknown/unsupported
choice types or a malformed function object (missing name) as
invalid_request_error and return an error instead of mapping to nil/auto/any;
update callers to handle the new error returns and propagate a proper
invalid_request_error to the client.
- Around line 478-486: In buildAnthropicMessageContent, validate that when
msg.Role == "tool" the msg.ToolCallID is non-empty and return an error if it is
missing instead of emitting a tool_result block; update the logic around
creation of the anthropicMessageContentBlock (the tool_result block and its
ToolUseID/ToolCallID usage) to check msg.ToolCallID (tool_call_id) and fail with
a clear invalid-request error when empty so uncorrelatable tool results are
rejected locally.

In `@tests/e2e/mock_provider.go`:
- Around line 39-60: Add Go doc comments for the exported methods on
MockLLMServer: document Requests to explain it returns a thread-safe
copy/snapshot of recorded requests (including that headers and body are cloned)
and document ResetRequests to explain it clears the server's recorded requests
in a thread-safe manner; place the comments immediately above the Requests and
ResetRequests method declarations and follow Go doc style (start with the method
name).

---

Outside diff comments:
In `@internal/providers/responses_adapter.go`:
- Around line 178-196: ExtractContentFromInput currently handles
[]core.ResponsesContentPart and []interface{} but not a top-level
[]map[string]any, so nested native Go payloads like []map[string]any with
content arrays return empty; add a new case in ExtractContentFromInput for
[]map[string]any that mirrors the []interface{} branch: iterate each map, check
for a "text" string and append it, and if a "content" field exists handle nested
[]map[string]any or []interface{} recursively (or reuse the existing extraction
logic), ensuring convertResponsesInputMap and ExtractContentFromInput both
accept and correctly parse []map[string]any content arrays so messages with
nested content produce the expected text.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@internal/core/responses.go`:
- Around line 10-11: Replace the untyped payloads in internal/core/responses.go
by introducing shared, strongly-typed models (e.g., ToolDefinition and
ToolChoice) in the internal/core package and using them instead of
[]map[string]any and any for the Tools and ToolChoice fields; add appropriate
JSON tags and fields on those structs to cover the current dynamic keys, update
the Tools field signature to []ToolDefinition and ToolChoice to ToolChoice (or
*ToolChoice) in responses.go, and also update the ChatRequest type to reference
the same shared ToolDefinition/ToolChoice types so validation, serialization,
and schema generation are consistent across requests and responses.

In `@internal/core/types.go`:
- Around line 56-59: The Message struct's Content field must be nullable so a
decoded assistant tool-call with content: null isn't turned into an empty
string; change Message.Content from string to *string (or introduce a nullable
type) and update UnmarshalJSON/MarshalJSON so Unmarshal preserves nil when
content was null and Marshal emits JSON null for Messages that originally had
null content (especially for messages with ToolCalls/ToolCallID); also update
callers that read Message.Content (for example
internal/providers/openai/openai.go and any logic that serializes req.Messages)
to handle the pointer/nullable type accordingly.

In `@internal/providers/anthropic/anthropic.go`:
- Around line 1281-1285: The conversion failure handling in
convertToAnthropicRequest currently discards the original GatewayError and
replaces it with a generic core.NewInvalidRequestError for each batch item;
instead, when err is returned from convertToAnthropicRequest (and similarly in
the other branch around the second conversion call), preserve the original typed
error (core.GatewayError) and return it with the batch-item index prefixed to
its message: detect if err is a core.GatewayError and wrap or annotate it to add
"batch item %d: " while keeping the original error type and message (do not
replace it with a new generic InvalidRequestError).
- Around line 553-568: The code currently drops the incoming tool_choice when
tool conversion yields no tools; instead, detect when
convertOpenAIToolChoiceToAnthropic returns a non-nil toolChoice (or the original
request had ToolChoice set) but anthropicReq.Tools is nil/empty and return a 400
validation error; update both convertToAnthropicRequest and
convertResponsesRequestToAnthropic to check after convertOpenAIToolsToAnthropic
and convertOpenAIToolChoiceToAnthropic: if toolChoice != nil (or req.ToolChoice
!= nil) && len(anthropicReq.Tools) == 0 then return an HTTP 400-style error
(with a clear message about tool_choice requiring at least one tool) rather than
clearing ToolChoice or proceeding, and keep the existing logic for
applyParallelToolCalls, ParallelToolCalls, and disableTools unchanged otherwise.
- Around line 482-492: The parseToolCallArguments helper currently accepts any
JSON value; after unmarshalling in parseToolCallArguments, verify that the
parsed value is a JSON object (i.e., assert it is a map[string]any /
map[string]interface{}); if it is not (e.g., slice, string, number, null),
return a descriptive error indicating tool arguments must be a JSON object; keep
the existing behavior that an empty/whitespace arguments string returns an empty
map.

In `@internal/providers/responses_adapter.go`:
- Around line 140-158: The function_call branch can emit an empty ToolCall.ID
when neither "call_id" nor "id" exist; update the branch in responses_adapter.go
(the case "function_call" block that reads name and callID) to normalize callID
before building the core.Message by replacing an empty callID with the
ResponsesFunctionCallCallID constant (or alternatively return false if you
prefer rejecting blank ids), then use that normalized callID for ToolCall.ID so
downstream providers always receive a stable id.

In `@internal/providers/responses_converter_test.go`:
- Around line 52-55: The test currently sets foundArgumentsDelta true if either
fragment matches, which allows missing halves to pass; update the assertion in
responses_converter_test.go to verify both streamed JSON fragments are received
in order (or assert the exact concatenated delta sequence) instead of a single
fragment: replace the single boolean foundArgumentsDelta check with either a
counter that increments when event.Payload["delta"] equals "{\"city\":\"War" and
when it equals "saw\"}" and assert count==2, or capture the sequence of observed
deltas and assert it equals the expected slice/concatenated string; ensure you
update any final expectations in the test accordingly (look for the case
handling "response.function_call_arguments.delta" and the foundArgumentsDelta
variable).

In `@tests/e2e/mock_provider.go`:
- Around line 297-307: The mock is emitting delta.tool_calls as []core.ToolCall
(see firstChunk and toolCall) but the streaming protocol requires each tool call
object to include an index to correlate incremental chunks; change the
construction of delta.tool_calls in firstChunk to emit a slice of objects that
include an "index" integer and the tool-call payload (instead of marshaling
core.ToolCall directly), e.g. build []map[string]interface{} entries with
"index": <seq> and the tool call fields, ensuring the same sequencing logic used
by the stream assembler is reproduced so tests exercise index-based
accumulation.

---

Duplicate comments:
In `@internal/providers/anthropic/anthropic_test.go`:
- Around line 910-939: The test TestConvertToAnthropicRequest_InvalidToolChoice
only asserts the error type but not the mapped HTTP status; update this and the
two similar tests to also assert that the returned *core.GatewayError
(gatewayErr) maps to HTTP 400 by calling gatewayErr.HTTPStatusCode() and
comparing it to http.StatusBadRequest, keeping the existing checks for
errors.As(err, &gatewayErr) and gatewayErr.Type == core.ErrorTypeInvalidRequest;
apply the same addition to the other two tests mentioned (lines ~941-958 and
~2083-2105) so all invalid-request tests verify both the error type and HTTP
status mapping.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@internal/core/types.go`:
- Around line 59-63: The guardrails pipeline drops the Message.ContentNull flag
causing null content to become an empty string; add a ContentNull bool field to
guardrails.Message (in internal/guardrails/guardrails.go), update chatToMessages
to copy the ContentNull from core.Message into the guardrails DTO, and update
applyMessagesToChat to read ContentNull from the guardrails DTO and set it on
the reconstructed core.Message (the core.Message constructed in
applyMessagesToChat must explicitly set ContentNull). Ensure
ToolCalls/ToolCallID/Role/Content handling remains unchanged while propagating
ContentNull through these adapters.

In `@internal/providers/anthropic/anthropic.go`:
- Around line 524-534: Normalize and validate tool call ID and function name
before creating anthropicMessageContentBlock: trim whitespace from toolCall.ID
and toolCall.Function.Name, and if either is empty after trimming apply the same
fallback/normalization used in responses_adapter.go (e.g., generate or
canonicalize an ID and replace empty names with a safe placeholder) so that the
block created in the loop that calls parseToolCallArguments and constructs
anthropicMessageContentBlock uses validated ID and Name values and preserves
correlation with tool_result messages.
- Around line 871-889: The initial tool-call emission is leaking Anthropic's
"{}" placeholder by writing and emitting initialArguments from
event.ContentBlock.Input; change the logic in the flow that builds the first
chunk (around extractInitialToolArguments, state.PlaceholderObject,
state.Arguments.WriteString, sc.toolCalls and sc.formatChatChunk) so that if
initialArguments == "{}" you do not append or emit that placeholder: set
state.PlaceholderObject = true but emit arguments as empty string (or omit the
arguments field) in the first chunk, and only start writing/emitting real
argument content when input_json_delta events provide real JSON fragments
(handle input_json_delta to write into state.Arguments and clear
PlaceholderObject when first non-placeholder fragment arrives); ensure the same
fix is applied to the responses path that builds tool_calls to prevent "{}"
being sent initially.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@internal/guardrails/provider.go`:
- Around line 331-336: applyMessagesToChat currently copies
core.Message.ContentNull verbatim, so if a guardrail transforms an assistant
tool-call from content:null to real text the resulting core.Message still has
ContentNull=true and will marshal as null; update the construction of
core.Message (the block that sets Role, Content, ToolCalls, ToolCallID,
ContentNull) so that ContentNull is cleared (set to false) whenever Content is
non-empty/non-nil (i.e., after applying guardrail mutations), ensuring that when
m.Content has real text you override ContentNull before returning the message;
reference applyMessagesToChat and core.Message/ContentNull to locate where to
change this behavior.

In `@internal/providers/anthropic/anthropic.go`:
- Around line 876-883: The code suppresses the initial "{}" placeholder by
setting emittedArguments = "" when extractInitialToolArguments returns "{}",
which prevents emitting the real empty object if no input_json_delta arrives;
change the logic so that when initialArguments == "{}", set
state.PlaceholderObject = true but set emittedArguments = "{}" (and still avoid
writing it into state.Arguments), so clients receive the empty JSON object for
zero-arg tool calls; apply the same change to the other occurrence that mirrors
this behavior (the block around the second occurrence currently at the 939-940
equivalent).
- Around line 500-509: The tool-result branch returns
anthropicMessageContentBlock with ToolUseID set to raw msg.ToolCallID, causing
mismatches with normalized tool_use.id; apply the same trim/canonicalize logic
used earlier for assistant tool-call IDs (the normalization in the nearby block
that processes assistant tool-call IDs around lines 525-537) to msg.ToolCallID
before assigning it to the ToolUseID field so tool_result.tool_use_id matches
tool_use.id.
- Around line 489-496: Replace the json.Unmarshal call that decodes into parsed
with a json.Decoder that has UseNumber enabled so numeric values are preserved
as json.Number; specifically, create a json.NewDecoder over the trimmed string,
call decoder.UseNumber(), decode into the existing parsed variable (any) and
keep the subsequent map[string]any type check and error handling the same so
integers beyond 2^53 aren't coerced to float64.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@internal/guardrails/provider_test.go`:
- Around line 201-224: The test only checks presence/counts/IDs of tool-related
fields, so update assertions to compare full tool payloads and fields that must
be preserved: assert the concrete values of got.Tools[0] (e.g.,
Name/Description/Arguments), got.ToolChoice (the selected tool name/value),
got.Messages[1].ToolCalls[0].Function.Name and Function.Arguments, the ToolCall
result Content, and got.Messages[2].ToolCallID equals "call_123"; also tighten
got.Reasoning to check Reasoning.Effort == "high" and any nested fields. Locate
and update assertions referencing got.Tools, got.ToolChoice, got.Messages,
ToolCalls, and ToolCallID to validate exact expected structs/values rather than
only lengths or non-nil checks.

In `@internal/providers/responses_adapter.go`:
- Around line 78-129: The assistant merging logic in convertResponsesInputItems
uses pendingAssistant and intentionally only inherits msg.ContentNull when
pendingAssistant.Content is empty (the block setting
pendingAssistant.ContentNull = pendingAssistant.ContentNull || msg.ContentNull),
which is subtle; add a short inline comment next to that conditional explaining:
when accumulated content is empty we must preserve a true ContentNull if any
merged piece is null (but once any real content exists we clear/ignore
ContentNull), so future readers understand why the assignment is guarded by
pendingAssistant.Content == "".

In `@internal/providers/responses_converter_test.go`:
- Around line 36-79: The test currently only checks presence flags and delta
fragments, which allows reorderings or extra lifecycle events; update the test
in responses_converter_test.go to assert the exact ordered sequence and payloads
emitted by parseTestSSEEvents(t, string(raw)) for the function_call lifecycle
(check event.Name values "response.output_item.added",
"response.function_call_arguments.delta",
"response.function_call_arguments.done", "response.output_item.done" in the
exact order) and validate each event.Payload (e.g., the added item map contains
type="function_call", call_id="call_123", name="lookup_weather"; the two delta
payloads concatenate to `{"city":"Warsaw"}`; the arguments payload on done
equals `{"city":"Warsaw"}`; the output_item.done payload item.arguments equals
`{"city":"Warsaw"}`) and fail the test if the sequence length, names, or
payloads differ or if extra function-call lifecycle events appear; use the
existing events slice returned by parseTestSSEEvents to perform the ordered
comparison instead of the boolean flags and unordered checks.

In `@internal/providers/responses_converter.go`:
- Around line 71-80: Convert the standalone function normalizeToolCallIndex into
a method on OpenAIResponsesStreamConverter for consistency: change its signature
to a receiver method (e.g., func (c *OpenAIResponsesStreamConverter)
normalizeToolCallIndex(value interface{}) (int, bool)), move the implementation
into the type's file, and update all call sites to use
c.normalizeToolCallIndex(...) instead of the package-level function; ensure any
tests or references are updated accordingly.
- Around line 186-201: In forceStartToolCall, when strings.TrimSpace(state.Name)
== "" currently falls back to "unknown" without logging; add a warning log right
before setting state.Name = "unknown" to record that the stream ended without a
function name (include context like state.CallID and state.OutputIndex). Use the
OpenAIResponsesStreamConverter receiver's logger (e.g., sc.logger.Warnf or the
existing logging field on sc) to emit a concise warning mentioning
forceStartToolCall, state.CallID, state.OutputIndex and that the name was blank
and substituted with "unknown".

---

Outside diff comments:
In `@internal/providers/anthropic/anthropic.go`:
- Around line 1671-1690: Replace the inconsistent use of map[string]interface{}
with map[string]any in the streaming response construction to match file-wide
style: update the responseData and doneEvent declarations (and any other
occurrences in the same streaming block, e.g., where cachedUsage is used) to use
map[string]any so symbols like responseData, doneEvent, sc.cachedUsage,
sc.responseID, and sc.model remain the same but types are consistent with the
rest of the file.
- Around line 1145-1158: This extraction path loses integer precision because it
uses json.Unmarshal; switch to a json.Decoder with UseNumber() before decoding
b.Input to preserve large integers: create a decoder (json.NewDecoder over
b.Input), call dec.UseNumber(), decode into parsed (any) and then
json.Marshal(parsed) as before; update the block that currently unmarshals
b.Input (the code handling b.Input/arguments) and ensure the same fallback to
trimmed string on decode error is kept; reference parseToolCallArguments and the
variables b.Input and arguments to locate the change.

---

Duplicate comments:
In `@internal/core/responses.go`:
- Around line 10-12: Introduce strongly-typed models ToolDefinition and
ToolChoice in internal/core and replace the untyped fields: change the Tools
field type from []map[string]any to []ToolDefinition and change ToolChoice from
any to ToolChoice in the responses struct (and the analogous ChatRequest
struct), keep the existing json tags (tools,omitempty and tool_choice,omitempty)
and preserve ParallelToolCalls *bool; update any code that constructs/consumes
these fields to use the new types and add validation constructors/marshalling
helpers if needed, then run the provided ripgrep check to verify no remaining
uses of map[string]interface{} or any for Tools/ToolChoice.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@internal/providers/anthropic/anthropic.go`:
- Around line 388-414: Trim the tool name before storing it: where the code
reads the raw name variable (name, _ := function["name"].(string)) and later
appends an anthropicTool, call strings.TrimSpace(name) and use that trimmed
value for anthropicTool.Name (and any other places that persist or compare the
name); apply the same fix to the other branch referenced (the second creation of
anthropicTool around lines 446-463) so stored names never retain
leading/trailing whitespace and matching logic (e.g., tool_choice vs tool_use)
works reliably.
- Around line 1132-1136: In convertAnthropicResponseToResponses, when building
the core.Message (msg) for responses that contain toolCalls but no text, set
msg.ContentNull = true so we mark content as intentionally absent; specifically,
after you collect toolCalls and content and before calling
providers.BuildResponsesOutputItems(msg), if content == "" (or nil/empty) AND
len(toolCalls) > 0 then set the ContentNull field on the core.Message instance
to true, otherwise leave it false.

In `@internal/providers/responses_adapter.go`:
- Around line 218-231: The function stringifyResponsesInputValue silently
swallows json.Marshal errors and returns an empty string; update this by either
logging the marshal error (use the package's logger at debug/trace level if
available, e.g., call logger.Debugf or similar with the error when
json.Marshal(v) fails) or, if silent fallback is intentional, add a clear
comment above stringifyResponsesInputValue explaining that marshal failures are
treated as absent values and intentionally return an empty string; modify the
json.Marshal error branch (in stringifyResponsesInputValue) to perform the
logging or add the explanatory comment accordingly.
- Around line 294-301: ResponsesFunctionCallItemID creates its own UUID when
given an empty callID, causing mismatch with ResponsesFunctionCallCallID; change
ResponsesFunctionCallItemID to delegate to ResponsesFunctionCallCallID for
normalization/UUID generation (i.e., call ResponsesFunctionCallCallID(callID)
and then prefix with "fc_") so both functions produce the same id when callID is
empty and keep the "fc_" prefix behavior consistent.

---

Duplicate comments:
In `@internal/providers/anthropic/anthropic.go`:
- Around line 811-821: The code currently unmarshals input into parsed (any)
then json.Marshals it, which uses json.Unmarshal into interface{} and converts
JSON numbers to float64 (losing integer precision); instead preserve numeric
literals and only remove whitespace by using json.Compact (or json.Indent as
needed) on the original input bytes and return that result; update the block
that references parsed, input, trimmed to call json.Compact into a bytes.Buffer
(or similar) and handle errors, returning trimmed on error and the compacted
string on success.