MCP tool-call parser concatenates `<parameter>` tail into first string arg when model emits `<TAG>…</TAG>` instead of `<parameter name="TAG">…</parameter>`

## Summary

On some MCP tool-calls, the SDK appears to emit (or fail to fully parse) a tool-call where the model wrote `…` instead of `…`. The result reaching the MCP server is that the first string parameter contains the whole trailing `\nVALUE…` blob, and the rest of the parameters arrive as `undefined`.

## Environment

- `@anthropic-ai/claude-agent-sdk` 0.2.92
- Model: `claude-opus-4-8`
- Transport: stdio MCP server from `@modelcontextprotocol/sdk`
- Tools registered with `server.tool(name, desc, zod-shape, handler)` — three string args (`prompt`, `preset?`, `caption?`)

## Observed payload

Three independent calls in the same session — every one of them stored the same shape in our DB (real values, untouched):

```
prompt:
"Flat 2D UI design of an iOS 26 music player … dark mode.\n[\"1024x1536\",\"format=png\",\"quality=high\"]"

preset: undefined
caption: undefined
```

i.e. the model wrote `…` rather than `…`, the parser didn't find a matching ``, and instead of bouncing the whole call or treating the next `` as the start of a new arg, it concatenated the tail into `args.prompt`.

## Expected behaviour

One of:

1. Treat `…` (where `TAG` matches a declared parameter name) as a valid alternate form of `…`, OR
2. Return a structured tool-call parse error so the agent can self-correct, OR
3. Stop the value at the next `` boundary even when the current `` is missing.

Current behaviour silently corrupts the args.

## Why it bites users

In our case this caused [FED-32](#) — an `image_generation` tool whose `preset` arrived as `undefined`, so the host's defaults kicked in and every call returned a 1024×1024 square regardless of the explicit `["portrait"]` / `["1024x1536"]` requested. Without inspecting the model's raw tool-call we'd have spent a long time looking for the bug in our preset parser.

We've shipped a workaround that detects the boundary, restores known params, and refuses calls where the boundary fired but no recognized parameter could be recovered (so the failure becomes visible instead of silently defaulting). It's a clear compensation — happy to share the normalizer code if useful.

## Asks

1. Confirm whether this is a known issue (couldn't find a direct match).
2. Decide whether the right fix lives in the SDK's tool-call parser (option 3 above seems lowest-risk).
3. Anything you'd like us to capture next time we see it in the wild — full request trace, MCP frames, model output, etc?