[Feature Request] Agent capabilities manifest + rollout channel protocol

Capability area

Agent harness / Agent Teams

What does M2.7 fail to do for you?

Workload: M3 (or M2.7) running inside host applications — web chat, Android app, IDE plugins, CLI — where the model is wrapped in an agent harness.

What M2.7 fails to do today:

It cannot tell — and cannot be told — which of its own capabilities are actually available to the current user/session. There is no protocol for the host application to advertise to the model:

• which tools are enabled, behind a flag, gradually rolling out, or disabled
• which surface (web / Android / iOS / IDE / CLI) and app version is hosting it
• which account tier, region, or experiment bucket the user is in
• when a capability's status changes mid-session

Concrete failure (real example):

User (Android app, free tier, EU region): "Generate a 10-second video of a cat playing piano."
Agent: "Sorry, that feature is not available in your account."
User: opens a bug report.
Reality: video gen is in gradual rollout at 12% and will reach them in ~3 weeks.

Every disabled feature surfaces as a bug. The user has no way to know whether it's:

• a bug,
• a region/tier lock,
• an experiment-bucket exclusion,
• a gradual rollout,
• a deprecation,
• or just "not enabled on this surface."

What I want M3 to support:

Pair the model with a small, model-agnostic Agent Capabilities Protocol:

1. GET /v1/agent/manifest at session start — static JSON listing
   model, host_context, account, and capabilities[] with status
   (available / behind_flag / gradual_rollout:<pct> / deprecated
   / disabled) and a human-readable reason + expected_full_rollout.
2. A live channel (SSE / WebSocket) emitting CHANGELOG_DIFF events
   when a capability's status changes mid-session.
3. An SDK helper like
   agent.capabilities().tool("gen_videos").status() so the model can
   reason about availability before calling a tool.
4. A host-UI surface that mirrors rollout state to the end user
   ("Video gen is in gradual rollout for your account — ETA 2026-08-15").

Why this matters for M3 specifically:

M3 is positioned as a 1M-context agentic model running across many
surfaces. Without a standardized capability-discovery protocol, every
host reimplements the same rollout logic, every user gets a different
"not available" message, and every bug report is filed against a
feature the user was never supposed to see yet.

The protocol itself is model-agnostic and would also benefit M2.5 /
M2.7 / future releases. Happy to relocate this to a different repo
(e.g. Mini-Agent or a platform repo) if the team prefers.

What would "good" look like in M3?

I am happy to follow up with a PR for the schema doc (JSON schema +
worked example) and a reference SDK helper, once the team signals
this is in scope. If MiniMax-M3 is not the right home for a
model-agnostic protocol, please point me to the preferred repo and
I will relocate.

References

• Related: this is conceptually similar to MCP toolAnnotations /
  tool.listChanged notifications, extended to cover rollout state.
• No prior issue found on MiniMax-AI/MiniMax-M3 (filed on 2026-07-22).

The payload names no existing files or tests. Start by defining the GET /v1/agent/manifest contract and capability status model, then review the SSE/WebSocket CHANGELOG_DIFF channel, SDK helper, and host-UI requirements. Done means an agreed protocol schema, worked example, and reference SDK helper, but scope and repository placement still need maintainer confirmation.