evds-mcp-server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct economic indicator (exchange rates, growth, inflation, policy rate, trade balance) and the compare_indicators tool explicitly combines two indicators. There is no ambiguity between tools.
Naming Consistency4/5
Five tools use a consistent 'get_' prefix for fetching single series, while the sixth uses 'compare_' for the comparison tool. The pattern is mostly consistent and predictable, with a minor deviation.
Tool Count5/5
With 6 tools covering core macroeconomic indicators and a comparison function, the set is well-scoped for a data retrieval server focused on Turkish economic data.
Completeness4/5
The tools cover the most commonly requested indicators (exchange rates, inflation, growth, policy rate, trade balance). While some indicators like unemployment are absent, the core set is complete for typical use cases.
Average 4.6/5 across 6 of 6 tools scored.
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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and idempotentHint true, consistent with a query tool. The description adds context about the data computation (balance = export - import) and return format, going beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections; each sentence adds necessary information. Slightly verbose but justified given the multilingual context and detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is moderately complex with nested period parameter and return schema. Description covers purpose, when to use, parameter details, and return format. Output schema exists, so return values need not be fully described here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage, so baseline is 3. The description adds value by explaining the 'flow' parameter with examples and detailing the specific series codes used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves Turkey's foreign trade data (export, import, balance) in monthly thousand USD. It distinguishes itself from sibling tools like get_growth or get_inflation, which focus on other economic indicators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes a 'Ne zaman kullanılır' section with example questions, guiding when to use the tool. It does not explicitly list alternatives, but the sibling tools are sufficiently different in purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, idempotent, non-destructive. The description adds useful context: output unit (%), basis (nominal rate), and a caution that AOFM may differ from official 1-week repo rate, noted in a 'not' field.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with clear bulleted sections for usage and parameters. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given annotations and output schema, the description adequately covers return format (unit, basis) and a key behavioral note. Some detail on the output schema structure is omitted but compensated by the output schema presence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions. The description adds extra meaning: monthly frequency provides averages for long-term trends, and explains the period parameter as inclusive date range. This goes beyond schema schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool retrieves TCMB Weighted Average Cost of Funding (AOFM), the closest daily indicator to the policy rate. It distinguishes from sibling tools which cover different economic indicators (fx, inflation, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage scenarios (e.g., queries about TCMB rate on a date, recent trend, long-term trend with monthly frequency) and explains parameter intent. It does not explicitly state when not to use, but siblings are distinct domains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds value by warning against confusing 'yoy' and 'level' modes, noting the basis field, and mentioning that TÜFE and core use a new 2025=100 index series. This goes beyond annotations in explaining how to interpret results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections, bullet points, and a clear hierarchy. It is front-loaded with the purpose, followed by usage, parameters, return schema, and an important note. Every sentence adds value without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, nested period, enums) and the presence of an output schema, the description covers all critical aspects: purpose, parameter usage, return format with unit/basis, and a behavioral caveat. It is sufficiently complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, baseline is 3. The description significantly adds meaning by providing usage examples for 'change', explaining return values (unit, basis) based on change selection, and noting the base year for measures. This goes beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves Turkish inflation data (TÜFE, Yİ-ÜFE, or core) on a monthly basis. The verb 'get' and resource 'inflation' are specific, and the title explicitly lists the measures, distinguishing it from sibling tools that deal with other economic indicators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage scenarios under 'Ne zaman kullanılır:' with examples (e.g., '2023 annual inflation' → change='yoy'). It differentiates between change types but does not compare against sibling tools; however, siblings are for different indicators, so the guidance is clear for parameter choices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds valuable context: weekend/holiday null values, data absence handling via note field, and return structure summary. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (purpose, when to use, parameters, return). Front-loaded key info. No unnecessary words; every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters (including nested period), output schema exists, and context signals high complexity. Covers return format, unit, basis, and edge cases (holidays null). Completely equips an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with full descriptions for all parameters. Description goes beyond by explaining side meanings (alis/satis) and providing usage examples in context. Adds value without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states it returns daily FX rates from TCMB, with resource (currency pairs) and verb (döndürür). Distinguishes from sibling compare_indicators by specifying it provides rate levels (TL) vs percentage changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly states when to use (rate levels for currencies) and when not (percentage changes should use compare_indicators or compute from observations). Provides explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent, non-destructive), the description details output structure, conditions for the 'real' transform (a must be inflation measure), and what happens when date frequencies mismatch. It explicitly warns about nominal/reel separation and basis field.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for purpose, usage, parameters, output, and notes. It is somewhat lengthy but every section adds value. The core function is front-loaded in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two indicators, nested objects, optional transform, output schema), the description covers all necessary aspects: purpose, when to use, parameter constraints, output fields (including derived and basis), and important behavioral notes. It is complete and self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions for all parameters. The description adds extra value by providing examples of indicator combinations, constraints (a must be inflation for 'real'), and explaining the meaning of transform values. This enhances parameter understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compares two curated indicators over the same period and optionally adjusts for inflation. It distinguishes from sibling tools (get_fx, get_growth, etc.) which retrieve single indicators. The title also reinforces the nominal/real focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
A dedicated 'Ne zaman kullanılır' section provides explicit usage examples (e.g., 'Dolar reel olarak arttı mı') and warns against incorrect parameter combinations (e.g., for real faiz, a='tufe', b='policy_rate' is not correct). This guides when to use the tool vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark as readOnly, idempotent, non-destructive. Description adds context on return format (unit and metric depending on basis) and the specific series code, going beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear headings and bullet points. Every sentence adds value; no redundant information. Front-loaded with purpose and usage, then parameter details, then return format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists (not shown but present), description still provides necessary context: query types, parameter choices, return units, and series identifier. Complete for a tool with 2 parameters and sibling differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so baseline is 3. Description adds practical guidance on when to use each basis value and explains the meaning of period and the return unit, improving parameter understanding beyond schema descriptions alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Türkiye ekonomik büyümesi (GSYİH, çeyreklik)' indicating it retrieves quarterly GDP growth for Turkey. Distinguishes from siblings (e.g., get_inflation, get_fx) which handle different indicators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit section 'Ne zaman kullanılır' with examples mapping queries to parameter values (basis='yoy' for annual growth, basis='level' for index level). Provides clear when-to-use guidance with no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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:

[![evds-mcp-server MCP server](https://glama.ai/mcp/servers/denizcakiroglu322/evds-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/denizcakiroglu322/evds-mcp-server)

Score Badge

Copy to your README.md:

[![evds-mcp-server MCP server](https://glama.ai/mcp/servers/denizcakiroglu322/evds-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/denizcakiroglu322/evds-mcp-server)

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/denizcakiroglu322/evds-mcp-server'

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