Tapetide - Indian Stock Market MCP

Screen & Rank by Tapetide Score

screen_tapetide_scores

Read-onlyIdempotent

List and rank stocks by the Tapetide Score, filtered by size bucket, band, score window, sector, minimum data-confidence and symbol/name search. Rows come back in the server's final order with score, band, pillars, sector, size, market cap and a next-page cursor. USE THIS for 'which large caps score highest', 'show me Strong-band pharma stocks', or any rank/filter-by-Tapetide-Score question — same data and ordering as the tapetide.com ranking page. IMPORTANT, or you will describe the results wrongly: (1) present rows by BAND, never as an ordinal '#1, #2, #3' leaderboard — nothing has ever scored above 77 and neighbouring scores are not meaningfully different; (2) the DEFAULT view is large+mid cap at confidence >= 75, a filtered slice and not the whole market, so state the active filters (meta.counts) alongside any ranking; (3) sizes:["all"] adds small/micro caps — flag their liquidity risk (market cap is a size proxy, not liquidity); (4) quote meta.snapshot.score_date and reuse next_cursor to stay on that run. These are stocks matching the given Tapetide Score criteria, NOT investment recommendations. Decision-support only. The Tapetide Score is data analysis, not investment advice. Tapetide is not a SEBI-registered research analyst or investment adviser. Bands are intentionally coarse; small point differences may not be meaningful.

Input Schema

TableJSON Schema

Name	Required	Description
`q`	No	Substring search on symbol or company name.
`sort`	No	Sort key, default "band" (coarse tiers first — the honest default). "score" is exact composite order; also confidence, market_cap, name.
`bands`	No	Score bands to include: "66-plus" (Strong), "55-65" (Good), "45-54" (Average), "37-44" (Weak), "below-37" (Poor) — the keys rows carry in `band`. Omit for all bands. The older keys "70-plus", "60-69", "50-59", "30-49", "below-30" still work and select the same tier by position (70-plus = Strong, i.e. 66+). There is no 80+ band.
`limit`	No	Rows per page (default 50, max 100).
`order`	No	Direction, default "desc".
`sizes`	No	Size buckets. Default ["large","mid"]. Use ["all"] for the full scored universe (dominated by micro caps by count — mention the liquidity caveat if you do).
`cursor`	No	Pass `meta.next_cursor` from the previous response to get the next page. The run date is embedded in it, so paging stays pinned to one scoring run.
`sectors`	No	Sector names as returned in `meta.facets.sectors` (e.g. "Metals & Mining"). Omit for all sectors.
`max_score`	No	Maximum composite score.
`min_score`	No	Minimum composite score.
`min_confidence`	No	Minimum data-confidence, default 75. Lowering it admits stocks with thinner data; the response reports how many the bar excluded.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 19, 2026

changedInput schema / properties / bands / description

Previous value: -"Score bands to include: \"70-plus\" (Strong), \"60-69\" (Good), \"50-59\" (Average), \"30-49\" (Weak), \"below-30\" (Poor). Omit for all bands. There is no 80+ band."New value: +"Score bands to include: \"66-plus\" (Strong), \"55-65\" (Good), \"45-54\" (Average), \"37-44\" (Weak), \"below-37\" (Poor) — the keys rows carry in `band`. Omit for all bands. The older keys \"70-plus\", \"60-69\", \"50-59\", \"30-49\", \"below-30\" still work and select the same tier by position (70-plus = Strong, i.e. 66+). There is no 80+ band."

changedInput schema / properties / bands / items / enum

Previous value: -[
-  "70-plus",
-  "60-69",
-  "50-59",
-  "30-49",
-  "below-30"
-]New value: +[
+  "66-plus",
+  "55-65",
+  "45-54",
+  "37-44",
+  "below-37",
+  "70-plus",
+  "60-69",
+  "50-59",
+  "30-49",
+  "below-30"
+]

First observedOct 9, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations only cover the safety profile (readOnly/idempotent/not destructive); the description adds substantial beyond-annotation context: the non-ordinal band presentation rule, the default filtered slice (large+mid, confidence>=75), the size-bucket liquidity caveat, and snapshot/cursor pinning to a single scoring run.

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?

Purpose and the key usage triggers are front-loaded, which is good. But the entry is bloated by a long 'IMPORTANT' block plus three near-duplicate disclaimers ('NOT investment recommendations', 'Decision-support only', 'not investment advice', SEBI line) that restate the same point and dilute the signal.

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

Completeness5/5

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

For an 11-parameter ranking tool with no output schema, the description fully discloses what rows contain (score, band, pillars, sector, size, market cap, next_cursor) and how to page, so an agent has everything needed to call and interpret it correctly.

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%, so the schema already documents every parameter (q, sort, bands, sizes, cursor, min_confidence, etc.) in detail. The description restates the filter set but adds little parameter syntax beyond echoing defaults already in the schema, so baseline 3 applies.

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?

States a specific verb+resource ('List and rank stocks by the Tapetide Score') with the filter axes enumerated, and it clearly separates the tool from siblings like get_tapetide_score and screen_stocks by framing it as the rank/filter-by-score surface that mirrors the tapetide.com ranking page.

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?

Gives concrete trigger queries ('which large caps score highest', 'show me Strong-band pharma stocks') and states the tool owns 'any rank/filter-by-Tapetide-Score question'. It does not explicitly name when to prefer get_tapetide_score (single-stock) or screen_stocks instead, so no true exclusion guidance.

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

All Tapetide - Indian Stock Market MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Screen & Rank by Tapetide Score

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources