Fetches news from RSS feeds of Turkish news sources, enabling retrieval and analysis of current events.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-news-server Summarize today's top stories"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Türkçe haber kaynaklarından haber çeken, özetleyen ve analiz eden MCP (Model Context Protocol) tabanlı sunucu.
Haber Çekme: BBC Türkçe, Ensonhaber, Milliyet ve BloombergHT gibi Türkçe haber kaynaklarından RSS ile haber toplama
Haber Özetleme: NLP tabanlı otomatik metin özetleme ve anahtar kelime çıkarma
Duygu Analizi: Haberlerin duygusal tonunu analiz etme (pozitif/negatif/nötr)
Tekrar Tespiti: Benzer veya tekrarlayan haberleri tespit etme
Trend Analizi: Günün/haftanın en çok konuşulan konularını belirleme
Web Arayüzü: REST API ve kullanıcı dostu web arayüzü
Related MCP server: Abhi-Nexus MCP Server
# Bağımlılıkları yükle
npm install
# Geliştirme modunda çalıştır
npm run dev
# Web sunucusunu çalıştır
npm run dev:web
# Derleme
npm run build
# Derlenmiş sürümü çalıştır
npm start.env dosyası oluşturarak aşağıdaki değişkenleri tanımlayabilirsiniz:
# MCP Sunucu Ayarları
MCP_SERVER_NAME=mcp-news-server
MCP_SERVER_VERSION=0.1.0
# RSS Kaynakları (virgülle ayrılmış)
RSS_FEEDS=https://feeds.bbci.co.uk/turkce/rss.xml,https://www.ensonhaber.com/rss/ensonhaber.xml
# Cache Ayarları
CACHE_TTL=3600
CACHE_CHECK_PERIOD=600
# Web Sunucu Portu
PORT=3000cd MCP-News-Server
npm install
npm run buildWindows:
%APPDATA%\Claude\claude_desktop_config.jsonclaude_desktop_config.json dosyasına şunu ekle:
{
"mcpServers": {
"news-server": {
"command": "node",
"args": ["C:\\Users\\Gamze Sirin\\Desktop\\MCP-News-Server\\dist\\index.js"],
"env": {
"MCP_SERVER_NAME": "news-summarizer",
"RSS_FEEDS": "https://feeds.bbci.co.uk/turkce/rss.xml,https://www.ensonhaber.com/rss/ensonhaber.xml,https://www.milliyet.com.tr/rss/rssnew/dunyarss.xml,https://www.bloomberght.com/rss"
}
}
}
}Uygulamayı tamamen kapat ve tekrar aç.
Claude Desktop'ta şu komutları kullanabilirsin:
"Güncel haberleri getir"
"Bu metni özetle: ..."
"Haberlerdeki trendleri analiz et"
"Spor haberlerini ara"
RSS kaynaklarından güncel haberleri çeker.
source: Haber kaynağı URL'si (opsiyonel)
category: Kategori filtresi (opsiyonel)
keyword: Arama kelimesi (opsiyonel)
limit: Maksimum haber sayısı (varsayılan: 10)
Haber metnini özetler.
text: Özetlenecek metin
newsId: Daha önce çekilen haberin ID'si
sentenceCount: Özetteki cümle sayısı (varsayılan: 3)
extractKeywords: Anahtar kelimeleri çıkar (varsayılan: true)
Haberin tam içeriğini web sayfasından çeker.
url: Haber URL'si
newsId: Haberin ID'si
Haberlerdeki trendleri ve en çok kullanılan kelimeleri analiz eder.
hours: Son kaç saatteki haberler (varsayılan: 24)
topWords: En çok kullanılan kelime sayısı (varsayılan: 10)
Haber metninin duygusal tonunu analiz eder.
text: Analiz edilecek metin
newsId: Haberin ID'si
Birden fazla haberin duygusal tonunu toplu analiz eder.
category: Kategori filtresi (opsiyonel)
limit: Maksimum haber sayısı (varsayılan: 10)
Haberlerdeki tekrarlayan/benzer içerikleri tespit eder.
threshold: Benzerlik eşiği (0-1 arası, varsayılan: 0.6)
category: Kategori filtresi (opsiyonel)
Tekrarlayan haberler temizlenmiş benzersiz haber listesi döndürür.
threshold: Benzerlik eşiği (varsayılan: 0.6)
limit: Maksimum haber sayısı (varsayılan: 20)
Belirli bir haberin başka haberlerle benzerliğini kontrol eder.
newsId: Kontrol edilecek haberin ID'si
threshold: Benzerlik eşiği (varsayılan: 0.6)
Günlük haber özeti oluşturur.
Belirli bir konu hakkında haberleri analiz eder.
Farklı haber kaynaklarının aynı konuyu nasıl ele aldığını karşılaştırır.
Haftalık haber brifing raporu oluşturur.
Endpoint | Metod | Açıklama |
| GET | Haberleri listeler |
| POST | Metin özetler |
| GET | Trend analizi yapar |
| POST | Duygu analizi yapar |
| GET | Haberlerin toplu duygu analizi |
| GET | Tekrarlayan haberleri bulur |
| GET | Benzersiz haberleri listeler |
| POST | İki metin arasındaki benzerliği hesaplar |
MCP yerine web arayüzünü kullanmak isterseniz:
npm run start:webTarayıcıda http://localhost:3000 adresini açın.
mcp-news-server/
├── src/
│ ├── index.ts # MCP sunucu giriş noktası
│ ├── web-server.ts # Express web sunucusu
│ ├── frontend.html # Web arayüzü
│ ├── styles.css # CSS stilleri
│ ├── types/
│ │ └── news.ts # TypeScript tip tanımları
│ └── services/
│ ├── newsService.ts # Haber çekme servisi
│ ├── summaryService.ts # Özetleme servisi
│ ├── sentimentService.ts # Duygu analizi servisi
│ ├── duplicateService.ts # Tekrar tespiti servisi
│ └── cacheService.ts # Önbellek servisi
├── package.json
├── tsconfig.json
└── README.mdTypeScript: Tip güvenli JavaScript
Model Context Protocol (MCP): AI model entegrasyonu için standart protokol
Express.js: Web sunucu framework
RSS Parser: RSS feed okuma
Cheerio: HTML parsing ve web scraping
Natural: NLP işlemleri için
Node-Cache: Bellek içi önbellek
Tekrarlayan haberler temizlenmiş benzersiz haber listesi döndürür
| Name | Required | Description | Default |
|---|---|---|---|
| threshold | No | Benzerlik eşiği (0-1 arası, varsayılan: 0.6) | |
| limit | No | Maksimum haber sayısı (varsayılan: 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It only states the output is a unique news list with duplicates cleaned. It does not specify whether the tool is read-only, how duplicates are determined, or any side effects. The mention of threshold parameter adds minimal context but not enough for full transparency.
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?
Description is a single short sentence, which is concise and directly states the purpose. It is front-loaded with the key action. However, it could be slightly more descriptive without being verbose.
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 output schema and no annotations, the description is too brief. It lacks information about return format, edge cases (e.g., empty input, extreme threshold values), and any behavioral notes. For a simple tool with two parameters, it is minimally complete but leaves gaps.
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 coverage is 100%, so baseline is 3. Description does not add extra meaning beyond the schema; it does not explain the purpose of threshold or limit in more detail. The description is self-contained but provides no added value.
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?
Description clearly states the tool returns a unique news list with duplicates removed. The verb 'döndürür' (returns) and resource 'benzersiz haber listesi' (unique news list) are specific. This distinguishes it from sibling tools like haber_cek (fetch) and kopyalari_bul (find copies).
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?
No usage guidelines provided. The description does not indicate when to use this tool versus alternatives (e.g., kopyalari_bul for finding duplicates, or haber_cek for fetching raw news). No context about prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Haber metninin duygusal tonunu analiz eder (pozitif/negatif/nötr)
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Analiz edilecek metin | |
| newsId | No | Alternatif olarak, daha önce çekilen haberin ID'si |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the basic function. No disclosure of side effects, idempotency, rate limits, or output format beyond the sentiment categories.
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 sentence, concise and to the point. It front-loads the action but could be more structured.
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?
The description lacks details about output format, error handling, and how it differs from batch analysis. Given the simplicity of the tool, it is minimally adequate but incomplete.
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 coverage is 100%, with both parameters having clear descriptions. The tool's description adds no additional meaning beyond the schema, so a baseline of 3 is appropriate.
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 analyzes the emotional tone of news text as positive/negative/neutral. It does not explicitly distinguish from sibling 'toplu_duygu_analiz' (batch analysis), but the singular nature is implied.
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?
No guidance on when to use this tool versus alternatives like 'toplu_duygu_analiz' for batch processing. No usage context or when-not-to-use is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
RSS kaynaklarından güncel haberleri çeker
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | Haber kaynağı URL'si (opsiyonel, boş bırakılırsa tüm kaynaklar) | |
| category | No | Haber kategorisi filtresi (opsiyonel) | |
| keyword | No | Arama kelimesi (opsiyonel) | |
| limit | No | Maksimum haber sayısı (varsayılan: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description fails to disclose rate limits, pagination, or behavior when no results are found. Only states basic fetch action.
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?
Single sentence is concise and front-loaded, but lacks structure for a 4-parameter tool. Minimal waste.
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?
No output schema; description omits return format, error handling, or example usage. Incomplete for a news fetching tool with optional filters.
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 covers all 4 parameters with descriptions; description adds no extra meaning. Baseline 3 is appropriate.
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?
Description clearly states the tool fetches current news from RSS sources, differentiating it from siblings that perform analysis or plagiarism checks.
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?
No guidance on when to use this tool vs. alternatives like 'benzersiz_haberler' or 'duygu_analiz'. Context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Haber metnini özetler
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Özetlenecek metin | |
| newsId | No | Alternatif olarak, daha önce çekilen haberin ID'si | |
| sentenceCount | No | Özetteki cümle sayısı (varsayılan: 3) | |
| extractKeywords | No | Anahtar kelimeleri çıkar (varsayılan: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It only states 'summarizes' without any mention of side effects, authorization needs, rate limits, or whether it mutates data. Critical behavioral context is missing.
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 sentence, efficient and front-loaded. However, it is somewhat under-specified, so a 4 is appropriate for conciseness without excess.
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 the tool has 4 parameters, constraints, no output schema, and a rich sibling context, the description is insufficient. It does not explain the output format (e.g., returns a summary string) or the behavior of the 'sentenceCount' and 'extractKeywords' parameters beyond schema defaults.
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%, so baseline is 3. The description does not add meaning beyond the schema; it only restates the tool's action. No additional parameter details or usage hints are provided.
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?
Description 'Haber metnini özetler' clearly states the tool's action (summarize) and resource (news text). It is distinct from sibling tools like duygu_analiz (sentiment analysis) or kopya_kontrol (plagiarism check), 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or trade-offs compared to sibling tools, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Belirli bir haberin başka haberlerle benzerliğini kontrol eder
| Name | Required | Description | Default |
|---|---|---|---|
| newsId | Yes | Kontrol edilecek haberin ID'si | |
| threshold | No | Benzerlik eşiği (0-1 arası, varsayılan: 0.6) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only states the basic operation. It does not mention if it's read-only, performance implications, or what happens with no results. The brief description leaves significant behavioral gaps.
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, succinct sentence with no filler. It is front-loaded and efficiently conveys the core function.
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?
Lacking output schema, the description fails to explain what the tool returns (e.g., a list of similar news, scores). Also, the threshold parameter's effect could be clarified. The tool is simple but incomplete for effective use.
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 coverage is 100%, and the description adds no extra meaning beyond what the schema already provides. Baseline 3 is appropriate as the description does not compensate or enhance understanding of parameters.
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 checks similarity of a specific news against others using a verb+resource pattern. It distinguishes from sibling 'kopyalari_bul' (find copies) by focusing on similarity, but lacks explicit differentiation.
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?
No guidance on when to use this tool versus alternatives like 'kopyalari_bul' or in what context. The description provides no usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Haberlerdeki tekrarlayan/benzer içerikleri tespit eder
| Name | Required | Description | Default |
|---|---|---|---|
| threshold | No | Benzerlik eşiği (0-1 arası, varsayılan: 0.6) | |
| category | No | Kategori filtresi (opsiyonel) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fails to disclose behavioral traits such as how similarity is determined, whether it is read-only, or if it has side effects. It only states the basic purpose.
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 concise sentence that front-loads the context ('Haberlerdeki'). It is efficient but perhaps too brief given the lack of other 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 the tool has two parameters and no output schema, the description should provide more context on how the tool works and what the output looks like. It is incomplete.
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 schema description coverage is 100%, so the description does not need to add much for parameters. The tool description adds no additional meaning beyond the schema's parameter descriptions.
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 detects repetitive/similar content in news, using a specific verb and resource. However, it does not differentiate from sibling tools like 'kopya_kontrol' which likely has overlapping functionality.
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?
No guidance on when to use this tool versus alternatives. There is no mention of context, prerequisites, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Haberin tam içeriğini web sayfasından çeker
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Haber URL'si | |
| newsId | No | Alternatif olarak, daha önce çekilen haberin ID'si |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states that content is pulled from the web page, but does not disclose side effects, authentication needs, rate limits, or error handling. The behavior is opaque beyond the basic action.
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, concise sentence. Every word is functional with no unnecessary content.
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?
The description lacks details about the return format (e.g., plain text, HTML) and does not explain how the tool behaves for different inputs. Given the absence of an output schema, more completeness is needed.
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 schema already provides 100% coverage with descriptions for both parameters. The description does not add meaningful context beyond what the schema offers, such as when to choose url over newsId. Baseline score applies.
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 pulls full news content from a web page, specifying the verb and resource. It distinguishes itself from sibling tools like 'haber_cek' by focusing on full content retrieval, but could be more explicit about the difference.
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?
No guidance is provided on when to use this tool versus alternatives like 'haber_cek' or 'haber_ozetle'. There are no prerequisites or conditions mentioned for using url vs newsId.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Birden fazla haberin duygusal tonunu toplu analiz eder
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Kategori filtresi (opsiyonel) | |
| limit | No | Maksimum haber sayısı (varsayılan: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the core function without disclosing any behavioral traits such as side effects, authentication, or limits. This is minimal transparency.
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?
Single sentence efficiently conveys the purpose. However, it could include some usage or behavioral context without being verbose.
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 two optional parameters and no output schema, the description covers the primary function. However, it lacks details on return format or edge cases, but overall adequate.
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 coverage is 100% with both parameters described (category and limit). The description adds no additional meaning beyond the schema, justifying a baseline score of 3.
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 function: to analyze the emotional tone of multiple news items in bulk. This distinguishes it from sibling tool 'duygu_analiz' which likely handles single items.
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?
Usage is implied by the name 'toplu' (batch) but no explicit guidance on when to use this versus single analysis or other siblings. No when-not or alternative conditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Haberlerdeki trendleri ve en çok kullanılan kelimeleri analiz eder
| Name | Required | Description | Default |
|---|---|---|---|
| hours | No | Son kaç saatteki haberler (varsayılan: 24) | |
| topWords | No | En çok kullanılan kelime sayısı (varsayılan: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose whether the operation is read-only, any side effects, rate limits, or output format. Only states high-level purpose.
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?
Single sentence, concise, and front-loaded with purpose. No wasted words, but could include more context without being verbose.
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 output schema or annotations, the description is too minimal. It does not explain what the tool returns (e.g., list of words with frequencies) or how to interpret results.
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 coverage is 100%, so baseline is 3. Description adds no extra meaning beyond schema; it only implies the parameters correspond to time range and top word count.
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?
Description clearly states it analyzes trends and most used words in news ('Haberlerdeki trendleri ve en çok kullanılan kelimeleri analiz eder'). This distinguishes it from siblings like sentiment analysis ('duygu_analiz') or summarization ('haber_ozetle').
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?
No guidance on when to use this tool versus alternatives. Does not mention when not to use it or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0benzersiz_haberlerduygu_analizhaber_cekhaber_ozetlekopya_kontrolkopyalari_bultam_icerik_altoplu_duygu_analiztrend_analizMost tools have distinct purposes: fetching, deduplication, sentiment analysis (individual and batch), summarization, full content retrieval, and trend analysis. The two duplicate detection tools (kopya_kontrol and kopyalari_bul) are similar but serve different granularities; descriptions help differentiate them.
All tool names are in Turkish snake_case, but the pattern varies: some are noun_verb (haber_cek), others are adjective_noun (benzersiz_haberler) or combined (tam_icerik_al). While the naming is readable and descriptive, the structural inconsistency lowers the score.
With 9 tools covering core news operations, the count is well-scoped. Each tool addresses a distinct need without overlap or bloat, making the set appropriate for a news analysis server.
The tool surface covers key workflows: fetching, deduplication, sentiment analysis (batch and single), summarization, full content extraction, and trend analysis. Missing are search or source management, but core functionality is solid.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Cross-source news (AP, BBC, NPR, HN, Google News) with topic filtering and dedup.
Summarize URLs, repurpose content, daily news digests, find competitors. Cost telemetry built in.
Track and browse RSS feeds with ease. Fetch the latest entries from any feed URL and extract full…
Real-time news and trending topics from major sources
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/gamzesirin/MCP-News-Server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server