Skip to content

[BUG] Preserve MCP structuredContent and all content block types #1664

Description

@FenjuFu

Problem

Astron Agent's MCP tool-call adapter currently rebuilds only text and image content blocks. This silently drops newer/other MCP content types and top-level structured results:

  • audio;
  • embedded resource contents;
  • resource_link blocks;
  • unknown forward-compatible content blocks;
  • structuredContent returned by a tool.

The image adapter also reads mineType instead of the MCP field mimeType, so a standard SDK image block can lose its MIME type or expose a misspelled public field.

Silent loss is especially risky for agent workflows: a transport call can be reported as successful while part of the authoritative tool result has disappeared.

Proposed solution

  1. Preserve MCP SDK content blocks by serializing their full protocol shape instead of rebuilding a two-type subset.
  2. Add typed public models for known block types while allowing unknown forward-compatible fields/types to pass through explicitly.
  3. Expose top-level structuredContent without coercing it to text.
  4. Correct mimeType and retain a documented compatibility alias for existing clients that consumed mineType; do not perform a silent breaking rename.
  5. Preserve isError, _meta/annotations where supported, and protocol errors separately from content.
  6. Apply bounded response-size/content-count limits and explicit truncation metadata rather than unbounded buffering or silent drops.
  7. Add tests with standard MCP SDK result models, not hand-shaped dictionaries only.

Acceptance criteria

Pinned baseline: iflytek/astron-agent@aaef2a286b9fb8396d42d5d4f6bb7af9b19afa22

  • Text and image responses remain backward compatible.
  • Standard mimeType is returned for image/audio; the legacy misspelling is handled explicitly during a deprecation window.
  • Audio, embedded resource, and resource-link blocks survive the plugin-link response unchanged in meaning.
  • structuredContent survives as structured JSON.
  • Unknown future block types are returned as explicit generic blocks or a clear unsupported-content error; they are never silently omitted.
  • Oversized block counts/payloads produce bounded truncation/error metadata.
  • A tool-level isError: true remains distinguishable from transport/session failures.
  • Tests cover round trips through both the service function and public FastAPI schema serialization.

Current implementation evidence

Related

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions