Turkish gold-market digest, derived indicators and analysis search. Keyless, read-only, gated.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.3/5 across 4 of 4 tools scored.
Each tool has a clearly distinct purpose: fetch retrieves full articles by ID, gunluk_ozet gives a daily summary, search finds articles, and turev_gostergeler provides computed indicators. No overlap in functionality.
The naming convention is inconsistent: 'fetch' and 'search' are English verbs, while 'gunluk_ozet' and 'turev_gostergeler' are Turkish noun phrases. No uniform pattern is followed.
With 4 tools, the server is well-scoped for a digest service. It covers the essential operations (search, retrieve, summary, indicators) without being too sparse or bloated.
The tool set covers the main workflow (search, fetch, daily summary, derived indicators) but lacks historical data retrieval, trend analysis, or user customization options, which are reasonable omissions for a digest server.
fetchMetalTakip makalesini getirAsearch sonucundaki id ile MetalTakip'in kendi makalesinin tam metnini getirir. Yalnız birinci taraf içerik sunulur.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | search sonucundaki makale id değeri |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| text | Yes | |
| title | Yes | |
| metadata | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a meaningful behavioral trait beyond the annotations: it states that only first-party content is provided ('Yalnız birinci taraf içerik sunulur'). The annotations already declare readOnlyHint=true and openWorldHint=false, so the description enhances transparency by specifying the content scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences. The first sentence clearly states the primary action and its prerequisite, while the second adds an important constraint. No unnecessary words or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one required parameter, clear annotations, and an output schema present, the description is complete. It covers the purpose, usage context (post-search), and a key constraint (first-party only). The presence of an output schema reduces the need to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the 'id' parameter as the article ID from search results (100% coverage). The tool description essentially repeats this information without providing additional meaning or context for the parameter. As per rules, baseline is 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it retrieves the full text of a MetalTakip article using an ID from a previous search result. It also distinguishes from siblings by specifying that it provides first-party content only, contrasting with search which returns IDs and other tools like gunluk_ozet and turev_gostergeler which serve different functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly indicates that the tool should be used with an ID obtained from the search tool ('search sonucundaki id ile'), providing clear usage context. However, it does not explicitly mention when not to use this tool or compare it to alternatives, which prevents a score of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gunluk_ozetGünlük piyasa özetiAMetalTakip içerik motorunun en güncel Türkçe piyasa analizini (başlık, özet, bağlantı) ve kendi türetilmiş piyasa göstergelerini döndürür. Kaynak atıflı, kişiselleştirilmemiş bilgi.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=false. The description adds value by disclosing return content (title, summary, link), source attribution, and non-personalization, which are beyond annotation scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the key action and resource. Every word contributes meaning, with no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no input schema, no output schema, and annotations covering safety, the description provides sufficient context about what is returned and its characteristics. Minor gap: no mention of output format or when to use vs siblings, but adequate overall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema coverage is 100% and no additional parameter meaning is needed. The description does not add param info, but baseline for 0 params is 4, and no contradiction.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the most up-to-date Turkish market analysis (title, summary, link) and derived market indicators from MetalTakip. It uses specific verbs and nouns, making the purpose unambiguous and distinct from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing the latest Turkish market summary with derived indicators, but does not explicitly state when to use this tool over siblings like 'fetch', 'search', or 'turev_gostergeler'. No exclusions or alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchMetalTakip analiz arşivinde aramaAMetalTakip'in kendi yayınladığı Türkçe analiz ve araştırma makalelerinde arama yapar. Yalnız birinci taraf içerik döner; üçüncü taraf haberler kapsam dışıdır.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Arama sorgusu (Türkçe) |
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds value by clarifying the scope (only first-party content). No contradictory information; behavior is transparent for a read-only search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and every sentence is meaningful. No redundancy or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with one parameter and an output schema, the description adequately covers the scope and source. It could mention query language or format, but overall is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'query', which is described in the schema. The tool description does not add any extra meaning or examples beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches in MetalTakip's own Turkish analysis and research articles, with a specific verb and resource. It distinguishes from siblings by specifying it only returns first-party content, not third-party news.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use for searching first-party content only. It implicitly excludes third-party news, but does not explicitly compare with sibling tools like fetch or gunluk_ozet.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
turev_gostergelerTüretilmiş piyasa göstergeleriAMetalTakip tarafından hesaplanan oran ve prim göstergeleri: fiziki altın primi, dijital altın (PAXG) primi, çeyrek altın primi, altın/gümüş ve altın/Bitcoin oranları, resmi aylık fiziki akış serilerinin yıllık değişimleri. Ham üçüncü-taraf verisi içermez.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating safe read operation. The description adds valuable context: data is calculated, not raw third-party, which helps agents understand the nature of the output. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Lists specific indicators efficiently. Perfectly front-loaded with the key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, readOnly annotations, and no output schema, the description provides adequate context by listing the indicators included. It fully informs an agent what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so schema coverage is 100%. According to guidelines, baseline for 0 params is 4. The description does not need to add parameter details, and it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides calculated ratios and premiums (türetilmiş göstergeler) from MetalTakip, listing specific indicators. It distinguishes itself from generic sibling tools (fetch, daily summary, search) by specifying derived data vs raw data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly tells when to use (when derived indicators are needed) and what it excludes ('raw third-party data'), suggesting alternatives for raw data. However, it does not explicitly name alternative tools or provide when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
