A
licenseA
qualityF
maintenanceA comprehensive MCP server for stock analysis and trading insights, including stock screening, fundamental analysis, insider trading, options analysis, social media research, and news analysis.
10
75
MIT
Investo
Investo is an AI-powered investment analysis server that gathers public financial data to produce comprehensive company analyses, with a primary focus on Indian (NSE/BSE) companies and support for US/global markets.
Search & Resolve (
search_company): Look up a company name and resolve it to the correct exchange ticker (NSE/BSE or global), with ranked alternatives returned.Company Profile (
get_company_profile): Retrieve sector, industry, business summary, market cap, and executive details.Financial Statements (
get_financials): Access income statements, balance sheets, and cash flow statements (annual or quarterly).Key Ratios (
get_key_ratios): Get valuation, profitability, leverage, liquidity, growth, and cash-flow ratios in one call.Peer Comparison (
compare_peers): Compare a company against sector peers across revenue, margins, valuation, and growth metrics.Industry Intelligence (
get_industry_intelligence): Explore sector sub-domains, demand drivers, industry CAGR estimates, and sector-level risks.News Analysis (
get_news): Fetch and categorize recent headlines into earnings, M&A, management, legal, and product/AI news.Management Analysis (
get_management): Review executives, promoter/insider/institutional holdings, and capital allocation signals.DCF Valuation (
dcf_valuation): Run a two-stage DCF model to estimate intrinsic value per share, margin of safety, and expected return, with optional parameter overrides.Moat Assessment (
moat_assessment): Evaluate brand, cost, scale, IP, and switching-cost signals with a 0–10 heuristic moat score.Risk Assessment (
risk_assessment): Analyze leverage, currency, concentration, and regulatory risks with a 0–5 safety score.Investment Rating (
score_company): Generate a composite 0–100 score across 11 weighted buckets (Growth, Profitability, Cash Flow, Debt, Valuation, Moat, Management, Industry, Innovation, Risk, ESG) with per-bucket rationale.Full Bundled Analysis (
analyze_company): Run everything above in one call, including SWOT seeds and growth-driver hints for narrative generation.SEC EDGAR Cross-Check (
get_sec_facts): Pull SEC EDGAR company facts for US-listed companies or Indian ADRs as an optional data verification step.
Fetches categorized recent news headlines about companies from Google News.
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., "@InvestoAnalyze Infosys"
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.
Investo 📈
An AI investment-analysis agent you run from Claude or Cursor.
⚠️ Research and education only — not investment advice.
Give Investo a company name — Indian (NSE/BSE) or global — and it gathers public financial data and produces a full analysis: what the company does, its financials & ratios, a competitor comparison, DCF intrinsic value, economic moat, risks, management, recent news, SWOT seeds, and a 0–100 investment rating.
Investo is a Model Context Protocol (MCP) server. It exposes tools to an AI client (Claude Code, Claude Desktop, Cursor); the client calls those tools and writes the analysis narrative grounded in the structured data Investo returns.
Primary focus: Indian companies listed on NSE (
.NS) and BSE (.BO). US/global companies are supported too.
What it produces
For any company, Investo supplies the evidence for:
Domain / sector — what the business does and its sub-domains.
Financials & ratios — income statement, balance sheet, cash flow + valuation, profitability, leverage, liquidity, growth, cash-flow ratios.
Competitor analysis — auto-compares against sector peers (e.g. Infosys → TCS, Wipro, HCL, Tech Mahindra, LTIMindtree).
Industry intelligence — sub-domains, demand drivers, CAGR, risks.
News analysis — recent headlines categorized (earnings, M&A, management, legal, product/AI).
Management analysis — executives, promoter/insider holding, capital allocation.
DCF valuation — intrinsic value/share, margin of safety, expected return.
Economic moat — brand / network / cost / scale / switching-cost signals.
Risk analysis — debt, currency, concentration, regulation, tech obsolescence.
Rating out of 100 — a balanced 11-bucket score with per-bucket rationale.
Warren Buffett checklist — a weighted 0–100 quality-fit score; each criterion (ROE, ROIC, debt, owner earnings, margin of safety, management, moat) shows value vs threshold, a pass/warn/fail with the reason, a confidence, and its multi-year trend.
Relative to industry — key metrics vs the peer-set median with favourable-side percentiles.
Shareholding pattern — promoter/FII/DII/public split + promoter pledge, with quarter-over-quarter smart observations and an ownership signal (NSE/BSE filings; Yahoo fallback).
5-year growth engine — the primary engine plus ranked drivers (estimated contribution %, per-driver risks), a catalyst timeline, and a blended growth band.
Fundamentals trend, red-flags, and an investment thesis — multi-year health at a glance, automated deterioration warnings, and a synthesized pros/cons verdict.
Every section carries a confidence score, provenance and reasoning (the evidence layer), so an
AI agent — or you — can judge how far to trust each conclusion. A machine-readable ai_signals
digest and a self-contained, print-ready research note (--html) — numbered sections, inline
SVG exhibits, footnotes and per-exhibit source lines, styled as an institutional equity-research
document rather than a dashboard — are available too.
Rating buckets (out of 100)
Growth | Profitability | Cash Flow | Balance Sheet | Valuation | Moat | Management | Industry | Innovation | Risk | ESG* |
15 | 17 | 10 | 11 | 10 | 12 | 10 | 5 | 5 | 5 | 5* |
*ESG is optional; when unavailable the remaining buckets renormalize to 100.
Valuation is quality-aware. A premium multiple isn't punished when the company's economics justify it — the acceptable P/E · P/B · EV/EBITDA ceilings widen with ROE, margins and growth, so a proven compounder isn't floored just for not being cheap (while a low-quality expensive name still is). Net cash strengthens the score — it lifts the Balance Sheet bucket and lowers the effective equity multiple — and net debt weakens both.
Related MCP server: financial-research-agent
Install
Requires Python 3.10+.
git clone https://github.com/YashvantHange/Investo
cd Investo
python -m venv .venv
# Windows: .venv\Scripts\activate | macOS/Linux: source .venv/bin/activate
pip install -e .No API keys are required — Investo works out of the box using free Yahoo Finance data and
Google/Yahoo news. Optional keys (Alpha Vantage / FMP / Finnhub) enable richer/fallback data;
copy .env.example to .env and fill in any you have.
Try it from the command line
investo analyze "Infosys" # terminal report + auto HTML note
investo analyze "Reliance Industries"
investo analyze "Tata Motors"
investo analyze AAPL
investo analyze "Reliance Industries" --html reliance.html # self-contained research note
investo analyze "Infosys" --pdf infosys.pdf # PDF via headless Chrome/Edge
investo analyze "Infosys" --json --html infy.html # flags compose; nothing is discarded
investo analyze "Infosys" --no-html # skip the automatic HTML note
investo search "tata motors"Every investo analyze writes a self-contained HTML research note automatically (named
investo-<SYMBOL>-<date>.html in the working directory) alongside its terminal output — the path is
announced on stderr, so --json stays pipeable. Use --no-html to skip it, or --html FILE to
choose the location. The MCP analyze_company tool does the same, returning the file in
html_report_path; pass emit_html=false to suppress it.
--pdf needs a Chromium-family browser: it uses a system Chrome, Edge, Chromium or Brave if one
is installed (no setup), falls back to a managed Chromium via pip install 'investo[pdf]' && playwright install chromium, and otherwise prints exactly how to fix it while still leaving the
.html on disk. Point INVESTO_CHROME at a specific executable to override discovery. Bare --html
/ --pdf (no filename) write investo-<SYMBOL>-<date>.<ext> in the working directory.
Use it from Claude Code / Cursor
Do the one-time setup (creates the venv the launcher looks for):
python -m venv .venv
.venv\Scripts\pip install -e . # macOS/Linux: .venv/bin/pip install -e .Claude Code — this repo ships a project-scoped .mcp.json that runs
python scripts/mcp_launcher.py. No paths to edit — the launcher finds the project's
.venv itself and works on Windows/macOS/Linux. Opening the folder in Claude Code offers to
load the investo server (approve on first use); the included CLAUDE.md makes the agent
introduce itself as Investo.
Cursor — Investo is in the Cursor Directory. One-click
install (requires uv — the Python equivalent of npx):
Or add manually to .cursor/mcp.json (project) or ~/.cursor/mcp.json (global) — both work:
{ "command": "uvx", "args": ["--from", "git+https://github.com/YashvantHange/Investo", "investo-mcp"] }uvx builds & runs Investo straight from GitHub — no clone, no venv, works from any folder.
Claude Desktop — use the same uvx config (see examples/claude_desktop_config.json), or
install the one-click .mcpb bundle (scripts/build_mcpb.sh).
From source (no uv) — clone, python -m venv .venv && pip install -e ., then point the
MCP config at the launcher: { "command": "python", "args": ["<ABSOLUTE>/scripts/mcp_launcher.py"] }
(the launcher finds the venv itself). This is what a project-scoped .mcp.json uses.
See PUBLISHING.md for PyPI / .mcpb / MCP-registry release steps.
Then ask: "Analyse Infosys", "Compare HDFC Bank with its peers", "What's the DCF value of Reliance?"
How the launcher works:
scripts/mcp_launcher.pyis a tiny standard-library script. When a client runs it with anypython, it re-launches the server inside the project's.venv(or uses the current interpreter ifinvestois already installed there). That's why the committed config needs no machine-specific paths.
MCP tools
Tool | Purpose |
| Resolve a name to an NSE/BSE/global ticker |
| Sector, business summary, market cap, executives |
| Income statement / balance sheet / cash flow |
| Valuation, profitability, leverage, growth, cash-flow ratios |
| Competitor comparison table |
| Sub-domains, demand drivers, CAGR, risks |
| Categorized recent headlines |
| Executives, holdings, capital allocation |
| Intrinsic value, margin of safety, expected return |
| Economic-moat signals + heuristic score |
| Risk signals + heuristic score |
| 0–100 composite rating |
| Warren-Buffett quality checklist: weighted 0–100 fit, per-criterion pass/warn/fail + reason, confidence & multi-year trend |
| Key metrics vs the peer-set median (industry proxy) with favourable-side percentiles |
| Promoter/FII/DII/public split + pledge, QoQ smart observations & ownership signal (NSE/BSE filings, Yahoo fallback) |
| 5-year growth engine: ranked drivers (contribution %, risks), catalyst timeline, blended growth band |
| Multi-year revenue/profit/margin/EPS/ROE with per-year direction & health grade |
| Automated deterioration warnings + overall risk level |
| Synthesized pros/cons, quality grade, valuation stance & one-line verdict |
| Compact machine-readable digest (thesis, quality, confidence, ownership/growth signals, risk, valuation) |
| Price/momentum context: 50/200-DMA + golden/death cross, RSI, volatility, drawdown, beta, 52-week position (context, not a signal) |
| Intrinsic value across a discount-rate × terminal-growth grid + the growth implied by today's price |
| Head-to-head across 2–6 named tickers (not a curated group) |
| List the curated peer groups and their members |
| Render a full analysis to an HTML/PDF file (writes a file; path sandboxed) |
| Everything above bundled into one report (with a confidence/provenance evidence layer); also auto-writes an HTML note and returns its |
| SEC EDGAR cross-check (US/ADR only) |
Configuration
All optional — set as environment variables (or in .env; see .env.example):
Variable | Purpose | Default |
| Licensed data (primary when set) | — |
| Log verbosity to stderr (DEBUG/INFO/WARNING/ERROR) |
|
| Min seconds between Yahoo calls |
|
| Alpha Vantage daily cap before Yahoo fallback |
|
| Contact for the SEC EDGAR User-Agent | repo URL |
| Fetch NSE/BSE shareholding filings (else Yahoo fallback) |
|
|
|
|
| DCF discount / terminal / years overrides | see |
Data sources & legal
Investo prefers licensed data when you configure a key, and falls back to free Yahoo data otherwise:
With an API key (
ALPHAVANTAGE_API_KEY/FMP_API_KEY/FINNHUB_API_KEY): licensed fundamentals are used as the primary source and take precedence for the fields they cover (recommended for production / commercial use).Without a key (default, zero-config): Yahoo Finance is used via
yfinance, which relies on Yahoo's public but unofficial endpoints. This is best-effort, may be rate-limited, and is subject to Yahoo's terms of service. For NSE/BSE fundamentals Yahoo remains the practical source of record even when a key is set, because the licensed APIs' India coverage is limited.
The provider in effect is reported by the provider_status in tool output. See
SECURITY.md for the full list of endpoints Investo contacts.
Privacy — what leaves your machine
Only the company name or ticker you ask about is sent to the data endpoints above. Investo has no telemetry, stores no personal data, and reads API keys only from environment variables (never logged). It is read-only and does not modify your system.
Known limitations
Promoter/insider shareholding for NSE/BSE has no clean free API — best-effort, often unavailable for Indian names.
Industry CAGR / market share are curated/estimated (
data/*.yaml), not live. Each peer group carries anupdated_atso you can judge staleness rather than assume freshness.Peer lists start curated for major Indian sectors and are extensible via
data/peers.yaml. A ticker in no group falls back to a keyword match on its Yahoo industry; that guess is reported asbasis: sector-fallbackand scored below a curated group. After editing peers.yaml, runpython scripts/validate_peers.py— a dead ticker silently drops a company out of its own peer table, and no offline test can catch it.Confidence is about evidence quality, not about being right — see docs/confidence.md for how it's computed and where it stops being trustworthy.
Sharp reporting discontinuities (e.g. a demerger) can distort growth; Investo flags a warning when it detects one, but read the note in context.
⚠️ Investo is for research and education only — not investment advice. Do your own due diligence.
License
MIT
Available Tools
14 toolsanalyze_companyB
Full investment analysis for a company name or ticker.
Bundles profile, ratios, peer comparison, DCF, moat, risk, management, news, the 0-100 score, plus SWOT seeds and growth-driver hints for the host LLM to turn into a narrative.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| market | No | IN |
TDQS
B3.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description must disclose behavioral traits. It does not mention side effects, authentication needs, rate limits, or whether it is read-only. It hints at output structure for LLM narrative but does not clarify operational characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One clear sentence stating purpose, followed by a bullet-style list of components. Every part adds value; no redundant or unnecessary text. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (bundles many components) and absence of output schema, the description is insufficient. It lists what is included but does not describe output format, how to interpret results, or any integration details, making it incomplete for an AI agent to use without further info.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must explain parameters. It clarifies 'query' as a company name or ticker, adding meaning. However, it omits any explanation for 'market' parameter, which has a default of 'IN', leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states it provides 'Full investment analysis for a company name or ticker' and lists all bundled components (profile, ratios, peer comparison, DCF, moat, risk, management, news, score, SWOT seeds, growth-driver hints), clearly distinguishing it from sibling tools that cover individual aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly suggests use when a comprehensive analysis is needed, but lacks explicit guidance on when to use this vs. individual tools, no exclusion criteria, and no mention of prerequisites or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_peersB
Competitor comparison table vs sector peers (revenue, margins, valuation, growth).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| market | No | IN | |
| ticker | Yes |
TDQS
B3.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavior. It indicates a read operation returning a table with specific metrics. However, it does not mention that it requires a ticker, the default market value, or any side effects. Adequate for a simple read tool but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence of 10 words is very concise. No repetition or filler. However, it could be more informative without adding much length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters and no output schema, the description is too minimal. It omits how to use the tool (e.g., requires a ticker), what the output exactly looks like, and any limitations. Leaves the agent guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% coverage in descriptions. The tool description does not explain what 'ticker' or 'market' mean, nor does it mention that 'market' defaults to 'IN'. No additional meaning is provided beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to compare a company with its sector peers on revenue, margins, valuation, and growth. It uses a specific verb ('compare') and resource ('peers'), and is distinct from sibling tools like 'analyze_company' or 'get_industry_intelligence'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. It does not mention prerequisites, when it's appropriate, or when to avoid it. The sibling list is provided but not leveraged.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dcf_valuationB
Two-stage DCF: intrinsic value/share, margin of safety and expected return.
Optional overrides: discount_rate (e.g. 0.12), terminal_growth (e.g. 0.04), years, growth_rate. Handles cases where statements and the stock trade in different currencies.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| years | No | ||
| market | No | IN | |
| ticker | Yes | ||
| growth_rate | No | ||
| discount_rate | No | ||
| terminal_growth | No |
TDQS
B3.3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It mentions handling different currencies, but fails to specify default behavior, computational assumptions, or that results depend on financial statements. No mention of mutation, idempotency, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, front-loading the core purpose and output. It efficiently lists optional parameters, though could benefit from clearer separation between outputs and overrides.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a DCF valuation and the lack of an output schema, the description is incomplete. It does not specify the format of outputs, the data source (e.g., financial statements), or limitations. The tools' behavior under missing data is unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds meaning by listing optional overrides (discount_rate, terminal_growth, years, growth_rate) with example values. However, it omits explanations for 'market' and 'ticker', and does not define the parameters' roles or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a Two-stage DCF calculation and outputs intrinsic value per share, margin of safety, and expected return. It is distinct from sibling tools like analyze_company or get_financials, which are broader in scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through the description (e.g., 'Two-stage DCF'), but no explicit guidance on when to use this tool versus alternatives like get_key_ratios or risk_assessment. No when-not-to-use or prerequisite information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_company_profileC
Company profile: sector, industry, business summary, market cap, executives.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| market | No | IN | |
| ticker | Yes |
TDQS
C2.8/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description only lists output fields but does not disclose behavioral traits such as read-only nature, rate limits, or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the tool's output. However, it could be slightly longer to include parameter hints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple profile tool with no output schema, the description provides a basic purpose but lacks detail on parameters, usage context, and is insufficient among 13 siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain the parameters (ticker, market) or their expected values, leaving the agent without guidance beyond the schema's defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a company profile and lists specific fields (sector, industry, business summary, market cap, executives), distinguishing it from siblings like get_financials or get_management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives like get_financials or analyze_company. The description does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_financialsC
Income statement, balance sheet and cash flow (period = 'annual' or 'quarterly').
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| market | No | IN | |
| period | No | annual | |
| ticker | Yes |
TDQS
C2.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description only mentions the period parameter options. It does not disclose data source, rate limits, authentication needs, or any side effects. The read-only nature is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It front-loads the main purpose, but could be more informative without significant length increase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters (0% schema coverage), no output schema, and many sibling tools, the description is inadequate. It fails to explain parameter details, expected output, or how it differs from similar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only mentions 'period' in parentheses. It does not describe the ticker or market parameters, their functionality, or allowed values beyond the schema defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns income statement, balance sheet, and cash flow, and mentions the period parameter options (annual or quarterly). This differentiates from sibling tools like get_key_ratios or dcf_valuation, but does not explicitly state it requires a ticker, which is a required parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_key_ratios or dcf_valuation. The description does not specify prerequisites or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_industry_intelligenceC
Sector sub-domains, demand drivers, industry CAGR and risks.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| market | No | IN | |
| ticker | Yes |
TDQS
C2.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose behavior like idempotency, data freshness, error handling, or authentication needs. Only lists output content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but underwhelming. It lacks structure and does not front-load the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and moderate complexity (2 parameters, industry focus), the description fails to fully convey what the tool returns or its relationship to sibling tools like risk_assessment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (parameters have no descriptions). The tool description does not explain the 'ticker' or 'market' parameters, leaving the agent uninformed about their meaning or default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description lists specific outputs (sector sub-domains, demand drivers, CAGR, risks) which clearly indicate the tool provides industry-level intelligence. It distinguishes from siblings like get_financials (company-level) and compare_peers (peer comparison).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or avoid this tool. No mention of prerequisites or alternatives. The agent must infer usage from the output list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_key_ratiosC
Valuation, profitability, leverage, liquidity, growth and cash-flow ratios.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| market | No | IN | |
| ticker | Yes |
TDQS
C2.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only lists ratio categories without disclosing behavioral aspects such as time period, calculation methods, or constraints like data availability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, but it is too minimal to be fully effective. It could be restructured to front-load the core purpose while adding brief parameter context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and parameter descriptions, the tool is under-specified. The agent cannot infer what exactly is returned, how to interpret ratios, or any prerequisites (e.g., market coverage).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain how parameters (market, ticker) influence the output. The ratio categories listed do not map to any parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly lists the types of ratios (valuation, profitability, leverage, liquidity, growth, cash-flow), making it clear that the tool returns financial ratios. However, it does not differentiate from sibling tools like get_financials, which may also return some ratios.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. The description lacks context about scenarios where key ratios are preferred over other analyses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_managementC
Executives, promoter/insider/institutional holding and capital-allocation signals.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| market | No | IN | |
| ticker | Yes |
TDQS
C2.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose behavioral traits such as read-only nature, permissions needed, rate limits, or potential side effects. Given it's a retrieval tool, some expectation of safety exists but is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that encapsulates multiple types of data. It is concise and front-loaded with key information, though it could be better organized for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description does not describe the output format or structure. It omits behavioral details and parameter explanations, leaving gaps for an AI agent to infer. The tool's relationship to siblings is unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain the 'ticker' or 'market' parameters, nor their roles. It adds no semantic value beyond the schema's structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names specific data types (executives, holdings, capital-allocation signals), making the tool's purpose clear. It distinguishes from siblings like dcf_valuation or get_news, though there is slight potential overlap with get_company_profile. A clearer verb would improve it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. The description does not mention prerequisites, exclusions, or when not to use it. Sibling tools are listed but not compared.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_newsB
Recent company news, categorized (earnings, M&A, management, legal, product/AI).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| market | No | IN | |
| ticker | Yes |
TDQS
B3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only mentions 'recent' and 'categorized' without detailing data sources, update frequency, or other 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no superfluous text, but it sacrifices necessary detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no output schema, and no annotations, the description is inadequate for an agent to use the tool effectively without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 3 parameters, the description adds no meaning to limit, market, or ticker beyond their schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves recent company news with categorization, distinguishing it from sibling tools like get_company_profile or get_financials.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching news but provides no explicit guidance on when to use vs alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_sec_factsB
SEC EDGAR company facts (US-listed companies / Indian ADRs only). Optional cross-check.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ticker_or_cik | Yes |
TDQS
B3.1/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions scope restrictions and an optional cross-check but does not explain what the cross-check entails, data freshness, rate limits, or any side effects. For a data retrieval tool, more behavioral context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one short sentence), which is efficient but lacks important details. It is front-loaded with the core purpose, but additional context about the cross-check or parameter would improve usability without adding much length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and only one parameter, the description is insufficient. It does not explain the return format, the cross-check feature, or how it complements sibling tools like get_financials. An agent needs more context to decide when to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter ticker_or_cik has 0% schema description coverage. The description does not explain what values are acceptable (e.g., ticker symbol vs CIK number) or provide any formatting guidance. The parameter's purpose is partly inferred from the tool name, but explicit details are missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly specifies the source (SEC EDGAR), scope (US-listed companies / Indian ADRs only), and mentions an optional cross-check feature. It immediately distinguishes the tool from siblings like get_financials or get_key_ratios by focusing on company facts from a specific regulatory source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for US-listed/ADR companies by stating the scope limitation, but it does not explicitly state when to use this tool versus siblings like get_financials or analyze_company. No alternative tools are named, and there is no guidance on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
moat_assessmentC
Economic-moat signals (brand/cost/scale/IP) with a 0-10 heuristic score.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| market | No | IN | |
| ticker | Yes |
TDQS
C2.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states the tool returns a heuristic score and signals, but does not explain side effects, data source, freshness, or whether it is read-only. This leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single salient sentence, front-loaded with key information. It could be more structured but remains concise and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and simple parameters, the description should cover usage context, score interpretation, and parameter constraints. It only offers a high-level summary, missing critical details for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for parameters. The description adds no meaning to 'ticker' or 'market' (e.g., what 'market' values like 'IN' represent). The agent must guess from names, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's subject (economic-moat signals) and output (0-10 heuristic score), with examples of signal types (brand, cost, scale, IP). It effectively distinguishes from sibling tools like 'score_company' and 'risk_assessment' by specifying the moat focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'analyze_company' or 'risk_assessment'. It lacks any 'use when' or 'prefer X for' statements, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
risk_assessmentC
Risk signals (leverage, currency, concentration, regulation) with a 0-5 safety score.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| market | No | IN | |
| ticker | Yes |
TDQS
C2.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses the types of risk signals but omits behavioral traits like whether the tool is read-only, any side effects, or data freshness. The safety score scale is mentioned (0-5) but not further explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) but at the cost of essential details. It earns its place by being brief, but more sentences would improve completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, two parameters, and many siblings, the description lacks sufficient detail. It does not explain how to interpret the safety score or differentiate from similar tools like score_company or analyze_company.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any parameters despite schema having two parameters (ticker required, market optional). Schema description coverage is 0%, so the description adds no value for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool returns risk signals (leverage, currency, concentration, regulation) and a safety score, clearly indicating the output. It distinguishes from sibling tools like analyze_company or score_company by focusing on risk, though it could specify the score range more explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives such as moat_assessment or score_company, nor does it mention prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
score_companyC
The 0-100 investment rating with its eleven weighted buckets and rationale.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| market | No | IN | |
| ticker | Yes |
TDQS
C2.1/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should fully disclose behavior. It mentions 'eleven weighted buckets and rationale' but omits whether the tool is read-only, idempotent, or has any side effects. The brevity leaves key behavioral aspects undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single fragment ('The 0-100 investment rating with its eleven weighted buckets and rationale.') rather than a complete sentence. It is too sparse, sacrificing clarity for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a simple parameter set, the description should explain what the tool returns (e.g., structure of the rating, rationale format). It does not, leaving the agent with incomplete information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fails to explain either parameter ('ticker' or 'market'). It does not add any meaning beyond what the schema provides, which is just field names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description hints at the tool's output (a 0-100 investment rating with eleven buckets and rationale), but it lacks an explicit verb. It does not clearly state that the tool scores a company, and it does not differentiate from siblings like 'analyze_company' or 'risk_assessment'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. There is no mention of prerequisites, ideal scenarios, or exclusions, leaving the agent to guess based solely on the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_companyA
Resolve a company name to an exchange ticker (NSE/BSE preferred for India).
Returns the best match plus ranked alternatives.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| market | No | IN |
TDQS
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns the best match plus ranked alternatives, indicating a read-only lookup behavior. However, it lacks details on side effects, authentication, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two sentences (18 words) that front-load the core purpose. Every word is meaningful without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with two straightforward parameters and no output schema, the description covers essential aspects: input (company name), output (ticker with alternatives), and scope (India). It is adequately complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 2 parameters with 0% description coverage. The description adds context about Indian market preference (NSE/BSE), hinting at the 'market' parameter's role, but does not fully explain its syntax or options. It adds some value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves company names to exchange tickers, with specific mention of NSE/BSE for India. This distinguishes it from sibling tools like analyze_company or get_company_profile which deal with analysis or profile retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you have a company name and need a ticker) but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or when-not-to-use guidance.
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.
14 tool updates
v0.1.0- First observed
analyze_company - First observed
compare_peers - First observed
dcf_valuation - First observed
get_company_profile - First observed
get_financials - First observed
get_industry_intelligence - First observed
get_key_ratios - First observed
get_management - First observed
get_news - First observed
get_sec_facts - First observed
moat_assessment - First observed
risk_assessment - First observed
score_company - First observed
search_company
TDQS
B3.3/5.0
Scored across 14 tools
Disambiguation5/5
Each tool targets a distinct aspect of investment analysis (profile, financials, ratios, valuation, moat, risk, etc.), with no overlapping purposes. The comprehensive description helps an agent clearly distinguish between them.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern (e.g., get_company_profile, analyze_company, dcf_valuation) using lowercase and underscores. This makes the tool set predictable and easy to navigate.
Tool Count5/5
With 14 tools, the server covers the full breadth of investment analysis without being excessive. Each tool adds specific value, and the count matches the domain's complexity well.
Completeness5/5
The tool set covers all major areas of fundamental analysis: company lookup, profile, financials, ratios, peer comparison, DCF valuation, moat, risk, management, news, SEC data, and a scoring system. No obvious gaps for the intended purpose.
Maintenance
ActivitySlowing
ResponsivenessWithin a week
Related MCP Connectors
The Octagon MCP server provides specialized AI-powered financial research and analysis by integrating with the Octagon Market Intelligence API. It enables users to analyze public market data (SEC filings, earnings transcripts, financial metrics, and stock data for 8000+ companies), private market data (3M+ companies, 500k+ funding rounds, 2M+ M&A/IPO transactions), and conduct deep research including web scraping capabilities. The server also features autonomous research agents that search hundreds of sources and return fully cited reports in approximately one minute.
Research-only MCP server: your AI as a quant research desk. 90 tools, no trades, no brokers.
Stock analysis MCP: 38 indicators, 7 optimizers, 8 backtests, US + India sectors.
7-factor stock scoring MCP server. US/HK/CN, 74 stocks. Free + Premium (USDC/Base). x402 ready.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceMCP server that exposes stock research tools (fundamentals, news, technicals, analyst ratings) to AI clients, enabling autonomous generation of structured investment briefs.-
- AlicenseNot gradedqualityFmaintenanceAn AI-powered MCP server for value investors. Analyze stocks using principles from Benjamin Graham and Warren Buffett.9 npm22MIT
- AlicenseBqualityBmaintenanceComprehensive MCP server for Indian stock market with 60 tools covering NSE/BSE, derivatives, mutual funds, technicals, and more, requiring no API keys. Enables users to access live market data, analyze indicators, and manage investments through natural language.12601MIT