On the third issue (errors starting from the second user message) - this looks like it's coming from how the app's own conversation-history handling deals with items from the OpenAI Agents SDK's output, rather than from the model or MCP layer itself.

The payload in your error - {'status': None, 'content': [{'text': ..., 'type': 'output_text'}], 'role': 'assistant', 'type': 'message'} - is a standard "message" item shape from the Agents SDK / Responses API (roughly what you'd see from a run's output items, or from to_input_list()). If the app template keeps its own conversation state by appending previous turns and only handles a subset of item shapes (e.g. assumes content is a flat string, or only expects tool-call/tool-output items), a "message" item where content is a list of output_text objects can trip up whatever code path builds the next request - which would explain why it works on the first turn (no history yet) and breaks as soon as a prior assistant message has to be folded back in.

Worth checking wherever the template reconstructs the input/message history between turns for a type or role check that doesn't have a branch for type == "message" with a list-shaped content. If you're passing to_input_list() straight from the SDK, that should normalize this correctly already, so the bug is more likely in custom glue code the template layers on top of it.

On the other two - the model limitation and the mcp<2.0.0 pin both sound like genuine doc/template maintenance gaps rather than expected behavior, so worth filing them as explicit feedback (in-product feedback widget or docs feedback link) so they get tracked rather than staying tribal knowledge from a YouTube video.