finans-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
Most tools have distinct targets, but several quantitative/analytical tools overlap: portfoy_risk_analizi, monte_carlo_simulasyonu, and stres_testi_simulasyonu all compute risk metrics (VaR, CVaR) and could be confused. Similarly, sapma_analizi_raporu and korelasyon_raporu both measure analyst divergence. The descriptions help, but the boundaries are slightly blurry.
Naming Consistency3/5
Tool names are mostly snake_case noun phrases (e.g., kap_son_bildirimler, portfoy_risk_analizi), but rapor_indir follows an object-verb pattern. Prefixes like kap_, spk_, tcmb_, tefas_, openbb_ are applied inconsistently, and no uniform verb_noun or noun_verb structure is maintained across the set.
Tool Count4/5
At 18 tools, the server is on the heavier side but still appropriate for a comprehensive finance domain covering regulatory data, analytics, simulations, and report management. Each tool fills a niche, though a few could potentially be consolidated.
Completeness4/5
The server covers a broad swath of Turkish financial research: KAP disclosures, insider transactions, regulatory compliance, portfolio analytics, macro data, fund analysis, broker consensus, and simulations. Minor gaps exist (e.g., no dedicated tool for financial statement parsing beyond KAP announcements), but the overall surface is robust and cohesive.
Average 3.7/5 across 18 of 18 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 12 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
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

Behavior2/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 of disclosing behavioral traits. It mentions analysis scope but does not state whether the operation is read-only, what data source is used, what the output looks like, or any limitations, leaving the agent without critical context.
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 compact sentence that expands the TEFAS acronym and enumerates the analyzed metrics without filler. It is front-loaded and every word adds value.
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?
The tool is relatively simple with one well-documented parameter and an output schema, so return details need not be explained. However, the description lacks when-to-use context and behavioral caveats, making it adequate but not fully complete for an agent deciding among many sibling analysis tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the single parameter 'fon_kodu' with a default value and examples, achieving 100% schema description coverage. The description adds no additional parameter-level meaning, so the baseline score of 3 is appropriate.
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 performs TEFAS fund price, AUM size, and return analysis, identifying a specific resource and analysis scope. This distinguishes it from sibling tools focused on KAP filings, SPK compliance, and macro indicators, though the verb 'analiz yap' remains slightly generic.
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 given about when to use this tool versus alternatives, no prerequisites are mentioned, and no exclusions or conditions are described. The appropriate context must be inferred entirely from the tool name and the bare description.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that the tool audits and produces a score, but it does not disclose whether it is read-only, whether it uses only the provided JSON, whether any data is stored or sent externally, or what side effects (if any) exist. For an analytic tool, this is sparse.
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 sentence with no fluff or repetition of the tool name. It front-loads the core action and outcome. However, it is so terse that it omits operational details, which is a minor structural weakness, but it remains appropriately compact.
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?
With one parameter, no annotations, and no explanation of the input format, the description is incomplete for an agent to invoke the tool correctly. The output schema exists, but the description still does not cover the decision-history input or how to interpret the calibration score. Sibling tools do not clarify this tool's boundaries.
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?
The only parameter, islem_gecmisi_json, has zero schema description coverage and the description never mentions it. The phrase 'geçmiş yatırım kararları' hints at the intended content, but the expected JSON structure, format, and how the parameter is used to generate the calibration score are completely unexplained.
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 ('denetle' = audit) and names the resource ('geçmiş yatırım kararları' = past investment decisions) and the output ('kalibrasyon skoru' = calibration score). The 'Verdict Matrisi' detail differentiates this tool from sibling tools like sapma_analizi_raporu, making its purpose unambiguous.
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 the tool is for auditing past investment decisions, but it does not explicitly state when to use it versus alternatives, nor does it mention exclusions or compare with related sibling tools such as sapma_analizi_raporu or portfoy_risk_analizi. Usage context is only implied through the purpose statement.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely says 'simulate' without stating whether the operation is read-only, deterministic, how the simulation works, or whether external data is fetched. This is a minimal disclosure for a tool with no annotation support.
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, front-loaded sentence that efficiently states the tool's purpose. No wasted words.
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?
The description names the specific scenarios, which is useful, and an output schema exists to cover return values. However, given the presence of overlapping sibling tools, it could be more complete by clarifying the simulation methodology or that it is specifically a stress test for risk assessment. It is minimally complete but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters clearly described (scenario name and asset:weight pairs). The description adds no additional meaning beyond what the schema already provides, so the baseline 3 is appropriate.
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 simulates a portfolio under four specific crisis scenarios (BIST Crash, Currency Shock, Rate Hike, Stagflation). This specific verb+resource+scenario list distinguishes it from sibling tools like monte_carlo_simulasyonu and markowitz_portfoy_optimizasyonu, which are more general simulation/optimization 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 guidance on when to use this tool versus alternatives. The scenario list implies it is for stress testing under predefined crises, but there is no mention of exclusions, prerequisites, or comparisons to the Monte Carlo simulation or Markowitz optimization tools.
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?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It mentions data sources (OpenBB, yfinance) and the list of outputs, but does not disclose potential rate limits, data freshness/caching behavior, what happens if the symbol is invalid or delisted, or whether the tool performs network calls that might be slow. It also does not state any side effects (none expected for a read-only tool, but that is not explicitly confirmed).
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 concise, with a clear lead sentence followed by a bullet-like list of outputs. It avoids redundancy with the schema. The only minor issue is that it mixes Turkish and English terms (e.g., 'Fiyat/Kazanç (F/K)') but that is not a structural problem. It earns a 4 due to good front-loading and no wasted words.
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 there is an output schema and only one fully documented parameter, the description covers the core functionality. However, it lacks guidance on error handling, data coverage limitations (e.g., global stocks may use yfinance, BIST via OpenBB), and whether the output schema includes all listed metrics. The tool appears to be a straightforward data retrieval, but the description could add a note about the data sources' reliability or the meaning of the metrics. This is a minimal viable description but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'sembol' is fully described in the input schema with examples, achieving 100% coverage. The description's mention of metrics like 'F/K, PD/DD' provides additional context but does not add meaning beyond what the schema already gives for the parameter. The tool name itself is in Turkish, and the description is in Turkish, which is aligned. Baseline 3 is appropriate because the schema is already strong.
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 retrieves fundamental analysis data for BIST and global stocks via OpenBB and yfinance, listing specific metrics (F/K, PD/DD, dividend yield, 52-week range, analyst target prices). It names the resource and verbs ('çek', 'raporlar') but does not explicitly differentiate from sibling tools like 'openbb_makro_gostergeler' or 'konsensus_analiz', though the specific metrics and stock scope provide implicit distinction.
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 implies usage for stock fundamental analysis, and the schema example ('THYAO, GARAN, EREGL, AAPL, NVDA') indicates both BIST and global stocks. However, it does not explicitly state when to prefer this tool over alternatives like 'konsensus_analiz' (which also deals with analyst targets) or mention any exclusions or prerequisites. The context is clear enough for basic selection.
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 must fully disclose behavior. It does mention the simulation count (10,000 random portfolios), which is useful. However, it omits important assumptions—such as how correlations are treated when only volatilities are provided—and does not state whether the computation is deterministic or has 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 only two sentences and is front-loaded with the core purpose. However, it redundantly mentions Markowitz and the 1952 date twice, and 'Nobel Prize-winning' is extra fluff; trimming these would make it perfectly concise.
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?
The description gives a high-level algorithm summary but fails to disclose key model assumptions, such as whether correlations are assumed to be zero given only volatilities are inputs. It also does not warn about equal-length input requirements or non-negative values, which are critical for a financial optimization tool in the absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are already well-documented with defaults and units. The description adds no extra parameter-level meaning, such as constraints on list lengths or valid ranges, so it remains at the baseline.
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 calculates the Markowitz efficient frontier and the maximum Sharpe ratio portfolio via 10,000 random simulations. It names a specific method (Markowitz Modern Portfolio Theory) and a specific output (optimal asset allocation weights), distinguishing it from siblings like portfoy_risk_analizi or monte_carlo_simulasyonu.
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 the tool is suited for Markowitz portfolio optimization, but it gives no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives among the sibling tools, nor does it state any exclusions or prerequisites.
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?
No annotations are provided, so the description alone must disclose behavioral traits. It only states the calculation intent but omits any side effects, data dependencies (e.g., historical prices), or assumptions about input formats beyond the schema. Since it's a calculation, it likely is safe, but the description doesn't confirm that.
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, front-loaded sentence that names the output metrics directly. No filler or redundant text; it earns its place efficiently.
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?
The tool has an output schema and complete parameter documentation, but the description lacks context about the data source (e.g., whether it fetches market data or uses provided time series) and assumptions like the lookback period. These are important for a risk-analysis tool and are not addressed, creating a moderate completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions already cover both parameters fully (risk-free rate and asset:weight CSV), so baseline is 3. The description adds no extra detail about how these parameters influence the computed metrics. It doesn't compensate for any gaps because there are none.
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 uses specific verb 'hesapla' (calculate) and names precise metrics (Sharpe, Sortino, Max Drawdown, HHI). This clearly differentiates it from sibling tools like markowitz_portfoy_optimizasyonu, which focuses on optimization. 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when these risk metrics are needed, but it provides no explicit guidance on when to prefer this tool over alternatives like stres_testi_simulasyonu or monte_carlo_simulasyonu. No exclusions or alternative references are given, so the guidance is limited to inference.
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?
No annotations are provided, so the description must disclose behavioral traits. It only reveals the file storage location, not overwrite behavior, directory creation, error handling on missing reports, or required credentials. This is insufficient for a file-downloading 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 two short sentences, directly stating the action and the storage structure, with zero redundant words. It is well-structured and front-loaded.
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?
Despite having 3 optional parameters and no annotations, the description provides the core functionality and storage convention. However, it lacks edge-case behavior (missing files, overwrites) and does not explain the broader workflow context, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides comprehensive parameter descriptions with defaults and examples, achieving 100% coverage. The description adds the file path template ({tarih}-{kurum}-{tip}.pdf), which is a minor extension. Baseline of 3 is appropriate.
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 a specific action: 'Download current report from brokerage and save to date-based folder', with an explicit storage path pattern. This distinguishes it from sibling analysis tools, making its purpose unambiguous.
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 reports but does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions. Sibling tools like araci_kurum_listesi or konsensus_analiz are not referenced, leaving the usage context 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 burden of behavioral disclosure. It identifies the data source (KAP) and the filtered population (board members and major shareholders), and 'listele' implies a read-only operation. However, it does not mention pagination, ordering, time range, or any limitations, which keeps it at a mid-range score.
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, focused sentence with no filler. It clearly states the action, resource, and source, and the parenthetical '(Insider)' adds useful clarification without extra length.
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, single-optional-parameter list tool, the description is largely sufficient: it states the domain, subject, and action, and the output schema covers return structure. A minor gap is the lack of explicit mention of whether all historical disclosures or only recent ones are returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the single parameter, and the hisse_kodu description includes examples and default behavior. The tool description adds no additional parameter information, so the schema-driven baseline of 3 is appropriate.
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 ('listele') and a clear resource: share buy/sell (Insider) disclosures by board members and major shareholders via KAP. This clearly distinguishes it from the sibling tool kap_son_bildirimler, which covers general KAP notifications.
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 explicit guidance on when to use this tool versus alternatives, no exclusions, and no mention of prerequisites. The intended use case is only implied by the resource type, and there is no differentiation from kap_son_bildirimler or other KAP-related tools.
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?
No annotations are provided, so the description carries the full transparency burden. It only says 'getir' (fetch), implying a read operation, but does not disclose data source characteristics, latency, caching, authentication requirements, or potential for missing data. The OpenBB integration mention adds some context but is insufficient for a complete behavioral profile.
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, efficiently structured with the action verb and a comma-separated list of assets. It is front-loaded with the key information and contains no unnecessary words, making it appropriately concise.
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 zero parameters and the presence of an output schema, the description does not need to explain return values. It lists the specific data categories (USD/TRY, EUR/TRY, BIST100, Altın, Petrol, S&P500) and the integration source (OpenBB). Minor gaps remain, such as data frequency or caveats, but the tool is simple and the description is mostly complete.
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 input schema has zero parameters, so there is no need for parameter documentation. According to the rubric, a tool with 0 parameters receives a baseline of 4. The description does not need to add any parameter semantics because there are none.
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 action ('getir' - fetch) and the specific resources: USD/TRY, EUR/TRY, BIST100, Gold, Oil and S&P500 macro data via OpenBB integration. This distinguishes it from sibling tools like openbb_hisse_analiz and tcmb_evds_gostergeler due to the explicit asset list and integration source.
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. It does not mention any exclusions, prerequisites, or alternative tools. While the asset list implies usage when these macro indicators are needed, there is no explicit differentiation from siblings such as tcmb_evds_gostergeler.
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 exist, so the description carries the burden. It adds useful context by noting output includes original KAP URLs, but lacks explicit statements about read-only nature, pagination, or limitations. 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 two sentences, front-loaded with the primary function and a concise list of notification types. No wasted words; 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?
With 100% schema coverage and an output schema present, the description sufficiently covers the tool's scope. It could be more explicit about filtering behavior, but the schema handles that, making the overall context complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with clear descriptions (limit and hisse_kodu), including defaults and examples. The description adds no additional parameter semantics beyond what the schema already provides, so baseline 3 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 the tool fetches company announcements and notifications from KAP, listing specific types (ÖDA, financial reports, dividends, capital increases) and mentioning original URLs. This distinguishes it from sibling tools like 'kap_insider_islemleri'.
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 when KAP announcements are needed, but it does not explicitly say when to use this tool vs alternatives like 'kap_insider_islemleri'. No exclusions or alternative tool mentions are provided.
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 full disclosure weight. It explicitly reveals the GBM model, the fixed 2,500 simulated paths, and the computed risk metrics. It also notes randomness via 'rastgele fiyat patikası', giving an honest picture of the stochastic behavior without needing to restate schema defaults.
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: a first sentence stating the action, a second providing model provenance, and a third listing outputs. No repetition or filler; the citations are brief and relevant.
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 presence of an output schema covers return-value details. The description defines the model, path count, and metrics, which is sufficient for a parameterized simulation tool. It does not explain edge cases (e.g., zero volatility), but that is beyond typical selection needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-level detail but reinforces the simulation context (e.g., '2,500 random price paths' matches simulasyon_sayisi default). It adds no semantics beyond 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 opens with a specific verb phrase 'Geometric Brownian Motion (GBM) ile Monte Carlo Fiyat Yolu Simülasyonu gerçekleştir' and lists concrete outputs (P5/P50/P95 scenarios, VaR, CVaR), clearly distinguishing this from sibling tools like portfoy_risk_analizi or stres_testi_simulasyonu.
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?
There is no explicit guidance on when to choose this tool over alternatives such as stres_testi_simulasyonu or portfoy_risk_analizi. The description implies usage through 'simulate' and risk metrics but does not state conditions, exclusions, or alternative scenarios.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It names data sources and indicator categories, but it does not explicitly state whether the tool is read-only, fetches live data, has network dependencies, or produces a report artifact. The term 'raporla' is too vague to fully disclose operational behavior.
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, tight sentence that front-loads the data source and lists the exact indicators covered. There is no filler or redundancy, and every word adds meaningful 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?
With zero parameters and an output schema present, the description provides sufficient context by specifying the data sources and the full indicator set. It is concise but complete enough for a no-input reporting tool, though it could slightly benefit from stating the output form (e.g., report generation vs. data retrieval).
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 input schema is empty (0 parameters), so the baseline is 4. The description's indicator list gives context about what the report covers, but there are no parameters that need explanation. This is appropriate for a no-argument tool.
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 imperative verb 'raporla' (report) and specifies the exact resource: TCMB EVDS and TÜİK data, covering defined indicators (Politika Faizi, TÜFE/ÜFE, Rezervler, Kur). This clearly distinguishes it from siblings like openbb_makro_gostergeler, which likely targets a broader macro dataset.
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 reporting Turkish central bank and statistical indicators, but it provides no explicit when-to-use or when-not-to-use guidance, nor does it name alternatives. The indicator list and data sources suggest a context, but the agent gets no direct decision support.
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 statistical method (Pearson correlation, mean deviation percentage), which adds context beyond the tool name. However, it does not mention data sources, whether the operation is read-only, or any side effects. Given the zero-parameter nature, basic transparency 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?
The description is succinct and front-loaded with the primary action. The two rhetorical questions add value without redundancy. Every sentence contributes to understanding the tool's purpose and output.
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 zero-parameter tool with an output schema, the description is reasonably complete. It covers the purpose, methodology, and typical use cases. However, it lacks explicit usage boundaries and alternative tool references, which prevents a perfect score.
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 tool has zero parameters, so the baseline is 4. The description adds meaningful context about what the report contains (correlation and deviation metrics), which is helpful even though there are no parameters to document.
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 computes target price correlation between brokerage houses, using Pearson correlation coefficient and mean deviation percentage. It also provides example questions it answers, which differentiates it from siblings like sapma_analizi_raporu and konsensus_analiz.
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 by describing the questions it addresses ('Which institutions make close estimates? Which deviates?'), but it provides no explicit when-to-use guidance, exclusions, or comparisons to alternative tools. The sibling tools offer related analyses, but no differentiation is made.
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 burden of behavioral disclosure. It states it 'shows' status, implying a non-mutating read operation, but does not explicitly mention whether it requires any setup, permissions, or how data is refreshed. The lack of explicit read-only confirmation is a minor gap, but the nature of a status tool makes it largely self-evident.
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 short sentences with the main purpose front-loaded. Every sentence adds value, and there is no wasted wording or repetition.
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 (0 params) and has an output schema, so the description does not need to detail return values. It explains what data is displayed (dates, counts, directory summary), which is sufficient for a status tool. Slightly more specificity on what 'general status' encompasses would improve completeness, but given the low complexity, it is nearly complete.
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 tool has zero parameters and the schema coverage is 100% (vacuous). Baseline is 4 for zero-param tools. The description adds no parameter information, but there are no parameters to describe, so it fully meets expectations.
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: showing the general status of downloaded reports and data directory. It specifies the exact information shown (dates, counts, directory summary), and this distinguishes it from sibling analysis tools like portfoy_risk_analizi or stres_testi_simulasyonu.
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 checking download status but does not provide explicit guidance on when to use it versus alternatives. No exclusions or alternative tool references are given, making this a reasonable but not fully explicit context.
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 of behavioral disclosure. It discloses the output contents and scope ('all registered'), but does not mention error behavior, performance, authentication needs, or whether the operation is read-only, which is notable for a tool without annotations.
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 two sentences with no filler. The main purpose is front-loaded, and each sentence adds specific, useful detail about what the tool returns.
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?
For a zero-parameter listing tool, the description adequately covers scope and output contents. The presence of an output schema (per context signals) handles structural details, so the description is complete for its complexity.
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 tool has zero parameters, so the schema is trivially complete. The description adds value by enumerating the output data (codes, URLs, tips), providing context beyond the empty 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 lists all registered brokerage firms and research portal resources, and specifies the exact data returned (BIST member codes, research portals, target price URLs, Python library tips). This specific verb+resource combination distinguishes it from sibling analytical tools.
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 the tool should be used when broker or research portal data is needed, but it does not explicitly mention alternatives or when-not-to-use scenarios. It lacks clear exclusions or comparisons with 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?
With no annotations provided, the description carries the full burden. It discloses the output metrics (average/median/high/low, AL/TUT/SAT distribution, consensus score range, standard deviation) and the dependency on previously downloaded reports. This goes beyond basic safety traits and gives useful behavioral context.
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: an imperative first sentence, followed by a clear bullet list of outputs. No filler or redundant phrasing. It front-loads the core purpose immediately.
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 are handled. The description covers the input context (downloaded reports), the optional parameter behavior (via schema), and the main output components. It could mention edge cases like missing reports, but given the output schema and simple input, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the only parameter (hisse_kodu) with a description and example, achieving 100% schema coverage. The tool description adds no parameter-specific nuance beyond the schema, so the baseline of 3 is appropriate.
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 a specific verb and resource: "Tüm aracı kurumların hedef fiyatlarını çapraz karşılaştır ve konsensüs skoru üret" (cross-compare all brokerages' target prices and generate a consensus score). It distinguishes itself from siblings like rapor_indir (which downloads reports) and sapma_analizi_raporu (which analyzes deviations) by focusing on consensus synthesis.
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 by mentioning "İndirilen raporlardaki hedef fiyatları sentezleyerek" (synthesizing target prices from downloaded reports), implying it should be used after downloading reports. However, it does not explicitly state when not to use it or name alternative tools, so it stops short of full guidelines.
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 states the tool 'raporlar' (reports) on legal protection provisions, which suggests a read-only audit, but it does not explicitly confirm that no data is modified or mention any permissions or side effects. It adds useful detail about the legal areas covered, but stops short of full behavioral disclosure.
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 two concise sentences. The first sentence immediately states the purpose, and the second adds essential legal scope. No unnecessary words or repetition, making it efficient for an agent to parse.
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 no parameters and has an output schema, so the description does not need to explain return values. It clearly specifies the legal areas covered, which is sufficient for an agent to decide when to invoke it. Slight gap: it does not clarify what 'the system' refers to or any prerequisites, but given the zero-parameter nature, it is reasonably complete.
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 tool has zero parameters, so the schema coverage is trivially 100%. The baseline for zero-parameter tools is 4, and the description does not need to explain parameters. No additional parameter semantics are required.
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 the specific verb 'denetle' (audit) and clearly identifies the resource: the system's compliance with the Capital Markets Law and SPK Communiqués. It further narrows scope to specific legal areas (Investment Advisory license, Insider Trading, Market Manipulation), making it distinct from sibling tools like kap_son_bildirimler or portfoy_risk_analizi.
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 clearly implies when to use this tool: when a legal compliance audit of the system under Turkish capital markets regulations is needed. It does not explicitly name alternative tools or exclusions, but the legal specificity (Tebliğ III-52.1, Madde 106/107) provides strong contextual guidance for an agent.
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 provided, the description carries the full burden of behavioral disclosure. It transparently explains the analytical approach (Z-score measurement) and the output concept (which brokerage deviates in which stock), making the read-only analytical nature clear. It stops short of describing limitations or prerequisites, but the methodology and purpose are well conveyed.
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 three concise sentences, front-loaded with the primary purpose, then expanding into methodology and use case. Every sentence adds distinct value with no redundancy or filler.
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 zero parameters and the presence of an output schema, the description provides sufficient context. It explains what the tool does, how it does it (Z-score), and when to use it, making it a complete standalone definition for this comparably simple tool.
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 tool has zero parameters, so the input schema is trivially complete and the baseline is 4. The description adds no parameter-specific details because none are needed; it focuses on the analytical result and use case, which is appropriate.
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: 'Konsensüsten en çok sapan analist görüşlerini bul' (find analyst views deviating most from consensus), clearly stating the tool's core function. It further specifies the Z-score methodology and differentiates from the sibling tool 'konsensus_analiz' by focusing on outliers rather than the consensus itself.
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 states the intended use case: 'Kontrarian fırsat tespiti için kullanılır' (used for contrarian opportunity detection). This provides clear contextual guidance, though it does not explicitly name alternatives or exclusions beyond the implicit contrast with consensus analysis.
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:

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

Score Badge

Copy to your README.md:

[![finans-mcp MCP server](https://glama.ai/mcp/servers/tufankoc/finans-mcp/badges/score.svg)](https://glama.ai/mcp/servers/tufankoc/finans-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/tufankoc/finans-mcp'

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