Türkiye Vergi MCP

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each 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.
Naming Consistency5/5
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.
Tool Count5/5
Eight tools cover the core tax workflows (calculations, calendar, invoice check, circular) without being excessive. The count is well-scoped for the domain.
Completeness4/5
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.
Average 3.4/5 across 8 of 8 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must 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.
Purpose4/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus 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.
Behavior1/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists (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.
Parameters4/5
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.
Purpose5/5
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.
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 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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![vergiMcp MCP server](https://glama.ai/mcp/servers/BrkAzmn/vergiMcp/badges/card.svg)](https://glama.ai/mcp/servers/BrkAzmn/vergiMcp)

Score Badge

Copy to your README.md:

[![vergiMcp MCP server](https://glama.ai/mcp/servers/BrkAzmn/vergiMcp/badges/score.svg)](https://glama.ai/mcp/servers/BrkAzmn/vergiMcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/BrkAzmn/vergiMcp'

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