Reading the tape in a window we don't own

At 07:20 on a Wednesday in April, an analyst I've had on a call most months is writing a memo in one window with our feed open in a tab behind it. Single-sector fund, healthcare, a bit under $70m. She's four paragraphs into an argument about a mid-cap and she needs to know what the company has actually said since Friday.

So she tabs across. Filters to the ticker, reads down, opens a row, copies the headline and the link, tabs back, pastes both, types "this one, what do you make of it". Then she does it twice more, because there turned out to be three items and she'd assumed there was one.

Call it ninety seconds a round trip. She did some version of it eleven times that morning. The cost was never the ninety seconds. It's that somewhere around the third trip she stopped writing the memo and started operating a clipboard, and the memo is the job.

Eight tools, and a good session uses two

What replaces the clipboard is a local MCP server. It runs on her machine over stdio, talks to our API with her key, and gives whatever model she's working in a set of tools it can call mid-answer without her leaving the paragraph she's in.

There are eight of them. search_feeds and get_feed do almost all the work. score_artifact runs the Verdict Engine over text you hand it. list_symbols, get_symbol, list_tags and list_sources are reference data, and they exist mostly so the model can look up what a valid filter value is instead of guessing Earnings when the tag dictionary says earnings. account reports which plan the key is on and what it has spent today.

Now she types the question into the memo window. The model calls search_feeds with symbol set to the ticker and since set to Friday's date, gets back a count, a cursor and a list of items trimmed down to nine fields each: id, title, source, published_at, link, actionability, actionability_score, sentiment_score, symbols. That trimming is deliberate and it has one consequence worth knowing. The reasoning string isn't in it. If the model wants to know why an item scored 71, it has to call get_feed with the id, which returns the fuller record including actionability_reasoning and sentiment_reasoning.

Which is fine, and is also two requests instead of one, and both of them are metered.

Nobody watches this counter, which is the point and also the risk. A model that decides to be thorough will call get_feed on nine rows because it can, and a long research session can spend a few hundred requests without anyone feeling it. Tell it to call account when you're curious. That one is free, deliberately, because a tool that charges you for asking how much you've spent is a bad tool.

One config block, one key, nothing else in the loop

Setup is a bearer key in the client's env config and nothing more. No OAuth handshake, no browser round trip, no per-client app to install. Claude Desktop and Cursor both take the same block:

{  "mcpServers": {    "forecite": {      "command": "npx",      "args": ["-y", "@forecite/mcp"],      "env": { "FORECITE_API_KEY": "fc_live_your_key" }    }  }}

Claude Code takes the equivalent as a single claude mcp add forecite invocation with the key passed as an env flag, and /mcp in a session tells you whether it connected. The server reads FORECITE_API_KEY at boot and exits with a message on stderr if it's missing, because stdout belongs to the protocol and anything we print there corrupts the transport.

Two things follow from that simplicity, and one of them is a caveat. We only ever store the SHA-256 of your key plus its first twelve characters, so the dashboard can show you fc_live_a1b2 without holding the secret. Revoke it and every client using it stops working on the next call. But the key itself sits in a config file on your laptop in plaintext, which is how every MCP client works today and is not something we've solved. If that's outside what your compliance team allows, this is the wrong integration and I'd rather you find out here. Key counts by plan: Free gets 1, Starter 3, Pro 10, Quant as many as you want.

Where your plan stops, and how quietly

Here's the one that generated support email, and it's ours.

Both feed tools go through GET /v1/feeds, which is a paid endpoint. On Free the server returns a 403 with historical_api_unavailable and the model relays some version of that back to you, so at least the failure is loud. Scoring is a harder gate: score_artifact needs Pro or above, and Starter keys get a 403 saying so.

The quiet one is lookback. Starter reaches back 48 hours, Pro 30 days, Quant a year. Ask a Starter key for everything on a ticker since January and the server takes the later of your since and the plan floor, then answers. No warning, no flag in the payload. The model sees an empty list and tells you, in perfectly good faith, that the company hasn't published anything. It has. You just can't see it from here. I've watched that happen in a live session and the analyst believed the answer. So when an agent tells you a company has gone quiet, check the window you're asking through before you believe it.

Don't ask it to watch anything

This is a research tool for a person who is mid-thought. It is not a monitor.

There's no subscribe tool and no streaming tool in the server. Nothing here pushes. If you want a row to arrive on a screen the moment it's scored, that's the WebSocket feed and the dashboard, and pointing a model at search_feeds in a polling loop is a worse version of both, plus it burns your daily quota to discover that nothing changed. The same goes for anyone hoping to run a desk out of a chat window. Two windows is still the right answer: the feed watches, the chat thinks.

The thing I keep coming back to isn't a ninth tool. It's that people don't think in corp_activity and market_country. They think in "my energy book", which is a filter they already built and named and can see in a sidebar. Getting a chat window to speak in someone's own vocabulary rather than the schema's is the interesting problem here, and it's a naming problem long before it's an engineering one.