How do I use evds-mcp-server?

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., "@evds-mcp-server What was the annual inflation rate for 2023?" 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.

evds-mcp-server

by denizcakiroglu322

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

evds-mcp-server

Türkiye ekonomik verisini (TCMB EVDS) bir LLM'in güvenle çağırabileceği, curated araçlar olarak sunan bir MCP server'ı.

FRED/ECB/Eurostat için MCP server'lar var; Türkiye (EVDS) için yoktu. Bu server o boşluğu dolduruyor: Claude (Desktop/Code) "2023'te yıllık enflasyon neydi?", "dolar son 1 yılda ne oldu?" gibi soruları serbest sorgu yazmadan, önceden doğrulanmış araçlarla EVDS'den canlı çekip kaynağıyla yanıtlar.

Tasarım ilkesi: LLM serbest seri seçmez. Her araç doğru EVDS seri koduna ve birime kilitlidir. Bu, yanlış seri / nominal-reel karışması / hallucination'ı baştan engeller. Her yanıt kaynak + dönem + birim + nominal/reel taşır.

Stateless: veritabanı yok, cache yok. Her çağrı EVDS'ye canlı gider.
Stdio transport, tek paket, TypeScript.
Veri kaynağı: yalnızca EVDS (TCMB).

Araçlar (6 curated tool)

Araç	Ne yapar	Önemli parametreler
`get_inflation`	TÜFE / Yİ-ÜFE / çekirdek (C) enflasyon	`measure`, `change: yoy\|level`, `period`
`get_fx`	TCMB döviz alış/satış kuru (günlük)	`pair`, `side: alis\|satis`, `period`
`get_policy_rate`	Politika faizi proxy'si (AOFM)	`frequency: daily\|monthly`, `period`
`get_trade_balance`	Dış ticaret: ihracat / ithalat / denge	`flow: export\|import\|balance`, `period`
`get_growth`	GSYİH büyüme	`basis: yoy\|level`, `period`
`compare_indicators`	İki göstergeyi aynı dönemde (nominal/reel)	`a`, `b`, `transform: real\|yoy`, `period`

period her araçta { start, end } ve tarihler YYYY, YYYY-MM veya YYYY-MM-DD olabilir.

Ortak çıktı şeması

Her araç (compare hariç) aynı zarfı döndürür:

{
  "series": "TP.DK.USD.S.YTL",        // EVDS seri kodu
  "label": "ABD Doları (Döviz Satış)",
  "unit": "TL (1 USD karşılığı)",
  "basis": "nominal",                  // nominal | reel | düzey | yıllık % değişim ...
  "observations": [
    { "date": "25-06-2026", "value": 46.4935 },
    { "date": "26-06-2026", "value": 46.5139 }
  ],
  "source": "TCMB EVDS",
  "fetchedAt": "2026-06-26T11:58:05.746Z",
  "note": "…"                          // varsa metodoloji/uyarı
}

Yukarıdaki, EVDS'den dönen gerçek bir örnektir (USD satış, 25–26 Haz 2026).

Related MCP server: publicfinance

Kurulum

Gereksinim: Node.js ≥ 20.

git clone <repo-url> evds-mcp-server
cd evds-mcp-server
npm install
npm run build        # dist/index.js üretir

EVDS API anahtarı

https://evds3.tcmb.gov.tr adresine kayıt olun / giriş yapın.
Profil → API Anahtarı'ndan anahtarınızı alın (ücretsiz).
.env dosyası oluşturun (.env.example'ı kopyalayın):

cp .env.example .env
# .env içine: EVDS_API_KEY=sizin_anahtarınız

Anahtar 2024 değişikliğiyle artık HTTP header olarak gönderilir (URL'de değil). Bu server bunu sizin için yapar. .env repoya girmez (.gitignore'da).

Seri kodu doğrulama / sağlık kontrolü

13 seri kodunun tamamı canlı evds3 katalogundan + gerçek bir veri çağrısıyla doğrulanmıştır (TÜFE/çekirdek 2025=100 yeni seri, dış ticaret "Toplam", GSYİH toplam dahil). Anahtarınızla bir sağlık kontrolü çalıştırmak için:

npm run verify

Bu komut her seriyi canlı EVDS'den teyit eder, resmî EVDS etiketini ve son gözlemi yazar, ardından gerçek bir get_fx USD örneği basar. TÜİK ileride yeniden baz yılı değiştirirse (örn. 2003=100 → 2025=100 geçişinde olduğu gibi) bu komut hangi serinin durduğunu gösterir; doğru kodu src/series.ts içine yazabilirsiniz.

Claude'a ekleme

Claude Desktop

claude_desktop_config.json dosyasına ekleyin (macOS: ~/Library/Application Support/Claude/claude_desktop_config.json):

{
  "mcpServers": {
    "evds": {
      "command": "node",
      "args": ["/MUTLAK/YOL/evds-mcp-server/dist/index.js"],
      "env": { "EVDS_API_KEY": "sizin_anahtarınız" }
    }
  }
}

Claude Desktop'ı yeniden başlatın. /MUTLAK/YOL'u kendi yolunuzla değiştirin (pwd ile bulabilirsiniz).

Claude Code (CLI)

claude mcp add evds --env EVDS_API_KEY=sizin_anahtarınız -- node /MUTLAK/YOL/evds-mcp-server/dist/index.js

Manuel stdio çalıştırma

EVDS_API_KEY=xxx node dist/index.js     # MCP istemcisi stdin/stdout ile konuşur
node dist/index.js --help               # yardım

Doğruluk kuralları

Her yanıt kaynak + dönem + birim + nominal/reel taşır. İstisna yok.
EVDS boş/null dönerse uydurulmaz — note alanında "veri yok" denir.
Birim ve nominal/reel ayrımı asla karıştırılmaz (TL ≠ USD, endeks ≠ % değişim).
EVDS yanıtı zod ile doğrulanır; beklenmeyen şekil → açıklayıcı hata.
Anahtar eksik/geçersizse araç çağrısı net Türkçe hata döndürür (server çökmez).

Veri kaynağı, lisans, etik

Veri: TCMB EVDS. Kişisel kullanım ve araştırma amaçlıdır; EVDS kullanım koşulları geçerlidir. Ticari yeniden-dağıtım iddiası yoktur.
Her araç çıktısında source: "TCMB EVDS" bulunur — kaynak gösterimi hem etik hem zorunludur.
API anahtarı size aittir; repoya girmez.
Kod lisansı: MIT (bkz. LICENSE). Lisans yalnızca bu server'ın kaynak kodunu kapsar; veriyi değil.

Sonraki fazlar (bu sürümün kapsamı dışında)

Web arayüzü.
Ek kaynaklar: World Bank, TÜİK doğrudan.
Daha fazla curated gösterge (işsizlik, cari denge, konut fiyat endeksi…).

Proje yapısı

src/
  index.ts          # MCP server (stdio), 6 aracı kaydeder
  evds.ts           # EVDS adapter: fetch + header auth, zod, tarih/frekans, katalog
  series.ts         # curated seri kayıt defteri (kodlar burada kilitli)
  constants.ts      # frekans/formül/aggregation kodları
  types.ts          # ortak çıktı şeması (zod)
  format.ts         # ortak çıktı montajı + hata biçimleme
  tools/            # 6 aracın implementasyonu
scripts/
  verify.ts         # canlı katalog doğrulama (npm run verify)

Available Tools

6 tools

compare_indicatorsGösterge Karşılaştırma (nominal/reel)A

Read-onlyIdempotent

İki curated göstergeyi aynı dönemde karşılaştırır; istenirse birini enflasyondan arındırarak REEL değeri verir.

Ne zaman kullanılır:

"Reel faiz neydi" → a='tufe', b='policy_rate'? Hayır: reel için b nominal BÜYÜME olmalı. Reel faiz için a='tufe', b='policy_rate' yerine yorum gerekir; en sağlam kullanım:
"Dolar reel olarak arttı mı" → a='tufe', b='usd', transform='real'.
"Büyüme enflasyonun üstünde mi" → a='tufe', b='gdp', transform='yoy' (ikisini yan yana).

Parametreler:

a, b: { indicator: 'tufe' | 'ufe' | 'cekirdek' | 'usd' | 'eur' | 'gbp' | 'policy_rate' | 'gdp' }
period: { start, end }
transform: 'real' (b'yi a=enflasyon ile reelleştir) | 'yoy' (ikisi de yıllık %) | boş

Dönüş: { transform, period, a, b, derived?, source, fetchedAt, note }.

a/b: her biri { series, label, unit, basis, observations }.
derived: transform='real' başarılıysa reel(b) (basis 'reel'). Tarihler eşleşmezse (örn. aylık vs çeyreklik) reel hesaplanmaz ve not'ta belirtilir. ÖNEMLİ: nominal/reel ayrımı her blokta 'basis' ile açıkça verilir; karıştırmayın. transform='real' için 'a' enflasyon (tufe/ufe/cekirdek) olmalıdır.

ParametersJSON Schema

Name	Required	Description
`a`	Yes	First indicator. For transform='real' this MUST be an inflation measure.
`b`	Yes	Second indicator (the one deflated when transform='real').
`period`	Yes	Inclusive date range to query.
`transform`	No	'real' = reel(b) = b enflasyondan (a) arındırılmış. 'yoy' / boş = her ikisi de yıllık % olarak.

Output Schema

ParametersJSON Schema

Name	Required	Description
`a`	Yes
`b`	Yes
`note`	No
`period`	Yes	Inclusive date range to query.
`source`	Yes
`derived`	No	reel(b), present only when transform='real' succeeds.
`fetchedAt`	Yes
`transform`	Yes	Applied transform: 'real' \| 'yoy'.

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations (readOnly, idempotent, non-destructive), the description details output structure, conditions for the 'real' transform (a must be inflation measure), and what happens when date frequencies mismatch. It explicitly warns about nominal/reel separation and basis field.

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 well-structured with sections for purpose, usage, parameters, output, and notes. It is somewhat lengthy but every section adds value. The core function is front-loaded in the first sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (two indicators, nested objects, optional transform, output schema), the description covers all necessary aspects: purpose, when to use, parameter constraints, output fields (including derived and basis), and important behavioral notes. It is complete and self-contained.

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?

Input schema has 100% coverage with descriptions for all parameters. The description adds extra value by providing examples of indicator combinations, constraints (a must be inflation for 'real'), and explaining the meaning of transform values. This enhances parameter understanding beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool compares two curated indicators over the same period and optionally adjusts for inflation. It distinguishes from sibling tools (get_fx, get_growth, etc.) which retrieve single indicators. The title also reinforces the nominal/real focus.

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?

A dedicated 'Ne zaman kullanılır' section provides explicit usage examples (e.g., 'Dolar reel olarak arttı mı') and warns against incorrect parameter combinations (e.g., for real faiz, a='tufe', b='policy_rate' is not correct). This guides when to use the tool vs alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_fxDöviz Kuru (TCMB)A

Read-onlyIdempotent

TCMB'nin gösterge niteliğindeki günlük döviz alış/satış kurlarını döndürür (1 birim yabancı para = X TL).

Ne zaman kullanılır:

"Dolar/Euro kuru bugün/şu tarihte neydi", "son 1 yılda dolar nasıl değişti" gibi sorularda.
Kur SEVİYESİ (TL) gerekir; yüzde değişim gerekiyorsa observations'tan hesaplayın ya da compare_indicators kullanın.

Parametreler:

pair: USD | EUR | GBP | CHF | CAD | AUD | SAR | DKK | SEK | NOK
side: 'alis' | 'satis' (vars. 'satis')
period: { start, end } (YYYY | YYYY-MM | YYYY-MM-DD)

Dönüş: ortak şema — series, label, unit ("TL (1 karşılığı)"), basis ("nominal"), observations[{date,value}], source, fetchedAt. Notlar: Hafta sonu/tatil günlerinde değer null olabilir. Veri yoksa uydurmaz; not alanında belirtir.

ParametersJSON Schema

Name	Required	Description	Default
`pair`	Yes	Currency against TRY. One of: USD, EUR, GBP, CHF, CAD, AUD, SAR, DKK, SEK, NOK.
`side`	No	'alis' = TCMB buying rate, 'satis' = TCMB selling rate (default).	satis
`period`	Yes	Inclusive date range to query.

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	No	Methodology, caveats, or verification warnings, when relevant.
`unit`	Yes	Unit of the values, e.g. '%', 'TL', 'endeks (2003=100)'.
`basis`	Yes	What the numbers represent: 'nominal' \| 'reel' \| 'düzey' \| 'yıllık % değişim' \| ...
`label`	Yes	Human-readable Turkish name of the series.
`series`	Yes	EVDS series code that produced these observations (e.g. 'TP.DK.USD.A.YTL').
`source`	Yes	Always 'TCMB EVDS'.
`fetchedAt`	Yes	ISO-8601 timestamp of when the data was fetched.
`observations`	Yes	The time series, oldest to newest.

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds valuable context: weekend/holiday null values, data absence handling via note field, and return structure summary. No contradictions.

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?

Well-structured with clear sections (purpose, when to use, parameters, return). Front-loaded key info. No unnecessary words; every sentence serves a purpose.

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 3 parameters (including nested period), output schema exists, and context signals high complexity. Covers return format, unit, basis, and edge cases (holidays null). Completely equips an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% coverage with full descriptions for all parameters. Description goes beyond by explaining side meanings (alis/satis) and providing usage examples in context. Adds value without redundancy.

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?

Explicitly states it returns daily FX rates from TCMB, with resource (currency pairs) and verb (döndürür). Distinguishes from sibling compare_indicators by specifying it provides rate levels (TL) vs percentage changes.

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?

Clearly states when to use (rate levels for currencies) and when not (percentage changes should use compare_indicators or compute from observations). Provides explicit alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_growthBüyüme / GSYİH (TÜİK)A

Read-onlyIdempotent

Türkiye ekonomik büyümesi (GSYİH, çeyreklik).

Ne zaman kullanılır:

"Türkiye 2023'te ne kadar büyüdü", "çeyreklik büyüme oranı" → basis='yoy' (yıllık % değişim).
Endeks düzeyi gerekirse → basis='level' (zincirlenmiş hacim endeksi).

Parametreler:

period: { start, end }
basis: 'yoy' (vars.) | 'level'

Dönüş: ortak şema. basis='yoy' → unit '%', basis 'yıllık % değişim'. basis='level' → unit 'bin TL' (zincirlenmiş hacim, düzey). Seri: TP.GSYIH26.HY.ZH (Harcama Yöntemiyle, Zincirlenmiş Hacim, Toplam).

ParametersJSON Schema

Name	Required	Description	Default
`basis`	No	'yoy' = yıllık % büyüme (vars.), 'level' = zincirlenmiş hacim endeksi düzeyi.	yoy
`period`	Yes	Inclusive date range to query.

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	No	Methodology, caveats, or verification warnings, when relevant.
`unit`	Yes	Unit of the values, e.g. '%', 'TL', 'endeks (2003=100)'.
`basis`	Yes	What the numbers represent: 'nominal' \| 'reel' \| 'düzey' \| 'yıllık % değişim' \| ...
`label`	Yes	Human-readable Turkish name of the series.
`series`	Yes	EVDS series code that produced these observations (e.g. 'TP.DK.USD.A.YTL').
`source`	Yes	Always 'TCMB EVDS'.
`fetchedAt`	Yes	ISO-8601 timestamp of when the data was fetched.
`observations`	Yes	The time series, oldest to newest.

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark as readOnly, idempotent, non-destructive. Description adds context on return format (unit and metric depending on basis) and the specific series code, going beyond annotations without contradiction.

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?

Well-structured with clear headings and bullet points. Every sentence adds value; no redundant information. Front-loaded with purpose and usage, then parameter details, then return format.

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 output schema exists (not shown but present), description still provides necessary context: query types, parameter choices, return units, and series identifier. Complete for a tool with 2 parameters and sibling differentiation.

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. Description adds practical guidance on when to use each basis value and explains the meaning of period and the return unit, improving parameter understanding beyond schema descriptions alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Türkiye ekonomik büyümesi (GSYİH, çeyreklik)' indicating it retrieves quarterly GDP growth for Turkey. Distinguishes from siblings (e.g., get_inflation, get_fx) which handle different indicators.

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?

Explicit section 'Ne zaman kullanılır' with examples mapping queries to parameter values (basis='yoy' for annual growth, basis='level' for index level). Provides clear when-to-use guidance with no ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_inflationEnflasyon (TÜFE / Yİ-ÜFE / Çekirdek)A

Read-onlyIdempotent

Türkiye enflasyon verisi: TÜFE (tüketici), Yİ-ÜFE (üretici) veya çekirdek (C) — aylık.

Ne zaman kullanılır:

"2023'te yıllık enflasyon neydi", "TÜFE son 12 ayda nasıl değişti" → change='yoy' (yıllık % değişim).
Endeks düzeyi gerektiğinde (örn. iki dönem arası kümülatif hesap) → change='level'.

Parametreler:

measure: 'tufe' | 'ufe' | 'cekirdek'
change: 'yoy' (vars.) | 'level'
period: { start, end }

Dönüş: ortak şema. change='yoy' → unit '%', basis 'yıllık % değişim'. change='level' → unit 'endeks (2025=100)', basis 'düzey (endeks)'. Önemli: 'yoy' ile 'level' BİRBİRİNE KARIŞTIRILMAZ; basis alanını dikkate alın. TÜFE ve çekirdek 2025=100 yeni seridir.

ParametersJSON Schema

Name	Required	Description	Default
`change`	No	'yoy' = annual % change (yıllık enflasyon, default), 'level' = the index level.	yoy
`period`	Yes	Inclusive date range to query.
`measure`	Yes	'tufe' = TÜFE (CPI), 'ufe' = Yİ-ÜFE (PPI), 'cekirdek' = core CPI (C indicator).

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	No	Methodology, caveats, or verification warnings, when relevant.
`unit`	Yes	Unit of the values, e.g. '%', 'TL', 'endeks (2003=100)'.
`basis`	Yes	What the numbers represent: 'nominal' \| 'reel' \| 'düzey' \| 'yıllık % değişim' \| ...
`label`	Yes	Human-readable Turkish name of the series.
`series`	Yes	EVDS series code that produced these observations (e.g. 'TP.DK.USD.A.YTL').
`source`	Yes	Always 'TCMB EVDS'.
`fetchedAt`	Yes	ISO-8601 timestamp of when the data was fetched.
`observations`	Yes	The time series, oldest to newest.

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only and idempotent behavior. The description adds value by warning against confusing 'yoy' and 'level' modes, noting the basis field, and mentioning that TÜFE and core use a new 2025=100 index series. This goes beyond annotations in explaining how to interpret results.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with sections, bullet points, and a clear hierarchy. It is front-loaded with the purpose, followed by usage, parameters, return schema, and an important note. Every sentence adds value without unnecessary verbosity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (3 parameters, nested period, enums) and the presence of an output schema, the description covers all critical aspects: purpose, parameter usage, return format with unit/basis, and a behavioral caveat. It is sufficiently complete for an agent to select and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, baseline is 3. The description significantly adds meaning by providing usage examples for 'change', explaining return values (unit, basis) based on change selection, and noting the base year for measures. This goes 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 it retrieves Turkish inflation data (TÜFE, Yİ-ÜFE, or core) on a monthly basis. The verb 'get' and resource 'inflation' are specific, and the title explicitly lists the measures, distinguishing it from sibling tools that deal with other economic indicators.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage scenarios under 'Ne zaman kullanılır:' with examples (e.g., '2023 annual inflation' → change='yoy'). It differentiates between change types but does not compare against sibling tools; however, siblings are for different indicators, so the guidance is clear for parameter choices.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_policy_ratePolitika Faizi / AOFM (TCMB)A

Read-onlyIdempotent

TCMB Ağırlıklı Ortalama Fonlama Maliyeti (AOFM) — politika faizine en yakın günlük gösterge.

Ne zaman kullanılır:

"TCMB faizi (fonlama maliyeti) X tarihinde neydi", "faiz son dönemde nasıl seyretti" sorularında.
frequency='monthly' aylık ortalamayı verir (uzun dönem trend için).

Parametreler:

period: { start, end }
frequency: 'daily' (vars.) | 'monthly'

Dönüş: ortak şema — unit '%', basis 'nominal faiz (düzey, %)'. Not: Bu, resmî 1 hafta vadeli repo politika faizinden farklı olabilen AOFM göstergesidir; not alanında belirtilir.

ParametersJSON Schema

Name	Required	Description	Default
`period`	Yes	Inclusive date range to query.
`frequency`	No	'daily' = günlük seri (vars.), 'monthly' = aylık ortalama.	daily

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	No	Methodology, caveats, or verification warnings, when relevant.
`unit`	Yes	Unit of the values, e.g. '%', 'TL', 'endeks (2003=100)'.
`basis`	Yes	What the numbers represent: 'nominal' \| 'reel' \| 'düzey' \| 'yıllık % değişim' \| ...
`label`	Yes	Human-readable Turkish name of the series.
`series`	Yes	EVDS series code that produced these observations (e.g. 'TP.DK.USD.A.YTL').
`source`	Yes	Always 'TCMB EVDS'.
`fetchedAt`	Yes	ISO-8601 timestamp of when the data was fetched.
`observations`	Yes	The time series, oldest to newest.

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate read-only, idempotent, non-destructive. The description adds useful context: output unit (%), basis (nominal rate), and a caution that AOFM may differ from official 1-week repo rate, noted in a 'not' field.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with clear bulleted sections for usage and parameters. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given annotations and output schema, the description adequately covers return format (unit, basis) and a key behavioral note. Some detail on the output schema structure is omitted but compensated by the output schema presence.

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% with descriptions. The description adds extra meaning: monthly frequency provides averages for long-term trends, and explains the period parameter as inclusive date range. This goes beyond schema schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies the tool retrieves TCMB Weighted Average Cost of Funding (AOFM), the closest daily indicator to the policy rate. It distinguishes from sibling tools which cover different economic indicators (fx, inflation, etc.).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly provides usage scenarios (e.g., queries about TCMB rate on a date, recent trend, long-term trend with monthly frequency) and explains parameter intent. It does not explicitly state when not to use, but siblings are distinct domains.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_trade_balanceDış Ticaret (İhracat / İthalat / Denge)A

Read-onlyIdempotent

Türkiye dış ticareti: ihracat, ithalat veya dış ticaret dengesi (aylık, bin USD).

Ne zaman kullanılır:

"İhracat/ithalat X ayında ne kadardı", "dış ticaret açığı son dönemde nasıl" sorularında.
flow='balance' → ihracat − ithalat (negatif = açık).

Parametreler:

flow: 'export' | 'import' | 'balance'
period: { start, end }

Dönüş: ortak şema — unit 'bin USD', basis 'düzey' (balance için 'düzey (ihracat − ithalat)'). Seri: Genel Ticaret Sistemi, ISIC Rev.4 Toplam (ihracat TP.IHRISICREV4.TT / ithalat TP.ITHISICREV4.TT).

ParametersJSON Schema

Name	Required	Description	Default
`flow`	Yes	'export' = ihracat, 'import' = ithalat, 'balance' = denge (ihracat − ithalat).
`period`	Yes	Inclusive date range to query.

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	No	Methodology, caveats, or verification warnings, when relevant.
`unit`	Yes	Unit of the values, e.g. '%', 'TL', 'endeks (2003=100)'.
`basis`	Yes	What the numbers represent: 'nominal' \| 'reel' \| 'düzey' \| 'yıllık % değişim' \| ...
`label`	Yes	Human-readable Turkish name of the series.
`series`	Yes	EVDS series code that produced these observations (e.g. 'TP.DK.USD.A.YTL').
`source`	Yes	Always 'TCMB EVDS'.
`fetchedAt`	Yes	ISO-8601 timestamp of when the data was fetched.
`observations`	Yes	The time series, oldest to newest.

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint and idempotentHint true, consistent with a query tool. The description adds context about the data computation (balance = export - import) and return format, going beyond annotations.

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?

Well-structured with clear sections; each sentence adds necessary information. Slightly verbose but justified given the multilingual context and detail.

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?

Tool is moderately complex with nested period parameter and return schema. Description covers purpose, when to use, parameter details, and return format. Output schema exists, so return values need not be fully described here.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% description coverage, so baseline is 3. The description adds value by explaining the 'flow' parameter with examples and detailing the specific series codes used.

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 Turkey's foreign trade data (export, import, balance) in monthly thousand USD. It distinguishes itself from sibling tools like get_growth or get_inflation, which focus on other economic indicators.

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?

Includes a 'Ne zaman kullanılır' section with example questions, guiding when to use the tool. It does not explicitly list alternatives, but the sibling tools are sufficiently different in purpose.

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 updatesv0.1.0Jul 12, 2026
- First observedcompare_indicators
- First observedget_fx
- First observedget_growth
- First observedget_inflation
- First observedget_policy_rate
- First observedget_trade_balance

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/5.0

Scored 2026-07-12 08:25 across 6 tools

Disambiguation5/5

Each tool targets a distinct economic indicator (exchange rates, growth, inflation, policy rate, trade balance) and the compare_indicators tool explicitly combines two indicators. There is no ambiguity between tools.

Naming Consistency4/5

Five tools use a consistent 'get_' prefix for fetching single series, while the sixth uses 'compare_' for the comparison tool. The pattern is mostly consistent and predictable, with a minor deviation.

Tool Count5/5

With 6 tools covering core macroeconomic indicators and a comparison function, the set is well-scoped for a data retrieval server focused on Turkish economic data.

Completeness4/5

The tools cover the most commonly requested indicators (exchange rates, inflation, growth, policy rate, trade balance). While some indicators like unemployment are absent, the core set is complete for typical use cases.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

FXMacroData A
io.github.fxmacrodata
Macroeconomic and FX time-series data for AI agents: indicators, calendars, COT, forex, commodities.
Finance Search Research & Data
5023
Market Intel MCP A
io.github.selflabbs
Live & historical FX rates and currency conversion for AI agents. No API keys.
Finance Cryptocurrency
2
Market Intel MCP A
com.datakoot
Live & historical FX rates and currency conversion for AI agents. No API keys.
Finance Open Data
51
Economy Intel MCP A
com.datakoot
Macro data for AI agents: GDP, inflation, unemployment and more (World Bank, US BLS). No keys.
Open Data Government Data Research & Data
51

Related MCP Servers

TCMB MCP
Finance Open Data Government Data
ofurkanuygur
A
license
B
quality
F
maintenance
Provides access to Turkish Central Bank (TCMB) exchange rates with current and historical data since 1996, currency conversion, rate history statistics, and multi-currency comparisons with smart caching.
Updated 10 months ago (2025-11-30 08:05 UTC)
6
1
MIT
publicfinance
Finance Government Data
Leviai-ai
A
license
A
quality
D
maintenance
Enables AI agents to access SEC EDGAR filings, US Treasury rates, BLS labor statistics, and economic indicators without API keys.
Updated 6 months ago (2026-04-02 21:57 UTC)
6
21 npm
MIT
Bitcoin Monetary Data MCP
Finance Cryptocurrency
Team23gm
F
license
Not graded
quality
D
maintenance
Exposes tools for AI agents to access honest economic data, including purchasing power comparisons, M2 vs CPI divergence, Bitcoin vs dollar performance, and current monetary stats.
Updated 3 months ago (2026-06-29 22:39 UTC)
-
turkiye-veri-mcp
Government Data Open Data Research & Data
ahmthamza
A
license
A
quality
B
maintenance
Provides unified access to Turkish official data from TÜİK (statistics via SDMX) and TCMB EVDS (financial series), enabling search, query, and tidy CSV export with full frequency, aggregation, and formula support.
Updated a month ago (2026-08-05 19:34 UTC)
16
1
MIT