Fix four bugs in MCP tool schema and result handling

[hsm207]

This PR fixes four bugs in the MCP server integration, including the one reported in #912 (tool inputSchema.properties stripped at registration). I found them by exercising all 13 tools of @modelcontextprotocol/server-everything, the official example MCP server, end-to-end against a source build.

The four bugs

1. Tool schemas arrive at the model as {}. lodash cloneDeep drops zod v4's non-enumerable _zod engine, and a silent fallback then serves an empty schema. This is MCP Tool inputSchema.properties stripped when registering tools from external MCP servers #912's properties: {} and its expected string, received undefined errors.
2. Live zod schemas stored in run state. Tool definitions are serialized every turn, and storing zod instances makes JSON.stringify throw, so the session errors from the second turn onward. Schemas are now stored as plain JSON Schema.
3. Text resources stored as media. The prompt rebuild base64-decodes file-part data, so a text resource stored as media made every later turn fail with The string contains invalid characters. Text resources now stay text.
4. Non-image binary resources become media. The OpenAI-compatible chat converter accepts only image file parts and threw at prompt build. Non-image resources now become descriptive text, and the converter degrades other file parts to a placeholder.

Testing

Each bug has its own regression tests, in a commit immediately after its fix. The tests fail against the pre-fix code and pass after. The first commit is a behavior-preserving extraction that makes the MCP content mapper testable without a live server. A final commit adds a warning when a schema falls back to empty, so this failure class shows up in logs.

[quwin]

I tested this PR at commit 780db6f against a local NodeSpec Community Edition MCP server using both ordinary and loose/complex JSON Schemas.

The clone and persistence fixes work for ordinary named schemas, but several tools with loose object fields or unions still fall back to an empty model-facing schema. The Freebuff log reports:

Error: Custom types cannot be represented in JSON Schema

The remaining failure path is:

1. The MCP JSON Schema is correctly preserved in run state.
2. getToolSet() converts it using zod-from-json-schema.
3. For the affected schemas, loose objects or union constructs become Zod custom types.
4. z.toJSONSchema() throws because those custom types cannot be represented.
5. ensureJsonSchemaCompatible() catches the error and substitutes z.object({}).passthrough().
6. The model-facing schema consequently has no named properties, so constrained decoding emits {} and the MCP server receives no arguments.

A minimal reproduction is:

{
  "type": "object",
  "properties": {
    "project_id": { "type": "string" },
    "payload": { "type": "object" }
  },
  "required": ["project_id", "payload"]
}

The approach I tested builds on the idea from PR #921, which previously proposed preserving the raw schema in getToolSet() but became stale.

My follow-up wraps raw MCP schemas with AI SDK's jsonSchema() helper, while retaining the existing Zod path for native Zod schemas. The wrapper also supplies a Zod-backed validate callback, so AI SDK input validation is preserved without converting the schema back to JSON Schema. On successful validation it returns the original value, preventing permitted loose fields from being stripped.

The focused regression test verifies that:

• the model-facing JSON Schema remains identical to the MCP schema;
• permitted arbitrary nested fields survive validation; and
• invalid arguments are rejected.

Would it be helpful if I opened a small dependent PR against this PR's branch with the implementation and regression test?