finance-mcp
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@finance-mcpget the stock symbol for Apple"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Finance MCP Server
A minimal MCP server built with Python that exposes two example tools: one to convert a company name into a stock symbol, and another to fetch financial data from Yahoo Finance. The project focuses on learning how to build and run an MCP server—using a simple financial scenario purely as a demo use case.
Installation
Development Installation
# Clone the repository
git clone https://github.com/yourusername/mcp-finance-server-py.git
cd mcp-finance-server-py
# Install in development mode
uv pip install -e .Production Installation
uv pip install finance-mcpRelated MCP server: Model Context Protocol Demo
Usage
Running the Server Directly
finance-mcpConfiguration with Claude Desktop or other MCP clients
Add this to your MCP configuration file (e.g., claude_desktop_config.json):
{
"mcpServers": {
"finance-mcp": {
"command": "uv",
"args": [
"--directory",
"/absolute/path/to/mcp-finance-server-py", // Update this path
"run",
"finance-mcp"
]
}
}
}Video Walkthrough

Watch: Build Your Own MCP Server: Practical Guide with Python SDK and Cursor IDE
This video provides context and explanations that complement the code in this repository:
See the MCP server in action with a practical demonstration in Cursor IDE
Understand the design decisions behind the implementation
Learn how the different components work together
Get insights into how AI models discover and interact with custom tools
If you're looking to understand not just the "what" but the "why" behind this MCP implementation, the video offers a guided tour through the development process and explains the reasoning behind key architectural choices.
Available Tools
2 toolsfetch_stock_dataC
Fetches comprehensive stock data for a given symbol.
Args: stock_symbol: The stock ticker symbol (e.g., 'TSLA'). period: The period to analyze (e.g., '1mo', '3mo', '1y').
Returns: A dictionary combining general stock info and historical market data.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | 1mo | |
| stock_symbol | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. Mentions return type (dictionary with stock info and historical data) but lacks details on data freshness, rate limits, or idempotency. Not enough to fully inform an agent about behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description uses a docstring format with Args and Returns sections, which is structured but slightly verbose. Could be more concise without the formal sections.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should detail return value structure. Only says 'dictionary combining general stock info and historical market data,' which is vague. Lacks error handling or edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds meaning: 'stock_symbol' as ticker symbol with example 'TSLA', 'period' as analysis period with examples. Provides default for period. Lacks allowed values for period, but is adequate for basic usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Fetches comprehensive stock data for a given symbol.' The verb 'Fetches' and resource 'stock data' are specific. Differentiates from sibling 'lookup_stock_symbol' by implication, but could be more explicit about the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus the sibling 'lookup_stock_symbol'. Missing prerequisites or context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_stock_symbolB
Converts a company name to its stock symbol using a financial API.
Args: company_name: The full company name (e.g., 'Tesla').
Returns: The stock symbol (e.g., 'TSLA') or an error message.
| Name | Required | Description | Default |
|---|---|---|---|
| company_name | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions using a financial API and returns symbol or error, but does not disclose rate limits, authentication needs, or idempotency. Basic transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences including Args and Returns. No extraneous text. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with one parameter and no output schema. Description adequately explains purpose and return. Could mention expected company name format (e.g., full legal name), but not necessary for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
One parameter, company_name, is described with example 'Tesla'. Schema coverage is 0% but description effectively provides 100% coverage. Adds an example beyond schema, which is helpful but minimal. Baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool converts a company name to a stock symbol using a financial API. It distinguishes from sibling 'fetch_stock_data' which likely fetches data for a given symbol.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Sibling tool is named but no differentiation or context provided. Agent has no help in deciding which to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v0.1.0- First observed
fetch_stock_data - First observed
lookup_stock_symbol
TDQS
Scored across 2 tools
Each tool serves a distinct purpose: one converts company names to stock symbols, the other fetches stock data given a symbol. No overlap in functionality.
Both tools follow a consistent verb_noun pattern with snake_case: 'fetch_stock_data' and 'lookup_stock_symbol', making them predictable and easy to understand.
With only 2 tools, the set feels thin for a finance server. While the two tools are essential, the count is borderline low, lacking additional common operations.
The server covers only basic stock data retrieval and symbol lookup. Many common finance operations (e.g., financial statements, market indices, historical comparisons) are missing, posing significant gaps for agents.
Maintenance
Related MCP Connectors
MCP server exposing the Backtest360 engine API as tools for AI agents.
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Related MCP Servers
- AlicenseAqualityAmaintenanceA simple MCP server for Yahoo Finance using yfinance. This server provides a set of tools to fetch stock data, news, and other financial information.15191MIT
- AlicenseNot gradedqualityDmaintenanceA demonstration server for the Model Context Protocol (MCP) that exposes calculator and Yahoo Finance tools, allowing LLMs to interpret natural language requests and make tool calls via the MCP standard.1Apache 2.0
- AlicenseNot gradedqualityCmaintenanceA simple MCP server that exposes stock price lookup tools, demonstrating how to set up MCP from scratch with Ollama.23-
- AlicenseAqualityAmaintenanceMCP server that exposes Yahoo Finance data through tools for searching instruments, fetching quotes, history, company info, financials, dividends, news, recommendations, and options. Enables AI assistants to answer market-data questions using natural language.22MIT