Click on "Install 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., "@tickertape-mcp Screen US tech stocks with P/E under 25 and ROE above 15%"
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.
An MCP server for screening and analyzing US stocks and ETFs using Tickertape's screener data, usable from any MCP client. Ask in plain language — "profitable US semiconductor stocks under 20× P/E with ROE above 20%" — and get a ranked, filterable table back.
Disclaimer. This is an unofficial project. It is not affiliated with, endorsed by, or supported by Tickertape or Smallcase. It calls an undocumented public API that may change or break at any time. Data is provided "as is", may be delayed or wrong, and is not investment advice. Only the US market is supported. Use at your own risk and review Tickertape's terms of service before use.
screen_stocks — filter US stocks by any of 70+ metrics (valuation, growth,
profitability, dividends, technicals, ownership, analyst ratings), plus sector /
industry, with sorting and pagination.
screen_etfs — screen ETFs by AUM, expense ratio, returns, yield, and fund
category.
list_filters — discover the available metrics, their units, value ranges, and the
allowed sector/industry values.
search_stocks — look up a ticker or company name.
get_stock_details — a full metric snapshot for one stock or ETF, grouped by
category, with a link to its Tickertape page.
It validates every metric name and value against the live filter catalog, so a typo gets a helpful "did you mean" instead of silently wrong results (see docs/api-notes.md for why that matters).
Related MCP server: Trading MCP Server
Requires Node.js ≥ 18.
claude mcp add tickertape -- npx -y tickertape-mcpAdd to your MCP config (claude_desktop_config.json, or Cursor's mcp.json):
{
"mcpServers": {
"tickertape": {
"command": "npx",
"args": ["-y", "tickertape-mcp"]
}
}
}Then restart the client. No API keys or account are needed.
"Screen US stocks: market cap over $10B, P/E under 25, ROE above 15%, in Technology. Sort by dividend yield."
"Find low-cost S&P 500 ETFs — expense ratio under 0.05%, sorted by AUM."
"What are NVDA's valuation and profitability metrics?"
"Which large-cap healthcare stocks are trading more than 30% below their 52-week high?"
Tool | Key parameters |
|
|
|
|
|
|
|
|
|
|
Metric names accept either a friendly alias (peRatioTtm, marketCap,
returnOnEquity, dividendYield, debtToEquity, expenseRatio, aum) or the raw
Tickertape label. Call list_filters to see them all. Premium metrics (e.g. forward
P/E, analyst estimates) can be shown as columns but not used to filter or sort — that
requires a Tickertape subscription.
On first use it fetches Tickertape's filter catalog (cached in memory) to build the metric list and aliases.
search_stocks / get_stock_details build a local index of the full universe the
first time they run (a few seconds), cached on disk under
~/.cache/tickertape-mcp/ (override with TICKERTAPE_MCP_CACHE_DIR) for 24 hours.
All output is compact markdown to keep token usage low.
See docs/api-notes.md for the reverse-engineered API contract.
npm install
npm run typecheck # tsc --noEmit
npm test # vitest, uses fixtures (no network)
npm run build # bundle to dist/ with tsup
npm run smoke # live end-to-end checks against the real API (not in CI)Inspect the server interactively:
npm run build
npx @modelcontextprotocol/inspector node dist/index.jssrc/
index.ts entry — starts the stdio MCP server
server.ts tool registration and wiring
api.ts HTTP client for the Tickertape API
catalog.ts filter catalog: fetch, aliases, name/value resolution
match.ts builds a query body from tool input (the silent-failure guard)
universe.ts local ticker/name index with disk cache
format.ts markdown renderersnpm run typecheck && npm test && npm run build
npm pack --dry-run — confirm the tarball contains only dist/, README.md,
LICENSE.
Test the bin: npx ./tickertape-mcp-<version>.tgz.
npm publish --access public (optionally --provenance from CI).
Get a detailed metric snapshot for a single US stock or ETF by ticker: valuation, growth, profitability, dividends, and more, grouped by category, with a link to its Tickertape page.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Ticker symbol, e.g. "NVDA" or "VOO". | |
| metrics | No | Additional metric aliases to include beyond the default snapshot. | |
| asset_type | No | Whether the ticker is a stock or ETF. | stock |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes output snapshot and link, but does not disclose error handling, rate limits, authentication needs, or behavior for invalid tickers. Insufficient for a complete behavioral profile.
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?
Single sentence, efficient and without fluff. Covers key details but could benefit from structuring the metric categories (e.g., list). However, it remains clear and front-loaded.
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?
Given no annotations or output schema, description lacks completeness. Does not specify return format, pagination, error behavior, or usage limits. For a single-ticker snapshot, more context (e.g., data refresh frequency) would be helpful.
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 100% with descriptions for all 3 parameters. Description reinforces that ticker is required and adds grouping by category, but does not significantly enhance parameter understanding beyond schema. Baseline 3 is appropriate.
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 it retrieves a detailed metric snapshot for a single US stock or ETF. Mentions specific categories (valuation, growth, profitability, dividends) and a link to Tickertape page. Distinguishes from sibling tools like screen_stocks (screening) and search_stocks (search).
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?
Implicitly indicates it is for individual tickers, but does not explicitly state when to use alternatives or provide exclusions (e.g., for multiple tickers use screening tools). No guidance on prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the metrics and classifications available for screening US stocks and ETFs. Call this first to discover valid metric names (aliases), units, value ranges, and the allowed sector/industry values. Metric aliases returned here are the names to pass to screen_stocks/screen_etfs.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Only show metrics whose name/description matches this text. | |
| category | No | Filter to one category, e.g. "Valuation", "Profitability", "Classification". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description tells what the tool returns (metrics, classifications, units, ranges, sector/industry values) and that results are inputs for other tools. Could mention read-only nature explicitly, but overall transparent.
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?
Two sentences: first states purpose, second provides usage guidance. No unnecessary words, front-loaded with key information.
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, but description comprehensively lists what the tool returns (metrics, classifications, units, ranges, allowed values). Explains how output is used downstream, making it complete for a simple listing tool.
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 covers both parameters fully. Description adds usage context: search filters by name/description, category filters to a specific category with examples. This enhances understanding beyond the schema.
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 states clearly that the tool lists metrics and classifications for screening US stocks and ETFs. It distinguishes from sibling tools like screen_stocks and screen_etfs by being a discovery tool.
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?
Explicitly instructs to call this first to discover valid metric names, units, ranges, and values. Explains that returned aliases should be passed to screening tools, providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen US ETFs by AUM, expense ratio, returns, dividend yield, and other metrics. Use list_filters to discover metric names. Use categories to restrict to fund categories (e.g. "Large Blend", "Digital Assets").
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Rows to return (max 100). | |
| offset | No | Rows to skip, for pagination. | |
| columns | No | Extra metric columns to show. Filtered and sorted metrics are always shown. | |
| filters | No | Numeric constraints, e.g. [{"metric":"expenseRatio","max":0.1},{"metric":"aum","min":1000}]. | |
| sort_by | No | Metric to sort by (alias or label). | aum |
| categories | No | Restrict to these fund categories, e.g. ["Large Blend","Digital Assets"]. | |
| sort_order | No | Sort direction. | desc |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It doesn't explain return format, pagination behavior beyond parameters, or rate limits. The schema covers basic constraints, but behavioral traits are lacking.
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?
Two sentences, front-loaded with the core action and a quick reference to sibling tool. Every word is purposeful and no waste.
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?
Given 7 parameters, no annotations, and no output schema, the description covers the screening purpose and directs to list_filters. Missing return format explanation, but otherwise adequate.
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 100%, so baseline 3. The description adds context for filters and categories but doesn't significantly enhance understanding of parameters beyond the schema.
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?
The description clearly states the tool screens US ETFs by metrics like AUM, expense ratio, returns, and dividend yield. It distinguishes from siblings by specifying 'US ETFs' vs stocks or filter discovery.
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?
The description advises using list_filters to discover metric names and mentions categories for restriction. It could explicitly state when not to use, but the guidance is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen US stocks by fundamental and technical criteria (valuation, growth, profitability, dividends, technicals, etc.). Use list_filters to discover metric names. Numeric filters use min/max; sectors and industries use their own parameters. Results are sorted and paginated.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Rows to return (max 100). | |
| offset | No | Rows to skip, for pagination. | |
| columns | No | Extra metric columns to show. Filtered and sorted metrics are always shown. | |
| filters | No | Numeric constraints, e.g. [{"metric":"peRatioTtm","max":20},{"metric":"returnOnEquity","min":15}]. | |
| sectors | No | Restrict to these sectors, e.g. ["Technology","Healthcare"]. | |
| sort_by | No | Metric to sort by (alias or label). | marketCap |
| industries | No | Restrict to these sub-sectors/industries, e.g. ["Semiconductors"]. | |
| sort_order | No | Sort direction. | desc |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that results are sorted and paginated, and explains filtering mechanics for numeric and categorical parameters. It does not mention auth, rate limits, or edge cases, but for a screening tool this is adequate.
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 concise sentences, front-loaded with purpose, then usage guidance. Every sentence adds value with no redundancy.
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?
Given 8 parameters and no output schema, the description covers filtering, sorting, pagination, and references list_filters for metric discovery. It leaves out details on columns and error handling, but overall sufficient for correct invocation.
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 100%, so baseline is 3. The description adds context about using list_filters for metric names and clarifies that sectors and industries are separate, but does not significantly extend beyond the schema descriptions.
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?
The description clearly states the tool screens US stocks by fundamental and technical criteria, listing categories like valuation, growth, and dividends. It distinguishes from siblings such as screen_etfs and get_stock_details by specifying US stocks and referencing list_filters for metric discovery.
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?
It advises using list_filters to discover metric names and explains that numeric filters use min/max while sectors and industries have separate parameters. However, it does not explicitly contrast with screen_etfs or search_stocks, though sibling names provide context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up US stocks or ETFs by ticker symbol or company name. Returns matching tickers with their exchange and sector. The first call builds a local index and may take a few seconds.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results. | |
| query | Yes | Ticker symbol or (partial) company name. | |
| asset_type | No | Search stocks or ETFs. | stock |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses behavioral traits: 'The first call builds a local index and may take a few seconds.' This is valuable for agent planning. However, it does not mention any read-only nature, permissions, or caching behavior. Still, it is fairly transparent for a search tool.
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?
Two sentences, front-loaded with purpose and return info, no fluff. Every sentence adds value: purpose, return format, and a behavioral note. Highly efficient.
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?
The description covers purpose, return content (tickers with exchange and sector), and initial latency. However, without an output schema, it is incomplete: it does not specify the full result structure (e.g., if ticker symbol and company name are returned, or if there are additional fields like price). Also, no mention of pagination despite a limit parameter. Adequate but with gaps.
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 100%, so baseline is 3. The description adds minimal parameter context beyond the schema: it mentions query is 'Ticker symbol or (partial) company name' which repeats the schema description. No additional meaning is provided for 'limit' or 'asset_type' beyond defaults and ranges.
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?
The description clearly states the tool's purpose: 'Look up US stocks or ETFs by ticker symbol or company name. Returns matching tickers with their exchange and sector.' It uses a specific verb ('look up') and resource ('US stocks or ETFs'), and distinguishes from sibling tools like 'get_stock_details' (detailed info) and 'screen_stocks' (filtering).
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?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention when not to use it or suggest sibling tools like 'screen_stocks' for more advanced filtering. Usage is only implied from the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_stock_detailslist_filtersscreen_etfsscreen_stockssearch_stocksScored across 5 tools
Each tool has a clearly distinct purpose: getting details for a single ticker, listing available screening metrics, screening ETFs, screening stocks, and searching by name or symbol. No overlap or ambiguity.
All tool names follow a consistent snake_case verb_noun pattern (get_stock_details, list_filters, screen_etfs, screen_stocks, search_stocks), making them predictable and easy to distinguish.
With 5 tools, the set is well-scoped for a stock screening and details API. It covers essential operations without being too sparse or overly numerous.
The tool surface covers the full expected workflow: discovering available filters, searching for tickers, screening stocks and ETFs separately, and retrieving detailed metrics for a single ticker. There are no obvious gaps for a read-only screening service.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Stock analysis MCP: 38 indicators, 7 optimizers, 8 backtests, US + India sectors.
Screen 11,000+ stocks using natural language and detect chart patterns via MCP.
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.
7-factor stock scoring MCP server. US/HK/CN, 74 stocks. Free + Premium (USDC/Base). x402 ready.
