Skip to main content
Glama
ronyv89

screener-mcp

by ronyv89
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

screener-mcp

An MCP (Model Context Protocol) server that provides financial data for Indian listed companies from screener.in. Use it with Claude Desktop or any MCP-compatible client to query stock fundamentals, financial statements, and peer comparisons directly in your AI conversations.

Features

  • Search companies by name or ticker symbol

  • Fetch financial data (P&L, balance sheet, cash flow, ratios, peers, shareholding)

  • Supports both consolidated and standalone financials

  • Request only the fields you need to keep responses concise

  • Results cached for 5 minutes — repeated calls for the same company are instant

  • No API key required — uses screener.in's public data

Related MCP server: sfinance-mcp-server

Tools

Tool

Description

search_company

Search for a company by name or ticker

get_company_data

Financial data for a company. Use the optional fields parameter to fetch only what you need

get_company_data fields

Pass a fields array to limit the response to only the sections you need:

Field

Description

ratios

Key financial ratios (Market Cap, P/E, P/B, ROE, ROCE, etc.)

quarterly_results

Quarterly revenue, profit, and EPS

profit_loss

Annual profit & loss statement

balance_sheet

Annual balance sheet

cash_flow

Annual cash flow statement

shareholding

Promoter / FII / DII shareholding pattern

peers

Peer comparison table

Omit fields to fetch all sections at once.

Prerequisites

  • Node.js 18+

  • npm

Installation

git clone <repo-url>
cd screener-mcp
npm install
npm run build

Usage with Claude Desktop

Add the following to your Claude Desktop config file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "screener": {
      "command": "node",
      "args": ["/absolute/path/to/screener-mcp/dist/index.js"]
    }
  }
}

Restart Claude Desktop after saving the config.

Usage with Claude Code

Run this command after building (replace the path with where you cloned the repo):

claude mcp add screener -- node "/absolute/path/to/screener-mcp/dist/index.js"

Add --scope global to make it available in all projects:

claude mcp add --scope global screener -- node "/absolute/path/to/screener-mcp/dist/index.js"

Development

# Run in development mode (no build step needed)
npm run dev

# Build for production
npm run build

# Run production build
npm start

Tech Stack

Example Prompts

Once configured, you can ask Claude things like:

  • "What are the key financial ratios for Reliance Industries?"

  • "Show me the quarterly results for TCS"

  • "Compare HDFC Bank with its peers"

  • "Get the balance sheet for Infosys for the last 5 years"

  • "Search for companies with the name 'Tata'"

Notes

  • Data is scraped from screener.in's public pages — no login required for most data

  • Results depend on screener.in's availability and HTML structure

  • Financial data is sourced from BSE/NSE filings as aggregated by screener.in

Available Tools

2 tools
get_company_dataA

Fetch financial data for a company from screener.in. Use the 'fields' parameter to request only what you need and reduce response size. Available fields: ratios, quarterly_results, profit_loss, balance_sheet, cash_flow, shareholding, peers. Omit 'fields' to get all.

ParametersJSON Schema
NameRequiredDescriptionDefault
fieldsNoSubset of fields to return. Omit for all fields.
symbolYesNSE/BSE ticker symbol (e.g. RELIANCE, TCS, INFY)
consolidatedNoWhether to fetch consolidated financials (default: false for standalone)

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It states that data is fetched from an external source (screener.in) and hints at large response sizes via the 'fields' guidance, but it does not disclose whether the operation is read-only, potential rate limits, or any other behavioral traits that might surprise an agent. This is a minimal but not full disclosure.

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 two sentences, front-loaded with the main purpose, and every sentence earns its place. The second sentence provides actionable guidance without redundancy.

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?

With no output schema, the description could do more to explain the return format, but for a simple fetch tool with 3 parameters (1 required) and covered schema, the description is sufficiently complete. It clearly states the source and gives parameter guidance, though it could mention the 'consolidated' parameter explicitly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (baseline 3). The description adds meaning beyond the schema by explicitly noting 'Use the fields parameter to request only what you need and reduce response size' and 'Omit fields to get all', which provides practical, behavioral context for the parameter beyond its enum values.

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 uses specific verb+resource: 'Fetch financial data for a company from screener.in.' This clearly distinguishes it from the sibling 'search_company' which presumably searches for companies, while this tool retrieves specific financial 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.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context that this tool is for fetching financial data, implying when to use it (when financial data is needed) versus search_company. It also gives explicit usage guidance on the 'fields' parameter to reduce response size. However, it does not explicitly mention alternative tools or exclusions, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_companyA

Search for Indian listed companies on screener.in by name or ticker symbol. Returns a list of matching companies with their URLs.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesCompany name or NSE/BSE ticker symbol to search for

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of disclosing behavior. It accurately states the output (list of matching companies with URLs) but does not mention any potential limitations, authorization requirements, or discrepancies like exact-match vs partial-match results. The behavior is straightforward, but the description adds minimal context beyond the basic functionality.

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 a single, well-structured sentence that immediately states the action, scope, and expected result. There is no redundant information, and every word contributes to clarity.

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 tool with one parameter and no output schema, the description is mostly complete: it explains what the tool does, what input it takes, and what it returns. It lacks guidance on how this tool fits into a larger workflow (e.g., pairing with get_company_data), but for its standalone functionality, it is adequate.

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 covers 100% of parameter descriptions, with the 'query' parameter fully documented as 'Company name or NSE/BSE ticker symbol'. The description mirrors this information, adding only the context of 'Indian listed companies on screener.in'. Since schema coverage is high, the baseline is 3, and the description does not significantly enhance understanding 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's purpose: searching for Indian listed companies by name or ticker symbol on screener.in, and returning a list of matches with URLs. The verb 'Search' is specific, and the resource is well-defined, distinguishing it from the sibling tool 'get_company_data' which presumably fetches detailed data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use the tool: when you need to find companies by name or ticker. However, it does not explicitly mention alternatives or exclusions, such as 'use get_company_data for detailed information after searching'. The context is clear but lacks direct guidance on tool selection.

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.

  1. 2 tool updatesv1.0.0
    • First observedget_company_data
    • First observedsearch_company
Deploy Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: one for searching/locating companies, the other for retrieving detailed financial data for a specific company. There is no overlap in functionality.

Naming Consistency5/5

Both tool names follow a consistent verb_noun pattern: 'search_company' and 'get_company_data'. The naming is predictable and follows standard conventions.

Tool Count3/5

With only 2 tools, the server feels minimal. While this is borderline, the narrow scope (searching and retrieving data from screener.in) justifies a small set, but it may be slightly thin for a general-purpose financial data server.

Completeness4/5

The server provides the essential workflow: search for a company then retrieve its data. Gaps include no ability to list top companies or compare multiple companies, but these are not critical for the core purpose of fetching screener.in data.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • mcp-indian-stocks

    NagrajADesai
    F
    license
    Not graded
    quality
    D
    maintenance
    Enables real-time and historical Indian stock market data retrieval, including prices, news, recommendations, and top gainers/losers.
    -

  • screener-mcp

    aryamanw
    A
    license
    Not graded
    quality
    B
    maintenance
    MCP server that provides access to screener.in financial data for Indian stocks, enabling queries for company info, financials, ratios, quarterly results, shareholding, and stock screening.
    MIT

  • screener-mcp

    ashu017
    A
    license
    B
    quality
    B
    maintenance
    Exposes Screener.in data for Indian stocks (NSE/BSE) — fundamentals, financial statements, peers, and price/EPS time-series — as tools any MCP client can call.
    4
    164
    4
    MIT