tefas-fund-comparator

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
Tools like analyze_performance and compare_funds compute similar metrics (return, volatility, Sharpe, drawdown, AUM), and get_fund_details overlaps with get_portfolio_breakdown on portfolio allocation. While descriptions help differentiate, the boundaries between these tools are fuzzy, causing potential confusion.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case: analyze_performance, compare_funds, get_fund_details, get_historical_returns, get_portfolio_breakdown, list_funds. No mixing of styles or irregular patterns.
Tool Count5/5
With 6 tools, the server is well-scoped for the purpose of comparing TEFAS funds. Each tool addresses a distinct aspect (listing, details, performance, comparison, historical returns, portfolio breakdown) without being excessive or thin.
Completeness4/5
The tool set covers listing, detailed info, performance analysis, comparison, and portfolio breakdown. Minor gaps exist, such as lacking a direct raw price history endpoint (included in get_fund_details) and no filter for top performers, but overall the surface is sufficient for fund comparison.
Average 4/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides some behavioral context (fetches price history for each code, computes metrics) but does not disclose potential issues like multiple API calls per fund, data freshness, or rate limits that an agent should know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a one-line summary followed by a brief paragraph of detail. It is front-loaded and efficient, though the list of metrics could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 params, 3 required, output schema exists), the description adequately covers what the tool does and what metrics are computed. It mentions fetching price history, which implies potential performance considerations. Sufficient for an agent to understand scope.
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 100%; all parameters have descriptions. The description adds minimal new meaning beyond the schema (e.g., lists metric choices already described). Baseline of 3 is appropriate.
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 compares multiple TEFAS funds on specific metrics (return, risk, size), with a list of computed metrics. It differentiates from siblings like get_fund_details (single fund) and analyze_performance (likely broader analysis).
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 usage for comparing multiple funds, but lacks explicit guidance on when to use this vs alternatives like get_historical_returns or analyze_performance. No when-not-to-use or prerequisites mentioned.
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 full burden. It discloses the default behavior (latest_only true, one row per fund) and data source, but does not mention error handling, rate limits, or authorization needs. Adequate but not comprehensive.
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, with two short paragraphs. The first sentence front-loads the main purpose, and every sentence contributes meaningful information. No redundancies.
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 8 well-documented parameters and the presence of an output schema, the description provides sufficient context for a listing tool. It explains the default single-date snapshot and data source. Minor gap: no mention of pagination or performance considerations for large date ranges.
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 100%, so baseline is 3. The description adds some context (e.g., summarizing output behavior) but does not significantly extend beyond what the schema already provides. Meets minimum expectations.
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 lists TEFAS funds by type and optional date range/filters, and specifies the data source and fields returned. It is easily distinguished from sibling tools like get_fund_details or analyze_performance.
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 does not explicitly provide when-to-use or when-not-to-use guidance, nor does it mention alternatives. The purpose is clear, but an agent lacks direct guidance on selecting this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full transparency burden. It reveals behavioral traits such as fund code resolution, optional type search (with speed implication), and the data returned. However, it omits potential side effects or auth requirements, though none are expected.
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 paragraph that front-loads the purpose and then details the output. It is concise without being terse, but could benefit from clearer structuring such as bullet points for the returned data elements.
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 an output schema exists (signal: true), the description need not explain return values. It adequately covers the main aspects (fund info, price history, allocation) and references parameter behavior (e.g., slower when type omitted). Some parameters like history_limit are omitted but are well-defined in the schema.
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 100%, so baseline is 3. The description adds context about fund code resolution and type search slower behavior, but does not significantly enhance understanding beyond the schema's detailed parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves general info, optional price history, and portfolio allocation for a fund. It uses a specific verb ('Get') and resource ('fund details'), and the purpose distinguishes it from siblings like get_portfolio_breakdown and get_historical_returns.
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 usage for retrieving fund details but does not explicitly state when to use this tool versus alternatives like analyze_performance or compare_funds. No when-not guidance is provided, leaving the agent to infer context from the sibling list.
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 must cover behavioral aspects. It discloses that the tool returns whatever TEFAS publishes for the selected date, setting accurate expectations about data completeness. However, it does not discuss potential limitations, errors, or authorization requirements, which are minor omissions.
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 extremely concise, consisting of two sentences that immediately convey the tool's purpose and output. Every part adds value with no redundancy or filler.
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?
The tool is simple with well-documented parameters and an output schema mentioned. The description covers the nature of the output (asset allocation types). It lacks usage guidelines, but given the output schema and parameter coverage, it is mostly complete.
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?
Input schema coverage is 100% with clear descriptions, defaults, and types. The description adds context about the output but does not enhance parameter understanding beyond the schema. Baseline 3 is appropriate as the schema already does the heavy lifting.
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 returns asset allocation for a TEFAS fund, listing examples of holdings. It distinguishes itself from siblings like 'get_fund_details' (general info) and 'analyze_performance' (performance metrics) by focusing specifically on portfolio breakdown.
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 usage when a user needs asset allocation percentages, but it does not provide explicit guidance on when to use this tool versus alternatives (e.g., 'get_fund_details' for broader fund info) or when not to use it. The context is implied but not elaborated.
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 must fully disclose behavioral traits. It transparently lists the computed metrics and mentions the use of 'risk_free_annual' parameter. However, it omits details like data source reliance (daily price history) or any limitations, which would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with a clear lead sentence and a bullet list of computed metrics. Every sentence adds value without redundancy. It is front-loaded with the purpose and efficiently conveys the key 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?
The description sufficiently explains inputs and computations. Since an output schema exists, the return values are covered. However, it lacks mention of prerequisites (e.g., data availability for the date range) or any edge cases. Still, it is complete for a typical analysis tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining what the tool computes using the parameters (e.g., Sharpe ratio uses risk_free_annual) and providing context for defaults. It also lists the output metrics, which aids understanding beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool analyzes risk/return statistics for TEFAS funds, listing specific metrics computed (e.g., cumulative return, Sharpe ratio). This verb+resource combination is specific and distinguishes it from sibling tools like compare_funds or get_historical_returns.
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 does not explicitly state when to use this tool versus alternatives. It implies usage for computing performance stats but lacks guidance on when not to use it or when to prefer siblings like compare_funds. The context of sibling tools is present but not leveraged.
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 responsibility for behavioral disclosure. It explains that RB returns multi-horizon returns/risk when dates are omitted and period return when dates are set, while SB and MB require both dates. This provides substantial transparency, though it does not mention read-only nature, rate limits, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise, using a clear first sentence to state the main action, followed by a brief explanatory paragraph and a bullet-point list for each basis. Every sentence adds value, and the structure is efficient with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, no required, output schema exists), the description covers the core behavior well—explaining the three bases and their date dependencies. It does not discuss edge cases, pagination, or comparison with siblings, but these gaps are minor given the richness of the schema and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds significant meaning beyond the schema for the 'basis' and date parameters by explaining their behavior for each basis. Other parameters like limit, fund_type, etc. are adequately described in the schema. The added context for key parameters raises the score above baseline.
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 the resource 'TEFAS return tables', and immediately distinguishes by ranking basis (RB/SB/MB). It provides concise explanations for each basis, making the tool's purpose specific and distinct from sibling tools like analyze_performance or compare_funds.
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 usage context by explaining each basis and their date requirements, but it does not explicitly state when to use this tool versus alternatives (e.g., when to use get_historical_returns vs. get_fund_details or compare_funds). No direct comparison or 'when-not' guidance is provided.
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:

[![tefas-mcp MCP server](https://glama.ai/mcp/servers/merkezekre2026/tefas-mcp/badges/card.svg)](https://glama.ai/mcp/servers/merkezekre2026/tefas-mcp)

Score Badge

Copy to your README.md:

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

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