Skip to content

Document that Binance refused the MCP client #5

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
angelraph merged 1 commit into from
Sep 21, 2026
Merged

Document that Binance refused the MCP client #5

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -159,7 +159,7 @@ CHARTER always executes against a real order-matching engine. It never fabricate

`mainnet-mcp` points at the real [Binance Agent OS MCP server](https://developers.binance.com/en/docs/agent-native/mcp-server), against a real, self-funded Agentic sub-account. It's used only where explicitly stated, with a small amount of real funds.

The MCP connection is not finished, and this is where it stands. `charter mcp probe` reads the server's public OAuth metadata (verified live: public client, PKCE S256, authorization code grant only, no dynamic registration, no refresh tokens). `charter mcp login`, `tools` and `status` implement the sign-in as the server describes it: the client identifies itself with an HTTPS URL that hosts [docs/mcp-client.json](docs/mcp-client.json), the browser consent happens on Binance's own page, and the code returns to a loopback listener that checks `state`. The flow is tested against a fake authorization server, including that the PKCE verifier matches the challenge. It has not been run against Binance's live consent page, so whether Binance accepts this client is unconfirmed. Order placement through MCP is not built; it waits on seeing the real tool schemas that `charter mcp tools` saves after a login.
The MCP connection is not finished, and this is where it stands. `charter mcp probe` reads the server's public OAuth metadata (verified live: public client, PKCE S256, authorization code grant only, no dynamic registration, no refresh tokens). `charter mcp login`, `tools` and `status` implement the sign-in as the server describes it: the client identifies itself with an HTTPS URL that hosts [docs/mcp-client.json](docs/mcp-client.json), the browser consent happens on Binance's own page, and the code returns to a loopback listener that checks `state`. The flow is tested against a fake authorization server, including that the PKCE verifier matches the challenge. When run against Binance's live consent page, Binance refused the client with "The AI Agent you are using is not currently supported" (error 3346001), so access to this server is limited to agents Binance has approved, and CHARTER is not one yet. CHARTER does not present itself as another agent to get around that. Order placement through MCP is therefore not built: it needs a login to see the real tool schemas. Everything else, including the live proof, runs on Binance Spot Testnet and does not depend on the MCP server.

Every audit log entry records which venue produced it. Check `data/audit.log.jsonl` to see exactly which fills were testnet and which, if any, were mainnet.

Expand Down
Loading