What can you do with this server?

This server provides read-only access to Screener.in data for Indian stocks, covering fundamentals, financial statements, peer comparisons, and chart time-series. * get_fundamentals: Fetches a key-ratios scorecard (P/E, P/B, ROE, ROCE, market cap, dividend yield, etc.) plus pros/cons and a short company about. * get_financials: Retrieves full financial statement tables — quarterly results, P&L, balance sheet, cash flow, ratios, and shareholding patterns. * get_peers: Gets the sector peer comparison table for a given stock (with peers’ P/E, ROE, market cap, etc.). * get_chart: Returns time-series data from Screener’s chart API, with configurable metric (e.g. Price, Price-DMA50-Volume, Quarter Sales, EPS) and lookback window. All tools take an NSE/BSE trading symbol (e.g. TCS, RELIANCE) and require no authentication or setup beyond running the MCP server.

How do I use screener-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@screener-mcp show fundamentals for TCS" 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.

screener-mcp

by ashu017

Overview Schema Source Related Servers Score Discussions Admin

Remote

screener-mcp

An MCP server exposing Screener.in data for Indian stocks (NSE/BSE) — fundamentals, financial statements, peers, price/EPS time-series, and stock screening that works without an account — as tools any MCP client (Claude, etc.) can call.

Screener.in is server-rendered (Django), so most data comes from a single HTML GET; the chart tool uses Screener's JSON chart API.

Tools

Tool	Args	Returns
`get_fundamentals`	`symbol`	Key ratio cards (P/E, P/B, ROE, ROCE, Market Cap, Book Value, Dividend Yield, etc.), pros/cons, about
`get_financials`	`symbol`	Statement tables: Quarterly Results, P&L, Balance Sheet, Cash Flow, Ratios, Shareholding
`get_peers`	`symbol`	Sector peer comparison table (CMP, P/E, Market Cap, Div Yield, NP, ROCE, sales growth) + sector median
`get_chart`	`symbol`, `metric?`, `days?`	Time-series from the chart API. `metric` e.g. `Price-DMA50-Volume`, `Price`, `Quarter Sales`, `EPS`
`get_ratios`	`symbol`	The same fundamentals as typed numbers (`pe`, `pb`, `roe`, `roce`, `debtEquity`, `salesGrowth3yPct`, `promoterHoldingPct`, …) rather than display strings
`get_quarterly_results`	`symbol`	Per-quarter Sales / Net Profit / EPS / OPM keyed by ISO quarter-end date
`screen_stocks`	`query`, `limit?`, `sort?`, `order?`, `minMarketCapCr?`, `refresh?`	Screens ~5,400 companies with no sign-in. Nine metrics; see Screening
`get_public_screen`	`screen`, `maxPages?`, `sort?`, `order?`	Reads a saved screen by id or URL, no sign-in. Also returns the screen's own DSL
`build_screen_link`	`query`	A link the user clicks to run any query in their own signed-in browser, plus the words to send with it
`list_public_screens`	`page?`, `maxPages?`	Screener's directory of public screens, for finding one that already exists
`run_screen`	`query`, `maxPages?`, `sort?`, `order?`	Screener's own DSL endpoint — the full ratio vocabulary. Needs sign-in
`screener_auth_status`	—	Four-state sign-in report with an instruction to relay. See Signing in

get_fundamentals returns what Screener displays ("₹ 17,60,650 Cr."); get_ratios returns what you can compute with (marketCapCr: 1760650). Reach for get_ratios when comparing or grading stocks, get_fundamentals when showing a human the page as-is.

Every company tool reads one page, preferring the consolidated view and falling back to standalone. The fallback triggers on an empty consolidated page as well as a 404, because Screener serves some consolidated views as a 200 whose statement tables carry row labels and no period columns at all — Netweb, Bharti Hexacom, KSH International and Dynamic Cables all render that way while their standalone pages hold 13 quarters. Without the emptiness check those companies come back with null ratios and zero quarters and look like real answers. url in the result says which view you actually got, which matters when comparing companies.

Banks and NBFCs get null for debtEquity and salesGrowth3yPct on purpose — their "Borrowings" are customer deposits and their "Sales" is interest income, so those ratios don't mean what they mean elsewhere. isFinancialCompany and caveats say when this applied.

Related MCP server: screener-mcp

Screening

Screener gates its DSL endpoint (/screen/raw/) behind a login, so there are three routes to a screen. Start with screen_stocks — it needs no account at all.

`screen_stocks` — no account, whole market

Screener publishes the same table a screen renders on its public industry pages under /market/. screen_stocks sweeps them into a local cache — 5,438 companies as of 2026-09-04, from Bharti Airtel down to sub-crore microcaps — and evaluates your query against all of it. That's the whole listed universe, not 50 rows a page.

Return on capital employed > 15 AND Market Capitalization > 10000
  AND YOY Quarterly profit growth > 20

The trade is vocabulary. Only these nine metrics exist anonymously:

Current price · Price to Earning · Market Capitalization · Dividend yield · Net Profit latest quarter · YOY Quarterly profit growth · Sales latest quarter · YOY Quarterly sales growth · Return on capital employed

A clause on anything else — ROE, debt/equity, Piotroski, promoter holding, 3-year growth — is not silently dropped. It comes back in unappliedClauses, the rows are labelled a superset of your query, and note says so in plain language. The intended workflow is "narrow here, then call get_ratios per shortlisted symbol to check the rest". A query where nothing applies throws rather than handing back 5,438 rows dressed up as a result.

Only AND is supported; OR and parentheses land in unappliedClauses too.

Cold-call cost, and how to cut it

The first call builds the cache by sweeping Screener at a deliberately slow ~0.77 req/s, so its cost is essentially the number of pages fetched. A market-cap floor in the query cuts that by 7×, because two properties of these pages compound:

/market/'s four-level taxonomy aggregates. Only the 188 leaves are linked, but the 1-, 2- and 3-level prefixes are live URLs serving the union of their children — /market/IN02/ reports 1,402 companies, matching what its 12 leaves held. So the same universe is reachable from 12 sector pages instead of 188 leaves.
Every page is strictly market-cap descending (verified across all 188 leaves and 5,438 rows, zero inversions). So a query with a market-cap floor can stop paging a sector the moment its rows drop below the floor.

Coarse buckets are what make the floor pay: the fixed one-page-per-bucket cost is 12 requests rather than 188, leaving early termination something to save. Measured:

Sweep	Pages	Time
188 leaves, no floor (the old default)	334	449 s
12 sectors, no floor	223	~300 s
12 sectors, `Market Capitalization > 1000`	70	~94 s
12 sectors, `Market Capitalization > 10000`	32	36 s

That last row is measured end-to-end and returns the identical 152 matches the 449 s sweep did. So put a market-cap clause in the query when you can, or set minMarketCapCr when the DSL has no such clause but the user doesn't care about microcaps — it's reported back as an applied clause, since it narrows the answer.

The pacing constants are untouched; the speed-up is entirely fewer requests. Results are cached 12 h. Progress goes to stderr, which most MCP clients surface as server logs.

Two things a floored sweep gives up, both reported rather than hidden. universeSize counts only companies at or above the floor, so it is not the size of the market — the result carries universeMinMarketCapCr and says so in note. And a cache swept to floor F is only reused for queries whose own floor is ≥ F; widen the query below F and it re-sweeps rather than answer from a universe that is missing exactly the companies you just asked for.

Sector-level sweeping also makes each row's industryName a sector ("Consumer Discretionary") rather than a specific industry ("Commodity Chemicals"). industryLevel on every row says which you got, and note mentions it.

`build_screen_link` + `get_public_screen` — any query, still no credential

When a query needs a metric screen_stocks lacks, don't ask the user for a cookie — hand them a link. build_screen_link mints a /screen/new/?query=… URL and the words to send with it. Their browser is already signed in to Screener, so the screen runs there.

Once they save it, the screen lives at /screens/<id>/<slug>/, which is readable anonymously, with pagination, and doesn't expire. They paste that address back and get_public_screen can read it forever. One click converts a login-gated query into a permanent public read.

get_public_screen is liberal about what it accepts — a bare id, a full URL, a URL with a ?page=2 tail, a missing scheme — because that's where a non-technical user's copy-paste lands. It also returns the screen's own DSL in query, so you can see what a saved screen actually filters on.

One limit, measured rather than assumed: ?sort= is login-gated, and the gate is on the parameter rather than its value (?sort=name redirects too), while ?page= passes and ?order= passes but is then ignored. So there is no anonymous ordering lever. sort raises an auth error instead of sorting whichever 25 rows happened to be fetched and calling them the top. To get "the biggest in this screen" anonymously, raise maxPages to cover the screen and order the rows yourself.

`run_screen` — the full vocabulary, with sign-in

Screener's own DSL endpoint, 50 rows per page, every ratio it supports:

Return on capital employed > 15 AND Debt to equity < 1
  AND Piotroski score >= 7 AND Market Capitalization > 5000

This is the one tool that requires sign-in — Screener redirects anonymous callers to /register/. Use it when screen_stocks can't express the query.

symbol is the NSE/BSE trading symbol, e.g. TCS, RELIANCE, MTARTECH. Every screening tool returns a slug per row that works as symbol for the others.

Use it (no setup)

Requires Node 18+. Nothing to clone or build — add this to your MCP config (.mcp.json in a project, or ~/.claude.json globally):

{
  "mcpServers": {
    "screener": {
      "command": "npx",
      "args": ["-y", "screener-mcp"]
    }
  }
}

Or, from Claude Code:

claude mcp add screener -- npx -y screener-mcp

That's the whole setup. Fundamentals, financials, peers, charts and screen_stocks all work immediately, with no account.

To pin a version, use screener-mcp@0.2.0. To run straight from git without npm: npx -y github:ashu017/screener-mcp (builds on install via the prepare script).

Signing in (optional)

Sign-in buys exactly one thing: run_screen's full ratio vocabulary. Everything else, screening included, works anonymously — so treat this as optional.

Screener has no OAuth or API keys. It's a Django app, so being "signed in" means holding a sessionid cookie. Three ways to get one:

npx screener-mcp login --chrome     # opens the Chrome you already have (easiest)
npx screener-mcp login --browser    # same, via a browser Playwright downloads
npx screener-mcp login              # email + password, prompted with no echo
npx screener-mcp status             # is my session still valid?
npx screener-mcp logout             # delete it

Only the returned cookie is kept, in ~/.config/screener-mcp/session.json at mode 0600 — never a password, never anything in an MCP config file. The session outlives the server process, so you log in once, not per MCP session.

When the cookie expires, tools return an instruction to re-run login instead of failing obscurely, and agents can call screener_auth_status deliberately. That tool reports four states, not two: active, anonymous, expired, and unknown — the last meaning Screener couldn't be reached, so it is not a sign-in problem and the user shouldn't be sent to log in again over a dropped connection. Each state carries an instruction written to be relayed verbatim, including the case where SCREENER_SESSION_ID is the thing that expired and running login therefore won't help.

`login --chrome` (recommended)

Drives the Chrome, Chromium, Edge or Brave already installed on your machine over the DevTools Protocol. Nothing to download, and no new dependency in this package — it uses Node's built-in WebSocket.

It opens Screener's login page in a browser profile of its own, kept at ~/.config/screener-mcp/browser-profile (mode 0700), so your everyday tabs, bookmarks and history are untouched. You sign in however you normally do; it watches for sessionid, verifies it, saves it, and closes the browser. Nothing you type passes through the CLI.

Two requirements: Node 22+ (older versions have no built-in WebSocket) and a display. The server itself still runs on Node 18 — this limit applies only to --chrome.

It reads sessionid even though the cookie is HttpOnly, which a browser console could not do, and captures csrftoken alongside it. It never touches your default Chrome profile: Chrome 136+ refuses remote debugging there outright, and the consent-gated path Chrome 144 added needs a checkbox in chrome://inspect plus an Allow dialog on every run — a harder and scarier ask than signing in once in a fresh window.

`login --browser`

The same flow through Playwright, which downloads its own Chromium. Use it if --chrome can't find a browser. Needs Playwright — not a dependency of this package, since it pulls a several-hundred-megabyte browser and most installs only ever run the server:

npm install playwright && npx playwright install chromium

It's looked up in your working directory and the global npm root; SCREENER_PLAYWRIGHT_PATH points at it anywhere else. Needs Node 20+.

`login` (email + password)

Posts once to Screener's own /login/ form and keeps the sessionid it returns. Your password is used for that single request and is never stored or logged.

Screener also offers /login/google/ and /login/apple/. If you signed up with Google or Apple there is no password to post, so this path cannot work for you — use --chrome.

If none of those fit (headless host, or Screener puts a captcha in front of login), sign in with a browser, take the sessionid value from DevTools → Application → Cookies, and pass it as an env var (this takes precedence over the stored file):

{
  "mcpServers": {
    "screener": {
      "command": "npx",
      "args": ["-y", "screener-mcp"],
      "env": { "SCREENER_SESSION_ID": "your-sessionid-cookie" }
    }
  }
}

Env var	Purpose
`SCREENER_SESSION_ID`	Use this cookie instead of the stored session. Overrides the file, so `login` can't replace an expired value here
`SCREENER_MCP_CONFIG_DIR`	Override where the session, browser profile and universe cache are stored
`SCREENER_UNIVERSE_TTL_HOURS`	How long `screen_stocks` reuses its cached sweep (default 12)
`SCREENER_USERNAME` / `SCREENER_PASSWORD`	Non-interactive `login`, for CI/headless
`SCREENER_BROWSER_EXECUTABLE`	Path to the browser to use for `--chrome` or `--browser`
`SCREENER_PLAYWRIGHT_PATH`	Path to a `playwright` module dir, if it isn't in cwd or the global npm root
`SCREENER_BROWSER_HEADLESS`	Run browser login headless. Only refreshes an already signed-in profile — it cannot complete a first-time sign-in
`SCREENER_USER_AGENT`	Override the User-Agent sent to Screener

Use your own account only, and note that automated access to account-gated pages is subject to Screener's terms, which license the site's material "for personal, non-commercial transitory viewing only".

Local development

npm install        # runs tsc via the prepare script
npm run build      # tsc
npm start          # node dist/index.js  (stdio transport)
npm run dev        # tsx src/index.ts
npm test           # vitest (needs Node 20+)

Point an MCP client at a local checkout with:

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

How peers works

Screener lazy-loads the peer table from GET /api/company/{warehouseId}/peers/ — note this uses a separate warehouse id (from data-warehouse-id on the page), not the company id, and requires the X-Requested-With: XMLHttpRequest header. get_peers resolves the warehouse id from the company page, fetches that fragment, and parses the comparison table plus the sector-median row.

Testing

npm test

Tests run the parsers against a captured Screener HTML fixture (test/tcs.fixture.html), so they are deterministic and don't hit the network.

Notes / etiquette

Data is scraped from Screener.in for personal use. Respect their terms and don't hammer the site; cache results and rate-limit in your client.
Screener will IP-block you at the TCP level, with no 429 first — connections simply stop being accepted. Measured: 4 concurrent requests at 200 ms spacing got a host blocked for ~57 minutes after roughly 30 requests. screen_stocks therefore defaults to 2 concurrent with 2000 ms spacing, which swept every industry page untouched, and caches the result for 12 h. Don't raise those without re-measuring — screen_stocks got 12× faster by fetching fewer pages, not by pacing them harder, which is the only safe lever here.
screener.in/robots.txt disallows the ?page=, ?sort=, ?limit= and ?q= query parameters. Paginating a screen or an industry page necessarily requests ?page=N, so screen_stocks, get_public_screen and run_screen do send disallowed query strings. Page 1 is always fetched as the bare, allowed URL.
Selectors target Screener's current DOM; if Screener changes markup, the parsers (src/screener.ts, src/market.ts, src/public-screens.ts) may need updating. The fixture test will catch regressions in the company-page parsers.

License

MIT

Available Tools

4 tools

get_chartA

Time-series for an Indian stock from Screener.in's chart API. Metric examples: 'Price-DMA50-Volume', 'Price', 'Quarter Sales', 'EPS'. days: lookback window.

ParametersJSON Schema

Name	Required	Description	Default
`days`	No	Lookback in days
`metric`	No	Chart metric key	Price-DMA50-Volume
`symbol`	Yes	NSE/BSE trading symbol, e.g. TCS, RELIANCE, MTARTECH

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It does describe the metric structure and lookback window, but doesn't mention return format, frequency of data points, whether historical adjustments are made, or any rate-limiting concerns. It's a read operation, which is reasonably clear.

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?

Three concise sentences with zero filler. The provided examples and days explanation are efficient and front-loaded. Slightly sparse but every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description must hint at return semantics; the metric examples partially convey this. Given the moderate complexity (3 params, no enums) and no output schema, the description is adequate but could benefit from noting data granularity (daily/eod) and source limitations.

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%, so the schema fully documents all 3 parameters. The description adds modest value by showing real metric examples ('Price-DMA50-Volume', 'Quarter Sales', 'EPS') that illustrate valid key formats beyond the generic schema field. Baseline 3 with slight credit for concrete examples.

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 provides time-series data for an Indian stock from a specific API, with concrete metric examples. It distinguishes itself reasonably from siblings (get_financials, get_fundamentals target fundamentals/ratios, not chart series), though it doesn't explicitly differentiate.

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 when to use (when you need time-series/chart data for an Indian stock) but doesn't explicitly state when not to use it or name alternatives. With siblings like get_financials and get_fundamentals, the guidance is only implicit via the metric examples.

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

get_financialsB

Financial statement tables (quarterly results, P&L, balance sheet, cash flow, ratios, shareholding) for an Indian stock, from Screener.in.

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	Yes	NSE/BSE trading symbol, e.g. TCS, RELIANCE, MTARTECH

TDQS

B3.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 describes the tool as fetching read-only table data, which implies a safe read operation, but doesn't disclose data freshness, pagination, or whether the tables are comprehensive or summarized views. For a non-mutating data fetch tool this is acceptable but not rich.

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 efficient sentence that lists the specific financial statement types returned. Zero waste, though the list is somewhat long. It's front-loaded with the core purpose and adds the data source detail without fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter data-fetch tool with no output schema, the description reasonably covers what's returned. However, it doesn't clarify how it differs from get_fundamentals, which could lead to incorrect tool selection, and doesn't note data freshness or coverage limitations. Adequate but with identifiable gaps.

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 description coverage is 100%, with the symbol parameter fully documented ('NSE/BSE trading symbol, e.g. TCS, RELIANCE, MTARTECH'). The description names the data categories returned but doesn't add meaning beyond the schema for the single symbol parameter. Baseline 3 is appropriate when schema does the heavy lifting.

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 retrieves 'Financial statement tables' (quarterly results, P&L, balance sheet, cash flow, ratios, shareholding) for an Indian stock from Screener.in. It identifies the specific resource (financial statements) and the data source (Screener.in). It doesn't fully distinguish from get_fundamentals, which could overlap significantly, so it's not a 5.

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 this tool versus alternatives. The sibling tools include get_fundamentals, which likely overlaps in purpose, but the description provides no differentiation or exclusion criteria. There's no note about when financial statements are needed vs. fundamentals or peers.

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

get_fundamentalsA

Key ratios scorecard for an Indian stock (P/E, P/B, ROE, ROCE, market cap, dividend yield, etc.), plus pros/cons and a short about, from Screener.in.

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	Yes	NSE/BSE trading symbol, e.g. TCS, RELIANCE, MTARTECH

TDQS

A3.6/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 transparency burden. It identifies the data source (Screener.in) and the return shape (ratios + pros/cons + about), which is useful. However, it doesn't disclose freshness/delay of data, whether coverage is limited to certain stocks, or failure behavior for invalid symbols. For a clearly read-only informational tool these gaps are moderate.

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, efficient sentence that front-loads the purpose (key ratios scorecard) and lists deliverable content without waste. It conveys source and scope compactly. It could arguably be slightly more structured but is not verbose or redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter, no-output-schema read-only tool, the description covers the core deliverable list adequately. However, it doesn't mention the return format, value discipline (e.g., updated annually vs real-time), or any caveats about coverage breadth on Screener.in. Given the simplicity, this is minimally complete but not richly so.

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 100% and the symbol parameter is well documented in the schema with examples (TCS, RELIANCE, MTARTECH). The description adds context by indicating the symbol must be an Indian NSE/BSE stock, slightly enriching the schema. With full schema coverage, the baseline of 3 is appropriate.

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 a specific verb+resource combination: it returns a 'key ratios scorecard' for an Indian stock from Screener.in, listing specific metrics (P/E, P/B, ROE, ROCE, market cap, dividend yield). It also adds the pros/cons and about sections, distinguishing it from siblings like get_financials (financial statements) and get_peers (comparison).

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 identifies the tool as a ratios scorecard distinct from financial statements and peers, which implies appropriate usage for snapshot ratio analysis. However, it doesn't explicitly say when-not-to-use, state alternatives, or note prerequisites like whether the symbol must be an Indian/NSE/BSE stock beyond the implicit mention.

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

get_peersB

Sector peer comparison table for an Indian stock (peers with P/E, ROE, market cap, etc.), from Screener.in.

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	Yes	NSE/BSE trading symbol, e.g. TCS, RELIANCE, MTARTECH

TDQS

B3.4/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 behavioral burden. It identifies the data source (Screener.in) and the nature of the output (comparison table of peers), but doesn't disclose potential behaviors like scrape delays, rate limiting, unavailable data for certain symbols, or what happens for symbols without sector peer data.

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, efficient sentence that packs in the purpose (peer comparison), scope (Indian stocks), content (P/E, ROE, market cap), and source (Screener.in). No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-required-parameter tool with full schema coverage and no output schema, the description covers the basics well. However, there's no mention of the output format/structure, whether the peer set is defined by Screener.in's sector classification, or edge cases. Given its relative simplicity, this is a slight gap but not severe.

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 100%, and the parameter 'symbol' has a clear description with concrete examples (TCS, RELIANCE, MTARTECH). The description adds minimal value beyond the schema since the symbol parameter is self-explanatory. Baseline 3 is appropriate given full schema coverage.

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 provides a sector peer comparison table for an Indian stock, listing metrics like P/E, ROE, market cap. It names the source (Screener.in), which adds useful context. It doesn't explicitly distinguish from siblings, but its purpose is specific and clear.

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 when to use it (when you want peer comparison data for a stock), but doesn't explicitly state when NOT to use it or mention alternatives like get_fundamentals or get_financials. The context is clear but no exclusionary guidance is provided.

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. Dates show when Glama detected each change.

4 tool updatesv0.1.0Aug 4, 2026
- First observedget_chart
- First observedget_financials
- First observedget_fundamentals
- First observedget_peers

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Scored 2026-08-04 03:55 across 4 tools

Disambiguation4/5

The four tools target distinct data resources: financial statements, peer comparison, chart time-series, and fundamentals scorecard. get_financials vs get_fundamentals have some descriptive overlap (both include ratios), but their descriptions are distinct enough to typically select correctly.

Naming Consistency5/5

All tools follow a consistent get_noun pattern with clear camelCase-free snake_case naming. Each name clearly indicates retrieving a specific resource type.

Tool Count3/5

Four tools is on the low end for a general stock screener/research server. It feels somewhat thin for a 'screener' purpose, which typically expects searching/screening functionality in addition to viewing a single stock's data.

Completeness2/5

The server covers data retrieval for a single stock but is missing obvious screening/search capabilities despite the 'screener' name. There's no way to search stocks by criteria, scan the market, or discover tickers—significant gaps for the stated screener purpose.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

DalalOSOAuth
io.github.aatharva16
Indian NSE/BSE research data and mechanically-computed ratios; read-only market tools.
Finance Research & Data Search
2
ko-mcp A
io.github.SharpLu
Real SEC, 13F, insider, congress & macro data your AI agent can cite. Hosted MCP, 24 tools.
Finance Government Data
242
Drillr — The financial MCP for AI agents A
ai.drillr
The financial MCP for AI agents - 90+ financial tables, SEC filings, signals, alt-data.
Finance Research & Data Data Platforms
1036
secedgar-mcp-server A
io.github.cyanheads
Query SEC EDGAR filings, XBRL financials, and company data through MCP. STDIO & Streamable HTTP.
Finance Government Data Open Data
1629

Related MCP Servers

sfinance-mcp-server
Finance Research & Data
shivakharbanda
F
license
Not graded
quality
D
maintenance
Provides access to Indian stock market data via screener.in, enabling stock analysis, document access, screening, and more through MCP.
Updated 5 months ago (2026-04-02 15:08 UTC)
-
screener-mcp
Finance Web Scraping
ronyv89
F
license
A
quality
D
maintenance
Provides financial data for Indian listed companies from screener.in, enabling users to search companies and fetch financial statements, ratios, and peer comparisons.
Updated 3 months ago (2026-06-20 08:35 UTC)
2
1
-
screener-mcp
Finance Research & Data
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.
Updated 2 months ago (2026-07-01 05:01 UTC)
MIT
screener-mcp-pro
Finance Research & Data
vidyasagardivi9
A
license
A
quality
C
maintenance
MCP server providing fundamental and technical data on Indian-listed companies from Screener.in and Yahoo Finance, including financial statements, ratios, and technical indicators.
Updated 2 months ago (2026-07-16 02:55 UTC)
12
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ashu017/screener-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

screener-mcp

Tools

Screening

screen_stocks — no account, whole market

Cold-call cost, and how to cut it

build_screen_link + get_public_screen — any query, still no credential

run_screen — the full vocabulary, with sign-in

Use it (no setup)

Signing in (optional)

login --chrome (recommended)

login --browser

login (email + password)

Cookie by hand

Local development

How peers works

Testing

Notes / etiquette

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`screen_stocks` — no account, whole market

`build_screen_link` + `get_public_screen` — any query, still no credential

`run_screen` — the full vocabulary, with sign-in

`login --chrome` (recommended)

`login --browser`

`login` (email + password)