MCP

MCP support is remote HTTPS/SSE only. Stdio MCP servers are rejected because aex is a remote session dispatcher, not a local process supervisor.

Rules:

• MCP servers are declared in the run request config (mcpServers).
• Runtime HITL is disabled.
• Tool policy must be configured before session start.
• Enabled MCP tools use always_allow provider permissions.
• always_ask is not used by aex MVP.
• Bearer/OAuth-style auth is carried by the McpServer instance (its headers); the SDK splits it into the vaulted secrets channel server-side.

Use allowlists for sensitive servers whenever possible.

Large-payload responses

aex is a session dispatcher, not an MCP runtime. We intentionally do not interpose on the transport between the model and an upstream MCP server, so we cannot elide MCP responses or write them to the session filesystem on the user's behalf. Anything an MCP tool returns lands directly in the model's context.

For ingestion-style MCP servers that return large JSON blobs (search results, catalogue dumps, bulk reads), prefer a skill that writes files instead of putting the whole response in model context:

1. Package the upstream helper as a Skill (Skill.fromDir / Skill.fromUrl) and pass it via the top-level skills option. The skill can include a CLI binary or script that the agent invokes with its bash tool.
2. Keep any upstream HTTPS credentials in environment.secrets.
3. Have the CLI write the full payload to the session filesystem. By default, files it creates or modifies are captured automatically; pass outputs.allowedDirs only when you want to narrow capture to specific roots. Return only a small handle (path, item count, summary) to the model.

The agent sees the handle in context; the bytes ride out through download() as a normal captured output.

If you genuinely want everything in context (small responses, code search, etc.), use MCP. If the payload would blow your context budget, the CLI-as-skill pattern is the supported answer — there is no platform flag to elide MCP responses.