DEV Community: Calix

Building a read-only MCP server where a connector token can never become a login

Calix — Sat, 31 Oct 2026 11:46:25 +0000

I run a read-only crypto portfolio tracker (last time I wrote about how far back each exchange's API actually lets you go), and I wanted people to ask ChatGPT, Claude or Cursor questions about their own portfolio. That meant an MCP server, and an MCP server means handing a token to a third party whose context window I do not control. This post is about the one design decision that matters most there: making sure that token can never be used as a login to the rest of the app.

The code is a Fastify API. Everything below is simplified from it.

The trap: any Bearer is a session

Our auth hook runs on every /api request. It reads a token from the session cookie, or failing that from Authorization: Bearer, and verifies it:

// simplified from the session path
const token = readAccessToken(req);          // cookie first, then Bearer header
const claims = token ? verifyAccessToken(token) : null;
if (!claims) return reply.code(401).send({ error: 'authentication required' });

const row = await users.byId(claims.uid);
if (!row || row.token_version !== claims.ver) {
  return reply.code(401).send({ error: 'session expired' });
}
req.user = toSafeUser(row);
req.tenantId = row.active_profile_id;

That is fine for a browser and for the iOS app. The problem is what it implies: a token that passes verifyAccessToken is accepted on every route. So if I had minted the MCP connector's token with the same signer, then handing it to ChatGPT would have handed ChatGPT a full session. "Read-only" would have been a description of what I hoped the client would do, not a property of the credential.

You can scope tokens with claims, but then every route has to remember to check the claim. I did not want a security property that depends on every call site remembering.

A separate HMAC domain

So MCP tokens are signed in their own domain. Same secret, different signed input:

const PREFIX = 'mcp_';
const DOMAIN = 'mcp.v1:';

function mac(body: string) {
  return createHmac('sha256', authSecret())
    .update(DOMAIN + body)          // session tokens sign just `body`
    .digest('base64url');
}

export function signMcpToken(claims: McpClaims) {
  const body = Buffer.from(JSON.stringify(claims)).toString('base64url');
  return `${PREFIX}${body}.${mac(body)}`;
}

The mcp_ prefix is only a marker so we can reject obvious strangers before running any crypto. The real separation is the mcp.v1: string folded into the MAC. A session verifier computes its MAC over body, the MCP verifier over mcp.v1:body, so neither signature can satisfy the other. An MCP token presented to /api/trades is not a weaker session. It is not a session.

I wrote the tests in both directions, because only one of them is scary:

it('an MCP token is NOT accepted by the session verifier', () => {
  expect(verifyAccessToken(signMcpToken(CLAIMS))).toBeNull();
});
it('stripping the prefix does not help', () => {
  const stripped = signMcpToken(CLAIMS).slice('mcp_'.length);
  expect(verifyAccessToken(stripped)).toBeNull();
});
it('a session token with mcp_ bolted on is not an MCP token', () => {
  expect(verifyMcpToken(`mcp_${signAccessToken('u1', 3)}`)).toBeNull();
});

The honest tradeoff: one secret signs both domains. I chose domain separation over a second secret because it removes a rotation and storage problem, and the tests pin the property. If you would rather have two secrets, that is a reasonable call too.

The MCP endpoint authenticates differently

/api/mcp is branched out of the normal hook before the session check:

if (isMcpEndpoint(req.url)) {
  if (req.method === 'OPTIONS') return;   // preflights carry no credentials
  await authenticateMcp(req, reply);
  return;
}

authenticateMcp does four things, and the order is deliberate:

Verifies the mcp_ token and its expiry.
Requires the read scope.
Looks up the grant row on every call and rejects it if it is revoked or expired.
Checks the user's token_version against the one in the token.

It never falls back to the session cookie. A browser signed in to the app should not be able to drive the MCP endpoint through ambient authority. The grant means "the user approved this connector", and a cookie carries no such approval. It would also be a CSRF surface on a POST endpoint.

Re-dispatch with a freshly minted session token

Here is the awkward part. The read tools do not query the database themselves. Almost every one calls an existing read endpoint in-process with app.inject(), so the MCP surface inherits tenancy scoping and Pro gating instead of reimplementing them. (The one exception, the portfolio overview, builds its summary directly and applies its Pro gate by hand, which is exactly why I wanted the rest to inherit theirs.) But that injected request runs the real auth hook again, and the hook would reject an MCP token, because it is deliberately not a session.

So the route mints a fresh, short-lived session token for the same user and forwards that:

function redispatchAuth(user, tokenVersion, profileId) {
  return {
    authorization: `Bearer ${signProfileScopedAccessToken(user.id, tokenVersion, profileId)}`,
  };
}

// inside a tool
await app.inject({ method: 'GET', url, headers: injectHeaders(auth) });

The injected request is indistinguishable from the user's own browser, with the same tenant and the same capability gates, and it exists only inside the process for the length of one tool call. The MCP token itself stays useless anywhere but /api/mcp. The portfolio the call targets travels inside the minted token as a signed claim, and the hook re-checks ownership of it rather than trusting the signature alone.

Read-only, as a property of the executor

The server exposes 15 tools: 13 reads and 2 writes that can only propose. The reads are grouped by the question they answer, with a view argument that picks the endpoint, so get_money_flows with view capital_flow returns deposit and withdrawal totals in dollars. Every endpoint-backed view names a path, and every one runs through the same executor, which refuses any path outside an allowlist and hard-codes the method:

const res = await app.inject({ method: 'GET', url, headers: injectHeaders(auth) });

There is no method parameter to widen, and a test checks every view's path against the allowlist, so a new view cannot quietly reach a route that is not on it. The server instructions tell the model plainly that it cannot trade, move funds or read exchange API keys. Annotations are set per tool rather than as a blanket default: readOnlyHint: true on the reads, false on the two writes. A client reads that hint to decide whether to ask the user before calling, so stamping it on a write would switch off the very confirmation the next part relies on.

The two writes, set_target_allocation and propose_alert_change, still cannot write. They need a separate portfolio:write scope that the user approves on the consent screen, and even then the tool only validates, renders a diff, parks the payload and returns a link. The change applies only when the user opens that link in their own browser, under their own session cookie, reads a server-rendered before and after, and clicks Apply. The confirm routes are session-authed and origin-checked, and an MCP token is not a session (that is the whole point of the separate domain), so a connector cannot approve its own proposal. Prompt injection into the AI client can produce a perfectly authentic tool call. It cannot produce my browser session.

What this does not defend against is a user who clicks Apply without reading. It turns an invisible write into a visible one.

Revocation

Three directions, because "disconnect" has to mean disconnect:

Per connector. Revoking one grant flips its row, and since the row is read on every call, the next request from that app fails. Refresh tokens are stored only as hashes and rotate on use.
Account-wide. token_version is bumped on "sign out everywhere", and it is checked against both session and MCP tokens. Otherwise logging out of everything would quietly leave an AI client still reading your portfolio.
Account deletion. The grant row cascades.

And it has to be findable. Grants are listed in Settings, each with its client label, scope, last used time and the portfolio it reads, with a revoke button. A grant with no visible off switch is a leak with a consent screen in front of it.

What I would check if you build one

Do your session and connector credentials verify against each other? Test both directions, and test the stripped-prefix case.
Is the grant checked per call, or only when the token is minted?
Does "sign out everywhere" reach connectors?
Can a connector reach the endpoint that approves its own writes?
Does the redirect URI match exactly, with no prefix or wildcard matching?

If you want to try the connector, the public setup page is here: whereitgoes.money/connect-ai.

I build WhereItGoes; this article was drafted with AI assistance and checked against the code.

How far back each exchange's API actually lets you go (11 exchanges compared)

Calix — Sun, 25 Oct 2026 07:40:00 +0000

I build a read-only crypto portfolio tracker, which means I spend a lot of time asking exchange APIs for old trades and finding out how little they will give me. We integrate 11 exchanges, and I keep one manifest of how far back each one will actually serve history. This post is that manifest, with the endpoints behind it.

The short version: two different limits get confused, and only one of them is a problem.

Window caps versus retention walls

A window cap limits how much time a single request may span. HTX's match results accept at most a 48 hour span. Bybit's execution list works in 7 day windows. Gate.io allows 30 days, Bitget 90, Upbit 7. These are annoying, but they are not limits on your history. You loop backwards in chunks and eventually reach the start of the account. If your tool says "only 7 days available" because of a window cap, the tool is lazy, not the exchange.

A retention wall means the data no longer exists behind the API. Nothing you write can recover it. OKX serves about 90 days of fills. MEXC serves about a month. Bitget about 90 days. HTX about 120. A wall is a fact about the exchange, and it decides how much of your cost basis can be rebuilt from an API key.

Conflating the two would put a warning on six venues about caps we walk through without trouble, so the manifest deliberately lists only walls. Splitting them is the most useful thing in it.

One more distinction that bit me: the same venue can have a wall on one surface and none on another. OKX serves its funding ledger (deposits, withdrawals, fiat, rewards) back to February 2021, while its savings interest is a rolling 30 days. A year-old month shows real deposits next to a confident zero of earnings.

The table

Numbers come from the manifest in our repo (packages/ui/src/history-limits.ts), which a test keeps in sync with the adapter registry, so a new venue cannot ship without declaring its limits. "Full" means no retention wall: the API reaches account opening. "About" is on purpose; exchanges do not promise these figures, and I would rather round than imply a contract.

Exchange	Trade history	Deposits / withdrawals	Endpoints and quirks
Binance	Full	Full	`/api/v3/myTrades` requires a symbol, so there is no account-wide trade feed: you have to know which pairs to ask about. A coin bought and fully sold, with no deposit or withdrawal pointing at it, is named only by the daily account snapshot (`/sapi/v1/accountSnapshot`), which reaches about 30 days back. Transfers (`/sapi/v1/capital/deposit/hisrec`, `withdraw/history`) walk in 90 day windows back to account opening.
OKX	About 90 days	Full (funding bills back to Feb 2021)	`/api/v5/trade/fills-history` serves roughly 3 months. A deeper `/api/v5/trade/fills-archive` exists but needs a separately requested download, and returned 404 for the account shape I tested. Savings interest on `/api/v5/finance/savings/lending-history` is a rolling 30 days.
KuCoin	Full	Full	Per-fill data (`/api/v1/fills`) is only 7 days, but done orders (`/api/v1/orders`, status done) reach account opening with a 7 day range cap per query, so trades are reconstructed from orders. `/api/v1/accounts/ledgers` is capped at 1 year with a 24 hour query window.
Gate.io	Full	Full	`/spot/my_trades` and `/wallet/deposits` use a 30 day request window, walked back in full.
Bybit	About 2 years	Full	`/v5/execution/list` retains roughly two years of executions and is queried in 7 day windows. Older fills come back empty rather than as an error.
Coinbase	Full	Full	Advanced Trade fills (`/api/v3/brokerage/orders/historical/fills`) are cursor paginated with no retention floor. Simple-mode buys and sells are not in that feed at all; they live on the legacy v2 `/v2/accounts/{id}/buys` and `/sells` endpoints, which Coinbase has deprecated but still serves, with the real fiat amount.
Kraken	Full	Full	`/0/private/TradesHistory` is account-wide, and `/0/private/Ledgers` carries the movements. Both reach the start.
Bitget	About 90 days	Full	`/api/v2/spot/trade/fills` has a 90 day wall. Deposit and withdrawal records (`/api/v2/spot/wallet/deposit-records`) walk 90 day windows back to the 2018 launch.
Upbit	Full	Full	`/v1/orders/closed` is queryable 7 days at a time; you walk back about 11 years. Markets are KRW based.
MEXC	About a month (31 days)	About 90 days	`/api/v3/myTrades` plus 7 day windows inside a hard retention limit. Older data is only available as a manual export from the website.
HTX	About 120 days	About a year	`/v1/order/matchresults` caps each query at 48 hours and returns at most 500 rows per page, so a busy window has to be split. Transfers come from `/v1/query/deposit-withdraw`.

Five of the eleven have a trade wall: OKX, Bybit, Bitget, MEXC and HTX. MEXC and HTX also wall transfers. For KuCoin the honest summary is "full history", even though one of its endpoints is walled at 7 days; I document the outcome, not the endpoint.

A note on sourcing. The OKX figures were verified against a real account in September 2026, and the KuCoin ones were re-checked against KuCoin's own docs in August 2026. The rest are the limits recorded in each adapter from earlier probing, and I did not re-probe all of them for this post. Re-probe before you build on any of it. Exchanges change these quietly.

Why this matters at year end

This is the part that made me write the post. Walls are measured from today, not from the start of the year. If you read the API in the last week of October 2026, the reach is roughly:

OKX and Bitget, 90 days: back to late July
HTX, 120 days: back to late June
MEXC, about a month: back to late September
Bybit, about 2 years: back to late October 2024

By 31 December the same walls reach back only to about 2 October (OKX, Bitget), 2 September (HTX) and 30 November (MEXC). Anything you traded earlier in 2026 on those venues will be gone from the API by then. It is not hidden, it is deleted from the API's point of view. Bybit's two year wall means 2024 trades are the ones leaving now.

The consequence is not abstract. On one real OKX account, 90 days of fills against an account funded since March 2024 left about 27 months of buys unrecorded. It surfaced as "you hold 87 LINK the ledger has never seen". A tool built on such an API will quietly compute a cost basis that is wrong forever, and the symptom does not tell you whose fault it is.

What to do about it now

Export CSVs from each exchange's web UI before the wall moves. Trade history and deposit/withdrawal history, the longest range each site allows. For MEXC, this is the only route to anything older than the API serves. Do the venues with the shortest walls first: MEXC, then OKX, Bitget, HTX.
Do it per account and per product. Spot, funding, earn and derivatives are separate ledgers. OKX derivatives bills, for instance, are 7 days live and 3 months archived.
Store the files somewhere you control. An export is the only copy you will ever have of the data the API has already dropped.
If you build against these APIs, record the first sync date. A history that starts at your first successful sync is a different claim from a history that starts at account opening, and your users will want to know which one they have.
Do not let a lazy walk truncate you. Never stop a backward window walk after N empty windows. Real accounts have long gaps, and you will silently lose everything older.

None of this is tax advice. It is just arithmetic about which dates are still reachable.

If you only want to see how an allocation would have held up, rather than rebuild old trades, the free in-browser stress test needs none of this history: whereitgoes.money/stress-test.

The per-exchange breakdown I maintain for users is on whereitgoes.money/exchanges.

I build WhereItGoes; this article was drafted with AI assistance and checked against the code.