[Tracker] Broker connector requests: what a new broker needs before it can be supported

This is the single tracking issue for new broker connector requests, replacing the one-issue-per-broker threads that were drifting without a decision. Requests consolidated here: Scalable Capital (#1360), Upbit / Korea Investment & Securities / Toss Securities (#1364), mStock / Mirae Asset (#542).

What decides whether a broker can be supported, and how far

Every connector lands in one of three tiers, and which tier is not our preference — it is a property of what the broker's own API exposes:

Tier	Requirement	What ships
Read-only	A documented read API (REST or an official MCP server)	trading_account / trading_positions / trading_orders / trading_quote / trading_history, plus portfolio aggregation when the profile advertises account.read + positions.read
Paper	A sandbox, or a local simulation under a hard guard	The above plus paper order placement, which skips the mandate gate because it cannot reach a real account
Bounded live	A structural runtime paper/live discriminator the server reports — account-id format, host separation, a demo flag, or a trade-environment field	Live order placement through the mandate gate, kill switch, and audit ledger

The third row is the one that decides most of these. A broker that exposes no server-reported discriminator is capped at paper and read-only, and its place_order / cancel_order hard-refuse any non-paper config at the first line. That is not a policy we can waive per broker: a config flag the agent could flip is not a boundary. Longbridge, Dhan, Shoonya and Zerodha all sit at that cap today; Trading212 goes further and refuses order placement entirely.

What a request needs before it can be picked up

Anyone proposing a broker — including the three consolidated here — please post:

1. The read surface: a link to the API docs, or for an MCP server the tools/list output (tool names and argument schemas, no account data).
2. The discriminator answer: does the API expose a sandbox, or any field in an account/session response that tells a live account from a test one? A "no" is a useful answer — it sets the tier, it does not disqualify the connector.
3. Auth shape: OAuth, API key, or session token, and whether it can be issued for a read-only scope.

agent/src/trading/connectors/robinhood/ is the template for a remote-MCP broker and agent/src/trading/connectors/alpaca/ for a direct SDK; a connector is a sdk.py + profiles.py + classification.py triple plus its entry in src/trading/profiles.py.

Status

• Scalable Capital — Agentic Investing is real (MCP endpoint https://mcp.scalable.capital/mcp, enabled under Profile > Security, every trade confirmed on Scalable's side). Blocked on item 1: nobody maintaining this repo has a Scalable account, so we cannot see the tool list.
• Upbit / KIS / Toss — Upbit and KIS both publish REST APIs; KIS documents a mock-trading domain, which reads like a host-separation discriminator and would make it the most promising of the three. Needs item 2 confirmed against the live docs.
• mStock (Mirae Asset) — awaiting the discriminator answer from the broker, which @noob-coder-19 went to ask directly.

PRs welcome for any of them. Post the three items on this issue first so the tier is settled before the code is written — that is the part that is expensive to get wrong.