Schwab MCP

schwab-mcp

Your brokerage data, conversationally. Ask your AI assistant about your positions, screen option spreads, audit today's trades against your strategy rules, and get end-of-day reports — all from natural language. The data cost? About 6 sats per session (~$0.005).

Why This Exists

The data in schwab-mcp is nothing you can't get from ThinkOrSwim, OptionAlpha, or Schwab's own web UI. What you *can't* get from those tools is a personal trading assistant that blends:

• Your live positions and account balances
• Real-time option chains with Greeks, IV, and OTM%
• Your trading strategy rules (credit floors, RWR targets, sector concentration limits)
• Market context (earnings calendars, VIX levels, sector rotation)
• All of the above in a single conversational turn

Ask *"How would you judge my new trades for the day?"* and get a structured audit against your criteria. Ask *"What are three SPS candidates aligned with my strategy and balanced with my current book?"* and get sector-aware, earnings-aware, IV-aware suggestions — grounded in your actual positions, not generic advice.

The AI does the synthesis. schwab-mcp provides the data bridge. You pay per-call in Bitcoin Lightning sats — no subscription, no KYC, no vendor lock-in. A full day of morning report + evening report + follow-up analysis costs about 6 sats (< $0.01).

---

Multi-tenant MCP server exposing Charles Schwab brokerage data to AI agents via FastMCP. Monetized via Tollbooth DPYC&trade; Lightning micropayments. Serves over Streamable HTTP with direct async httpx calls to api.schwabapi.com.

Don't Pester Your Customer&trade; (DPYC&trade;) &mdash; API monetization for Entrepreneurial Bitcoin Advocates

*Inspired by The Phantom Tollbooth by Norton Juster, illustrated by Jules Feiffer (1961).*

The DPYC&trade; Economy

DPYC&trade; stands for Don't Pester Your Customer. It is a philosophy and protocol for API monetization that eliminates mid-session payment popups, subscription nag screens, and KYC friction.

How it works

1. Pre-funded balances -- Users buy credits (api_sats) via Bitcoin Lightning *before* using tools. Each tool call silently debits from their balance. No interruptions, no "please upgrade" modals. Credits expire after a tranche_lifetime window set by the operator's pricing model.

1. Nostr keypair identity -- Users are identified by a Nostr public key (npub), not an email or password. One keypair per role, managed by the user. No account creation forms.

1. Identity on the connection -- Every paid tool call names the patron's npub; the connection proves it. A client holding the nsec signs each request (NIP-98). A client holding no key connects with OAuth and proves the npub once through request_npub_proof / receive_npub_proof -- a human-in-the-loop Secure Courier exchange the patron approves in their Nostr client. The connection then holds the npub for the duration the patron chose, across MCP restarts.

1. UUID-keyed tool identity -- Every tool is a ToolIdentity object with a deterministic UUID v5 derived from a capability name. Pricing hints come from the category field:

Actual prices (api_sats) are set dynamically by the operator's pricing model in Neon.

1. Rollback on failure -- If the downstream API fails after a debit, credits are automatically rolled back via a compensating tranche. The user never pays for a failed call.

1. Social Contract -- The DPYC&trade; ecosystem is a voluntary community:

• Citizens -- Users who consume API services
• Operators -- Developers who run MCP services (like this one)
• Authorities -- Certify operators and collect a small tax on purchases
• First Curator -- The root of the chain, mints the initial cert-sat supply

Tools

Brokerage (paid -- credit-gated)

All paid tools take the patron's npub; the connection proves it.

Free

All brokerage tools are read-only. No orders are placed.

Architecture

• Multi-tenant: operator delivers btcpay_host + btcpay_api_key + btcpay_store_id + app_key + secret via Secure Courier (service="schwab-operator"); each patron authenticates via OAuth2 browser flow. Sessions are keyed by npub. No Schwab credentials in env vars
• Direct httpx: thin SchwabClient wrapper with bearer auth and proactive token refresh (no third-party Schwab SDK)
• Tollbooth DPYC&trade;: pre-funded Lightning balances, Authority-certified purchase orders, NeonVault (Postgres) for ledger persistence
• Registry discovery: OAuth2 collector URL resolved from DPYC&trade; registry at runtime (no OAUTH_COLLECTOR_URL env var needed)
• Credential validation: operator credentials are validated at receive time -- btcpay_host, app_key, and secret must all be present before vaulting
• Identity on the connection: a request signed with the npub's key (NIP-98), or an OAuth connection that holds the npub after one Secure Courier DM. Survives restarts; patron-chosen duration. Restricted tools (operator-only) need the operator's npub proven the same way.

---

Getting Started

This guide covers the full Tollbooth onboarding path -- from generating a Nostr identity to making your first brokerage data call. It applies to both Operators (who deploy schwab-mcp) and Patrons (who consume it through Claude.ai or another MCP client).

1. Get a Nostr Identity (npub)

Every participant in the DPYC&trade; ecosystem is identified by a Nostr keypair -- no email, no password, no vendor lock-in.

What is an npub? It is a public key in the Nostr protocol, encoded as a bech32 string starting with npub1.... Your corresponding private key (nsec1...) stays on your device. The npub is safe to share -- it is how the system knows who you are.

How to generate one:

1. Install Oxcart (the preferred Nostr client for DPYC&trade; workflows; other clients have not been tested)
2. Create an account -- the app generates your keypair automatically
3. Find your npub in the app's profile/settings screen (it starts with npub1...)

Alternatively, use a CLI key generator like nak: nak key generate

Operators should keep a separate npub for their service identity, distinct from their personal Nostr account.

2. Register as a DPYC&trade; Citizen

Before you can buy credits or operate a service, register your npub with the DPYC&trade; community:

1. In Claude.ai (with the DPYC Oracle connected), call how_to_join() to learn about citizenship
2. Follow the Oracle's instructions to register your npub

Citizenship is free and gives you a portable identity across the entire Tollbooth network.

3. For Operators -- Set Up Your BTCPay Store

The Operator collects Lightning payments from Patrons via BTCPay Server. You need:

• A BTCPay Server instance (self-hosted or hosted by your Authority)
• A Store ID and API Key with invoice creation permissions

These credentials are delivered via Secure Courier (see step 6), not set as environment variables.

4. For Operators -- Register with a Tollbooth Authority

Every Operator is sponsored by an Authority in the DPYC&trade; trust chain. The Authority certifies your purchase orders and collects a small fee (default 2%).

1. On your own Schwab MCP, call request_adoption(authority_npub= , service_url= ), signing the request with your operator nsec (NIP-98; Pricing Studio does this for you)
2. The Authority's owner approves it (approve_operator_request), which creates your ledger entry and provisions your Neon database
3. adoption_status(authority_npub=...) on your MCP reads provisioned once it is done

5. For Operators -- Fund Your Certification Balance

Before your service can issue credits to Patrons, you need cert-sats:

1. Call authority_purchase_credits(amount_sats=1000) on your Authority -- returns a Ligh