Disclosure: I run TradingAIHub, an independent directory of finance MCP servers, agent skills and APIs. All the numbers below come from its public data (tools.json and the 29 October 2026 verification run). This post has no affiliate or partner links.

AI-assist note: I drafted this with help from an AI assistant, then reviewed and edited it myself. I checked every figure against the live pages on 29 October 2026.

Nothing here is investment advice. These tools fetch data or place orders you tell them to. None of them predicts markets.

If you search "TradingView MCP", "Binance MCP" or "FMP MCP", you get a mix of servers published by the vendor and servers written by someone who uses the vendor's API. Both kinds can be good. But they fail in different ways, and when the server can read your brokerage account or place orders, you should know which kind you're installing.

Below is what I learned from labelling 104 finance tools (73 MCP servers, 16 APIs, 15 agent skills) as official or community and re-checking all of them every week.

The split, and what it says about reliability

Of the 104 listings, 61 are official (published by the company whose product or data they expose) and 43 are community projects.

On the 29 October 2026 run, a listing counted as "passing" if its repo was reachable, its links worked, and (for repos) it had a commit in the last 180 days. Here's how the two groups did:

Two takeaways:

1. Community servers mostly fail by going quiet. 15 of the 16 that didn't pass are stale or aging. Nothing broke loudly. The maintainer simply moved on.
2. "Official" is not a guarantee. Six official listings didn't pass. Two are archived by their own vendors (Base MCP, Ramp MCP), two are stale, and two need review. One of those two has a repo that now redirects to a different GitHub owner. The other has a hosted endpoint that returned 401 to an unauthenticated check.

The split also varies a lot by category. Every listing in payments and banking is official (10 of 10). In quant and backtesting it's 3 of 11, in research and filings 3 of 10, and in personal finance 2 of 7. If you're building on budgeting or backtesting tools, you'll mostly be choosing between community projects, so maintenance signals matter more.

Six ways to tell official from community

1. Who owns the repo, not what the repo is called

Look at the GitHub owner, not the project name. Official finance servers in the directory live under organisations such as alpacahq, stripe, paypal, coinbase, square, krakenfx, webull-inc, XeroAPI and intuit.

The word "official" in a name proves nothing. The community Binance MCP lives under an account called TermiX-official. It isn't published by Binance, and it was stale on the last run (no commits for 561 days).

2. Hosted endpoints on the vendor's own domain

More and more official finance servers are hosted rather than installed. Examples:

• https://mcp.alphavantage.co/mcp
• https://mcp.finnhub.io/mcp
• https://mcp.eodhd.com/v2/mcp
• https://mcp.api.coingecko.com/mcp
• https://mcp.tradingview.com/mcp
• Robinhood's https://agent.robinhood.com/mcp/trading

If the endpoint is on the vendor's domain and the vendor's docs link to it, that's about as clear a signal as you'll get. Community servers are almost always run locally with npx or uvx, using your own API key in an environment variable.

3. Does the package link back to the repo?

This is the check that catches the most surprises. When a README says npx some-name or pip install some-name, look up that name on npm or PyPI. Then confirm the registry entry's repository field points back to the same GitHub repo.

On the latest run, 10 listings named a package whose registry entry doesn't link back. Six were community projects and four were official. Square's official MCP server is one of them: the repo is verified and active, but the npm entry for square-mcp-server doesn't link to it.

That doesn't mean the package is malicious. It means you can't tell from the registry alone, so install from the vendor's documented command or straight from the repo.

4. Repo redirects

GitHub silently redirects renamed or transferred repositories, so an old link keeps "working". That's convenient, but it also means a link can end up pointing at a different owner without anyone noticing.

On the latest run, the stored link for one large, official research platform redirected to a different organisation. We flagged it as Needs review rather than verified. If git remote -v or your browser's URL bar shows a different owner from the one you expected, find out why before you install.

5. "Not affiliated" disclaimers and naming

Good community projects say what they are. The most-starred TradingView server in the directory (5.2k stars, commit 28 October 2026) describes itself as an unofficial community MCP, not affiliated with TradingView. TradingView's own server is a separate, hosted product.

The two differ in practical ways:

• Official TradingView server: hosted, OAuth login, public beta. It isn't included in free or trial plans.
• Community server: self-hosted and free to run. It adds things like backtests.

Neither is "the right one". They're different products that happen to share a name.

FMP is a second example. The official hosted server exposes 27 dataset tools. A well-maintained community server wraps 250+ FMP endpoints. Both use your FMP plan and its limits.

6. Auth model and data source

Official hosted servers increasingly use OAuth. Finnhub, TradingView (OAuth 2.1, no API keys) and Robinhood's agent endpoint (OAuth with PKCE) all do, and EODHD accepts either an API key or OAuth. Community servers usually take a raw API key.

Also ask where the data comes from. A community server built on a vendor's official SDK (the community YNAB server is one, with an optional read-only mode) is a very different risk from one that scrapes an undocumented endpoint.

When community is the better choice

Community doesn't mean worse. Several of the most useful finance tools have no official MCP server in the directory. (SEC and FRED do publish official APIs, but not MCP servers.)

• an SEC EDGAR MCP server (380 stars)
• a Schwab MCP server
• a tastytrade agent
• a FRED server
• the most popular trading skill pack in the directory (3.4k stars)

Where an official server does exist, the community version sometimes covers more endpoints (FMP) or more features (TradingView).

What matters is that you check the things that actually fail. With community projects, that's mostly maintenance. With official ones, it's mostly archived repos, moved repos and access changes.

A two-minute checklist

Before you connect an MCP server to a brokerage, exchange or bank account:

1. Find the repo owner. Is it the vendor's organisation, or does the README say "not affiliated"?
2. Check the last commit date. Over 180 days is worth a second look. Over a year, test it carefully before relying on it.
3. Look up the npm or PyPI name and confirm it links back to that exact repo.
4. Prefer the vendor's documented install command or hosted endpoint.
5. Use read-only or paper-trading keys first, with the smallest permissions that work.
6. Re-check it later. On the latest run, 16 of 43 community listings and 6 of 61 official listings weren't passing.

The full per-tool results, including the failures, are public on the verification page. If you maintain one of these servers and something there is wrong, please tell me in the comments.

The number of MCP servers and agent skills for finance has grown fast. You can now point Claude, Cursor or ChatGPT at a server and pull quotes, read 10-Ks, reconcile a ledger or place a paper trade. The trouble is the long tail. Many repos get a burst of stars in their launch week and then go quiet. Others have names that sound official but have nothing to do with the vendor.

I wanted a list that removes the dead ones on its own. So every entry in the directory goes through a script once a week, and the results are published. This post explains how that check works and what it found this week.

The numbers (run of Oct 29, 2026)

The directory has 104 tools: 73 MCP servers, 15 agent skills and 16 APIs, across 9 categories.

So 20 of 104 (19%) don't currently pass. That number is lower than you might expect, because the list is curated first and verified second. It still matters, though, because the failures aren't the obscure ones:

• Financial Datasets MCP has 2.3k stars and an official badge, but no commit since June 2025 (510 days). Stale.
• MetaTrader 5 MCP has 843 stars and has been quiet for 214 days. Aging.
• Base MCP (Coinbase's Base, official, 351 stars) and Ramp MCP (official) are both archived.
• Crypto is the roughest category: only 8 of 16 pass (5 stale, 2 aging, 1 archived). Macro is the opposite, at 8 of 8.

Official vs community is the other split worth watching. Of the 61 tools published by the vendor, 57 pass (93%). Of the 43 community projects, 27 pass (63%). Community tools aren't worse. Plenty of the best ones are community-built, like Maverick MCP (714★), investor-agent (348★) and the unofficial TradingView MCP (5.2k★). They just go quiet more often, and you should know that before you depend on one.

How the check works

The verifier is a single Python file (scripts/verify.py) run by a GitHub Action every Monday at 05:00 UTC. The pipeline is verify → regenerate awesome-list → regenerate OG images → build → deploy. For each entry it does five things.

1. Is the repo still there, and is it archived?

It calls the GitHub API, follows renames, and records archived, stars, license and the last commit date. An unreachable repo is flagged as unreachable. An archived one is archived, whatever its stars.

2. How long since the last commit?

days = age_days(g.get("last_commit")) if g else None
links_ok = all(c["ok"] for c in v["checks"] if c["check"] != "package published")
if not links_ok: status = "warning"
elif days is None: status = "verified" if not g else "warning"
elif days <= 180: status = "verified"
elif days <= 365: status = "aging"
else: status = "stale"

180 days is lenient on purpose. Some finance servers are thin, stable wrappers around a REST API that don't need monthly commits. "Aging" is a yellow flag, not a verdict. Whether 180 should be tighter, given how fast the MCP spec moves, is an open question.

3. Does the published package really belong to this repo?

This one surprised me most. If a repo has a package.json or pyproject.toml, the script looks up that name on npm or PyPI. It only counts the package if the registry entry points back to the same owner/repo:

res["links_back"] = f"{owner}/{name}".lower() in res.pop("_lb")
if res and res["links_back"]:
    v[kind] = res
elif res:
    v["issues"].append(f"{kind} name '{cand}' exists on the registry "
                       "but does not link to this repo (not counted)")

_lb is the JSON of the registry's repository, homepage and bugs fields (npm), or project_urls and home_page (PyPI). In this week's run, 10 of 104 entries had a package name that exists on the registry but belongs to someone else. Examples are mcp-server on PyPI, which Financial Datasets' repo declares, and binance-mcp and bitcoin-mcp on npm. If your install instructions say npx <name> or pip install <name>, this is the difference between running the author's code and running a stranger's. 28 entries have a package that does link back.

4. Are the homepage, docs and hosted endpoint alive?

Homepages and docs must return a status below 400. 401, 403 and 429 also count as alive, because many vendor sites block bots. Hosted MCP endpoints need different handling: without auth, most answer 401 or 405. So any HTTP response below 500 counts as reachable:

a = alive(t["remote_mcp_url"])  # MCP endpoints answer 401/405/406 without auth
a["ok"] = not isinstance(a.get("status"), str) and a["status"] < 500

15 tools now ship an official hosted MCP endpoint, including Alpha Vantage, Finnhub, EODHD, CoinGecko, Stripe, PayPal, Square, Mercury, Interactive Brokers and Robinhood. This week 10 of them returned 401, 3 returned 405, and the other two returned 400 and 404. This check is admittedly coarse. It proves something is listening, not that the MCP handshake works. A real initialize call is next on the list.

5. Official or community?

This label is curated rather than computed. "Official" means the vendor publishes it (its GitHub org, its docs, its domain). Everything else is community, and community tools that use a brand name get an explicit "not affiliated" note.

What's verified in the busiest categories

Market data: Maverick MCP (714★), Massive MCP (official, 398★), investor-agent (348★), Alpha Vantage MCP (official, hosted, 223★), FMP MCP (150★). Finnhub, EODHD and FMP also run official hosted endpoints.

Brokers: Alpaca MCP (official, 1.0k★), Kraken CLI with a built-in MCP server (official, 783★), tasty-agent for tastytrade (88★) and Schwab MCP (66★, read-only by default). Interactive Brokers and Robinhood have hosted MCPs. If you connect any of them, use paper trading first.

Research & quant: OpenBB (74.9k★), SEC EDGAR MCP (380★), Claude Trading Skills (3.4k★) and QuantConnect's official MCP (79★).

What I'd do differently

• Stars are a terrible proxy for maintenance. The stale list includes Financial Datasets MCP (2.3k★), the aging list includes MetaTrader 5 MCP (843★), and Base MCP (351★) is archived.
• Publish the rules, not just the badges. The full table, with each tool's last commit and issues, is public at /verification/. The raw data is at /tools.json, so you can disagree with a status and see exactly why it was assigned.
• Verification is a floor, not an endorsement. A recent commit doesn't mean a server is safe to give your brokerage credentials to. Read the code, scope the API keys, and keep trading tools read-only or in paper mode until you trust them.

If you maintain a finance MCP server or skill that's missing, or you think a status is wrong, I'd like to hear it in the comments. I'm also curious where you'd set the staleness threshold.

Informational only. Not investment, financial or trading advice. Star counts and statuses are from the Oct 29, 2026 run and change weekly.