turkiye-veri-mcp

Server Quality Checklist

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

Latest release: v0.16.0
Disambiguation4/5
The tools are mostly distinct, with clear separation between TUIK and EVDS domains. The main potential confusion is between get_data and download_data variants, but descriptions clarify preview vs. file output. Some similar names like tuik_get_data vs. tuik_get_table_data could cause misselection, but the underlying resources differ (SDMX vs. istab).
Naming Consistency4/5
TUIK tools follow a consistent verb_noun pattern (list_*, search_*, describe_*, get_*, download_*). EVDS tools mix noun-only names (categories, datagroups) with verb_noun names (search_series, get_data, download_data), and 'series_list' is a noun phrase. This is a minor inconsistency that does not severely hinder readability.
Tool Count4/5
With 16 tools, the server is slightly above the typical 3-15 range, but the breadth of functionality for two distinct national statistical data sources justifies the count. Each tool serves a specific purpose, and none are redundant, though a few could arguably be consolidated.
Completeness5/5
The server delivers end-to-end coverage for both TUIK and EVDS: discovery (categories/themes/datagroups), search, metadata (dataflow description), and multiple retrieval formats (preview, CSV download, raw files). No major operations are missing for a read-only statistical data access server.
Average 4.2/5 across 16 of 16 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 19 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden. It discloses the scope (main categories) and gives examples, but does not mention any additional behaviors like pagination, language handling nuances, or read-only assurance. For a simple listing tool, this is adequate 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?
The description is concise, front-loaded with the main action, uses examples to clarify scope, and includes the parameter explanation in two brief lines. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and an output schema. The description explains purpose and parameter semantics. The examples and scope are sufficient for an agent to correctly invoke it, though it does not mention any limitations or edge cases.
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?
The schema lacks descriptions (0% coverage). The description compensates by explicitly stating 'lang: 'TR' or 'ENG'', providing allowed values that are not in the schema. This adds significant meaning beyond the schema.
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 it lists TCMB EVDS main categories, with specific examples (exchange rates, interest rates, inflation). This is a specific verb+resource+scope. However, it does not explicitly distinguish it from sibling tools like evds_datagroups, though the term 'main categories' gives implicit differentiation.
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 usage is implied: the tool is for listing main EVDS categories. There is no explicit mention of when to use this vs. alternatives such as evds_datagroups, nor any exclusions. The example categories give some context, but no direct guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the file type and source, but does not mention important behaviors such as overwrite semantics for output_path, file size limits, or authentication/authorization requirements. For a download tool, this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a compact argument list. Every sentence earns its place, and the structure is front-loaded with the core purpose.
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?
For a simple download tool, the description covers the essential context: what is downloaded, where the url comes from, and where the file will be saved. Minor gaps like directory creation, overwriting, and error handling are not addressed, but an output schema exists to cover return values.
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?
The description adds clear meaning to both parameters: url is defined as the url field of an istab row from specific tools, and output_path includes a file extension example. Since the schema has zero coverage, this is essential value beyond the schema.
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 'Download an istab table file (usually Excel) from the TUIK portal' with a specific verb and resource. It is unambiguous even without referencing sibling tools, but it does not explicitly differentiate from other download-related siblings like tuik_download_data.
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 a prerequisite by mentioning the url comes from tuik_list_tables/tuik_search_tables, but it gives no guidance on when to choose this tool over alternatives or when not to use it. There are no explicit exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It discloses that the tool writes a 'tidy CSV file' and accepts an output_path, but omits important safety/behavioral details such as whether existing files are overwritten, whether directories are created, or any error/rate-limit behaviors. This is a significant gap for a file-writing mutation tool.
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 front-loaded with the main purpose and then lists parameters in a clear Args block. Each line is concise and directly useful. The 'Same parameters as evds_get_data' line is slightly redundant with the subsequent parameter list, but it serves as a cross-reference and aids navigation. Overall it is well-structured and not wordy.
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?
Given the tool's complexity (7 parameters, file output), the description covers the core functionality and parameter meanings. An output schema exists, so return values do not need to be explained. However, it lacks details about file overwrite semantics, directory creation, or CSV formatting specifics, which could impact real-world usage. The 'Same parameters as evds_get_data' hint is useful but not fully integrated.
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 description coverage is 0%, so the description's Args list is the only source of parameter meaning. It provides brief but adequate semantics for each parameter, including default for end and allowed values for frequency, aggregation, and formula. This compensates well for the schema gap, though some formats (like start date) are not exhaustively detailed.
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 uses a specific verb and resource: 'Fetch EVDS series and write them as a tidy CSV file (for analysis pipelines).' It clearly distinguishes from siblings like evds_get_data by emphasizing the file-writing output. This makes the tool's core function immediately obvious.
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 phrase 'for analysis pipelines' gives clear context for when to use this tool, and 'Same parameters as evds_get_data' implies it's an alternative to evds_get_data for output-to-file scenarios. However, it does not explicitly state when not to use it or name alternatives beyond evds_get_data, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the behavior of fetching all dimensions, full time span unless narrowed, and the max_rows preview limit. However, it doesn't mention side effects, authorization requirements, or data volume implications, leaving some gaps for a read tool. A 3 is appropriate.
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 efficient, with a clear opening sentence and a structured Args section that is necessary due to the schema's lack of descriptions. It is front-loaded and not verbose, though the Args section adds a bit of length, so a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values need not be explained. The description covers purpose, parameters, and preview behavior, but lacks explicit usage guidelines and some behavioral details. Given the simplicity of a fetch-with-preview tool, it's adequate but not comprehensive, so a 4.
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?
The input schema has no descriptions (0% coverage). The description compensates fully by explaining each parameter with examples ('TR,DF_ADNKS_T26,1.0', 'TR..2021'), providing meaning for dataflow_id, key, start, end, and max_rows. This adds significant value, earning a 5.
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 fetches observations from a TUIK SDMX dataflow and previews them in chat, specifying the resource and action. It doesn't explicitly differentiate from sibling tools like tuik_get_table_data or tuik_download_data, but the verb 'fetch' and 'preview' suggest a read operation, earning a 4.
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 previewing data with a default row limit and full time span, but does not explicitly state when to prefer this over alternatives like tuik_download_data or tuik_get_table_data. It provides context ('preview in chat') but lacks explicit exclusions or alternative mentions, so a 3.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It discloses a read-only behavior via 'list' and that the lang parameter affects the language of names, but it does not mention ordering, error conditions, or pagination. For a simple listing, this is minimally adequate 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?
The description is extremely concise and front-loaded, with two sentences dedicated to purpose and parameter semantics. It avoids unnecessary detail while effectively conveying the necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and the presence of an output schema, the description is largely complete. It lacks usage guidance and explicit behavioral details, but these are less critical for a straightforward listing operation. The description covers the essential purpose and the only parameter.
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?
The schema provides no description coverage, but the description explains the lang parameter values ('tr' for Turkish, 'en' for English). This adds meaning beyond the schema, which only shows a default of 'tr'. The single parameter is well documented in the description.
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 lists TUIK statistical themes (top-level categories) with their ids. The verb 'list' and resource 'themes' are specific, and it distinguishes itself from siblings like tuik_list_tables and evds_categories. The clarification 'top-level categories' adds useful scope.
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 alternatives such as tuik_list_tables or evds_categories. It does not mention prerequisites, follow-on calls, or any context that would help an agent decide between them. The only usage hint is the lang parameter, which is parameter semantics.
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?
With no annotations, the description carries the full burden. It does disclose important behaviors: case-insensitive substring matching and all-theme scope. But it omits additional context such as behavior with no matches, pagination, or whether results are summaries, which would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately short, front-loaded with the purpose, and uses a compact Args section. Every sentence contributes either scope, an example, or a parameter detail, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter search tool with an output schema available, the description covers purpose, parameter semantics, and behavioral scope. It lacks explicit alternative differentiation but remains complete enough for correct invocation.
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?
Although schema description coverage is 0%, the description compensates well by explaining 'query' with concrete Turkish examples ('işgücü', 'tüketici fiyat') and clarifying that 'lang' accepts 'tr' or 'en'. This adds functional meaning beyond the bare 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 opens with a specific verb ('Search'), identifies the resource ('TUIK table names'), and adds scope ('across all themes') plus a key behavior ('case-insensitive substring'). This clearly differentiates it from sibling tools like 'tuik_list_tables'.
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 use case is implied: use this tool to find tables by substring search across themes. However, there is no explicit guidance on when to prefer this over alternatives, no when-not-to-use advice, and no reference to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses meaningful behavior: date defaults (end defaults to start), frequency and formula numeric codes, preview row counts, and aggregation semantics. Missing are authentication/network requirements and error behavior, but the core side effects and preview behavior are covered.
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 front-loaded with a one-sentence summary, then uses a compact Args block. Each parameter line is dense with useful details and no filler. For seven parameters, the length is justified and well structured.
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's complexity (7 parameters, transformations, aggregation), the description is quite complete: it covers every parameter, provides examples, and states preview behavior. An output schema exists, so not detailing the return payload is acceptable. It lacks a bit of clarity about how 'preview' relates to full data access, and it doesn't mention authentication requirements.
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?
Schema description coverage is 0%, but the description thoroughly compensates by explaining all seven parameters with formats, examples, default values, and enumerated options (e.g., frequency codes 1–8, formula codes 0–8, aggregation choices). This goes well beyond the bare input 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 opens with 'Fetch one or more EVDS series', a specific verb+resource combination, and 'with full API features and preview in chat' clarifies its role as a data-retrieval tool. This distinguishes it from sibling tools like evds_series_list or evds_categories, which handle metadata/listing rather than actual series values.
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 guidance is provided about when to use this tool versus alternatives; sibling tools such as evds_search_series or evds_get_datagroup_data are not mentioned. The parameter details imply usage for fetching and transforming series data, but there are no when-not-to-use conditions or alternative recommendations.
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?
With no annotations, the description carries the transparency burden. It discloses that the tool writes a CSV file to a specified output path, which is a side effect. However, it does not mention potential overwriting, required permissions, network access, or error behavior—context that would be valuable for a download/write tool.
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 compact and well-structured: a single purpose sentence followed by a concise args list. It contains no filler, and every line adds useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a moderate complexity of 5 parameters (2 required), and all are documented with examples. An output schema exists, so return values are likely self-explanatory. The description lacks explicit usage alternatives but covers the essentials for invoking 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?
The schema provides zero descriptions, but the description fully compensates by explaining each parameter with concrete examples, including the three-part dataflow_id format, output_path example, key syntax, and start/end period semantics. This adds substantial meaning beyond the raw 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 downloads a full TUIK SDMX dataset and writes it as a tidy CSV file. This is a specific verb+resource+output, and it distinguishes itself from sibling tools like tuik_get_data by emphasizing 'full' dataset download and CSV output.
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 downloading full datasets to CSV files via the argument explanations, but it does not explicitly state when to use this tool versus alternatives or offer exclusions. No sibling tool is referenced, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It discloses that the tool lists all series and returns codes and start dates, which gives some behavioral insight. However, it does not mention pagination, rate limits, or any side effects (though 'List' implies read-only). This is adequate 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?
The description is concise, front-loaded with the main action, and includes a clear argument list without unnecessary fluff. Every sentence earns its place.
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?
For a simple listing tool, the description covers the essential purpose and arguments. An output schema exists, so return values are already documented externally. The missing pieces are minor caveats (e.g., pagination, sorting), but overall it is complete enough for proper selection and invocation.
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?
The schema descriptions coverage is 0%, so the description must compensate. It defines datagroup_code as 'Datagroup code from evds_datagroups (e.g. 'bie_dkdovytl')' and lang as ''TR' or 'ENG''. This adds meaningful context beyond the bare schema, though it could include more detail about expected formats or defaults.
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 uses a specific verb ('List') and clearly states the resource ('all series in an EVDS datagroup') and the output ('with codes and start dates'). It distinguishes itself from siblings like evds_search_series by emphasizing 'all series' in a datagroup.
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 gives clear context for when to use the tool: to list series in a datagroup. It also notes that the datagroup_code comes from evds_datagroups, implying a prerequisite. However, it does not explicitly mention alternatives or exclusions, so it falls short of a 5.
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 discloses a key behavioral trait—that listing everything returns truncated results—which is not captured in annotations (none provided). However, it does not explain the output structure (left to the output schema) or mention potential errors, rate limits, or other behavioral details. The 'truncated' warning is valuable but limited.
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, front-loaded with the main purpose, followed by usage guidance and parameter details. Every sentence earns its place, and the structural separation (intro, usage patterns, args) improves readability without fluff.
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 presence of an output schema, the description need not explain return values. It covers all three optional parameters, their combinations, and the truncation caveat. The only minor gap is ambiguity when both category_id and query are provided simultaneously, but this is an edge case not critical for basic usage.
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 0% schema description coverage, the description compensates fully by documenting each parameter in an 'Args' section: category_id (a category id from evds_categories), query (substring to search), and lang (TR/ENG). It also explains their roles in the overall usage patterns, providing clear meaning beyond the raw 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's function: 'List or search EVDS datagroups (thematic bundles of series).' This specifies both the action and the resource, distinguishing it from sibling tools like evds_categories (categories) and evds_series_list (series).
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 specific usage patterns for each parameter combination: 'Provide category_id to list one category's datagroups, query to search all datagroup names, or neither to list everything (truncated).' This gives clear context on when to use the tool, though it does not explicitly mention alternatives or exclusions.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions 'Layouts vary, so check tidy_confidence' and output columns, but it does not clearly explain what the tool returns in terms of preview vs. full data. The max_rows argument is described as 'Rows to include in the preview,' implying the result might be a preview, but the top of the description says 'Download... and convert,' leaving ambiguity about whether the full table is returned or only a preview. tidy_confidence is also not defined.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It opens with a one-sentence purpose, briefly covers layout handling, points to the alternative raw-file tool, and then lists Args. Every sentence serves a purpose with no filler or 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?
The description covers the core behavior, layout handling, and the alternative tool. It also mentions output columns and tidy_confidence. However, given the complexity of TUIK layouts and the existence of an output schema, the description could clarify whether the result is a preview or full table, and what tidy_confidence represents. It lacks some completeness but is still reasonably thorough.
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?
Schema description coverage is 0%, so the description must compensate. It does so by providing meaningful arg descriptions for all three parameters: url is the field from an istab row, output_path is an optional CSV path, and max_rows controls preview size. This adds significant value beyond the bare type information in the 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's purpose with a specific verb and resource: 'Download an istab Excel table and convert it to tidy long format.' It also distinguishes itself from the sibling tool tuik_download_table_file by noting that it returns a tidy transformation instead of the raw file.
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?
The description explicitly tells when to use this tool: to get a tidy long format of TUIK istab tables, and when to use the alternative: 'tuik_download_table_file always gets you the raw file instead.' It also mentions checking tidy_confidence due to layout variability, and references the source of the url parameter from tuik_list_tables/tuik_search_tables.
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?
Without annotations, the description carries full responsibility for behavioral disclosure. It honestly explains the auto-chunking and stitching behavior to avoid truncation, and also notes defaults such as 'end' defaulting to 'start' and 'max_rows' for preview. This goes beyond the schema, which provides no descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence summary, a context sentence about mirroring the website action, and a clean Args list. Every sentence adds value, and the tone is informative without 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 complexity (8 parameters, 0% schema coverage, no annotations), the description covers all essential aspects: purpose, parameter semantics, auto-chunking behavior, and defaults. It also implies output (full table or preview) and CSV writing via output_path, and the output schema handles return details.
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?
The schema has 0% description coverage, but the Args section fully compensates by explaining each parameter: datagroup_code with example, start with format options, output_path purpose, end default, frequency allowed values, aggregation enumerated, formula allowed range, and max_rows purpose. This is exemplary parameter documentation.
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 opens with a specific verb+resource statement: 'Fetch every series in an EVDS datagroup at once (auto-chunked).' It further clarifies by likening it to the website's 'download the whole datagroup' action, clearly distinguishing it from siblings like evds_get_data or evds_download_data that target specific series or files.
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 clear context on when to use this tool: when you need every series in a datagroup, especially large ones or long spans. It does not explicitly state when not to use it or name alternatives, but the 'at once' phrasing and sibling names imply it is for bulk retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that 'database' is a legacy MEDAS/Biruni link-only resource and that output entries are either dataflow or istab types. This adds meaningful behavioral context beyond a simple 'list' verb, though it does not cover potential API limitations or pagination.
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 compact and front-loaded. The first sentence states the core purpose and downstream usage, followed by concise argument details. No filler or redundancy; every sentence adds value.
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 moderate complexity and that an output schema exists, the description is complete. It explains the three resource types, the source of theme_id, valid languages, and how returned identifiers should be used, leaving no ambiguity for the agent.
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?
The schema provides 0% description coverage and no enums, but the description fully compensates: theme_id is sourced from tuik_list_themes with an example, lang is constrained to 'tr' or 'en', and resource_type enumerates all allowed values with caveats. This is exactly the semantic detail needed for correct invocation.
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 states a specific action ('List tables under a TUIK theme') and identifies the resource (tables grouped by theme). It also distinguishes itself from siblings by clarifying that it lists dataflow entries and istab file downloads, while tuik_search_tables and tuik_list_themes serve different purposes.
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 explains how to use the results: dataflow_id feeds into tuik_get_data/tuik_download_data, and url into tuik_download_table_file. It also clarifies the legacy 'database' resource type. However, it does not explicitly state when to prefer this tool over alternatives like tuik_search_tables, though the theme-based listing context implies it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so excellently. It discloses key behavioral traits: the counting unit (tool calls, not sessions/people), the multi-line logging per session, the reset behavior on redeploy, and the limitation as a rough activity signal. This is exactly the kind of context an agent needs to interpret results correctly.
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 efficiently structured: it leads with the primary purpose, then adds essential behavioral caveats, then documents the argument. Every sentence contributes meaningful information—no fluff or redundancy—and the Args section is clean and minimal.
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?
This simple 1-parameter tool is fully covered: purpose, counting semantics, reset limitations, and parameter meaning are all explained. The presence of an output schema means return-value documentation isn't the description's job. Nothing relevant is missing for an agent to invoke and interpret this tool 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?
The schema only provides the parameter type, title, and default for 'days_recent' with no description. The tool description adds semantic meaning by explaining it is the 'Size of the recent window in days', which clarifies that it defines a lookback period rather than a specific date. This goes beyond the raw 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 opens with a specific verb and resource ('Show how much this MCP server has been used'), clearly stating the tool's function. This is distinct from the sibling data-retrieval tools, which fetch external datasets, so the purpose is unambiguous.
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?
Provides meaningful usage context: it explains that the tool counts tool calls rather than people, warns about resets on redeploy, and positions the local counter as a substitute for unavailable per-connector usage. This gives the agent clear situational framing, though it doesn't explicitly contrast with an alternative tool (none exists).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and excels. It discloses the lack of server-side search, the index-building process, caching, automatic weekly rebuild, AND logic for multiple words, and the refresh parameter's effect. This is rich behavioral detail beyond typical descriptions.
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: a one-line purpose, a brief behavioral note, and a clear Args list. Every sentence adds value, and the formatting is scannable. It is appropriately sized for the complexity of the tool.
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 output schema exists and the parameter semantics are fully covered, the description is complete. It addresses the tool's unique cost, caching, and refresh behavior, making the tool predictable and usable without further research.
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?
The input schema has 0% description coverage, so the description must compensate fully. It explains every parameter: query with examples, language values, limit with default, and refresh with its automatic weekly behavior. This fully bridges the semantic gap.
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 opens with 'Search EVDS series by name across every datagroup', which uses a specific verb (search), identifies the resource (EVDS series), and clarifies scope (across every datagroup). This clearly distinguishes it from sibling tools like evds_series_list that likely operate within a single datagroup.
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 clear context on when to use the tool: it searches across all datagroups and notes the cost of the first call. However, it does not explicitly state when not to use it or name alternative tools for specific cases, stopping short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It discloses the key template semantics, position order, empty-slot meaning, and language parameter. However, it does not explicitly state that this is a read-only metadata operation or whether any API call/network access occurs, which would make it fully transparent.
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 front-loaded with the core purpose, followed by usage context and argument details. Every sentence contributes value, and the structure is easy to scan. It avoids redundancy and is appropriately concise for the information provided.
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?
The tool is simple (2 parameters, 1 required) and has an output schema, so the description does not need to explain return values. It covers the tool's role in the workflow, key syntax, parameter formats, and typical usage. This is complete for both selection and invocation.
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?
Schema coverage is 0%, so the description must compensate. It fully describes both parameters: dataflow_id is defined as a 'Three-part SDMX id' with a concrete example, and lang is described as 'Label language for codelists' with allowed values 'tr' or 'en'. This adds substantial meaning beyond the bare 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's purpose with a specific verb and resource: 'Describe a TUIK SDMX dataflow: dimensions, codelists, key template.' This distinguishes it from sibling data-fetching tools like tuik_get_data and tuik_download_data by focusing on metadata exploration.
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 guidance is given: 'Use before tuik_get_data when a dataflow refuses key='ALL' or to build a narrower key.' This tells the agent exactly when to invoke this tool and why, and the example key format illustrates how it connects to subsequent data retrieval.
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:

[![turkiye-veri-mcp MCP server](https://glama.ai/mcp/servers/ahmthamza/turkiye-veri-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ahmthamza/turkiye-veri-mcp)

Score Badge

Copy to your README.md:

[![turkiye-veri-mcp MCP server](https://glama.ai/mcp/servers/ahmthamza/turkiye-veri-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ahmthamza/turkiye-veri-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ahmthamza/turkiye-veri-mcp'

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