etmoney-lyr

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource and operation. Mutual fund tools (mf_*) are separated by action (search, detail, list, compare, featured, categories) and stock tools (stock_screen, index_stocks, sector_stocks, stock_detail) cover distinct data views. No two tools appear to do the same thing.
Naming Consistency4/5
Mutual fund tools share a consistent 'mf_' prefix pattern. Stock tools are slightly inconsistent: 'stock_screen' and 'stock_detail' use 'stock_', while 'index_stocks' and 'sector_stocks' embed the resource type before 'stocks'. This is a minor deviation from a uniform pattern but still predictable and readable.
Tool Count5/5
With 10 tools, the server is well-scoped for covering two asset classes (mutual funds and stocks). Each tool serves a clear purpose, and the count is within the optimal 3-15 range, neither bloated nor insufficient.
Completeness3/5
Mutual fund coverage is strong (search, detail, list, compare, featured, categories), but stock coverage has a notable gap: no tool for searching stocks by name, requiring users to already know stock IDs or slugs. This limits discovery and may cause agent failures when trying to locate a specific stock.
Average 3.1/5 across 10 of 10 tools scored. Lowest: 1.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'curated lists' and does not state whether the operation is read-only, what it returns (a list of funds, fund metadata, etc.), or any side effects. The description is essentially a noun phrase without behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence but is essentially a list of theme names with a trailing ellipsis. It is not front-loaded with a purpose statement, and the list style is more enumeration than an informative explanation. It is under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists and so return values needn't be explained, the description still fails to convey the tool's core function (e.g., retrieving a curated mutual fund list based on a theme) and the meaning of the 'theme' parameter. Given a single required parameter and no annotations, this description is not sufficient for an agent to call it correctly.
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 provides no description for the 'theme' parameter (0% coverage), so the description must explain it. It lists several example values (best_mutual_funds, best_sip_funds, etc.) but does not clarify whether these are exhaustive, what format is expected, or what selecting a theme does. The examples give a hint but insufficient semantics for correct use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool provides 'ET Money curated lists' and lists example themes, which hints it returns curated mutual fund lists. However, it does not specify a verb or resource clearly (e.g., 'get' or 'fetch'), and it's ambiguous whether the tool returns the actual funds or just the list of themes. It is more than a tautology but lacks a clear action and object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 siblings like mf_search, mf_list, or mf_categories. There is no mention of alternatives, exclusions, or typical scenarios, leaving the agent to infer usage entirely.
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 carry the full burden. It mentions 'live metrics' which implies real-time data, but it does not disclose any other behavioral aspects such as pagination behavior, handling of the limit parameter, error conditions, authentication requirements, or rate limits. The single behavioral hint is minimal and insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, which could be seen as concise, but it is a noun phrase rather than a complete sentence. It lacks the structure of a well-formed instruction and omits critical details. It is under-specified rather than efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters, an enum, and an output schema, the description is far from complete. It does not explain how to use the index parameter, what limit controls, or any edge cases. Even though the output schema exists, the description still needs to provide usage context and parameter semantics, which it fails to do.
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 description coverage is 0%, so the description must explain the parameters. It does not mention the 'index' parameter or its enum values, nor does it explain the 'limit' parameter or its default. The description provides no added meaning beyond the raw parameter names in the schema.
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 identifies a specific resource (constituents of NSE indices) and a distinguishing feature (live metrics). The implied action is retrieval, and it is not a tautology of the tool name. It differentiates from siblings like sector_stocks (which focuses on sectors) and stock_detail (which focuses on a single stock), though it doesn't name them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. No mention of comparison with stock_screen, sector_stocks, or mf_* tools. The description is purely definitional and provides no context for selection 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?
With no annotations, the description must disclose behavioral traits. It says 'grouped' but does not mention ordering, pagination, authentication, rate limits, or whether the operation is read-only. It does not contradict annotations, but it provides minimal transparency for a data retrieval 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 very short and to the point, which is concise. However, it lacks structure and depth – it does not front-load key details like parameters or use cases. It is efficient but under-specifies, earning a middle score on this dimension.
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?
The tool has two parameters (one an enum) and an output schema, yet the description provides almost no context about expected results or behavior. It does not clarify how 'grouped' works, whether limit applies to each page, or what the output structure contains. Compared to sibling tools, this is incomplete for an agent to invoke correctly.
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% – the description does not mention limit or sector at all. While the schema has an enum for sector, the description adds no meaning beyond that. For a tool with no parameter documentation, this is a significant gap that the description should have filled.
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 states a clear resource (stocks) and a grouping action by sector pages. It implies the tool returns sector-wise stock lists, which distinguishes it from index_stocks and stock_screen, though it doesn't explicitly name those alternatives. The purpose is understandable but lacks precision about 'grouped' semantics.
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 given on when to use this tool versus its siblings like stock_screen or index_stocks. The description mentions 'sector pages' which hints at sector-based lists, but there is no explicit context about preferred use cases or exclusions. An agent would have to infer usage from the name 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the data fields returned (price, PE, market cap) but does not disclose how the limit parameter affects results, whether pagination exists, if the tool is read-only, or any other behaviors beyond the raw purpose. The description is too sparse to fully inform the agent.
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 concise sentence, which is efficient and front-loaded with the main concept. However, it lacks any structural aids such as bullet points or parameter notes, and the crowding of multiple screen types into a parenthetical makes it slightly harder to parse. It is acceptable but not exemplary.
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?
The tool is relatively simple with two parameters and an output schema, but the description omits key operational details like how limit modifies the result set and the exact enumeration values expected. The agent may struggle to correctly set the screen parameter given the informal naming. The presence of an output schema reduces the need to document return fields, but this description still 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?
Schema description coverage is 0%, so the description must compensate. It lists screen categories but uses informal names ('52w extremes' instead of exact enum values like '52w_high'/'52w_low') and does not explain the 'limit' parameter at all. The mapping between the description and the actual schema enum is loose, and limit usage is completely unexplained.
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 names the resource (ET Money market-data screens) and lists the screen types (gainers/losers/52w extremes/multibagger/bluechip/most active/dividend yield), which distinguishes it from sibling tools like stock_detail or index_stocks. However, it lacks an explicit action verb like 'retrieve' or 'list', leaving the exact operation slightly implied.
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 offers no guidance on when to use this tool versus alternatives such as stock_detail, index_stocks, or sector_stocks. There is no mention of preferred use cases, exclusions, or prerequisites, forcing the agent to infer based solely on the tool name and list of screens.
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 carries the full burden of behavioral disclosure. It states only the purpose and does not disclose any behavioral traits such as pagination behavior, filtering capabilities, or read-only nature. It does not mention what the tool returns or any constraints. This is a significant gap for a tool with no annotation support.
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, concise sentence that directly communicates the tool's core purpose. It is efficient and front-loaded, with no wasted words. It scores high on 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 tool has 8 parameters, 4 enums, and many siblings, the description is woefully incomplete. It does not explain how to use the tool, what filters are available, or how it relates to other mf_* tools. The existence of an output schema helps, but the description does not aid the agent in selecting this tool over alternatives or understanding its scope.
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 description provides zero information about the 8 parameters. It does not mention filtering, sorting, pagination, or any of the parameter names. Since schema coverage is 0%, the description should compensate but fails to do so. The agent would have to rely solely on the schema, which is insufficient for understanding the semantics.
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 function: browsing and screening mutual funds across 67 categories. It uses specific action verbs (browse/screen) and a clear resource (funds), and gives concrete examples of categories. This distinguishes it from siblings like mf_search (searching) and mf_categories (listing categories).
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 implies that this tool is for browsing funds by category, but it does not explicitly state when to use it over alternatives. For example, it does not mention that mf_search should be used for specific fund lookups or mf_categories for category lists. There is no guidance on exclusions or conditions, so the agent must infer usage from the context.
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 carries the full burden of behavioral disclosure. It does not explicitly state that this is a read-only operation, nor does it mention any side effects, rate limits, authentication requirements, or error behavior. It only describes the returned data, leaving potential behavioral aspects undisclosed.
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, dense sentence that front-loads the purpose and lists the data included. It is concise and free of fluff, though the run-on structure with multiple commas could be slightly clearer. Overall, it is appropriately sized.
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 presence of an output schema, the return values need not be described in detail. The tool handles one parameter with an explained format, and the core functionality is clear. However, it lacks any mention of usage context, restrictions, or safety profile (since annotations are absent), leaving gaps for an agent evaluating invocation behavior.
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 schema has no description for the sole parameter `stock_ref` (coverage 0%). The description compensates by specifying the accepted formats: either a numeric id or a path of the form '/stocks/<slug>/<id>'. This adds crucial semantics beyond the raw schema, though it does not provide examples or clarify the exact syntax of the path.
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 identifies the tool as retrieving a stock overview, likely for a single stock, and enumerates the key data fields returned (price, day change, returns, scores, peer fundamentals). It distinguishes itself from sibling tools like stock_screen or index_stocks by focusing on a single stock detail, though it does not explicitly contrast with them.
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 does not explicitly state when to use this tool versus alternatives. The name 'detail' implies it complements screening or listing tools, but no guidance is provided about choosing it over stock_screen or sector_stocks. An agent would need to infer the use case from the name and context.
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 itself. It only states a read operation (search) with example queries, but does not mention match semantics (exact, fuzzy, partial), pagination, default limit behavior, or whether results are sorted. It gives no context on the nature of the search results, leaving the agent to guess how 'search' behaves.
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 concise sentence with relevant examples, front-loaded with the core action and resource. Every word earns its place; there is no redundancy or verbose phrasing.
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 search tool with an output schema, the description is minimally adequate. It covers the primary parameter (query) but omits details on limit usage, match behavior, or result ordering. The presence of an output schema mitigates return-shape concerns, but the description still lacks enough behavioral context for an agent to fully anticipate tool behavior beyond 'returns matching funds'.
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 clarifies the 'query' parameter with examples and implies it expects a name or keyword. However, the 'limit' parameter is not described at all, and the description does not mention acceptable formats, case sensitivity, or whether the query is substring-based. Partial compensation only.
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 verb 'Search' and the resource 'mutual funds by name', with examples. It effectively distinguishes from siblings like mf_detail or mf_list by emphasizing name-based search, though it does not explicitly name any sibling.
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 implies when to use it (when you want to find funds by name or category keywords) but does not explicitly contrast it with mf_list, mf_categories, or mf_featured. No alternative tools or exclusion conditions are mentioned, leaving the agent to infer the appropriate scenario.
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 present, so the description carries full burden. It does not disclose whether the tool is read-only, any side effects, error behavior, or rate limits. 'Compare' implies a read operation, but this is not made 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?
A single sentence with no wasted words. The core action and scope are front-loaded, and the attributes are listed efficiently.
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 that an output schema exists, the description need not explain return values. It adequately conveys the purpose and parameter usage, though it could benefit from stating that it is a read-only operation given no annotations.
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 beyond the schema: it clarifies that scheme_ids refer to funds and enforces a constraint of 2-4 elements, which is not present in the schema. This compensates for the 0% schema 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 states a specific verb (compare), resource (funds), and scope (2-4 funds) with the attributes compared (returns, risk ratios, expense, rank). It clearly distinguishes from siblings like mf_detail (single fund) and mf_search (search).
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 implies use for comparing 2-4 funds side-by-side, but does not explicitly state when to use this tool over alternatives (e.g., mf_detail for a single fund). No exclusions or 'when not to use' guidance is provided.
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 bears the full burden of behavioral disclosure. It clearly conveys that the tool returns a detailed report (read-only), but it does not mention potential side effects, authentication needs, performance implications, or error conditions. It is reasonably transparent about the output scope but lacks depth on operational 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 a single sentence that front-loads the primary purpose ('Full fund report card') followed by a concise enumeration of contents. It is efficient and each listed item contributes meaning, though the colon-separated list is somewhat dense.
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 presence of an output schema (which presumably details return fields), the description covers the key aspects of what is returned. It does not mention potential errors, required permissions, or limits, but for a retrieval tool of a single fund, the description is largely complete. The missing details are minor and not critical for an agent to invoke it correctly.
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%, so the description must compensate for the single parameter. It only says 'by scheme id' without explaining what a scheme_id is, how to obtain it, or any constraints (e.g., positive integer, required format). This is insufficient to guide an agent on how to fill the parameter correctly.
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 states a specific verb ('Full fund report card') and a clear resource ('by scheme id'), enumerating the exact contents (NAV, returns, expense breakdown, holdings, sectors, risk ratios, peers, managers, tax treatment). This distinguishes it from sibling tools like mf_search (search) and mf_compare (compare) without confusion.
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 implies the tool is for retrieving a comprehensive report for a specific fund when a scheme_id is known, which is clear context. However, it does not explicitly state when not to use it or name alternatives, so it falls short of full explicit 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?
No annotations are present, so the description carries the full burden. It states it returns 'all' categories, implying completeness, but doesn't disclose whether there is any filtering, sorting, or pagination. For a simple read-only enumeration this is acceptable but not richly detailed; it doesn't mention side effects or authentication requirements, which is fine for a public list but still 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?
The description is a single, information-dense sentence that conveys purpose and usage without any filler. It's appropriately sized for a trivial no-parameter tool and front-loads the key fact (all categories with ids) before the usage hint.
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 and an output schema exists (noted in context), the description fully covers what an agent needs: it identifies the resource, its content, and its intended integration point. There are no gaps in guidance for a tool this simple.
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?
This tool takes zero parameters, so the description need not elaborate on parameter semantics. The baseline for 0 parameters is 4, and the description appropriately focuses on the output and usage context. No additional parameter guidance is needed.
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 states exactly what the tool provides: all fund categories with their ids. It mentions the intended use with mf_list's category parameter, which also distinguishes it from sibling tools that operate on funds or stocks rather than categories.
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 'use with mf_list's `category` param', giving a clear context for when to call this tool. This is a direct, actionable usage directive that leaves no ambiguity about where the returned categories should be applied.
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:

[![etmoney-lyr MCP server](https://glama.ai/mcp/servers/ishan-parihar/etmoney-lyr/badges/card.svg)](https://glama.ai/mcp/servers/ishan-parihar/etmoney-lyr)

Score Badge

Copy to your README.md:

[![etmoney-lyr MCP server](https://glama.ai/mcp/servers/ishan-parihar/etmoney-lyr/badges/score.svg)](https://glama.ai/mcp/servers/ishan-parihar/etmoney-lyr)

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/ishan-parihar/etmoney-lyr'

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