Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Tijori Finance MCP Pull Zomato's last 6 quarters of revenue and EBITDA margin"
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.
India's first MCP server for Indian equity research.
Talk to 5,000+ NSE/BSE listed companies directly from Claude with India's equity research MCP
"Pull Zomato's last 6 quarters of revenue and EBITDA margin, then read their
latest concall transcript — are they hitting the targets management guided for?"
"Bajaj Finance's FII stake dropped 400bps last year while promoters held flat —
pull their latest investor presentation to figure out if this is distribution or passive rotation."
"Crude is up — check the raw materials data for chemical spreads, then pull
revenue mix and operational metrics for Deepak Nitrite to see if margins are at risk.""The goal is to turn data into information, and information into insight." — Carly Fiorina
Related MCP server: Daito
Revenue mix pulled first, then cross-referenced against P&L data to explain trends
Full income statement history retrieved in one call — revenue, EBITDA, PAT across years
Knowledge base fetched the latest earnings call transcript, Claude read it and built a forward projection model
Most financial MCP servers are built for US markets — Yahoo Finance, SEC filings, S&P data.
Nothing existed for India.
Tijori Finance is the most comprehensive source for Indian equity data — operational KPIs, revenue segment breakdowns, market share trends, and curated investor documents that aren't available anywhere else. This MCP server exposes all of it to Claude.
Feature | Tijori Finance MCP | Traditional Research | Bloomberg / Refinitiv |
Setup Time | 5 minutes | Hours (Python, Excel...) | Weeks (Contracts) |
Cost | Free + Tijori subscription | Variable | $30k+/year |
Indian Market Coverage | ✅ 5,000+ NSE/BSE stocks | ❌ Fragmented / manual | ✅ |
Operational KPIs | ✅ Segment data, KPIs, market share | ❌ Manual scraping | ✅ Proprietary |
Concall Transcripts | ✅ Earnings calls, investor docs | ❌ PDF hunting | Partial |
AI-Ready Output | ✅ Structured JSON → Claude | ❌ Unstructured pages | ❌ Proprietary only |
API Keys Required | None | Multiple (OpenAI, etc.) | N/A |
A web search gives you unstructured pages. This gives Claude structured, queryable data — historical time series, typed fields, and consistent schemas across all 5,000+ companies. Claude can reason over it, compare across companies, and build analyses — not just summarize a webpage.
Tool | What it does |
| Search any company by name, returns slug |
| Key ratios, forensics score, market cap, PE, ROE, ROCE |
| P&L, Balance Sheet, Cash Flow, Ratios, Quarterly results |
| 10-quarter promoter / FII / DII / public breakdown |
| All operational KPIs with full historical time series |
| Capital allocation breakdown over 1/3/5/7/10 years |
| Segment breakdown with historical trend per segment |
| Market share % per metric with as-of date |
| Annual reports, earnings releases, investor presentations, conference calls — returns URLs grouped by type |
| Fetch and extract full text from a PDF URL returned by |
| Commodity price performance — chemicals, spreads, metals |
| India macro — credit, IIP, GST, auto sales, GDP, trade |
| Index performance — Nifty, sector indices, conglomerates |
| All stocks inside a TJI niche sector index. Pass |
| All companies inside a business group. Pass |
| Resolve slug to numeric company ID |
Tool | What it does |
| Browse Tijori's pre-built stock screens, grouped by category, with each screen's description and underlying query |
| Run a popular screen by name ( |
| Search the ~1,500-metric field catalog (with time-period variants like |
Alternate data queries. The Advanced Screener's second box now works ad-hoc: screen_companies({ alternate: "market share > 50" }) or { alternate: "revenue from Defence > 50", filters: "Market Capitalization > 1000" }. Relationships: makes, revenue from, market share, uses, caters to, has plant in, combinable with AND/OR/NOT.
The three screener checkboxes. latest_results_only (only companies that reported the latest quarter), superstar_investors (only companies a whale investor holds, with the holder named per row), and sme (search the SME-listed universe).
Popular screens actually run now. list_popular_screens previously returned queries with the AND glued to the next field name (newlines in the page's links were being stripped), and dropped each screen's category, description, market-share query, and superstar-investor flag. It now returns all of those, and screen_companies { preset: "Monopoly Companies" } runs any of them through the same endpoint the website uses — including the ones advanced queries can't express.
The advanced screener exposes Tijori's full query language. Queries support every field in Tijori's catalog, % values (ROCE > 20%), comparisons between fields (Net Sales > 3Yrs ago Net Sales), and arithmetic (capex/Net Block > 0.5).
New search_screener_fields tool. Tijori has ~1,500 financial metrics once you count time-period variants (3yr Avg ROCE, 5yr Growth Net Sales, 10Yrs ago PAT…). Search the catalog to find the exact name, then use it in a query.
Result caps + pagination. Screens used to return every matching row (1,000+ for loose queries). Results are now capped at 50 by default (limit raises it) and offset pages through the rest — "show me the next 50" is served instantly from cache without re-querying Tijori. total_results always reports the full count.
Long, multi-tool queries no longer time out. Asking for a full workup in one go — e.g. "build a model for MTAR: overview + financials + concall + revenue mix + operational KPIs" — used to overwhelm the browser and fail with page.goto: Timeout errors. Page loads are now faster (ads, trackers and images are skipped), capped to a safe number of concurrent loads, and retried once on a transient timeout. Tools also wait for the actual data to render rather than a fixed delay, so you get complete results instead of half-loaded ones.
Fixed a startup browser leak. A burst of parallel tool calls on a cold start could spin up several Chromium instances and leave most of them orphaned. It now launches exactly one and shares it.
get_market_share returns cleanly when there's no data. For companies that simply have no market-share metrics (most non-lenders), it now returns an empty result with a note instead of erroring — which previously made the assistant retry the same call in a loop.
Node.js v18+ — install the LTS version
A Tijori Finance account — free account works but has data limits; Pro recommended for full access
The setup script handles everything automatically: installs packages, downloads the browser, authenticates, and writes the Claude Desktop config for you.
Windows
Download Node.js and install it (choose LTS)
Download Claude Desktop and install it
Download this repo and unzip it anywhere
Double-click setup.bat inside the folder
Follow the prompts — enter your Tijori email/password, then log in through the browser window that opens
Fully quit and reopen Claude Desktop
Mac
Download Node.js and install it (choose LTS)
Download Claude Desktop and install it
Download this repo and unzip it anywhere
Double-click setup.command inside the folder — if macOS blocks it ("unidentified developer"), right-click the file and choose Open the first time
Follow the prompts — enter your Tijori email/password, then log in through the browser window that opens
Fully quit and reopen Claude Desktop (Cmd+Q, not just closing the window)
Linux (or any terminal)
git clone https://github.com/LaZZy0v0/tijori-finance-mcp.git
cd tijori-finance-mcp
node setup.jsFollow the prompts, then fully quit and reopen Claude Desktop.
For those who want to see exactly what each step does.
1. Clone and set credentials
# Mac / Linux
git clone https://github.com/LaZZy0v0/tijori-finance-mcp.git
cd tijori-finance-mcp
cp .env.example .env
# Windows
git clone https://github.com/LaZZy0v0/tijori-finance-mcp.git
cd tijori-finance-mcp
copy .env.example .envOpen .env in any text editor and fill in your Tijori credentials:
TIJORI_EMAIL=your@email.com
TIJORI_PASSWORD=yourpassword2. Install packages and browser
npm install
npx playwright install chromiumnpm install downloads the Node.js dependencies. playwright install chromium downloads a ~150 MB Chromium browser used to maintain your Tijori session — one-time only.
3. Authenticate
node discover.jsA browser window opens at the Tijori Finance sign-in page. Log in as you normally would. Once you're in, the script visits a few pages in the background to capture API endpoints, then the window closes automatically. Your session is saved to output/session.json.
4. Configure Claude Desktop
Find your config file and add the block below. The path to src/index.js must be absolute.
OS | Config file location |
Windows |
|
Mac |
|
{
"mcpServers": {
"tijori-finance": {
"command": "node",
"args": ["C:/Users/yourname/tijori-finance-mcp/src/index.js"]
}
}
}5. Fully quit and reopen Claude Desktop
"Search Tata Steel using Tijori MCP"
If Claude returns a result, you're connected.
Tijori sessions expire periodically. When tools stop working:
npm run reauthA browser window opens — log in manually and you're back.
The server uses Playwright to maintain an authenticated browser session with Tijori Finance. Each tool navigates to the relevant page or calls the underlying API, parses the response, and returns structured JSON to Claude. Results are cached in-memory (6 hours for financials, 30 minutes for metrics) to keep things fast.
This project is not affiliated with Tijori Finance. It requires your own paid Tijori Finance subscription. Use for personal research only — do not redistribute the underlying data.
Built with Model Context Protocol · Data from Tijori Finance
Fetch and extract text from a Tijori Finance document (PDF). Pass a URL returned by get_knowledge_base. Uses the authenticated browser session to bypass CDN access controls. Returns the full text content and page count.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses key behaviors: uses authenticated browser session to bypass CDN access controls (security/network context), and returns full text and page count (output). It does not mention rate limits or side effects, but the tool is read-only and non-destructive, so the disclosure is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no superfluous information. The first sentence states the core purpose, followed by usage instructions and a brief output summary. Every sentence 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 tool's simplicity (one required param, no output schema), the description fully covers what the tool does, what input is needed, and what output is returned. No additional context required.
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?
Only one parameter ('url') with schema specification of type string and format uri. The description adds meaning by stating it should be a URL from 'get_knowledge_base', which guides the agent on the source and validity of the input. This compensates for the 0% schema description coverage.
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 verb ('Fetch and extract text') and the resource ('Tijori Finance document (PDF)'), specifying it returns full text and page count. It distinguishes from sibling tools by its focus on document extraction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to 'Pass a URL returned by get_knowledge_base', providing clear context on when to use this tool. Also mentions using the authenticated browser session, implying it handles access control automatically. No exclusions or alternatives given, but sufficient for the use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get company overview: key financial ratios, forensics score, market cap, PE, ROE, ROCE.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for disclosing behavior. It fails to mention read-only nature, authentication needs, rate limits, or any side effects. The 'forensics score' is mentioned but undefined.
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 of 14 words is very concise. However, it sacrifices completeness; front-loading is achieved but at the cost of crucial details like parameter meaning and return structure.
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's single parameter, lack of output schema, and numerous sibling tools, the description is insufficient. It does not describe the return format, how 'slug' is used, or how this overview differs from other financial data endpoints.
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 descriptions for the single required parameter 'slug'. The tool description also omits any explanation of 'slug', leaving the agent with no semantic understanding beyond its name.
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 uses specific verb 'Get' with resource 'company overview' and lists key metrics such as PE and ROE, indicating a broad financial snapshot. However, it does not distinguish itself from siblings like get_financials or get_operational_metrics, which likely offer overlapping 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 guidance on when to use this tool versus alternatives. The description implies it provides an overview, but does not explicitly state scenarios where it is preferred or when to choose other related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all constituent companies of a conglomerate group. Pass the tjiid from get_markets({ tab: "conglomerates" }). Returns each company's slug (usable with other tools) and price returns for 1D/1W/1M/3M/6M/1Y/2Y/3Y/5Y/10Y. The conglomerates tab itself shows ROE by year; this tool gives the underlying price performance per stock.
| Name | Required | Description | Default |
|---|---|---|---|
| tjiid | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses input and output but lacks details on behaviors like error handling, pagination, or data freshness. It is adequate for a simple read operation but not exceptional.
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 concise, front-loaded with the main verb and object, and contains no redundant information. Every sentence 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 with one parameter and no output schema, the description covers purpose, input, output, and differentiation. It lacks discussion of edge cases or error states, but for a straightforward retrieval tool, it is nearly 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%, so the description compensates by explaining that tjiid is obtained from get_markets. This adds significant meaning beyond the schema's type constraints. A higher score would require more detail on valid values or behavior.
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 retrieves all constituent companies of a conglomerate group, specifies the input (tjiid from get_markets), and details output (slug and price returns). It distinguishes from sibling tools like get_sector_constituents by focusing on conglomerates and price performance vs ROE.
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 explains that the tjiid comes from get_markets({ tab: 'conglomerates' }) and contrasts with the conglomerates tab (ROE vs price returns). It provides clear context for when to use, though it does not explicitly list alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get financial statements. type: pl=Profit&Loss, bs=Balance Sheet, cf=Cash Flow, ratios=Financial Ratios, quarterly=Quarterly Results.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It does not mention any traits like data freshness, authentication requirements, rate limits, or whether the tool is read-only. The only behavioral hint is the mapping of type codes, but that's about parameter semantics, not behavior.
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 very concise: one sentence with a key-value mapping. Every part is relevant. However, the structure is minimal and could be slightly improved (e.g., listing each type on a new line) but is adequate for quick parsing.
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 two required parameters (slug, type) and no output schema, the description is incomplete. It does not explain that slug is a company identifier, nor does it describe the output format (e.g., JSON structure, field details). The tool returns financial data but the user cannot anticipate the response shape or any edge cases.
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 adds meaning for the 'type' parameter by mapping enum codes to human-readable names. However, the 'slug' parameter is not explained at all, leaving its purpose and format unclear. Partial value added, but insufficient for full semantic clarity.
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 'Get financial statements' and enumerates the types (pl, bs, cf, ratios, quarterly) with brief expansions. However, it does not explicitly clarify that 'slug' refers to a company identifier, though this is implied by the tool name and sibling context. It distinguishes from siblings like get_company_overview or get_shareholding by focusing on financial statements.
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. The description lacks context such as prerequisites (e.g., need a company slug first) or comparison with similar tools like get_operational_metrics or get_revenue_mix. The absence of usage hints reduces decision support for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get capital allocation (fund flow) breakdown over 1, 3, 5, 7, or 10 years. Run resolve_company_ids first.
| Name | Required | Description | Default |
|---|---|---|---|
| years | Yes | ||
| company_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only mentions the prerequisite and the time periods, with no information about read vs. write, side effects, rate limits, or return details. This is insufficient for a tool with no 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 with no fluff. The first sentence states the core functionality and constraints, the second provides a critical prerequisite. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is fairly complete for its simplicity (2 params, simple types). It covers the tool's purpose, parameter constraints, and a prerequisite. However, it could be more complete by describing what the breakdown contains (e.g., percentages, amounts).
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%, so description must compensate. It explains the 'years' parameter by listing allowed values and implies the 'company_id' comes from resolve_company_ids. This adds some meaning beyond the schema, but does not fully explain the purpose or format of company_id.
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 retrieves capital allocation (fund flow) breakdown with explicit time periods (1, 3, 5, 7, 10 years). It distinguishes from siblings like get_financials and get_shareholding by focusing on fund flow allocation.
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 a prerequisite ('Run resolve_company_ids first') but lacks guidance on when to use this tool over alternatives such as get_financials or get_shareholding. No comparative usage context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all investor documents for a company: annual reports, earnings releases, investor presentations, conference call transcripts, and curated research links. Returns URLs grouped by document type.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the output structure (URLs grouped by document type), which is useful behavioral information. However, it does not mention authentication requirements, rate limits, error handling for invalid slugs, or whether the operation is read-only. Without annotations, the description carries the burden but only partially fulfills it.
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 two sentences with no extraneous words. The first sentence states the primary action, and the second clarifies the output format. Every word earns its place.
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 only one parameter and no output schema, the description covers the essential purpose and return structure. It lists document types and mentions grouping, which is sufficient for basic selection. Minor gaps like slug definition and error behavior are acceptable for this simplicity.
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?
With 0% schema description coverage, the description fails to explain the 'slug' parameter beyond implying it identifies the company. No format, source, or required syntax is provided, leaving the agent to guess or rely on external context.
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 retrieves investor documents for a company, listing specific document types (annual reports, earnings releases, etc.) and notes that it returns URLs grouped by document type. This specific verb+resource combination distinguishes it from sibling tools like get_financials or fetch_document.
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?
There is no guidance on when to use this tool versus alternatives among the many sibling tools. It does not state prerequisites, when not to use it, or suggest other tools for different data needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get India macro indicators: industry credit/IIP, demand (GST/auto), or GDP & trade.
| Name | Required | Description | Default |
|---|---|---|---|
| tab | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It only states the purpose and categories, but does not disclose behavioral traits such as read-only nature, data freshness, permissions, or side effects. The description lacks transparency beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 15 words, immediately conveying the purpose. It is concise and front-loaded with the core action ('Get India macro indicators'), with no wasted 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?
For a simple tool with one enum parameter and no output schema, the description covers the basic purpose and parameter details. However, it lacks information about output format, data frequency, or any limitations. It is minimally viable but could be more 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?
The description adds meaning to the 'tab' parameter by explaining the subcategories for each enum value (e.g., 'industry credit/IIP', 'demand (GST/auto)'). This provides context beyond the raw enum, compensating for the 0% schema description coverage.
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 retrieves India macro indicators and lists the categories (industry, demand, GDP). The verb 'Get' indicates retrieval. However, it does not explicitly differentiate from sibling tools, though the macro focus distinguishes it from company-specific siblings.
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. The description only states what it does; it does not provide any context for when to choose this tool over siblings, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get index performance: headline (Nifty/Sensex/Nifty Bank etc.), niche (TJI sector indices with 1D–5Y price returns — each row includes tjiid for get_sector_constituents), or conglomerates (9 Indian business groups — each row includes tjiid for get_conglomerate_constituents).
| Name | Required | Description | Default |
|---|---|---|---|
| tab | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses output structure (rows with tjiid) and behavioral traits like linking to other tools. Importantly, it does not contradict any annotations (none present) and provides adequate transparency for a read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is well-structured, front-loads the purpose, and packs in specific details without being verbose. Every phrase 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?
For a tool with one parameter, no output schema, and no annotations, the description is remarkably complete. It explains all tab options and the structure of the returned data, including links to sibling tools for further drill-down.
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 single parameter 'tab' has enum values, and the description adds significant meaning by explaining what each value returns (e.g., headline for Nifty/Sensex, niche for TJI indices with returns, conglomerates for business groups). This compensates for the 0% schema description coverage.
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 it retrieves index performance with three specific categories (headline, niche, conglomerates), giving examples like Nifty/Sensex. It distinguishes from siblings by mentioning tjiid for linking to get_sector_constituents and get_conglomerate_constituents.
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?
Usage context is implied through the description of data returned and links to sibling tools, but there is no explicit guidance on 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.
Get all operational KPIs for a company with latest values and recent trend. Pass the company slug.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It implies a read operation but omits details like data freshness, error handling, permissions needed, or what 'recent trend' entails.
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, avoiding verbosity, but it lacks structure and key details expected for a tool with no output schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description should fully detail returns and usage; it provides only a vague notion of 'operational KPIs' and 'latest values with trend', leaving significant gaps for an agent.
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 single parameter 'slug' has 0% schema description coverage. The description adds only 'Pass the company slug', without specifying format, source, or validation, failing to compensate for the schema gap.
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 retrieves operational KPIs with latest values and trend, distinguishing it from sibling tools like get_financials or get_company_overview. However, it lacks specifics on which KPIs are included.
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 only instructs to pass a company slug, providing no context on when to use this tool over alternatives, prerequisites, or limitations. There is no mention of excluded cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get commodity price performance for Chemicals, Spreads, or Metals.
| Name | Required | Description | Default |
|---|---|---|---|
| tab | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose behavioral traits (read-only, permissions, side effects). Assumed read operation but not stated.
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, concise, front-loaded with purpose. No wasted words, but could include more details without overwhelming.
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?
For a simple tool with one enum parameter, description covers input categories and data topic (price performance). Lacks output details and behavioral context, but minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description mentions categories matching the enum, but schema already provides full enum. Adds no substantial meaning beyond the schema. Baseline 3 due to schema coverage (enum values clear).
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?
Specifies verb 'get' and resource 'commodity price performance' with categories (Chemicals, Spreads, Metals). Slightly ambiguous on what 'performance' means, but adequately distinct from siblings.
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 vs alternatives like get_macro_indicators or get_markets. Does not mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get revenue/segment mix breakdowns for a company. Returns latest % breakdown and full historical trend per segment.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool returns both latest and historical data, but does not mention whether the operation is read-only, any required permissions, rate limits, or data freshness. Without annotations, this leaves some behavioral aspects implicit.
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: two sentences totaling 14 words without any fluff. Every word adds value, clearly stating the action, resource, and output format.
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?
Adequately covers basic functionality and return content (latest breakdown + historical trend) but lacks details on error cases, data format, or handling of missing segments. For a simple data retrieval tool, this is minimally viable but not fully 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?
The input schema has one required string parameter 'slug' with no description. The tool description does not clarify what 'slug' represents (likely a company identifier), nor does it provide any additional meaning beyond the schema. With 0% schema description coverage, the description fails to compensate, leaving the parameter ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves revenue/segment mix breakdowns for a company, specifying it returns the latest percentage breakdown and full historical trend per segment. This distinguishes it from siblings like get_financials and get_operational_metrics, which cover broader financial or operational 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 guidance on when to use this tool versus alternatives. While the purpose is clear, the description lacks explicit instructions on prerequisites, scenarios where this tool is appropriate, or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all constituent companies of a TJI niche sector index. Pass the tjiid from get_markets({ tab: "niche" }). Returns each company's slug (usable with other tools), market-cap weight %, equal weight %, and price returns for 1D/1W/1M/3M/6M/1Y/2Y/3Y/5Y/10Y.
| Name | Required | Description | Default |
|---|---|---|---|
| tjiid | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden of behavioral disclosure. It details the output format including each company's slug, market-cap weight, equal weight, and multiple price returns, enabling the agent to anticipate results.
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 concise with just two sentences: the first states the core purpose, the second explains parameter sourcing and return data. Every word adds value without unnecessary elaboration.
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 no output schema, the description fully covers the single parameter and comprehensively lists the output fields, including how slugs can be used with other tools. This makes the tool self-contained and easy to invoke.
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%, but the description adds substantial meaning: it explains that 'tjiid' comes from get_markets({ tab: 'niche' }) and is required, far exceeding the schema's minimal type definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get all constituent companies of a TJI niche sector index.' It specifies the resource (TJI niche sector index) and action (get constituents), distinguishing it from sibling tools like get_conglomerate_constituents and get_markets.
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 instructs how to obtain the required parameter: 'Pass the tjiid from get_markets({ tab: 'niche' }).' This provides clear usage context, though it does not explicitly mention when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all pre-built popular stock screens on Tijori Finance, grouped by category, with each screen's name, description, and underlying query. Run one with screen_companies { preset: "" }.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the tool's behavior: it lists screens and groups them by category, without side effects. It doesn't mention authentication or rate limits, but for a read-only listing tool, the description is sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, no wasted words. It front-loads the purpose and immediately provides actionable next steps. Every sentence earns its place.
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, no output schema, and is a simple listing, the description is fully complete. It explains what is listed, how it is organized, and what to do with the results.
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 no parameters, so baseline is 4. The schema coverage is trivially 100%. The description adds value by explaining what the tool returns (screens with name, description, query) beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all pre-built popular stock screens, grouped by category, with specific details (name, description, query). The verb 'List' and resource are specific, and it distinguishes from sibling tool 'screen_companies' by indicating it is a listing action, not a query execution.
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 explicit guidance on when to use this tool (to discover available screens) and how to proceed (run with screen_companies). While it doesn't explicitly state when not to use, the context and alternative are clear enough for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a company slug to its numeric company_id. Required before calling get_fund_flow.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It describes the resolution action but does not disclose error behavior, idempotency, or whether it requires authentication. Adequate for simple lookup, but could be more explicit.
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 concise sentences, front-loaded with purpose and action. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is nearly complete. It explains the input, output, and usage context. Lacks example output format but is sufficient for the task.
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, but the description explains that the slug parameter is a 'company slug' and that it resolves to a numeric ID. This adds meaning beyond the schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (resolve), input (company slug), and output (numeric company_id). Also distinguishes from siblings by noting it is a prerequisite for get_fund_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?
Explicitly says 'Required before calling get_fund_flow,' guiding the agent on sequence. However, does not mention alternatives for resolving IDs via other tools like search_company.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen companies by financial metrics and/or business data. Pass 'preset' (a popular screen name from list_popular_screens, e.g. 'Cash Flow Machines'), OR 'filters' and/or 'alternate'. 'filters' accepts a query string like '( ROE > 15 ) and ( Market Capitalization > 500 )' or a shorthand object like {roe:{min:15}, debt_to_equity:{max:0.5}}. Query strings support any field name from search_screener_fields, % values ('ROCE > 20%'), field-vs-field comparisons ('Net Sales > 3Yrs ago Net Sales'), and arithmetic ('capex/Net Block > 0.5'). 'alternate' is a business-data query using relationships: 'makes ', 'revenue from <product/region> > N', 'market share > N', 'uses ', 'caters to ', 'has plant in ' — combinable with AND/OR/NOT, e.g. 'market share > 50' or 'revenue from Defence > 50'. Product/region names come from search_screener_fields with type Products/Regions. Optional flags: latest_results_only (only companies that reported the latest quarter), superstar_investors (only companies a superstar/whale investor holds — adds a 'whales' column), sme (search the SME-listed universe instead of mainboard). 'limit' caps returned rows (default 50) and 'offset' pages through the rest (e.g. offset: 50 for rows 51-100 — served from cache, no refetch); total_results always reports the full match count.
| Name | Required | Description | Default |
|---|---|---|---|
| sme | No | ||
| limit | No | ||
| offset | No | ||
| preset | No | ||
| filters | No | ||
| alternate | No | ||
| latest_results_only | No | ||
| superstar_investors | No |
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 discloses the tool is a read operation (screens data), explains caching for pagination, mentions optional flags that modify behavior, and details the query syntax. It does not mention rate limits or authentication, but these are expected for such a tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized, front-loading the primary purpose and then detailing each parameter. Every sentence adds value, though it could be slightly more structured with bullet points for readability.
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's complexity (8 parameters, no output schema, no annotations), the description is remarkably complete. It covers all parameters, query syntax, optional flags, pagination with caching semantics, and refers to sibling fields for valid values. The only minor omission is an explicit note about the output format, but it is implied.
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%, meaning the description must explain all parameters. It does so comprehensively: preset, filters (with string and object formats and examples), alternate (with relationship syntax and examples), latest_results_only, superstar_investors, sme, limit, and offset (with caching behavior).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool screens companies by financial metrics and/or business data. It uses a specific verb ('screen') and resource ('companies'), and distinguishes from sibling tools like search_company and list_popular_screens by detailing two modes (preset vs custom filters/alternate) and flags.
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 explains when to use preset vs custom filters/alternate, and covers optional flags and pagination. It does not explicitly list when not to use the tool, but provides clear guidance on query syntax and alternatives (e.g., using alternate for business-data queries).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Tijori Finance for companies by name. Returns name and slug. Use the slug with all other tools.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
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 discloses that the tool returns name and slug and implies a read-only search operation, but does not mention behavior such as case sensitivity, pagination, or error handling. Basic transparency is achieved, but gaps remain.
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 convey the purpose, return, and usage instruction without extraneous words. The structure is front-loaded with the action and result, followed by a directive, making it efficient for an AI agent.
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?
For a simple search tool with one parameter and no output schema or annotations, the description provides the essential information: what it does, what it returns, and how to use the result. Minor omissions like search behavior details are acceptable given the low complexity.
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 schema has one parameter 'query' with no description (0% schema coverage). The description adds 'by name' to imply the query is a company name, but provides no format, example, or constraints beyond the schema's minLength. Given low schema coverage, the description insufficiently compensates.
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 uses a specific verb ('Search'), identifies the resource ('companies by name'), and states the return value ('name and slug'). It clearly distinguishes from sibling tools by positioning this as the entry point to obtain slugs for use with other tools.
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 'Use the slug with all other tools,' providing a clear usage context. It implies that this tool is the first step in a workflow, but does not explicitly mention when not to use it or compare to alternatives like resolve_company_ids.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Tijori's screener field catalog (~1,500 financial metrics with time-period variants like '3yr Avg ROCE', '5yr Growth Net Sales', '10Yrs ago PAT', plus product segments and regions). Use to find the exact field name before building a screen_companies query. Example: query 'promoter holding' or 'npa'.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the catalog size (~1,500 metrics) and types (financial metrics, product segments, regions), but does not detail result format, pagination, or error handling. This is good but not exhaustive.
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 highly concise: two sentences and an example. It is front-loaded with the main purpose and provides essential details without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex domain (1500+ metrics), no output schema, and no annotations, the description gives a solid overview. It explains the tool's role in the pipeline but lacks details on result structure or query matching behavior. Still reasonably complete for its function.
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 'product segments and regions' in the catalog, which aligns with the 'type' enum, but does not explicitly describe the 'query' or 'type' parameters. The example shows a query string usage, but parameter semantics are only partially 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 'Search Tijori's screener field catalog' and specifies the tool is for finding exact field names before building a screen_companies query. It distinguishes itself from sibling tools like search_company and screen_companies, making its purpose unmistakable.
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 says 'Use to find the exact field name before building a screen_companies query,' providing clear when-to-use guidance. It includes an example but does not explicitly state when not to use it or mention alternatives, though the context is clear.
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.
v1.0.0fetch_documentget_company_overviewget_conglomerate_constituentsget_financialsget_fund_flowget_knowledge_baseget_macro_indicatorsget_market_shareget_marketsget_operational_metricsget_raw_materialsget_revenue_mixget_sector_constituentsget_shareholdinglist_popular_screensresolve_company_idsscreen_companiessearch_companysearch_screener_fieldsScored across 19 tools
Each tool targets a distinct resource or action: indices, constituents, knowledge base, screener fields, company metrics, and macro data. Even similar tools like get_markets vs get_macro_indicators or search_company vs screen_companies are clearly separated by their target resource and usage flow.
The set predominantly follows a get_<resource> convention (get_markets, get_financials, get_shareholding, etc.), which makes the API predictable. A few action-first names like list_popular_screens, screen_companies, search_company, and fetch_document break the pattern slightly but remain intuitive and consistent in style.
19 tools is slightly heavy, but the server's scope is broad: market indices, company fundamentals, screening, document retrieval, and macroeconomic data. Each tool earns its place and there is no obvious redundancy, so the count feels reasonable despite being on the upper end.
The tool surface covers the core investor research workflow: company search, screening, financials, shareholding, operational metrics, revenue mix, fund flow, documents, and market/macro context. Notable gaps like per-stock price history or direct peer comparison are missing, but most workflows can still be completed through constituents and screening tools.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Global stock research, ML forecasts, valuation signals, screeners & portfolio tracking in Claude
Research-only MCP server: your AI as a quant research desk. 88 tools, no trades, no brokers.
MCP server giving Claude AI access to 22+ NYC public-record databases for real estate due diligence
The financial MCP for AI agents - 90+ financial tables, SEC filings, signals, alt-data.
