Tijori Finance MCP

by rj250792

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct aspect of financial data: market indices, sector/conglomerate constituents, company documents, revenue mix, market share, screening, company overview, financials, shareholding, operational metrics, fund flow, raw materials, and macro indicators. No two tools have overlapping purposes.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern, e.g., get_markets, screen_companies, fetch_document. There are no deviations or mixed conventions.
Tool Count5/5
19 tools is well-scoped for a comprehensive financial data server. It covers multiple subdomains without being excessive, and each tool serves a clear purpose.
Completeness4/5
The tool surface covers key financial data: markets, company analysis, screening, documents, and macro indicators. A minor gap is the lack of direct stock price history for individual stocks, but price returns are available via constituents. Overall, it's nearly complete for its intended domain.
Average 3.7/5 across 18 of 19 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 67 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral traits. It indicates the tool returns financial data but does not specify whether it is read-only, potential side effects, authentication needs, or rate limits. This is insufficient for a mutation-free tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks structure. It lists metrics but could be organized more clearly. It is not verbose, but brevity comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of sibling tools and absence of an output schema, the description is incomplete. It does not clarify how this overview differs from other financial tools, nor does it describe the return format or structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'slug' has no description in the schema, and the description does not define what 'slug' represents (e.g., company identifier). With 0% schema coverage, the description adds no value to parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a company overview with specific financial metrics like market cap, PE, ROE, ROCE, and forensics score. This provides a clear purpose, though it does not differentiate from sibling tools like get_financials.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as get_financials or get_shareholding. The description lacks context about prerequisites or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only explains the 'type' parameter mapping. It does not disclose data freshness, restrictions, side effects, or whether the tool is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but mixes purpose with parameter explanation in a single sentence. Could be structured more clearly with separate sentences for purpose and parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (2 parameters, no output schema), the description partially covers the tool's behavior. However, without return value hints or error cases, an agent may not fully understand the outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the 'type' enum by mapping codes to full names (e.g., pl=Profit&Loss). However, it entirely fails to explain the 'slug' parameter, leaving that undocumented despite 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get financial statements' and lists supported types, making the resource and verb clear. However, it does not strongly distinguish from siblings like get_markets or get_company_overview, which are distinct but the tool's niche is evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no context on prerequisites, frequency limits, or excluded use cases. The description is purely functional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses that it returns 'latest % value and as-of date', indicating a read operation, but lacks details on data freshness, rate limits, or permissions. Basic behavioral transparency is present but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a single sentence with examples in parentheses. It front-loads the purpose and return format. However, it could be slightly more structured for clarity (e.g., separating input and output descriptions).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains return values ('latest % value and as-of date'). However, it does not specify whether the response is an array or object, nor the exact structure. The tool is simple, so completeness is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not clarify the 'slug' parameter beyond implying it identifies a company. With 0% schema description coverage, more detail is expected (e.g., format, example). The mention of 'for a company' provides minimal semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves all market share metrics for a company, with examples of metrics and return format. However, it does not differentiate from sibling tools like 'get_markets' or 'get_revenue_mix', which limits clarity in distinguishing use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or contextual hints. The description merely states what it does, leaving the agent to infer usage context without any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It implies a read-only data retrieval but does not explicitly state safety, rate limits, or error handling. The return format is partially described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, no superfluous words. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity, the description omits parameter semantics and does not mention limitations or prerequisites (e.g., need to resolve company IDs). Incomplete for an agent to reliably use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'slug' has no description in the schema (0% coverage), and the tool description does not explain its meaning or format. The agent must infer that 'slug' identifies a company, but no guidance is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'revenue/segment mix breakdowns', and specifies the return values. It distinguishes from siblings like 'get_financials' or 'get_operational_metrics'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'get_financials' for absolute numbers or 'get_market_share'. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full responsibility. Beyond stating it provides a breakdown over time periods, it discloses no behavioral traits such as read-only nature, data volume, required permissions, or side effects. This is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences convey the action, scope, and a prerequisite. No redundant or unnecessary text; every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description does not hint at the format or structure of the breakdown (e.g., per year, aggregated, percentages). It also omits units, data sources, and any limitations. Given the tool's financial nature and lack of annotations, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds minimal parameter meaning: 'years' is implied to be the time period (1/3/5/7/10), but 'company_id' receives no explanation (only integer). The description does not compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves a capital allocation breakdown (fund flow) for specific time periods (1, 3, 5, 7, 10 years). The verb 'get' and resource 'capital allocation breakdown' are specific, and the prerequisite 'run resolve_company_ids first' helps distinguish it from sibling tools like get_financials.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description includes a clear prerequisite (resolve_company_ids) and enumerates valid year inputs. However, it does not explicitly state when to use this tool versus alternatives, nor provide explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must carry the behavioral burden. It discloses the output structure (grouped by type) but omits details like authentication requirements, rate limits, error handling, or data freshness. It adequately signals a read-only operation but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It front-loads the primary action and output format. Minor improvement could be structuring the listing of document types for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter tool with no output schema, the description is partially complete. It explains what is returned and grouping, but fails to define the parameter or address potential errors. The lack of output schema notes means the description must clarify the response format more thoroughly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, meaning the 'slug' parameter is undefined. The description does not explain what a slug is, how to obtain it, or its format. Users must infer from context, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves all investor documents for a company, listing specific document types and indicating the output format (URLs grouped by type). It distinguishes itself from siblings like 'fetch_document' which likely retrieves a single document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'fetch_document' or other data retrieval tools. There is no mention of prerequisites, company identification, or scenarios where this tool is or is not appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states it returns a breakdown for 10 quarters but does not disclose authentication needs, error handling, or data freshness. The description is adequate but lacks depth for a fully transparent behavioral profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the purpose. It is concise with no wasted words, but the extreme brevity omits parameter documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple structure (1 param, no output schema), the description is mostly complete about the output but fails to explain the input parameter. Compared to siblings, it lacks context on the scope (e.g., company-specific only). Adequate but not fully informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single parameter 'slug', and the description adds no meaning to it. The agent is left to guess what a 'slug' refers to (e.g., company identifier, ticker). This is a critical gap that hinders correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Get' and the resource '10-quarter shareholding breakdown' with specific components (promoter %, FII %, DII %, public %). It distinguishes from sibling tools like get_fund_flow or get_financials by focusing on shareholding percentages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives is provided. However, the specificity of the data implicitly indicates it is for shareholding analysis. No exclusions or when-not-to-use are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only states what data is returned, not behavioral traits such as data freshness, rate limits, or that it's a read-only operation. Minimal transparency beyond the basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence with no wasted words. Front-loaded with the action and scope, followed by parameter options. Ideal for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and no output schema, the description covers the main purpose but lacks details on output structure, data granularity, or temporal coverage. It is functional but not fully complete for an agent to know exactly what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It maps the enum values to real-world concepts (industry->credit/IIP, etc.), adding some meaning beyond the raw enum. However, it does not explain what each category returns in detail (e.g., time series or single values).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves India macro indicators and lists specific categories (industry credit/IIP, demand GST/auto, GDP & trade). This distinguishes it from sibling tools like get_markets (market data) and get_sector_constituents (company data).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use when needing macro indicators. However, no explicit guidance on when not to use, prerequisites, or alternatives. The description could mention that this tool complements sibling tools like get_company_overview for micro-level data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It mentions returning 'latest values and recent trend', indicating data type but does not specify safety (read-only), pagination, rate limits, or whether the operation is safe. For a simple retrieval tool, this is minimally adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence conveying purpose and usage. No redundant or unnecessary information. Content is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers the basic purpose, it lacks detail on the output format (e.g., whether it returns a list or dictionary, units, time range for trend). Given no output schema, more detail would help the agent understand what to expect. However, for a single-param tool, it is partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'slug' has no description in the schema (0% coverage). The description adds value by stating 'Pass the company slug', clarifying its purpose as a company identifier. This goes beyond the schema's type-only definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get all operational KPIs for a company with latest values and recent trend', specifying verb, resource, and scope. However, it does not explicitly differentiate from sibling tools like get_revenue_mix or get_market_share, though the focus on 'operational KPIs' provides implicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description instructs to pass the company slug, giving basic usage context. However, it lacks explicit guidance on when to use this tool vs alternatives (e.g., when detailed KPI breakdown is needed) or any exclusions, leaving the agent to infer based on the tool name and resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses a read operation ('Get') with no side effects, but lacks details on output format, pagination, or rate limits. Adequate for a simple 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with zero wasted words. It conveys the purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (one parameter, no output schema), the description is complete. It specifies what data is returned (price performance) and for which categories (Chemicals, Spreads, Metals).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by listing the three enum values (Chemicals, Spreads, Metals) that match the 'tab' parameter, which is the only parameter. Since schema had no descriptions, this adds value beyond the enum names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'commodity price performance' with specific categories (Chemicals, Spreads, Metals), distinguishing it from sibling tools like 'get_markets'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'get_markets' or 'get_sector_constituents'. The description only states what it does, not context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description only discloses that niche includes price returns over 1D-5Y and includes tjiid. It does not mention data freshness, rate limits, error handling, or other behavioral traits that the agent should know. Since annotations are absent, the description should carry more weight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently front-loads the purpose and uses a clear bullet-like structure for the three categories. Every part adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one enum parameter, no output schema), the description covers the essential context: what each tab returns and links to sibling tools. It could mention typical output fields (e.g., name, value) but is sufficiently complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It successfully explains what each enum value returns: headline for major indices, niche for sector indices with price returns and tjiid, conglomerates for business groups with tjiid. This adds critical meaning beyond the schema's enum list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'Get' and the resource 'index performance'. It enumerates three distinct categories (headline, niche, conglomerates) and provides examples (Nifty/Sensex for headline, sector indices for niche, business groups for conglomerates). This clarity distinguishes it from sibling tools by mentioning tjiid links.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use each tab value and connects to sibling tools via tjiid. It could improve by stating when not to use this tool, but the clear mapping of tab values to specific data types provides adequate guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that it converts a slug to an ID and is required for get_fund_flow, but omits details about error handling, idempotency, or rate limits. Adequate for a simple lookup tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero wasted words. Front-loaded with the core action, followed by essential dependency info. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description covers purpose, dependency, and return value (numeric company_id). Lacks error behavior but is complete enough for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It adds meaning by stating 'company slug' for the parameter, but does not explain format, validation, or examples. Meets minimum compensation level.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it resolves a company slug to its numeric company_id, with a specific verb and resource. Also adds context by noting it's a prerequisite for get_fund_flow, which differentiates it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Required before calling get_fund_flow', providing clear guidance on when to use. However, it does not specify when not to use or offer alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses output details (slug and price returns for multiple periods) and contrasts with the conglomerates tab. However, it does not mention error handling, data freshness, or pagination, which could be expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load purpose and parameter guidance, followed by output details and contrast. Every sentence adds value with no extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter tool with no output schema or annotations, the description covers purpose, parameter source, and output format sufficiently. Minor gaps like error handling or data type for returns do not detract from overall completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It provides meaningful context for tjiid by specifying its origin from get_markets, which aids correct invocation. Yet it could further clarify the property's meaning (e.g., 'conglomerate group ID').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Get' and clearly identifies the resource as 'constituent companies of a conglomerate group'. It also differentiates from siblings by referencing the specific source of the tjiid ('from get_markets({ tab: 'conglomerates' })') and contrasting output with the conglomerates tab's ROE data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explains when to use (after get_markets for a conglomerate) but does not state when not to use or explicitly name alternatives like get_sector_constituents. The contrast with get_markets' tab provides context but lacks explicit redirection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It accurately describes the tool as a search function with no destructive behavior indicated. It adds context about the catalog size and variants, but doesn't disclose rate limits or authentication needs. However, for a search tool, this 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. First sentence defines the tool, second sentence gives usage and example. It is efficiently structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and low complexity, the description covers the essential aspects: purpose, context (catalog size, types of fields), and usage. It is complete enough for an agent to understand when and how to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (description does not explicitly describe parameters), but the example uses 'promoter holding' or 'npa' to illustrate the query parameter. The 'type' parameter is not mentioned. The description adds some value beyond the schema by giving an example, but could be improved by explaining both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches a catalog of ~1,500 financial metrics with time-period variants, product segments, and regions. It distinguishes from siblings like screen_companies (which builds queries) by explicitly stating it finds field names before building queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says to use it before building a screen_companies query and provides an example. While it doesn't explicitly state when not to use it, the context implies it's for finding field names, which is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It discloses the return format (name and slug) but does not mention pagination, error behavior, or rate limits. Adequate for a simple search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Front-loads the purpose and immediately follows with output usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with one parameter and no output schema, the description fully covers what the agent needs: purpose, output, and how to use the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds that the 'query' parameter is for company names, providing essential context beyond the schema's type and minLength constraint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for companies by name, returns name and slug, and explains the purpose of the slug. It distinguishes itself from siblings by being the primary search entry point for companies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use the slug with all other tools,' guiding the agent on when to use this tool as a prerequisite. Does not specify when not to use it, but 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses use of authenticated browser session to bypass access controls and return values (text and page count). Does not mention side effects, rate limits, or error handling, but is generally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, source of input, mechanism and output. Front-loaded with action verb. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simplicity (1 param, no output schema, no annotations), description covers purpose, input source, authentication, and output. Could mention error cases or limitations, but sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no parameter descriptions (0% coverage). Description adds meaning by specifying the URL should come from get_knowledge_base, reducing ambiguity about the parameter's source.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Cleary states specific verb 'Fetch and extract text' from a 'Tijori Finance document (PDF)', and distinguishes from siblings by mentioning the source URL from get_knowledge_base. No other sibling fetches documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance to pass a URL from get_knowledge_base and mentions use of authenticated browser session. Does not explicitly state when to use vs. alternatives, but context is clear given siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it's a read-only screening operation. It details pagination with limit/offset, caching for offset >0, reporting of total_results, and flags that modify results (latest_results_only, superstar_investors, sme). No contradictions noted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-organized, starting with the core purpose and then detailing each parameter. Every sentence adds value. It could be slightly more structured (e.g., bullet points), but for a complex tool it is clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 params, no output schema, no annotations), the description covers all necessary aspects: usage modes, syntax, flags, pagination, caching. It does not describe the output format explicitly, but the tool's purpose implies a list of companies with columns. Overall, it provides sufficient context for an AI agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the full burden. It explains each of the 8 parameters: preset, filters (with two formats and examples), alternate (with relationship grammar), latest_results_only, superstar_investors, sme, limit, and offset (including caching behavior). This is comprehensive and highly useful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it screens companies by financial metrics and/or business data, with two distinct modes (preset or filters/alternate). It distinguishes itself from sibling tools like list_popular_screens (which lists preset names) and search_screener_fields (which lists available fields) by being the actual screening execution tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use each mode: 'Pass preset... OR filters and/or alternate.' It provides detailed syntax for filters (query string or object) and alternate (relationship-based queries). It lacks explicit guidance on when NOT to use this tool (e.g., for simple company lookup), but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It details the output including slug, weights, and returns for multiple periods. While it implies read-only behavior, it does not explicitly state side effects or rate limits, but the comprehensive output description adds significant transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently cover the core function, input source, and detailed output. No unnecessary words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description is remarkably complete. It explains input derivation and enumerates all return fields, ensuring the agent understands what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the lone parameter tjiid by specifying its source ('from get_markets({ tab: 'niche' })'), which is not evident from the schema alone. Given 0% schema coverage, this contextual guidance is valuable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get all constituent companies') and resource ('TJI niche sector index'), clearly differentiating from the sibling tool 'get_conglomerate_constituents' via the 'niche' qualifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to use tjiid from get_markets with tab 'niche', providing a clear prerequisite and context. However, it does not state when not to use this tool or mention sibling alternatives beyond the implicit differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the output structure (grouped by category, with name/description/query) and implies a read-only operation. However, it does not explicitly state idempotency or lack of side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence describes action and output; the second provides critical usage guidance. All information is essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description thoroughly explains what the tool returns and how to use the results (via screen_companies). For a simple listing tool, this is fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so no parameter description is needed. The description adds no parameter meaning, which is acceptable given schema coverage is 100% (empty schema).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all pre-built popular stock screens from Tijori Finance, grouped by category, including each screen's name, description, and underlying query. This precise verb+resource+scope distinguishes it from siblings like screen_companies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs the agent to use screen_companies with preset parameter to run a screen after listing. This provides clear when-to-use guidance and an alternative, leaving no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![tijori-finance-mcp MCP server](https://glama.ai/mcp/servers/rj250792/tijori-finance-mcp/badges/card.svg)](https://glama.ai/mcp/servers/rj250792/tijori-finance-mcp)

Score Badge

Copy to your README.md:

[![tijori-finance-mcp MCP server](https://glama.ai/mcp/servers/rj250792/tijori-finance-mcp/badges/score.svg)](https://glama.ai/mcp/servers/rj250792/tijori-finance-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rj250792/tijori-finance-mcp'

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