How do I use tefas-fund-comparator?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@tefas-fund-comparator Compare MAC and AFT mutual funds" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

tefas-fund-comparator

by merkezekre2026

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

tefas-fund-comparator

MCP (Model Context Protocol) sunucusu: TEFAS fonlarını listeleme, karşılaştırma, getiri/performans analizi ve portföy dağılımı inceleme.

Sunucu adı: tefas-fund-comparator

Özellikler

Tool	Açıklama
`list_funds`	Fon tipi + tarih aralığı + kod/isim filtresi ile fon listesi
`get_fund_details`	Fiyat geçmişi, özet metrikler, portföy dağılımı
`compare_funds`	Çoklu fon: getiri, volatilite, Sharpe, max drawdown, AUM
`get_portfolio_breakdown`	Varlık dağılımı (hisse, repo, eurobond, …)
`get_historical_returns`	RB / SB / MB bazlı TEFAS getiri tabloları
`analyze_performance`	Risk/getiri istatistikleri (pandas)

stdio + Streamable HTTP transport
pytefas: otomatik chunking + rate-limit retry
tefasfon: RB/SB/MB getiri tabloları
Çıktı: markdown tablo veya JSON

Related MCP server: mftool-mcp

Kurulum

Gereksinimler

Python 3.10+
İnternet erişimi (TEFAS API)

pip

cd TEFAS-MCP
python -m venv .venv

# Windows
.venv\Scripts\activate

# macOS / Linux
# source .venv/bin/activate

pip install -e .
# veya
pip install -r requirements.txt
pip install -e .

uv

cd TEFAS-MCP
uv venv
uv pip install -e .

Çalıştırma

stdio (Claude Code / Cline / Cursor — varsayılan)

python -m tefas_mcp.server
# veya
tefas-fund-comparator

Streamable HTTP

python -m tefas_mcp.server --transport http --host 127.0.0.1 --port 8000
# Endpoint: http://127.0.0.1:8000/mcp
# Health:   http://127.0.0.1:8000/health

Yardım

python -m tefas_mcp.server --help

Docker (yerel)

# Image build + run (port 8000)
docker compose up --build

# veya
docker build -t tefas-fund-comparator .
docker run --rm -p 8000:8000 -e PORT=8000 tefas-fund-comparator

Kontrol:

curl http://127.0.0.1:8000/health
curl http://127.0.0.1:8000/

Render.com (Docker Web Service)

Hazır dosyalar: Dockerfile, render.yaml, .dockerignore.

A) Blueprint (önerilen)

Kodu GitHub’a push edin.
Render Dashboard → New → Blueprint.
Repo’yu seçin; render.yaml otomatik okunur.
Deploy sonrası URL örneği: https://tefas-fund-comparator.onrender.com
MCP endpoint: https://tefas-fund-comparator.onrender.com/mcp
Health: https://tefas-fund-comparator.onrender.com/health

B) Manuel Web Service

New → Web Service → repo bağla
Runtime: Docker
Dockerfile path: ./Dockerfile
Health Check Path: /health
Env (opsiyonel; Dockerfile varsayılanları yeter):

Key	Value
`MCP_TRANSPORT`	`http`
`HOST`	`0.0.0.0`
`MCP_PATH`	`/mcp`
`LOG_LEVEL`	`INFO`

PORT Render tarafından otomatik enjekte edilir; elle yazmayın.

Claude / Cline ile Render URL

Claude genelde uzak HTTP MCP’ye doğrudan bağlanmaz; mcp-remote kullanın (examples/mcp_config.render.json):

{
  "mcpServers": {
    "tefas-fund-comparator": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://YOUR-SERVICE.onrender.com/mcp"
      ]
    }
  }
}

YOUR-SERVICE kısmını kendi Render servis adınızla değiştirin.

Render notları

Free plan idle sonrası uykuya geçer; ilk istek ~30–60 sn sürebilir.
TEFAS rate-limit nedeniyle uzun analizler yavaş / timeout olabilir; gerekirse plan yükseltin veya timeout’ları artırın.
Servis herkese açıksa istek koruması (auth, IP allowlist, Cloudflare) eklemeniz önerilir — bu imajda API anahtarı yoktur.

MCP istemci yapılandırması

Aşağıda PYTHON yolunu kendi venv’inize göre düzenleyin.

Claude Code / Claude Desktop (`claude_desktop_config.json` veya proje `.mcp.json`)

{
  "mcpServers": {
    "tefas-fund-comparator": {
      "command": "C:\\Users\\kerem\\Documents\\TEFAS-MCP\\.venv\\Scripts\\python.exe",
      "args": ["-m", "tefas_mcp.server"],
      "cwd": "C:\\Users\\kerem\\Documents\\TEFAS-MCP"
    }
  }
}

macOS/Linux örneği:

{
  "mcpServers": {
    "tefas-fund-comparator": {
      "command": "/path/to/TEFAS-MCP/.venv/bin/python",
      "args": ["-m", "tefas_mcp.server"],
      "cwd": "/path/to/TEFAS-MCP"
    }
  }
}

Global pip install -e . yaptıysanız:

{
  "mcpServers": {
    "tefas-fund-comparator": {
      "command": "tefas-fund-comparator",
      "args": []
    }
  }
}

Cline (VS Code)

Cline → MCP Settings:

{
  "mcpServers": {
    "tefas-fund-comparator": {
      "command": "python",
      "args": ["-m", "tefas_mcp.server"],
      "cwd": "C:\\Users\\kerem\\Documents\\TEFAS-MCP",
      "disabled": false
    }
  }
}

HTTP + mcp-remote (isteğe bağlı)

Önce sunucuyu HTTP modunda başlatın, sonra:

{
  "mcpServers": {
    "tefas-fund-comparator-http": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "http://127.0.0.1:8000/mcp"]
    }
  }
}

uvx (paket yayımlanmışsa)

{
  "mcpServers": {
    "tefas-fund-comparator": {
      "command": "uvx",
      "args": ["tefas-fund-comparator"]
    }
  }
}

Yerel dizinden uv run:

{
  "mcpServers": {
    "tefas-fund-comparator": {
      "command": "uv",
      "args": ["run", "--directory", "C:\\Users\\kerem\\Documents\\TEFAS-MCP", "python", "-m", "tefas_mcp.server"]
    }
  }
}

Fon tipleri

Kod	Anlam	tefasfon alias
`YAT`	Yatırım fonu	`SEC`
`EMK`	Emeklilik	`PEN`
`BYF`	Borsa yatırım fonu (ETF)	`ETF`
`GYF`	Gayrimenkul	`RE`
`GSYF`	Girişim sermayesi	`VC`

Örnek tool çağrıları

Agent / istemci üzerinden (anlamsal örnekler):

list_funds(fund_type="YAT", name_contains="ALTIN", limit=20)

get_fund_details(fund_code="AAL", fund_type="YAT")

compare_funds(
  fund_codes=["AAL", "AAK"],
  start_date="2026-01-01",
  end_date="2026-04-01",
  metrics=["return", "volatility", "sharpe", "max_drawdown"]
)

get_portfolio_breakdown(fund_code="AAL")

get_historical_returns(fund_type="YAT", basis="RB", limit=25)

analyze_performance(
  fund_codes=["AAL", "AAK"],
  start_date="2025-04-01",
  end_date="2026-04-01",
  risk_free_annual=0.40
)

Rate limit ve süre

TEFAS yaklaşık dakikada 6 istek sınırına yakındır. pytefas uzun aralıkları ~28 günlük parçalara böler:

Aralık	Kabaca süre
1 ay	~10 sn
3 ay	~1 dk
1 yıl	~3 dk

Aynı istekler ~60 sn TTL ile bellekte önbelleğe alınır.

Test

pip install -e ".[dev]"
pytest -q

Ağ gerektiren smoke test (manuel):

python -c "from tefas_mcp.client import get_service; print(get_service().fetch_info('2026-04-20','2026-04-24',kind='YAT',fund_code='AAL').head())"

Proje yapısı

src/tefas_mcp/
  server.py           # FastMCP entrypoint
  client/             # pytefas + tefasfon façade
  tools/              # 6 MCP tools
  analytics/          # Sharpe, vol, max DD
  models/             # enums / validation
  utils/              # dates, formatters, errors

Bağımlılıklar

fastmcp
pytefas
tefasfon
pandas, pydantic, httpx

Uyarı

Bu araç yatırım tavsiyesi değildir. TEFAS API’si resmi olarak dokümante edilmemiştir; site değişikliklerinde paket güncellemesi gerekebilir. Metrikler eğitim / karşılaştırma amaçlı basitleştirilmiş istatistiklerdir.

Lisans

MIT

Available Tools

6 tools

analyze_performanceA

Analyze risk/return statistics for one or more TEFAS funds.

Computes for each fund (from daily price history):

Cumulative return
Annualized return
Annualized volatility
Sharpe ratio (using risk_free_annual)
Maximum drawdown
Observation count
Latest AUM and investor count when available

ParametersJSON Schema

Name	Required	Description	Default
`end_date`	Yes	Window end.
`fund_type`	No	Default kind YAT/EMK/BYF/GYF/GSYF.	YAT
`fund_codes`	Yes	One or more fund codes (max 15).
`start_date`	Yes	Window start (YYYY-MM-DD or DD.MM.YYYY).
`output_format`	No	``markdown`` or ``json``.	markdown
`risk_free_annual`	No	Annual risk-free rate as fraction (default 0.45).

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

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.

compare_fundsA

Compare multiple TEFAS funds on return, risk, and size metrics.

Fetches price history for each code and computes selected metrics: cumulative/annualized return, volatility, Sharpe ratio, max drawdown, latest AUM, and investor count.

ParametersJSON Schema

Name	Required	Description	Default
`metrics`	No	Subset of ``return``, ``volatility``, ``sharpe``, ``max_drawdown``, ``aum``, ``investors``. Default: all.
`end_date`	Yes	Analysis window end.
`fund_type`	No	Default fund kind for all codes (YAT/EMK/BYF/…). If a code is not found in this type, other types are tried.	YAT
`fund_codes`	Yes	2–10 fund codes to compare (e.g. ``["AAL", "AAK"]``).
`start_date`	Yes	Analysis window start (YYYY-MM-DD or DD.MM.YYYY).
`output_format`	No	``markdown`` or ``json``.	markdown
`risk_free_annual`	No	Annual risk-free rate for Sharpe (fraction, e.g. 0.45 = 45%). Adjust to current TR policy / deposit rates.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

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.

get_fund_detailsA

Get general info, optional price history, and portfolio allocation for a fund.

Resolves the fund code (and type if omitted), returns a summary of latest price / AUM / investors, period return, recent price history, and latest asset allocation.

ParametersJSON Schema

Name	Required	Description	Default
`end_date`	No	Price history end. Default today.
`fund_code`	Yes	TEFAS fund code (e.g. ``AAL``, ``YAC``, ``TTE``).
`fund_type`	No	Optional YAT/EMK/BYF/GYF/GSYF. If omitted, all types are searched (slower).
`start_date`	No	Price history start (YYYY-MM-DD). Default ~90 days ago.
`history_limit`	No	Max price history rows in the response (default 30).
`output_format`	No	``markdown`` or ``json``.	markdown
`include_portfolio`	No	Fetch latest portfolio breakdown (default true).
`include_price_history`	No	Include recent price rows (default true).

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

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.

get_historical_returnsA

Fetch TEFAS return tables by ranking basis (RB / SB / MB).

Uses tefasfon to pull TEFAS comparative return data:

RB (return-based): multi-horizon returns (1M/3M/6M/1Y/…) and risk value when dates are omitted; period return when dates are set.
SB (size-based): portfolio size / share count change and net return between two dates (both dates required).
MB (management fee-based): fee vs annual return metrics (both dates required).

ParametersJSON Schema

Name	Required	Description	Default
`basis`	No	``RB``, ``SB``, or ``MB``.	RB
`limit`	No	Max rows (1–500). Default 50.
`end_date`	No	Period end (required for SB/MB; optional for RB).
`fund_type`	No	YAT/EMK/BYF/GYF/GSYF (or SEC/PEN/ETF/RE/VC).	YAT
`fund_codes`	No	Optional exact code filter list.
`start_date`	No	Period start (required for SB/MB; optional for RB).
`name_contains`	No	Optional name keyword filter.
`output_format`	No	``markdown`` or ``json``.	markdown

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

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.

get_portfolio_breakdownA

Get asset allocation (portfolio breakdown) for a TEFAS fund.

Returns holdings percentages such as stocks, reverse repo, eurobonds, government bonds, precious metals, foreign assets, etc. (whatever TEFAS publishes for that fund on the selected date).

ParametersJSON Schema

Name	Required	Description	Default
`min_pct`	No	Hide allocation lines below this absolute percent (default 0.01). Use 0 to show all non-null columns.
`fund_code`	Yes	TEFAS fund code (e.g. ``AAL``).
`fund_type`	No	Optional YAT/EMK/BYF/GYF/GSYF. Auto-detected if omitted.
`as_of_date`	No	Snapshot date (YYYY-MM-DD). Default: latest available (searches up to ~14 days back to skip weekends/holidays).
`output_format`	No	``markdown`` or ``json``.	markdown

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

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.

list_fundsA

List TEFAS funds by type and optional date range / filters.

Pulls general fund information (code, name, price, AUM, investors) from TEFAS via pytefas. By default returns a snapshot of the latest available day in the range (one row per fund).

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Max rows to return (1–500). Default 50.
`end_date`	No	Range end. Defaults to start_date when only start given.
`fund_type`	No	Fund category. One of YAT (securities), EMK (pension), BYF (ETF), GYF (real estate), GSYF (venture capital). Aliases SEC/PEN/ETF/RE/VC also accepted. Default YAT.	YAT
`start_date`	No	Range start as YYYY-MM-DD or DD.MM.YYYY. Defaults to today if omitted (with end_date).
`latest_only`	No	If true (default), keep only the most recent date in the range so each fund appears once.
`code_contains`	No	Case-insensitive substring filter on fund code (e.g. "AA" matches AAK, AAL).
`name_contains`	No	Case-insensitive substring filter on fund name (e.g. "ALTIN", "PARA PİYASASI").
`output_format`	No	``markdown`` (table) or ``json``.	markdown

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesv1.0.0Jul 9, 2026
- First observedanalyze_performance
- First observedcompare_funds
- First observedget_fund_details
- First observedget_historical_returns
- First observedget_portfolio_breakdown
- First observedlist_funds

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored 2026-07-09 10:55 across 6 tools

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.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

ForInvest MCP ServerOAuth
io.github.foreksgithub
Financial data and analysis tools for Turkish BIST and international markets via MCP.
Finance Research & Data
2
Crypto Prices Mcp
io.github.varvararatta
Unlock the power of real-time cryptocurrency data with our Crypto Price Insights MCP server.
Cryptocurrency Finance
2
Caplia AOAuth
io.github.Caplia-Tech
MCP server for VC pitch-deck scoring, thesis-fit matching, and deal-flow management.
Finance AI & Machine Learning
2
Helvetic Research AOAuth
io.github.KushPatil22
Research-only MCP server: your AI as a quant research desk. 90 tools, no trades, no brokers.
Finance Research & Data
1

Related MCP Servers

FonParam MCP
Finance Search Research & Data
kemalersin
A
license
B
quality
D
maintenance
A Model Context Protocol server that enables Claude Desktop to access investment fund data in Turkey through the FonParam API, allowing users to list, compare, and analyze funds, view company statistics, and get inflation data.
Updated 3 months ago (2026-06-01 19:56 UTC)
15
25 npm
3
MIT
mftool-mcp
Finance Research & Data
NayakwadiS
A
license
A
quality
C
maintenance
MCP Server for publicly available real-time Indian Mutual Funds data
Updated 4 months ago (2026-05-09 01:19 UTC)
12
7
MIT
turkey-data-mcp
Finance Location Services Open Data
bodyegypt
A
license
A
quality
D
maintenance
MCP server for live Turkey data — gold & silver prices, official TCMB exchange rates, fuel pump prices, prayer times and the Kandilli earthquake feed.
Updated 3 months ago (2026-06-09 22:36 UTC)
7
26 npm
MIT
13flow
Finance Government Data Research & Data
bluetouff
A
license
Not graded
quality
B
maintenance
MCP server that reconstructs hedge-fund/superinvestor portfolios from SEC EDGAR 13F filings, offering tools to query fund holdings, consensus activity, and quarter-over-quarter changes through a read-only API.
Updated 12 days ago (2026-09-04 08:28 UTC)
3
AGPL 3.0

tefas-fund-comparator

Özellikler

Kurulum

Gereksinimler

pip

uv

Çalıştırma

stdio (Claude Code / Cline / Cursor — varsayılan)

Streamable HTTP

Yardım

Docker (yerel)

Render.com (Docker Web Service)

A) Blueprint (önerilen)

B) Manuel Web Service

Claude / Cline ile Render URL

Render notları

MCP istemci yapılandırması

Claude Code / Claude Desktop (claude_desktop_config.json veya proje .mcp.json)

Cline (VS Code)

HTTP + mcp-remote (isteğe bağlı)

uvx (paket yayımlanmışsa)

Fon tipleri

Örnek tool çağrıları

Rate limit ve süre

Test

Proje yapısı

Bağımlılıklar

Uyarı

Lisans

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Claude Code / Claude Desktop (`claude_desktop_config.json` veya proje `.mcp.json`)