Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Türkiye Vergi MCP 120.000 TL KDV dahil %20 KDV hesapla"
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.
Resmî Gelir İdaresi Başkanlığı (GİB) kaynaklarını kullanan, yerel çalışabilen ve yapılandırılmış sonuç üreten Model Context Protocol sunucusu.
Bu proje şu yetenekleri tek sunucuda toplar:
Kanun, madde, tebliğ, sirküler, özelge, yönetmelik ve karar arama
Resmî belge tam metni ve tarih aralığına göre değişiklik tarama
KDV, KDV tevkifatı, stopaj ve gecikme zammı hesaplama
Canlı GİB vergi takvimi ve isteğe bağlı ICS çıktısı
UBL-TR/e-Fatura XML ile CSV/XLSX fatura denetimi
Resmî kanıt bağlantıları içeren şirket içi vergi sirküleri taslağı
Bu sunucu genel bilgilendirme ve araştırma amaçlıdır. Hukuki görüş veya mali müşavirlik hizmeti vermez. İşleme özgü sonuçlar güncel resmî metin ve yetkili uzman tarafından doğrulanmalıdır.
Gereksinimler: Python 3.11–3.14 ve uv.
uv sync --native-tls --extra dev
uv run vergi-mcpstdio taşıması kullanılır; masaüstü MCP istemcileri için önerilen çalışma
şeklidir. Sunucu standart çıktıya log yazmaz, dolayısıyla JSON-RPC akışı bozulmaz.
Genel bir MCP istemci yapılandırması:
{
"mcpServers": {
"vergi": {
"command": "uv",
"args": [
"--directory",
"C:\\PROJE\\vergiMcp",
"run",
"vergi-mcp"
]
}
}
}Yolu kendi proje klasörünüzle değiştirin. API anahtarı gerekmez.
Related MCP server: e-Fatura MCP Server
Araç | İşlev |
| Sunucu sürümü ve isteğe bağlı canlı GİB erişimi |
| Tüm resmî vergi belge türlerinde arama |
| Konu, kanun ve tarih filtreli özelge arama |
| Arama sonucundaki GİB sayfasını temiz metin olarak alma |
| Tarih aralığındaki yeni düzenlemeleri tarama |
| KDV hariç/dâhil ve isteğe bağlı tevkifat hesabı |
| Brüt/net stopaj ve isteğe bağlı KDV hesabı |
| Yürürlük tarihli resmî oran tablosu |
| Tam ay ve günlük kesirleri dikkate alan hesaplama |
| Canlı beyan/ödeme takvimi ve ICS çıktısı |
| XML, CSV veya XLSX fatura kontrolü |
| Kaynak bağlantılı Markdown sirküler taslağı |
| Kullanılan birincil kaynak kataloğu |
Kaynaklar ayrıca vergi://resmi-kaynaklar,
vergi://oranlar/gecikme-zammi ve vergi://yasal-uyari URI’leriyle sunulur.
Bir MCP istemcisinde doğal dille şunları isteyebilirsiniz:
“KDV tevkifatı konusunda 2026 özelgelerini ara ve kaynaklarını göster.”
“118.000 TL KDV dâhil tutarı %20 KDV ve 7/10 tevkifatla hesapla.”
“1 Ocak–31 Temmuz 2026 arasındaki KDV son tarihlerini ICS olarak getir.”
“Bu UBL-TR XML faturasındaki matematik ve zorunlu alan hatalarını denetle.”
“Son altı aydaki e-Defter düzenlemelerinden yönetim sirküleri taslağı hazırla.”
Üç girdi biçimi desteklenir:
Doğrudan xml_icerigi
Base64 kodlu base64_xml
Yerel .xml, .csv veya .xlsx için dosya_yolu
Yerel dosya okuma varsayılan olarak yalnızca sunucunun başlatıldığı klasörle
sınırlıdır. İzinli kökleri .env içinde noktalı virgülle belirleyebilirsiniz:
VERGI_MCP_ALLOWED_INPUT_DIRS=C:\Faturalar;D:\Kontrol
VERGI_MCP_MAX_INPUT_BYTES=10485760
VERGI_MCP_MAX_INVOICE_ROWS=10000Denetleyici:
DTD/haricî varlık işlemeden güvenli XML ayrıştırır.
UBL 2.1/TR profil alanlarını ve taraf kimliklerini kontrol eder.
Satır, vergi, tevkifat ve ödenecek tutar matematiğini Decimal ile karşılaştırır.
CSV/XLSX sütunlarını Türkçe ve İngilizce yaygın başlıklarla eşler.
VKN/TCKN değerlerini çıktıda maskeleyerek raporlar.
Dosya içeriğini hiçbir dış servise göndermez.
Bu kontrol, GİB’in tam XSD/Schematron doğrulaması veya XMLDSig/XAdES imza doğrulaması değildir. Sonuç modeli bunu açıkça belirtir; “GİB tarafından geçerli” iddiasında bulunmaz. Tam resmî doğrulama için GİB’in güncel UBL-TR 1.2.1 XSD, Schematron/kod listesi ve uygun XPath 2.0 motoru ayrıca kurulmalıdır.
Para hesabında ikili kayan nokta yerine Decimal ve ROUND_HALF_UP kullanılır.
KDV ve stopaj oranları kullanıcı girdisidir; işlem sınıflandırması otomatik hukuki karar olarak verilmez.
Gecikme zammı oranları yürürlük başlangıç/bitiş tarihleriyle
tax_rates.json içinde tutulur.
Gecikme zammı motoru tam ayları, günlük kesirleri, dönem içi oran değişikliklerini, günlük oranın altı ondalığa yukarı tamamlanmasını ve asgari 1 TL kuralını raporlar.
Tecil, iflas, aciz, mücbir sebep ve benzeri özel durumlar standart hesap dışında bırakılır ve sonuçta uyarı olarak gösterilir.
Yerel HTTP endpoint’i çalıştırmak için:
uv run vergi-mcp-httpEndpoint http://127.0.0.1:8000/mcp olur. Kimlik doğrulamasız HTTP taşıması
güvenlik nedeniyle yalnızca loopback adresinde başlatılır. Özellikle mükellef veya
fatura verisi işlenecekse sunucuyu doğrudan internete açmayın. Uzak dağıtım için
OAuth/token doğrulaması, TLS, erişim kaydı ve veri saklama politikası ekleyin.
Tüm değişkenler VERGI_MCP_ önekini kullanır. Örnekler
.env.example dosyasındadır.
Değişken | Varsayılan | Açıklama |
|
| GİB HTTP zaman aşımı |
|
| Salt okunur yanıt önbelleği |
|
| Okunabilecek yerel klasörler |
|
| Azami fatura boyutu |
|
| Azami tablo satırı |
|
| Yerel HTTP bind adresi |
|
| Yerel HTTP portu |
|
| stderr log seviyesi |
uv run pytest
uv run pytest --cov=vergi_mcp --cov-report=term-missing
uv run ruff check .
uv run mypy src
uv run python scripts/live_smoke.py
uv run python scripts/http_smoke.pyTest paketi saf hesaplamaları, XML/tablo ayrıştırmayı, dosya yolu sınırlarını, GİB yanıt normalizasyonunu ve MCP’nin bellek içi araç sözleşmelerini kapsar.
src/vergi_mcp/
├── server.py MCP araç, kaynak ve prompt kayıtları
├── config.py Ortam ayarları ve dosya erişim sınırları
├── clients/gib.py GİB HTTP adaptörü, retry ve önbellek
├── services/mevzuat.py Mevzuat/özelge/değişiklik araması
├── services/calendar.py Canlı vergi takvimi
├── services/calculations.py Decimal tabanlı hesap motorları
├── services/invoice.py UBL-TR ve tablo denetimi
├── services/circular.py Kanıt tabanlı sirküler taslağı
└── data/tax_rates.json Yürürlük tarihli oran verisiİş mantığı MCP dekoratörlerinden ayrıdır; servisler doğrudan test edilebilir. GİB’in ön yüz API’sinin yayımlanmış bir OpenAPI sözleşmesi bulunmadığı için bütün uçlar tek bir değiştirilebilir adaptörde tutulur ve beklenmeyen yanıtlar sessizce yanlış sonuca çevrilmez.
Mevzuat ve takvim her çağrıda GİB’den alınır ve kısa süreli önbelleğe konur. Hesaplama oranları sürümlü yerel veridir. Oran dosyası güncellenirken:
GİB’in resmî oran geçmişini kontrol edin.
Yeni kaydı yürürlük tarihi ve kaynak URL’siyle ekleyin.
Önceki kaydın effective_to tarihini kapatın.
Oran sınır ve geçiş testlerini çalıştırın.
Yerel UBL-TR XML veya tabloyu disariya gondermeden yapisal/matematiksel denetler.
Dosya yolu yalnizca VERGI_MCP_ALLOWED_INPUT_DIRS altinda olabilir. Bu arac
tam GIB XSD/Schematron veya kriptografik imza dogrulamasi yaptigini iddia etmez.
| Name | Required | Description | Default |
|---|---|---|---|
| base64_xml | No | ||
| dosya_yolu | No | ||
| xml_icerigi | No |
| Name | Required | Description |
|---|---|---|
| valid | Yes | |
| source | Yes | |
| summary | Yes | |
| findings | No | |
| disclaimer | No | |
| checks_performed | No | |
| processed_locally | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true (no mutation) and openWorldHint=false. Description adds critical context: data is processed locally ('without sending out') and that this is not full GIB XSD/Schematron or cryptographic verification. This goes 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states functionality, second adds constraints and limitations. Efficient and front-loaded. Minor improvement could be separating parameter guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description explains what the tool does and its limitations. However, with 3 undocumented optional parameters and no output format details, the description leaves gaps about how to invoke the tool correctly. Output schema presence reduces burden, but input usage guidance is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 3 parameters (base64_xml, dosya_yolu, xml_icerigi) with 0% description coverage. Description does not explain the purpose of each parameter, how they differ, or when to use which. Only file path constraint is mentioned. This is severely inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states specific action: structural/mathematical inspection of UBL-TR XML or tabular files (e-Fatura, CSV, XLSX) without sending data out. Clearly distinguishes from sibling tax calculation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. The description only mentions file path constraints, but does not compare with alternatives or explain when to choose this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
6183 kapsamindaki standart gecikme zammini tarihli oranlarla hesaplar.
| Name | Required | Description | Default |
|---|---|---|---|
| ana_para | Yes | ||
| vade_tarihi | Yes | ||
| odeme_tarihi | Yes |
| Name | Required | Description |
|---|---|---|
| ana_para | Yes | |
| donemler | No | |
| uyarilar | No | |
| kaynaklar | No | |
| para_birimi | No | |
| toplam_borc | Yes | |
| vade_tarihi | Yes | |
| varsayimlar | No | |
| yasal_uyari | No | |
| odeme_tarihi | Yes | |
| geciken_gun_sayisi | Yes | |
| asgari_tutar_uygulandi | Yes | |
| hesaplanan_gecikme_zammi | Yes | |
| uygulanacak_gecikme_zammi | Yes | |
| gunluk_hesaplanan_gun_sayisi | Yes | |
| aylik_hesaplanan_donem_sayisi | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only (readOnlyHint=true). The description adds that it uses dated rates, but does not disclose details like rate source, edge cases, or output format. For a read-only calculator, this is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no fluff, directly stating purpose and scope. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 undocumented required parameters and existence of an output schema, the description does not explain prerequisites (e.g., current rates from 'gecikme_zammi_oranlari'), date handling, or what the output contains. It leaves gaps for a functional calculator tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. Parameter names (ana_para, vade_tarihi, odeme_tarihi) are self-explanatory, but the description does not explicitly map them or add meaning beyond name inference. Requirements for date format or currency type are missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it calculates standard delay interest under law 6183 with dated rates. The verb 'hesaplar' (calculates) and resource 'gecikme zammi' (delay interest) are specific. Sibling 'gecikme_zammi_oranlari' lists rates, distinguishing this as the calculation tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for standard delay interest calculation under 6183, but does not explicitly provide when-to-use or when-not-to-use guidance, nor does it mention alternatives like 'gecikme_zammi_oranlari' for rate lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paketlenmis, yururluk tarihli resmi gecikme zammi oran tablosunu dondurur.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| oranlar | Yes | |
| uyarilar | No | |
| kaynaklar | No | |
| para_birimi | No | |
| varsayimlar | No | |
| yasal_uyari | No | |
| kapsama_baslangici | Yes | |
| asgari_gecikme_zammi | Yes | |
| gunluk_hesap_baslangici | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds context about the return format (packaged, with effective dates), providing behavioral insight beyond annotations. However, it does not detail the structure or any limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence in Turkish, front-loaded with the key action and resource. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, existing annotations, and an output schema (though not shown), the description is fully sufficient for a simple retrieval tool. It states what is returned, meeting all contextual needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema trivially covers everything. The description does not need to add parameter details and does not, which is appropriate. Baseline score of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a packaged, effective-dated official delay interest rate table. The verb 'dondurur' (returns) and specific resource differentiate it from sibling tools like 'gecikme_zammi_hesapla' which is computational.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage is for retrieving the rate table, but it does not explicitly mention when to use this tool versus alternatives like 'gecikme_zammi_hesapla' or provide exclusion criteria. Guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
KDV haric/dahil tutari ve verilirse KDV tevkifatini Decimal ile hesaplar.
| Name | Required | Description | Default |
|---|---|---|---|
| tutar | Yes | ||
| kdv_orani | No | 20 | |
| tutar_tipi | No | haric | |
| tevkifat_payi | No | ||
| tevkifat_paydasi | No |
| Name | Required | Description |
|---|---|---|
| matrah | Yes | |
| uyarilar | No | |
| kaynaklar | No | |
| tutar_tipi | Yes | |
| para_birimi | No | |
| varsayimlar | No | |
| yasal_uyari | No | |
| girilen_tutar | Yes | |
| hesaplanan_kdv | Yes | |
| tevkifat_orani | No | |
| kdv_dahil_tutar | Yes | |
| kdv_orani_yuzde | Yes | |
| tevkif_edilen_kdv | Yes | |
| saticiya_odenecek_tutar | Yes | |
| saticinin_tahsil_edecegi_kdv | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions using 'Decimal' for precision, adding behavioral context beyond annotations. Annotations already state readOnlyHint=true, and the description does not contradict this. However, it does not elaborate on other traits like input validation or error cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence (13 words) that immediately conveys the tool's purpose. It is well-structured and front-loaded, but could be slightly more efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters (1 required) and 0% parameter descriptions, the description is insufficient. It does not mention output or provide enough context for correct invocation, despite having an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain individual parameters. While it alludes to 'haric/dahil' and 'tevkifat', it does not detail their meaning or format. The description fails to compensate for the lack of parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'hesaplar' (calculates) and the resource 'KDV haric/dahil tutari ve tevkifat', which distinguishes it from sibling tools even though it doesn't explicitly compare. It is specific and informative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like stopaj_hesapla or gecikme_zammi_hesapla. No usage context or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sunucunun kullandigi resmi birincil kaynaklari ve kapsam notlarini listeler.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is clear. The description adds that it lists 'resources and scope notes' but does not elaborate on whether results are cached, sorted, or filtered. Since the annotations cover the safety profile and the description does not contradict them, a 3 is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's action and subject. There is no fluff, and it is front-loaded with the key verb and object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists (from context signals), the description is nearly complete. It specifies what is listed (resources and scope notes). A slight improvement would be to mention that it is a read-only retrieval, but that is already covered by annotations. Score 4 for being sufficient but not maximally informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (0 params), so the baseline for schema coverage is 4. The description does not need to add parameter information since none exist. It implicitly indicates that the tool requires no arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists official primary resources and scope notes used by the server. The verb 'listeler' and the specific resource type ('resmi birincil kaynaklar ve kapsam notlar') make the purpose unambiguous. Sibling tools are all calculation, tax, or document generation tools, so this tool is easily distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 vs. alternatives. Usage is implied by the name and context (when you need the list of official resources), but there is no guidance on prerequisites, limitations, or when not to use it. Given the simplicity (no parameters), a score of 3 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GIB kanitlarini ekleyen ve uzman inceleme alanlarini isaretleyen Markdown taslagi kurar.
| Name | Required | Description | Default |
|---|---|---|---|
| konu | Yes | ||
| hedef_kitle | No | Sirket yonetimi ve ilgili is birimleri | |
| azami_kaynak | No | ||
| bitis_tarihi | No | ||
| baslangic_tarihi | No |
| Name | Required | Description |
|---|---|---|
| konu | Yes | |
| kanitlar | Yes | |
| uyarilar | No | |
| kaynaklar | Yes | |
| hedef_kitle | Yes | |
| yasal_uyari | No | |
| taslak_markdown | Yes | |
| olusturma_zamani | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description uses 'kurar' (creates), implying mutation, while annotations declare readOnlyHint=true. This is a direct contradiction. The description does not clarify whether the draft is merely generated and returned without 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the tool's purpose. It contains no fluff but could benefit from a bit more structure or parameter hints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While output schema covers return info, the description omits explanations for all 5 parameters, leaving significant gaps for a tool of this complexity. Annotations provide some safety context but do not compensate for missing parameter descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the 5 parameters (e.g., 'konu', 'hedef_kitle', 'azami_kaynak'). Without parameter semantics, the agent cannot correctly use or interpret input values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a Markdown draft with GIB evidence and expert review areas, which distinguishes it from siblings that focus on calculations, listing sources, or auditing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating a circular draft but does not explicitly state when to use it versus alternatives or provide exclusions. Sibling names give context but not explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Kullanici tarafindan verilen oranla brut/net stopaj ve opsiyonel KDV hesaplar.
| Name | Required | Description | Default |
|---|---|---|---|
| tutar | Yes | ||
| kdv_orani | No | ||
| tutar_tipi | No | brut | |
| stopaj_orani | Yes |
| Name | Required | Description |
|---|---|---|
| uyarilar | No | |
| kaynaklar | No | |
| net_tutar | Yes | |
| brut_tutar | Yes | |
| kdv_tutari | Yes | |
| tutar_tipi | Yes | |
| para_birimi | No | |
| varsayimlar | No | |
| yasal_uyari | No | |
| odeme_tutari | Yes | |
| girilen_tutar | Yes | |
| stopaj_tutari | Yes | |
| kdv_orani_yuzde | No | |
| stopaj_orani_yuzde | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, making the tool non-destructive. The description adds that it calculates with user-given rate and handles brut/net and optional VAT. No side effects, auth needs, or rate limits mentioned; but for a calculation tool, this is adequate. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single concise sentence that front-loads the main action. It is not verbose, but could benefit from slight restructuring to include key details without increasing length significantly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has output schema but the description does not mention what is returned (e.g., calculated amounts). It does not state that 'tutar_tipi' defaults to 'brut' or that 'kdv_orani' is optional. For a calculation tool with 4 parameters, this description is too sparse to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions), so the description must compensate. It mentions 'oran' and 'brut/net stopaj' but does not explain 'tutar', 'tutar_tipi' (enum brut/net), 'kdv_orani' (optional), or 'stopaj_orani' beyond the rate. Insufficient for a tool with 4 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'hesaplar' (calculates) and the resource: 'brut/net stopaj ve opsiyonel KDV' (gross/net withholding tax and optional VAT). This is specific and distinguishes it from siblings like 'kdv_hesapla' (only VAT) and 'gecikme_zammi_hesapla' (delay interest).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for stopaj calculation but provides no explicit guidance on when to use this tool versus alternatives like 'kdv_hesapla' for pure VAT or 'gecikme_zammi_hesapla' for delay interest. No exclusions or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GIB'in canli beyan/odeme takvimini filtreler; istenirse ICS metni uretir.
| Name | Required | Description | Default |
|---|---|---|---|
| konu | No | ||
| limit | No | ||
| vergi_turu | No | ||
| ics_olustur | No | ||
| tarih_alani | No | son_tarih | |
| bitis_tarihi | No | ||
| baslangic_tarihi | No |
| Name | Required | Description |
|---|---|---|
| ics | No | |
| stale | No | |
| kaynak | Yes | |
| toplam | Yes | |
| uyarilar | No | |
| etkinlikler | Yes | |
| tarih_alani | Yes | |
| yasal_uyari | No | |
| bitis_tarihi | Yes | |
| alinti_zamani | Yes | |
| baslangic_tarihi | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds that the tool filters and can produce ICS, but does not elaborate on behavior like data freshness, pagination, or error states. With annotations covering core traits, the description adds minimal extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It front-loads the key action (filtering) and adds the optional ICS generation. However, it could be more structured (e.g., separate lines) without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 7 parameters (including enums and date formats) and zero schema coverage, the description is far too brief. The output schema exists, so return values are covered, but the input parameters are completely undocumented, making the tool hard to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, it only mentions 'filters' and 'ICS production' without explaining any of the 7 parameters (konu, limit, vergi_turu, ics_olustur, tarih_alani, bitis_tarihi, baslangic_tarihi). No parameter meaning, format, or usage hints are provided, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: filtering GIB's live declaration/payment calendar and optionally generating ICS text. It uses a specific verb ('filtreler' and 'uretilir') and resource ('canli vergi takvimi'). It is distinguishable from siblings like calculation or listing tools, though no explicit differentiation is made.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its siblings (e.g., kdv_hesapla, stopaj_hesapla). There is no mention of when not to use it or what alternatives exist. The description omits usage context entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0fatura_denetlegecikme_zammi_hesaplagecikme_zammi_oranlarikdv_hesaplaresmi_kaynaklari_listelesirkuler_taslagi_olusturstopaj_hesaplavergi_takvimiEach tool serves a distinct tax-related function: VAT calculation, withholding, late fees (with a separate rate table), tax calendar, invoice validation, circular draft, and source listing. No two tools overlap in purpose.
All tool names follow a consistent Turkish snake_case pattern with descriptive verbs and nouns (e.g., kdv_hesapla, stopaj_hesapla, gecikme_zammi_hesapla). No mixing of conventions.
Eight tools cover the core tax workflows (calculations, calendar, invoice check, circular) without being excessive. The count is well-scoped for the domain.
The tool surface covers major tax operations (VAT, withholding, late fees, calendar, invoice validation) but may lack more specialized calculations (e.g., corporate income tax). Minor gaps exist but core workflows are addressed.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Brazilian AI-powered accounting & tax automation: NFS-e invoicing, CBS/IBS tax reform, compliance.
Open-source AI accounting skills verified by licensed accountants (tax, VAT, payroll).
Sourced Italian tax tools for AI agents: cited primary-source search + a deterministic tax engine.
Validate EU, UK, AU VAT numbers for AI agents. EU ViDA e-invoicing compliance.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/BrkAzmn/vergiMcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
