Developers: MCP server, SDK and API

Everything you can trade in the app is open to code and AI agents, through an MCP server, a TypeScript SDK and a REST API. All three follow one rule: nothing is ever signed or sent for you. They read markets and accounts and prepare transactions; your wallet signs each one.

Connect an AI agent (MCP)

bskts runs a Model Context Protocol server at https://api.bskts.xyz/mcp. Add it to Claude, ChatGPT, Cursor or any MCP client, and your agent can read the baskets, check a wallet, and prepare buys, sells and orders for you to sign. No install, no key, no account.

claude mcp add --transport http bskts https://api.bskts.xyz/mcp

{ "mcpServers": { "bskts": { "url": "https://api.bskts.xyz/mcp" } } }

• Claude (desktop and web): Settings → Connectors → Add custom connector, and paste the URL.
• ChatGPT: on plans with Developer mode, add a custom connector with the URL and no authentication.

To set your own limits, run it on your machine instead. The agent then can’t prepare a trade above your size cap or outside the baskets you allow:

{ "mcpServers": { "bskts": {
  "command": "npx", "args": ["-y", "@bskts/mcp"],
  "env": { "BSKTS_MAX_USD_PER_TRADE": "100", "BSKTS_ALLOWED_TICKERS": "DIGI64,MAG6" }
} } }

The tools:

• bskts_markets, bskts_basket: every basket’s NAV, 24h change and buy cost; one basket’s holdings, risk note and recent performance.
• bskts_account: a wallet’s USDG, ETH for gas, positions with PnL and open orders.
• bskts_buy, bskts_sell, bskts_order: prepare a buy, a sale to USDG, a limit buy, a stop-loss / take-profit, or a cancel.
• bskts_guide: the full trading guide, read on demand.

TypeScript SDK

@bskts/sdk is a typed client for the API, for your own app, bot or agent: every response checked against its schema, amounts as exact bigints, a dry-run guard and optional limits. It signs through viem, in a browser or on a server.

npm i @bskts/sdk viem

import { BsktsClient, robinhood, viemSender } from "@bskts/sdk";
import { createPublicClient, createWalletClient, custom } from "viem";

const wallet = createWalletClient({ chain: robinhood, transport: custom(window.ethereum) });
const [address] = await wallet.requestAddresses();
const sender = viemSender(
  createWalletClient({ account: address, chain: robinhood, transport: custom(window.ethereum) }),
  createPublicClient({ chain: robinhood, transport: custom(window.ethereum) }),
);

// guard rails, checked before anything is built
const bskts = new BsktsClient({ policy: { maxUsdPerTrade: 250 } });

const { markets } = await bskts.markets();        // NAV, 24h change, buy cost
const account = await bskts.wallet(address);      // USDG, ETH for gas

// buy $100: approval first if needed, then the buy (your wallet signs both)
await bskts.execute(await bskts.buildBuy({ ticker: "DIGI64", amountUsdg: 100, address }), sender, { wait: true });

// later: sell everything back to USDG
await bskts.execute(await bskts.buildSell({ ticker: "DIGI64", address }), sender, { wait: true });

Errors carry a stable code (POLICY, SIMULATION_FAILED, INSUFFICIENT_SHARES, NO_ROUTE and so on) and say whether a retry may succeed. Source, full reference and the MCP server live in the open at github.com/Tokenise-au/bskts-sdk.

REST API

Under both sits a public, keyless API at api.bskts.xyz: read endpoints return market and account data, and the /v1/tx/* endpoints return unsigned calldata you sign with your own wallet. It never holds keys and never broadcasts on your behalf.

• Approval, then transaction. Each /v1/tx/* response is { approval, tx, simulation }. When approval isn’t null, send it and wait for it to confirm before sending tx.
• Dry run. simulation.ok is true when the transaction passed as your address, false (with a reason) when it would revert, and null when it can’t run yet (send the approval first).
• Units. Dollars, NAVs and PnL are plain numbers; on-chain amounts (anything ending in Wei, and shares in requests) are integer strings in base units: 18 decimals for shares, 6 for USDG. Send walletSharesWei back exactly as you received it.
• Errors are { error, code, retryable }: branch on code, not the message.
• Compact by default. Responses are minified; ?fields= trims rows, ?format=summary turns NAV history into five numbers, and ?pretty=1 indents for reading.

Agent API

Setting up an agent? See AI agents. Building one? Give it its own signing key through its host wallet or secure signer. Share only the public address. In the Agents tab (next to Portfolio), connect that address and approve its limits once; Portfolio’s Agents view then lists everything the agent does. The suggested daily turnover is 10% of available account USDG (at least $10), capped at $100, with 0.5% maximum slippage and seven days of access. Deposits do not increase the approved limit.

Agents with a shell (OpenClaw, Hermes, Claude Code) need none of this: the bskts skill does it for them. See AI agents.

The agent checks /v1/agent/session?owner=0x…&key=0x…, then builds buys or sells with /v1/agent/trade. Its host signs the returned session Action and submits it to the relayer. Trades need no owner popup or ETH in the owner or agent wallet; network fees are paid separately in account USDG. Only your wallet can approve changed limits or renew access.

The SDK provides agentSession, buildAgentTrade,executeSession and sessionRelayer. The MCP toolsbskts_agent_session and bskts_agent_trade return unsigned plans for your host signer. Never paste a private key into the MCP, API or dashboard. Revoking a key stops new requests; existing orders and schedules must be cancelled or stopped separately in Portfolio.

For an agent that can restart, SDK 0.5.0+ provides executeSessionOnceand sessionActionState. Save the unsigned plan before signing and retain its outcome. Node hosts can use fileSessionStore from@bskts/sdk/node. Keep the journal, even after success: restarting checks the original nonce and never submits that operation again. Use a new journal ID only for a deliberate new trade after reconciliation. Store no keys or signatures in the journal.

Agent trading is newly released and still being tested. Agents can also buy Weekend Cover on baskets the account holds, once Cover is enabled for the account: take offers, request cover or cancel their own request (/v1/cover/* to read,POST /v1/agent/cover to build). Cover counts spending separately against the same daily limit, and a session pays at most 3% of the cover. The agent tools never underwrite: offering cover needs the owner’s own allowance. Open Cover listings remain after an individual key is revoked; withdraw them in My cover.

Earn fees by executing orders

Resting orders and scheduled buys are public jobs: anyone may execute a triggered one and keep its fee, max($0.25, 0.15%) of the order, up to 1%. GET /v1/jobs lists every job executable right now with its calldata and fee. Each fill is held to the order’s on-chain price floor, so simulate before sending.

Building on basket tokens

A basket share is an ordinary ERC-20 with two properties that make it safe to build on: anyone holding it can redeem in kind at any time, with no fee and no permission, and its price is readable on-chain: navPerShareE18() computes it from the vault’s own balances and its constituents’ pool prices, with no external feed and no trust in bskts.

• Price a share from NAV, never from a share/USDG pool. Such pools are thin; a small trade moves their quote far more than the basket’s value. NAV is the number the redemption right enforces.
• Liquidation doesn’t need a share market: redeem in kind and sell each constituent into its own, much deeper pool (/v1/leverage/sell-routes returns those swaps).
• navPerShareE18() reverts while a price read fails; in-kind redeem keeps working throughout, because it reads no prices.
• Baskets holding Stock Tokens trade around the clock but follow equity market hours, so overnight and weekend gaps are real; size margins for them.

Machine-readable: openapi.json, and for AI agents the API’s trading guide, this page as markdown and the product’s llms.txt.