MaverickMCP: a personal stock analysis MCP server you run yourself

The problem MaverickMCP solves, and the person it is aimed at

Most stock data tooling assumes you are building a product. You sign up, get a key, watch a quota, and then write glue code before you can ask a question about a ticker. MaverickMCP inverts that. It is a FastMCP server that exposes market data, technical indicators, screening, portfolio tracking and a trade journal as MCP tools, so an MCP client such as Claude Desktop, Claude Code, Cursor, VS Code, Codex CLI, OpenCode or Antigravity CLI can call them directly.

The README is explicit that this is for personal use: it runs on your own machine, with no authentication or billing configuration anywhere in the project. The .env.example states the same thing in its header comment, and notes that every variable listed there is read somewhere in maverick/. That is a narrower audience than a data platform, and it is a deliberate one.

The core tools need no API key because market data comes from yfinance. Two extras are opt-in: a backtesting extra built on VectorBT, and a research extra that uses LangGraph with a bring-your-own LLM key. If you never install those extras, you get 37 tools and no external account to manage.

How the server is put together: transports, tools and a tiered cache

MaverickMCP speaks standard MCP over two transports. STDIO is the default, and the client launches the server as a subprocess. Streamable HTTP is the alternative, where you start the server yourself with make dev and it listens at http://localhost:8003/mcp. The README frames client setup as a single decision, which transport, followed by pasting the config shape for that client: command plus args for STDIO, url for HTTP. Clients configured for STDIO do not need make dev running.

Caching is tiered. There is an in-memory layer, then Redis or SQLite, with what the README calls graceful fallback when Redis is not running. Setting REDIS_HOST enables Redis; leaving it unset skips it entirely. The cache settings live in the same .env file as everything else, including CACHE_TTL_SECONDS and CACHE_SQLITE_PATH.

Persistence is optional and defaults to SQLite via DATABASE_URL=sqlite:///maverick.db. PostgreSQL is supported, and the .env.example documents a full set of pool keys such as DB_POOL_SIZE, DB_POOL_MAX_OVERFLOW, DB_POOL_RECYCLE and DB_STATEMENT_TIMEOUT. The docker-compose.yml wires the backend to a postgres:15-alpine service and a redis:7-alpine service, both with healthchecks, and gives the backend CPU and memory limits.

One architectural detail is worth noting because it removes a common build headache: the Dockerfile comments state that ta-lib and its compile step are gone, and that every indicator is computed in maverick/technical/indicators.py with pandas and numpy. The same file also explains that httpx is pinned in pyproject.toml because FastMCP 4 no longer depends on it while maverick/platform/http.py imports it directly.

Installing MaverickMCP without touching PyPI

The README carries a warning that matters more than any other line in it. The package is not on PyPI yet. The name maverick-mcp-server is held by a dormant, unrelated project, and a PEP 541 name-transfer request is pending. Until that note is removed, the README says not to run pip install maverick-mcp-server or uvx --from maverick-mcp-server, because whatever the current owner publishes is what you would get. Three supported paths remain.

Option 1 runs the release tag straight from GitHub through uvx, invoking the maverick-mcp console script:

uvx --from "git+https://github.com/wshobson/[email protected]" maverick-mcp --transport stdio

Adding the extras changes the specifier. The README gives this form:

uvx --from "maverick-mcp-server[backtesting,research] @ git+https://github.com/wshobson/[email protected]" maverick-mcp --transport stdio

Option 2 is the GHCR image. The README maps container port 8000 to 8003 on the host and notes that --env-file is optional because core tools need no keys:

docker run --rm -p 8003:8000 --env-file .env ghcr.io/wshobson/maverick-mcp:1.1.0

Option 3 is a source checkout for development. uv sync creates the virtual environment, and the extras are additive:

git clone https://github.com/wshobson/maverick-mcp.git
cd maverick-mcp
uv sync --extra dev --extra backtesting --extra research
cp .env.example .env

Once installed, two Makefile targets start it. make dev serves Streamable HTTP on http://localhost:8003/mcp, and make dev-stdio serves STDIO in the terminal. If your client launches the server itself, you do not need either target running. Point the client at the server with the transport your client supports, then ask it for a quote or an RSI reading and confirm the tool call returns yfinance data rather than an error.

Where MaverickMCP is the wrong tool

There is no HTTP /health endpoint, and this is stated twice, in the Dockerfile and in docker-compose.yml, with the explanation that the server is an MCP server rather than a REST API. Container orchestrators that expect a health probe have nothing to call. The Dockerfile suggests process liveness or an MCP-aware probe instead, which is a real integration cost if your deployment platform insists on an HTTP check.

Screening is scoped to tickers you have already queried, according to the feature list. It is not a market-wide screener that scans every listed symbol on demand. If your workflow starts from "find me candidates across the whole market," this server does not do that.

The research extra requires an Exa API key and a bring-your-own LLM key, with LLM_PROVIDER, LLM_API_KEY, LLM_MODEL and LLM_BASE_URL configured in .env. That is a different setup burden from the core tools, and it means the research path is not free in the way the yfinance path is.

Finally, the project is personal-use by design. There is no authentication layer, which is fine on localhost and a problem the moment you expose Streamable HTTP beyond your machine. Nothing in the project describes a multi-user mode, access control or usage metering. Treat the lack of auth as the boundary it is.

How it differs from other finance MCP servers

The finance MCP space divides by data source. Alpha Vantage MCP servers and Financial Datasets MCP servers route through a commercial API, which usually means an account, a key and a rate limit before you see a number. Polygon MCP servers and Tradier MCP servers follow the same shape, and Tradier in particular sits closer to brokerage execution than to analysis. MaverickMCP takes the opposite route: yfinance supplies the market data, so the core 37 tools work with no key at all, and the trade-offs that come with a free scraping-backed source are accepted rather than hidden.

That choice has consequences. A commercial feed typically offers a documented SLA and a defined schema. yfinance does not, and MaverickMCP's answer is caching rather than a contractual guarantee. If your process depends on a stable, versioned market data contract, a keyed provider is the better fit.

A second difference is scope. Several of these servers expose quotes and fundamentals and stop there. MaverickMCP bundles portfolio tracking with average cost-basis, live P&L, a risk dashboard, watchlists and a trade journal, plus optional VectorBT backtesting with 12 rule-based strategy templates and 8 ML strategy classes. That is a wider surface than a pure data proxy, and it is the reason the tool count is 37 rather than a handful.

Maintenance, upgrades and what the MIT licence leaves to you

The repository is not archived, and the last push was on 2026-09-07. Version 1.1.0 was released on 2026-09-05, about a month after v1.0.0 on 2026-07-20. Two releases in two months with a same-week push behind the second one is a normal cadence for a young project, not a signal either way.

Upgrade cost depends on which install path you chose. The uvx form pins the tag in the URL, so moving to a new version means editing that string. The Docker image pins 1.1.0 in the tag, so upgrading is a tag change plus a container restart. A source checkout moves with git and uv sync. The .env.example points at docs/runbooks/migrating-to-v1.md for anyone coming from a pre-v1.0 install, which implies the v1.0 line was a breaking change; if you are on an older layout, read that runbook before upgrading.

The licence is MIT. That permits commercial use and modification, and it comes with no warranty, which is the standard MIT position. Nothing here is legal advice. The practical implication for a personal analysis tool is that you carry the risk of any decision you make from its output, and the README frames the project as personal-use rather than advisory.

One maintenance item sits outside the repository. The PyPI name situation is unresolved, and the README says a PEP 541 transfer request is pending. Until that is settled, the install command is longer than a normal package install, and anyone who types the short name gets someone else's code.

Editorial conclusion

Adopt MaverickMCP if you are one person who wants yfinance-backed quotes, RSI and MACD, screening and a trade journal reachable from Claude Desktop, Cursor or Codex CLI without an API key. Do not adopt it if you need a hosted multi-user service, a REST API, or a container health endpoint. Before you commit, verify that the v1.1.0 tag resolves through uvx, that your chosen transport matches how your client starts servers, and whether you actually want the backtesting and research extras, since the container image ships both by default.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. wshobson/maverick-mcp on GitHub