tijori-finance-mcp

by LaZZy0v0

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 (e.g., company search vs. financials vs. market indices vs. screening). The descriptions are detailed and include parameter guidance, making it clear when to use which tool.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., search_company, get_financials, list_popular_screens). The verbs (search, resolve, get, fetch, list, screen) are uniformly used and the noun phrases are descriptive.
Tool Count4/5
With 19 tools, the set is slightly above the typical 3-15 range, but each tool has a clear and non-redundant purpose given the broad scope of financial analysis (company data, market data, screening, documents). The count is justified by the domain complexity.
Completeness5/5
The tool surface covers the full lifecycle of financial research: company identification (search_company, resolve_company_ids), fundamental data (overview, financials, ratios, shareholding, operations, fund flow, revenue mix, market share), market data (indices, sectors, conglomerates, macro indicators), and advanced analysis (screening with field search, presets, and document retrieval). There are no obvious gaps for an investor-focused MCP server.
Average 3.7/5 across 19 of 19 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 64 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?
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose4/5
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.
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. 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.
Behavior2/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters2/5
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.
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 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.
Usage Guidelines2/5
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.
Behavior2/5
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 only states the data retrieved (10-quarter breakdown) but does not disclose any behavioral traits: e.g., whether it is read-only, requires authentication, rate limits, or side effects. The description is minimal and lacks transparency.
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 sentence that effectively front-loads the key information (10-quarter breakdown). It is concise with no wasted words. However, it could be restructured to add more detail without losing conciseness.
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 low parameter coverage (0%), no output schema, and no annotations, the description is incomplete. It fails to explain the slug parameter, what the output structure looks like, or any constraints (e.g., data availability for certain companies). The minimal information is insufficient for reliable tool usage.
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?
With schema description coverage at 0%, the description must explain the single parameter 'slug'. However, it does not define what 'slug' represents (likely a company identifier) or how to obtain it. The agents are left to guess its meaning, which is a critical gap.
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 a 10-quarter shareholding breakdown with specific categories (promoter, FII, DII, public). It uses a specific verb 'Get' and resource '10-quarter shareholding breakdown', which distinguishes it from sibling tools like get_financials or get_company_overview.
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. There is no mention of prerequisites, when-not-to-use, or comparisons to siblings such as get_company_overview or get_fund_flow. The agent must infer usage from the description alone.
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, 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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/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 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.
Purpose4/5
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.
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. 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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
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 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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
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 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.
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. 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the full burden. It states the output includes 'latest % value and as-of date', but does not disclose whether the operation is read-only, any authentication requirements, rate limits, or error conditions. The behavioral transparency is minimal.
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, clear sentence that efficiently conveys the tool's purpose and return value. No wasted words or redundant information.
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?
With only one parameter, no output schema, and no annotations, the description is somewhat complete: it states what is returned (latest % value and date). However, it does not explain the parameter 'slug' nor does it specify that multiple metrics are returned or how they are structured. For a simple tool, it is minimally adequate but leaves gaps.
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 schema has 0% description coverage for parameters. The description does not explain what 'slug' represents (presumably a company identifier) beyond the context 'for a company'. It adds no format guidance or examples, leaving the agent to infer meaning.
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 'all market share metrics for a company', with specific examples (Bank Advances, Credit Cards, Housing Loans). It distinguishes itself from siblings like get_financials and get_operational_metrics by focusing specifically on market share data.
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?
There is no explicit guidance on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or suggest sibling tools like search_company for obtaining the required slug.
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?
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters1/5
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.
Purpose5/5
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.
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. 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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
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 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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
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 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.
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 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.
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 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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It 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.
Conciseness5/5
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.
Completeness4/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 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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
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 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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
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,' 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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/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 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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
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 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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
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, 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.
Usage Guidelines4/5
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.
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 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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
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 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.
Parameters5/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 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.
Purpose5/5
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.
Usage Guidelines4/5
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.

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/LaZZy0v0/tijori-finance-mcp/badges/card.svg)](https://glama.ai/mcp/servers/LaZZy0v0/tijori-finance-mcp)

Score Badge

Copy to your README.md:

[![tijori-finance-mcp MCP server](https://glama.ai/mcp/servers/LaZZy0v0/tijori-finance-mcp/badges/score.svg)](https://glama.ai/mcp/servers/LaZZy0v0/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/LaZZy0v0/tijori-finance-mcp'

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