Loading ToolBench
Türkiye için hava durumu MCP sunucusu — Open-Meteo ile canlı Türkçe hava durumu (API anahtarı gerektirmez).
Three tools with basic schemas and Turkish descriptions. All tools have input schemas with type definitions and parameter descriptions, meeting minimum requirements. However, descriptions are minimal (10-30 chars), parameter descriptions lack actionable detail (format, constraints, examples), and output schemas are undocumented. No error handling guidance, no tool annotations, no pagination support. Tool names use Turkish verbs (guncel_, gunluk_, sehir_) which are non-standard in English-dominant LLM ecosystems, LLMs trained on English patterns may struggle to infer intent from Turkish naming. Composition is sound (three separate concerns), but descriptions do not guide LLM selection or explain when to use each tool vs. alternatives.
Bir Türk şehri için güncel hava durumunu döner.
Bir Türk şehri için N günlük hava tahminini döner.
Türkçe bir yer adını coğrafi koordinatlara çözer (geocoding).
Tool names in Turkish (guncel_hava, gunluk_tahmin, sehir_ara) violate English verb_noun convention. LLMs trained primarily on English patterns may fail to infer intent. Recommend English names: get_current_weather, get_daily_forecast, search_location.
Descriptions are 10 - 30 characters, below the 50-char minimum for LLM selection. 'Bir Türk şehri için güncel hava durumunu döner' (current weather for a Turkish city) lacks WHEN to use, WHAT it returns, and HOW it differs from gunluk_tahmin. Expand to 100 - 150 chars with actionable context.
Parameter descriptions lack format/constraint detail. 'Şehir veya yer adı (örn. "İstanbul", "Ankara")' includes example values, which LLMs may reuse literally. Replace with formal constraints: 'Turkish city or location name (string, 1 - 100 chars, e.g. Istanbul or Ankara)' and remove example values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 41 | 2026-07-28+ | v2 |
Output schemas are undocumented. Tools return JSON strings with nested objects (sehir, il, konum, guncel, ozet) but LLMs cannot see the structure. Document return types: 'Returns JSON object with fields: sehir (string), il (string), konum (object with enlem/boylam), guncel (object with temperature/humidity/wind), ozet (string summary).'
No error handling guidance. If geocoding fails (city not found), tools raise ValueError but LLMs see no recovery path. Add error descriptions: 'If city not found, try search_location() with partial name or nearby city.' Include timeout handling (15s httpx timeout exists but not documented).