MaverickMCP: a local stock analysis MCP server you run yourself

The gap MaverickMCP fills: indicators and positions inside the chat client

An MCP client can call tools, but it cannot compute an RSI or remember that you bought 40 shares at 182. MaverickMCP supplies both. It is a FastMCP server that registers 37 core tools for market data, technical analysis, screening, portfolio tracking with a risk dashboard, watchlists and a trade journal, and it runs on your own machine. The README is explicit that it is built for individual traders and investors and that there is no authentication or billing complexity. Core tools need no API key because market data comes from yfinance. That combination is the point: a single-user server with no signup, no quota and no third party holding your positions. The audience is narrow by design. If you need shared accounts, an audit trail, or a service that stays up when your laptop does not, this is the wrong shape of tool, and the README does not pretend otherwise.

How the server is put together: FastMCP, yfinance, tiered cache, optional SQLite or Postgres

The architecture visible in the README is a FastMCP server speaking the Model Context Protocol over two transports, STDIO and Streamable HTTP. Data flows from yfinance into the tool layer, with a tiered cache in front: memory first, then Redis or SQLite, with what the README calls graceful fallback when Redis is not running. Persistence for portfolios, watchlists and the journal is optional and defaults to SQLite, with PostgreSQL as the alternative. Two capability groups are opt-in rather than always present. The [backtesting] extra adds 12 tools built on VectorBT, covering rule-based strategy templates, 8 ML strategy classes, optimization, walk-forward analysis and Monte Carlo simulation. The [research] extra adds 3 LangGraph-based research tools over companies, sectors and market sentiment, backed by Exa web search and a bring-your-own LLM key. Redis and the research LLM key are both described as optional, so the minimum viable deployment is a Python process and a SQLite file. The trade-off is that caching quality and research depth scale with what you choose to run alongside it.

Installing MaverickMCP without touching the PyPI name

The README carries an unusual warning that changes the install instructions entirely: 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. Three supported paths remain. The first runs the release tag directly: uvx --from "git+https://github.com/wshobson/maverick-mcp@v1.1.0" maverick-mcp --transport stdio, with an extras variant that names maverick-mcp-server[backtesting,research] against the same git URL. The second pulls the container: docker run --rm -p 8003:8000 --env-file .env ghcr.io/wshobson/maverick-mcp:1.1.0. The third clones the repository and runs uv sync --extra dev, optionally adding --extra backtesting and --extra research, then copies .env.example to .env. Starting it is either make dev for Streamable HTTP on http://localhost:8003/mcp or make dev-stdio for STDIO. The README notes that clients configured for STDIO launch the server themselves, so make dev does not need to be running in that case.

Choosing a transport, and the config shape that follows

The README frames client setup as one decision, which transport, followed by pasting the right config shape. The table it provides is worth reading before you edit anything. With STDIO the client starts the server as a subprocess, there is no endpoint, and the config uses command plus args; the README calls this the default and recommends it for a single local client. With Streamable HTTP you start the server yourself via make dev, the endpoint is http://localhost:8003/mcp, and the config uses url; this suits several clients sharing one server or remote access. The distinction matters operationally. Running make dev and also configuring a STDIO client means two server processes against the same SQLite database, which is not a configuration the README describes as intended. The README lists Claude Desktop, Claude Code, GitHub Copilot, Codex CLI, Cursor, OpenCode and Antigravity CLI as clients that can connect, and states there is no client-specific behavior, so the same server works across all of them. Nothing in the material describes a health endpoint or a readiness check, so if you run HTTP mode behind anything, that is on you.

Screening is bounded by what you have already queried

This is the limitation most likely to surprise a new user. The README describes stock screening as Maverick bullish, bearish and supply/demand strategies computed over the tickers you have already queried. It is not a market-wide screener that scans thousands of symbols and returns matches. You populate the candidate set by asking for data first, then the strategies run across that set. If your mental model of a screener comes from a broker platform, this will feel inverted, and the practical consequence is that discovery is not what this tool does. The same applies to research: the [research] extra depends on Exa web search and a bring-your-own LLM key, so output quality tracks the model you supply and the search results it retrieves. Both extras are opt-in at install time, so a core-only install registers 37 tools and no backtesting or research tools at all. That is a clean boundary, but it also means a core-only user cannot backtest a signal they just generated without reinstalling with the extra.

MaverickMCP against a hosted analysis product

The README points to Capital Companion, described as the hosted product built on the same engine, offering AI technical analysis, trade-plan review sheets with outcome tracking, and price alerts, with 25 free analyses and no credit card. The difference in approach is not feature count, it is where the state lives. Self-hosting MaverickMCP means Python, uv and MCP client configuration on your machine, with Redis and a research LLM key optional; your positions, journal and cache stay in your SQLite or Postgres instance, and there is nothing to authenticate against. The hosted product moves that state to someone else's servers, which removes the setup work and adds alerting and outcome tracking that the README does not list among MaverickMCP's tools. Neither is strictly better. If you want your trade journal to be queryable by an agent running locally, and you are willing to manage a Python environment, the server is the fit. If you want alerts firing when you are not at your desk, the README's own framing points you at the hosted option.

Maintenance cost, extras and the MIT licence

The dependency surface is the maintenance cost. Core installs pull yfinance, FastMCP and the MCP stack, with Redis and PostgreSQL both optional. Adding [backtesting] brings VectorBT, and [research] brings LangGraph plus Exa and an LLM provider. Those extras carry heavier transitive dependency trees than the core, so pinning the release tag rather than tracking main is the lower-risk choice for anything you rely on. The README instructs configuring DATABASE_URL, LLM_PROVIDER and EXA_API_KEY in .env, all described as optional, which means a core-only deployment can run with an empty environment file. The project ships as v1.1.0 and v1.0.0 releases, and the install examples pin to the v1.1.0 tag and the 1.1.0 container image, so upgrades are explicit rather than automatic. The licence is MIT, which permits commercial use and modification provided the copyright notice and permission notice are retained; the repository does not state a support commitment, and this is a description of the licence text, not legal advice. Anyone embedding this in a product should read the licence themselves and check the terms of yfinance, Exa and whichever LLM provider they configure, since those are separate agreements.

Editorial conclusion

Adopt MaverickMCP if you already run an MCP client locally and want technical indicators, a trade journal and portfolio P&L without handing an API key to a hosted service. Do not adopt it if you need multi-user access control, a supported package on PyPI, or screening across the whole market: the README states the strategies are computed over the tickers you have already queried. Before installing, verify that the v1.1.0 release tag still resolves, that ghcr.io/wshobson/maverick-mcp:1.1.0 still pulls, and that your client is configured for exactly one transport, because the README says the package name on PyPI belongs to an unrelated project.

Official sources

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