Click on "Deploy 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., "@aa-mcp Compare GPT-5.2 and Claude Opus 4.5 on price and speed"
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.
Artificial Analysis'in bağımsız LLM ölçümlerini (fiyat, hız, benchmark, sağlayıcı) MCP üzerinden veren sunucu. Python, stdio, MCP spec 2026-07-28.
Veri kaynağı: Artificial Analysis — atıf tüm
katmanlarda zorunludur ve her tool yanıtının meta.attribution alanında taşınır.
Mevcut açık kaynak alternatif (davidhariri/artificial-analysis-mcp)
emekliye ayrılan /api/v2/data/llms/models ucunu kullanıyor (Sunset: 2026-11-04,
sonrası 410 Gone), sayfalama ve cache'i yok, TypeScript SDK'sı da 2026-07-28'i
konuşmuyor. Ayrıntılı karşılaştırma ve karar: PLAN.md.
Related MCP server: AgentLayer MCP Server
uv venv --python 3.14
uv pip install -e .
cp .env.example .env # AA_API_KEY'i doldurMCP istemcisine ekleme (Claude Code / Desktop) — komut repo venv'i olmalı,
global Python'da mcp 2.0.0 var ve aa_mcp kurulu değil:
{
"aa": {
"type": "stdio",
"command": "C:\\Projeler\\Claude\\homelab-aa-mcp\\.venv\\Scripts\\python.exe",
"args": ["-m", "aa_mcp"]
}
}Tool | Ne yapar |
| Fiyat/hız/benchmark'a göre süzülüp sıralanmış model listesi (özet alanlar) |
| Tek modelin tüm ölçümleri; bulunamazsa benzer slug önerir |
| 2–5 modeli yan yana koyar |
| Bir modeli sunan sağlayıcılar, ucuzdan pahalıya (ticari katman gerektirebilir) |
Hepsi salt-okunur (read_only_hint), yapılandırılmış çıktı verir ve yanıtına
meta ekler: katman, zeka indeksi sürümü, verinin çekilme zamanı, tazelik
(fresh/cached/stale) ve kalan kota.
Elimizdeki anahtar free katmanında (x-aa-tier: free). Gerçek yanıt:
/language/models → 403 "Language models list requires a Pro subscription",
sunucu otomatik /language/models/free'ye düşüyor — 652 model, 4 sayfa,
intelligence_index_version 4.3.
Alan | free | Pro |
| ✓ | ✓ |
Zeka / kodlama / agentic indeksi | ✓ | ✓ |
Zeka indeksi koşturma maliyeti ( | ✓ (652'nin 135'inde) | ✓ |
Girdi, çıktı, cache hit/write fiyatı | ✓ | ✓ |
tokens/s, TTFT, uçtan uca süre | ✓ | ✓ |
Harmanlanmış fiyat ( | — | ✓ |
Bağlam penceresi, açık ağırlık, parametre sayısı | — | ✓ |
| — | ✓ |
İndeks dışı benchmark'lar ( | — | ✓ |
index_cost, AA'nın zeka indeksi test setini o modelde koşturmasının toplam
maliyetidir (USD); get_model ayrıca görev başına maliyeti de verir
(intelligence_index_cost_usd, intelligence_index_cost_per_task_usd). Fiyat
listesi değil, "bu zekâ kaça mal oluyor" ölçüsüdür — modellerin yaklaşık
beşte birinde ölçülmüştür, geri kalanı sıralamada sona düşer.
list_models, harmanlanmış fiyata göre sıralama ya da max_price_blended
süzmesi istendiğinde katmanda bu alan yoksa sessiz boş sonuç yerine açık hata
verir; price_input / price_output çalışır.
list_providers ise Commercial erişim ister; free anahtarla AA'nın kendi
metnini taşıyan bir hata döner ("Providers list requires Commercial API access…").
Bu hata cache'lenmez, yani her çağrı kotadan 1 istek harcar.
İlk soğuk açılışta Pro yolu bir kez denendiği için 403 de kotadan sayılır (toplam 5 istek); seçilen yol cache'e yazıldığından sonraki tazelemeler 4 istek.
Ücretsiz katman 24 saatte 100 istek ve kota anahtar değil organizasyon
bazlıdır. Sunucu tüm model listesini tek seferde çeker, 12 saat (AA_CACHE_TTL_HOURS)
bellekte + diskte tutar; süreç yeniden başlasa bile disk kopyası kullanılır.
AA erişilemezse bayat kopya freshness="stale" işaretiyle döner.
Değişken | Varsayılan | Açıklama |
| — | Zorunlu |
| 12 | 0 = cache kapalı (önerilmez) |
|
| Disk cache yeri |
| 30 | Saniye |
.venv/Scripts/python.exe -m pytest -qAğ gerektirmez. Ücretsiz katman fixture'ları canlı yanıttan birebir alındı
(2026-09-18); harmanlanmış fiyat/lisans gibi yalnız Pro'da olan alanların
fixture'ları AA dokümanından türetildi ve canlı doğrulanmadı.
Duman testi sunucuyu gerçekten stdio'dan açıp protokol pazarlığının
2026-07-28 olduğunu doğrular.
GPL-3.0-or-later.
2-5 modeli yan yana koyar (fiyat, hız, benchmark'lar). 'X mi Y mi' sorularının tek çağrılık cevabı.
| Name | Required | Description | Default |
|---|---|---|---|
| slugs | Yes | ||
| force_refresh | No |
| Name | Required | Description |
|---|---|---|
| meta | Yes | |
| models | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety and side-effect expectations. The description adds value by specifying the comparison dimensions (price, speed, benchmarks) and the model-count constraint, but does not detail edge-case behavior like handling more than 5 slugs, which is acceptable given the annotation coverage.
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 short, front-loaded sentences with no filler. It states the core action, the comparison fields, and the intended use case in minimal words, making it highly efficient for an agent to parse.
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?
With an output schema present, return-value documentation is handled elsewhere. The description adequately covers the tool's purpose, usage scenario, and model-count range. The main gap is the unexplained 'force_refresh' parameter, but given the moderate complexity and existing annotations, the definition is nearly complete.
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 0%, so the description must compensate. It does clarify the 'slugs' parameter by constraining it to 2-5 models, but it completely omits the 'force_refresh' parameter, leaving its purpose and effect undocumented. This partial coverage earns a mid-range score.
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 compares 2-5 models side by side across price, speed, and benchmarks, and positions it as the one-call answer to 'X or Y' questions. This verb+resource combination distinctly separates it from siblings like list_models and get_model, which focus on enumeration or single-model details.
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?
It explicitly frames the usage as answering 'X or Y' questions, giving a clear context for when to invoke this tool. However, it does not explicitly name alternatives or state when not to use it, leaving some inference for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tek bir LLM'in tüm ölçümleri: fiyatlandırma (girdi/çıktı/cache), hız ve katmanın verdiği benchmark skorları. Harmanlanmış fiyat, bağlam penceresi, açık ağırlık ve parametre sayısı yalnız Pro katmanında gelir; ücretsiz katmanda bu alanlar boştur. Slug ya da ada göre arar; bulamazsa benzer slug'ları önerir.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | ||
| force_refresh | No |
| Name | Required | Description |
|---|---|---|
| meta | Yes | |
| model | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds genuinely useful behavior: Pro-tier fields are empty on free tier, and missing models trigger similar-slug suggestions. It does not explain force_refresh's behavior, which is a notable gap, but nothing contradicts the annotations.
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?
Three dense sentences with no filler. The first sentence front-loads the core purpose, the second adds tier-specific behavior, and the third covers search and fallback behavior. Every sentence earns its place.
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 is largely complete: core metric categories, tier-dependent field availability, and lookup behavior are all covered, and the output schema presumably documents the return shape. The main missing piece is the semantics of the optional force_refresh parameter, which keeps it from being fully complete.
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 0%, so the description must compensate. It does explain that the 'model' parameter accepts a slug or name and describes the not-found fallback. However, 'force_refresh' is completely unexplained in both the schema and the description, so only one of the two parameters gains meaningful semantic coverage.
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 starts with 'Tek bir LLM'in tüm ölçümleri', naming the exact resource (a single LLM) and the exact data returned (pricing, speed, benchmark scores). This singular scope clearly differentiates it from sibling tools like list_models, compare_models, and list_providers.
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 makes the intended use clear: fetch all metrics for a single model, searchable by slug or name, with fallback suggestions when not found. It does not, however, explicitly state when to prefer list_models or compare_models instead, so no direct alternatives/exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Artificial Analysis'teki LLM'leri fiyat, hız ve benchmark indeksleriyle listeler. Creator'a göre süzülebilir; zeka/kodlama/agentic indeksi, zeka indeksini koşturmanın maliyeti (index_cost), girdi/çıktı/harmanlanmış fiyat, tokens/s, TTFT ya da çıkış tarihine göre sıralanabilir.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| creator | No | ||
| sort_by | No | intelligence_index | |
| descending | No | ||
| force_refresh | No | ||
| max_price_blended | No | ||
| min_intelligence_index | No |
| Name | Required | Description |
|---|---|---|
| meta | Yes | |
| count | Yes | |
| models | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and openWorld, and the description adds the data source ('Artificial Analysis') plus the available sort/filter behaviors. However, it does not disclose pagination, freshness/refresh semantics, or rate/usage limitations; the description adds useful but non-essential context.
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?
One front-loaded sentence states the core purpose before moving to filter/sort details, and the details are dense but reasonably organized with semicolons. There is no filler or repetition, though the length makes it slightly dense for quick scanning.
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 establishes the main listing behavior and maps the enum, but with 7 parameters at 0% schema coverage it leaves multiple parameters unexplained, and the output schema cannot compensate for missing invocation semantics. For a list tool with no required params, an agent can call it safely but cannot correctly use max_price_blended, min_intelligence_index, or force_refresh without guessing.
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 0%, so the description carries the burden. It explains creator and enumerates the sort_by options (including index_cost and ttft), but omits limit, descending, force_refresh, max_price_blended, and min_intelligence_index entirely. This leaves most parameters semantically undocumented.
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?
States a specific action and resource ('Lists LLMs on Artificial Analysis') and names the included attributes (price, speed, benchmark indices). The verb and resource distinguish it from siblings like get_model and compare_models, so an agent can recognize it as the bulk-list entry point.
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 this is the listing tool compared to get_model, compare_models, or list_providers, but it never states when to prefer it over those alternatives or when not to use it. It provides clear functional context (filter by creator, sort options) but no explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bir modeli sunan sağlayıcıları fiyat ve throughput'larıyla listeler (ör. aynı DeepSeek'i hangi sağlayıcı daha ucuz/hızlı veriyor). Bu uç ticari katman gerektirebilir; anahtarın kapsamıyorsa açıkça söyler.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | ||
| force_refresh | No |
| Name | Required | Description |
|---|---|---|
| meta | Yes | |
| count | Yes | |
| offers | Yes | |
| model_slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds meaningful behavioral context by disclosing that the endpoint may require a commercial tier and will clearly say if the key lacks coverage. This goes beyond the annotations without contradicting them.
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 focused sentences: the first states the core function with a concrete example, the second covers the key caveat. There is no redundant content and the most important information is front-loaded.
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 output schema covers return values, and annotations cover safety, so the description does not need to repeat those. However, it omits semantics for force_refresh and does not guide the agent toward sibling tools, leaving the description minimally adequate but not complete.
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 0%, so the description must compensate for parameter meaning. It clarifies that 'model' refers to the model being served by providers, but it says nothing about 'force_refresh', its purpose, or when an agent should set it. The compensation is incomplete.
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 uses a specific verb ('listeler') with a clear resource: providers serving a given model, including price and throughput. The example ('hangi sağlayıcı daha ucuz/hızlı veriyor') makes the intent unmistakable and differentiates it from siblings like list_models or get_model.
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 gives clear context for when to call the tool: when you need to compare providers for a specific model by cost or speed. It also warns about commercial-tier requirements, but it does not explicitly state when to avoid this tool in favor of compare_models or list_models.
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.
v0.1.0compare_modelsget_modellist_modelslist_providersScored across 4 tools
Each tool targets a distinct query type: listing/filtering models, retrieving one model's full details, comparing a small set of models side-by-side, and finding which providers serve a model. The boundaries are clear and an agent would rarely have trouble picking the correct tool.
All tool names follow a consistent verb_noun snake_case pattern: list_models, get_model, compare_models, list_providers. Verbs clearly express the action and nouns consistently identify the resource.
Four tools is well-scoped for an LLM comparison and research server. Each tool addresses a major workflow—discovery, detail lookup, direct comparison, and provider analysis—without redundancy.
The read-only domain is covered end-to-end: list models with filtering and sorting, inspect a specific model's full metrics, compare 2-5 models directly, and check providers for a model. No obvious dead ends or missing operations are apparent for the server's stated purpose.
Analytics for MCP servers. Query your tool calls, first-call success, retries and schema cost.
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
Hosted MCP server for LLM cost estimation, model comparison, and budget-aware routing.
Connect MCP clients to 2,000+ AI models without managing provider API keys.
