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., "@screener-mcp-pro Show me the financial snapshot for HDFC Bank"
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 that gives an LLM (e.g. Claude) rich, structured data on Indian-listed companies: fundamentals and financial statements scraped from Screener.in, plus price-based technical indicators from Yahoo Finance. Built for deep, one-stock-at-a-time research — ratios, multi-year financials, shareholding trends, peer comparisons, annual reports/credit ratings/concall links, and SMA/RSI/ATR — in a single tool call.
Not affiliated with screener.in or Yahoo Finance.
Tool | What it returns | Login needed? |
| Everything below, in one call | No |
| P/E, book value, ROE, ROCE, market cap, dividend yield, About, pros/cons | No |
| Quarterly sales/profit table | No |
| Multi-year P&L with compounded growth | No |
| Multi-year balance sheet | No |
| Multi-year cash flow, incl. free cash flow | No |
| Promoter/FII/DII/govt/public % trend | No |
| Peer CMP/P/E/market cap/ROCE table | No |
| Announcements, annual reports, credit ratings, concall links | No |
| Headcount, $100M+ clients, revenue mix by geography/vertical, TCV, attrition | Yes (see below) |
| SMA20/50/200, RSI14, ATR14, 52w high/low (Yahoo Finance) | No |
| Diagnostic: are credentials configured, did login succeed | N/A |
Related MCP server: india-stock-mcp
claude mcp add screener-pro -- uvx --from git+https://github.com/vidyasagardivi9/screener-mcp-pro- screener-mcp-pro(Registered as screener-pro so it doesn't collide with any other screener MCP server you may already have.)
Every tool above except screener_get_company_insights works with zero configuration — screener.in serves company
pages, financial statements, peer data, and documents publicly. The Insights section (headcount, client counts,
revenue mix, etc.) is different: screener.in only sends those numbers to logged-in sessions. If you want that tool to
return real values instead of just the metric names, register with your own credentials:
claude mcp add screener-pro -e SCREENER_USERNAME=you@example.com -e SCREENER_PASSWORD=your_password \
-- uvx --from git+https://github.com/vidyasagardivi9/screener-mcp-pro- screener-mcp-proCredentials are read only from these environment variables, kept in an in-memory cookie jar for the process's
lifetime, and never written to disk or logged. See .env.example for all supported variables.
No company-search tool. screener.in's robots.txt disallows crawling its ?q= search endpoint, so every tool
takes an explicit symbol (the screener.in slug, normally identical to the NSE trading symbol — e.g. TCS,
INFY, RELIANCE). Resolve the ticker yourself or let the calling LLM infer it from general knowledge.
Scraping-based, not an official API. Parsers degrade gracefully (partial results plus a warnings list) if
screener.in changes its page structure, but they can still break. tests/test_parsers.py runs against saved HTML
fixtures to catch regressions early — if screener.in changes its markup, update the fixtures and parsers together.
screener_get_company_insights values are genuinely locked without login — this isn't a scraping trick to get
around, screener.in simply doesn't send the numbers to anonymous requests. With valid credentials and a successful
login, the tool currently still reports metric names only (numeric-value parsing for the authenticated table layout
is a follow-up, since it couldn't be verified without a live logged-in session during development).
Respectful by design: a single shared HTTP client, a descriptive User-Agent, retry/backoff only on
429/5xx/timeouts, a configurable minimum delay between requests (default 1.5s), and a defense-in-depth check
(robots.py) against screener.in's robots.txt disallow rules. No CAPTCHA or bot-detection bypass of any kind.
Intended for personal/educational use consistent with screener.in's terms and your own account's usage limits — not a redistribution or resale of screener.in's data.
uv sync
uv run pytest
uv run screener-mcp-pro # runs the server over stdioTo inspect tools interactively:
npx @modelcontextprotocol/inspector uv run screener-mcp-proMIT — see LICENSE.
Multi-year balance sheet: equity, reserves, borrowings, assets.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| consolidated | No | ||
| response_format | No | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description is not burdened with safety details. It adds context about multi-year data and specific line items but doesn't elaborate on limitations or error scenarios.
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?
The description is a single, front-loaded sentence with no unnecessary words. Every element (multi-year, balance sheet, specific items) adds value.
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 the simple tool, rich annotations, and existence of output schema, the description adequately states what the tool returns. However, lack of parameter semantics reduces completeness for proper 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 description coverage is 0%, and the description does not explain any parameters (symbol, consolidated, response_format). The tool's purpose is clear, but the agent receives no guidance on how to use optional parameters like consolidated or response_format beyond their names.
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 it is a balance sheet with specific components (equity, reserves, borrowings, assets) and indicates multi-year scope. This distinguishes it from sibling tools like screener_get_profit_loss and screener_get_cash_flow.
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?
No explicit when-to-use or when-not-to-use guidance is provided. However, the clear purpose and distinct resource name make it obvious when balance sheet data is needed. Lacks explicit differentiation from other financial statement tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Multi-year cash flow statement: operating/investing/financing activity, free cash flow.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| consolidated | No | ||
| response_format | No | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. Description adds value by specifying it is multi-year and includes specific cash flow components. No contradictions.
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?
Extremely concise and front-loaded. Every word is meaningful with no wasted text.
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 the tool has an output schema and low complexity (3 params, no nested objects), the description is mostly adequate but lacks parameter semantics. It covers the high-level data content but omits parameter details.
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 description coverage is 0% and the description provides no information about the parameters (symbol, consolidated, response_format). This is a critical gap as the description fails to explain what each parameter does.
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 clearly states the tool provides a multi-year cash flow statement with operating, investing, financing activities, and free cash flow. It is specific and distinct from siblings like profit_loss or balance_sheet, but does not explicitly differentiate itself.
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?
No guidance on when to use this tool versus alternatives such as screener_get_profit_loss or screener_get_balance_sheet. The description lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Headcount, $100M+ client counts, revenue mix by geography/vertical, TCV, attrition, and similar operational metrics. NOTE: screener.in only sends the actual numbers to logged-in sessions -- without SCREENER_USERNAME/SCREENER_PASSWORD configured (or if login fails), this returns the available metric names only, with values locked.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| consolidated | No | ||
| response_format | No | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds that results are locked without proper credentials, providing behavioral context beyond annotations.
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 lists the data types, second covers the login-dependent behavior. No filler, efficient 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?
The description covers the tool's purpose and a key behavioral nuance (login dependency). However, it omits explanation of parameters and output format, which are partially covered by the output schema but not in the description itself.
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 description coverage is 0%. The description does not explain any of the three parameters (symbol, consolidated, response_format) or their effects, leaving the agent to rely solely on schema structure.
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 lists specific operational metrics (headcount, client counts, revenue mix, TCV, attrition) and distinguishes from sibling tools like balance sheet or cash flow. The verb 'get' is implicit but the resource is well-defined.
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 explicitly notes the login requirement and behavior when not logged in, guiding the agent on prerequisites. However, it does not compare with sibling tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Key ratios (P/E, book value, ROE, ROCE, market cap, dividend yield), the company's About text, and its pros/cons checklist from screener.in.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| consolidated | No | ||
| response_format | No | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description adds value by specifying the output contents (ratios, about text, checklist). No contradictions are present.
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?
The description is a single, concise sentence that summarizes the tool's outputs without unnecessary detail. Every word adds value.
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?
Although the tool has an output schema covering returns, the description lacks guidance on when to choose this tool over siblings. It is adequate for basic understanding but incomplete without usage context.
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 description coverage is 0%, and the description does not explain any of the three parameters (symbol, consolidated, response_format). The baseline is 3, but since coverage is low and description fails to compensate for parameter meaning, the score drops to 2.
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 that the tool retrieves key ratios (P/E, book value, ROE, ROCE, market cap, dividend yield), company about text, and pros/cons checklist from screener.in. This distinguishes it from sibling tools like screener_get_balance_sheet or screener_get_cash_flow, making its purpose unambiguous.
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 does not explicitly state when to use this tool versus alternatives like screener_get_company_insights or screener_get_full_company_snapshot. The purpose is implied by the name and description, but there is no direct guidance on context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Links to recent announcements, annual reports, credit rating updates, and concall transcripts/presentations/recordings.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| consolidated | No | ||
| response_format | No | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, indicating safe, non-destructive behavior. The description adds context on document types provided, enhancing transparency beyond annotations.
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?
The description is a single concise sentence that covers the essential purpose without extraneous text. It is well-structured 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?
With an output schema present, the description does not need to detail return values. However, it lacks usage guidance and parameter semantics, making it marginally adequate for a 3-parameter 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 coverage is 0% with no parameter descriptions. The tool description does not explain the 'symbol', 'consolidated', or 'response_format' parameters, leaving the agent to infer from titles alone.
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 provides links to specific document types (announcements, annual reports, etc.), and the name 'get_documents' reinforces this. It is distinct from sibling tools that retrieve structured financial data.
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?
No explicit guidance on when to use this tool versus siblings. The implication is to use it when document links are needed, but alternatives are not discussed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Everything in one call: overview, all financial statements, shareholding, peer comparison, documents, and insights for a company. Use this for a full analysis; use the individual tools when you only need one section.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| consolidated | No | ||
| response_format | No | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint as true. The description does not add further behavioral context beyond stating it returns everything in one call, which is adequate but not enriched.
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?
The description consists of two concise sentences, front-loading the key purpose and usage guidance with no unnecessary words.
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?
While the description explains the tool's purpose and usage, it lacks parameter details. However, given the output schema exists and annotations are rich, the description is mostly complete for a composite 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 coverage is 0%, and the description provides no explanation of the three parameters (symbol, consolidated, response_format). It fails to add any meaning 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 it provides 'overview, all financial statements, shareholding, peer comparison, documents, and insights for a company' in one call, distinguishing it from sibling tools that serve individual sections.
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 explicitly states when to use this tool ('full analysis') and when to use alternatives ('individual tools when you only need one section'), providing clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Peer comparison table: CMP, P/E, market cap, dividend yield, quarterly profit/sales and growth, ROCE for the company and its industry peers.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| consolidated | No | ||
| response_format | No | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare safe read-only behavior; description adds value by listing the exact metrics returned, but does not disclose output format or limitations.
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 with 20 words, front-loaded with 'Peer comparison table', 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?
Despite having an output schema (not shown), the description lacks input parameter details and usage context, making it incomplete for an agent to fully understand the tool's requirements.
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 has 0% description coverage and the tool description does not explain any parameters (symbol, consolidated, response_format), leaving the agent without guidance on input semantics.
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 clearly states the tool returns a peer comparison table with specific financial metrics (CMP, P/E, market cap, etc.), which distinguishes it from sibling tools like balance sheet or cash flow reports.
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 implies usage context (comparing a company with its industry peers) but does not explicitly state when to use this tool over alternatives or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Multi-year Profit & Loss statement including compounded growth rows.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| consolidated | No | ||
| response_format | No | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds behavioral detail (multi-year coverage and compounded growth rows) beyond the annotations, enhancing transparency without contradiction.
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?
A single, front-loaded sentence with no wasted words efficiently communicates the tool's core purpose.
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?
While the description mentions the output nature, it omits parameter details and usage context, leaving the agent to rely solely on schema, which has zero descriptions. Adequate but not complete.
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 description coverage is 0%, and the description does not explain any of the three parameters (symbol, consolidated, response_format), failing to add meaning 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 it provides a 'Multi-year Profit & Loss statement including compounded growth rows', which precisely identifies the tool's function and distinguishes it from sibling tools like screener_get_balance_sheet.
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 guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Quarterly sales, expenses, operating profit, and net profit table.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| consolidated | No | ||
| response_format | No | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, so the agent knows it is a safe, idempotent read. The description does not add any behavioral context beyond what annotations provide, such as rate limits or authorization needs.
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?
The description is a single sentence with 10 words, containing only essential information. It is front-loaded and does not waste words.
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 that an output schema exists and annotations cover behavioral aspects, the description is minimally adequate. However, it lacks details about data coverage (e.g., how many quarters), update frequency, or any nuances that might affect agent decisions. It is functional but not comprehensive.
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 description coverage is 0%, requiring the description to compensate. However, the description only mentions the content of the result (sales, expenses, profit) and does not explain any of the three parameters (symbol, consolidated, response_format). Neither their purpose nor their effect is clarified.
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 that the tool returns quarterly sales, expenses, operating profit, and net profit as a table. It specifies the resource (quarterly financial data) and the action (retrieval), but does not differentiate this tool from siblings like profit_loss or balance_sheet.
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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, data currency, or appropriate contexts. The description only states what it returns, not when it should be chosen over sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
SMA20/50/200, RSI14, ATR14, and price-vs-SMA flags from free Yahoo Finance daily price history. No login required.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | 1y | |
| symbol | Yes | ||
| exchange | No | NSE | |
| response_format | No | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds that the data comes from free Yahoo Finance daily price history and requires no login. This provides context beyond annotations but does not disclose potential rate limits or data latency.
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 efficiently lists outputs, data source, and auth requirement. No redundancy; every word adds value.
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 4 parameters with zero schema description coverage and presence of an output schema, the description is incomplete. It fails to explain parameter usage, leaving the agent to guess about period defaults, exchange options, or response format. Output schema may help, but parameter coverage is insufficient.
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 description coverage is 0%, so the description must compensate. It mentions none of the four parameters (symbol, period, exchange, response_format) and does not explain their role or acceptable values. Agent must rely solely on schema names.
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 clearly lists the specific technical indicators computed (SMA20/50/200, RSI14, ATR14, price-vs-SMA flags) and the data source. It distinguishes the tool from sibling financial data tools (balance sheet, cash flow, etc.) by focusing on technical indicators from price history.
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?
No explicit guidance on when to use this tool versus alternatives. The description implies it is for technical analysis but does not state prerequisites, limitations, or when not to use it. Sibling tools are listed but no comparison is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Diagnostic: whether Screener.in credentials are configured and whether login succeeded. Never exposes the credentials themselves.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, but the description adds key behavioral context: it checks both configuration and login status, and crucially states it never exposes credentials. This adds safety and transparency beyond the annotation.
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, no wasted words. The word 'Diagnostic:' front-loads the purpose, making the tool's role immediately clear.
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 the tool has no parameters and a simple purpose, the description covers what it does (check credential config and login status) and what it does not do (expose credentials). An output schema exists, so return value details are handled there.
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?
The tool has 0 parameters, so schema coverage is 100%. The description does not need to add parameter information; baseline for zero parameters is 4.
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 it is a diagnostic tool for checking Screener.in credential configuration and login success, and explicitly notes it never exposes credentials. This purpose is distinct from all sibling tools which retrieve financial data.
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 implies it should be used before data retrieval tools to verify connectivity, but does not explicitly state when to use or not, nor mention alternatives. Usage guidance is implied through context but not clearly articulated.
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.0screener_get_balance_sheetscreener_get_cash_flowscreener_get_company_insightsscreener_get_company_overviewscreener_get_documentsscreener_get_full_company_snapshotscreener_get_peer_comparisonscreener_get_profit_lossscreener_get_quarterly_resultsscreener_get_shareholding_patternscreener_get_technical_indicatorsscreener_login_statusScored across 12 tools
Each tool targets a specific financial statement or aspect (balance sheet, cash flow, shareholding, etc.) with no overlap. The full snapshot tool aggregates everything but is distinct.
All tools follow a consistent pattern: 'screener_get_' followed by a descriptive noun phrase (e.g., 'balance_sheet', 'company_insights'). No mixing of conventions.
12 tools cover the essential financial data retrieval needs for a company analysis server. Each tool serves a clear purpose without redundancy.
The tool set covers all major financial statements, peer comparison, ownership, technical indicators, and a composite snapshot. No obvious gaps for fundamental analysis.
Stock analysis MCP: 38 indicators, 7 optimizers, 8 backtests, US + India sectors.
Indian NSE/BSE research data and mechanically-computed ratios; read-only market tools.
Financial data and research MCP for US/CN/JP equities: filings, statements, ownership, signals.
MCP server for stocksense-ai documentation, generated by doc2mcp.
