This MCP server gives your AI assistant real-time intelligence on LLMs and VLMs — pricing, benchmarks, and recommendations — fetched live from public sources (OpenRouter, SWE-bench, LM Arena, OpenCompass VLM, Aider Polyglot) and formatted as compact Markdown (~250–400 tokens) to minimize token usage.
Get detailed model info (get_model_info): Look up a model by ID or partial name to retrieve pricing (input/output/cache), benchmark scores (SWE-bench, Aider Polyglot, Arena Elo, MMMU, etc.), percentile ranks, capabilities (vision, tools, reasoning), and optional API code snippets (OpenAI SDK, curl, or Python requests).
List top models by category (list_top_models): Get a ranked leaderboard for categories like coding, math, vision, general, cost-effective, open-source, speed, context-window, or reasoning, with filters for minimum context window, release date, and result limit (1–20).
Compare models side-by-side (compare_models): Generate a Markdown comparison table for 2–5 models across pricing, benchmarks, context window, capabilities, and release dates — with best values automatically bolded.
Get personalized recommendations (recommend_model): Receive top-3 model picks tailored to a use case (coding, math, general, vision, creative, reasoning, or cost-effective), with optional filters for max price, minimum context window, vision/tool support, open-source requirement, and release date.
English | 日本語
Give your AI assistant real-time LLM/VLM knowledge. Pricing, benchmarks, and recommendations — updated every hour, not every training cycle.
LLMs have knowledge cutoffs. Ask Claude "what's the best coding model right now?" and it cannot answer with current data. This MCP server fixes that by feeding live model intelligence directly into your AI assistant's context window.
Zero config — No API keys, no registration. One command to install.
Low token — Compact Markdown tables (~300 tokens), not raw JSON (~3,000 tokens). Your context window matters.
5 benchmark sources — SWE-bench, LM Arena Elo, OpenCompass VLM, Aider Polyglot, and OpenRouter pricing merged into one unified view.
"What's the best coding model right now?" — list_top_models with category coding
"Compare Claude vs GPT vs Gemini" — compare_models with side-by-side table
"Find a cheap model with 1M context" — recommend_model with budget constraints
"What benchmarks does model X have?" — get_model_info with percentile ranks
Related MCP server: atom-mcp-server
claude mcp add llm-advisor -- npx -y llm-advisor-mcpclaude mcp add llm-advisor -- cmd /c npx -y llm-advisor-mcpAdd to your MCP configuration file:
{
"mcpServers": {
"llm-advisor": {
"command": "npx",
"args": ["-y", "llm-advisor-mcp"]
}
}
}That is it. No API keys, no .env files.
Client | Supported | Install Method |
Claude Code | Yes |
|
Claude Desktop | Yes | JSON config |
Cursor | Yes | JSON config |
Windsurf | Yes | JSON config |
Any MCP client | Yes | stdio transport |
get_model_infoDetailed specs for a specific model: pricing, benchmarks, percentile ranks, capabilities, and a ready-to-use API code example.
Parameters
Name | Type | Required | Default | Description |
| string | Yes | — | Model ID or partial name (e.g. |
| boolean | No |
| Include a ready-to-use code snippet |
| enum | No |
|
|
Example output
## anthropic/claude-sonnet-4
**Provider**: anthropic | **Modality**: text+image→text | **Released**: 2025-06-25
### Pricing
| Metric | Value |
|--------|-------|
| Input | $3.00 /1M tok |
| Output | $15.00 /1M tok |
| Cache Read | $0.30 /1M tok |
| Context | 200K |
| Max Output | 64K |
### Benchmarks
| Benchmark | Score |
|-----------|-------|
| SWE-bench Verified | 76.8% |
| Aider Polyglot | 72.1% |
| Arena Elo | 1467 |
| MMMU | 76.0% |
### Percentile Ranks
| Category | Percentile |
|----------|------------|
| Coding | P96 |
| General | P95 |
| Vision | P90 |
**Capabilities**: Tools, Reasoning, Vision
### API Example (openai_sdk)
```python
from openai import OpenAI
client = OpenAI(
base_url="https://openrouter.ai/api/v1",
api_key="<OPENROUTER_API_KEY>",
)
response = client.chat.completions.create(
model="anthropic/claude-sonnet-4",
messages=[{"role": "user", "content": "Hello"}],
)
---
### `list_top_models`
Top-ranked models for a category. Includes release dates for freshness awareness.
**Parameters**
| Name | Type | Required | Default | Description |
|------|------|----------|---------|-------------|
| `category` | enum | Yes | — | `coding`, `math`, `vision`, `general`, `cost-effective`, `open-source`, `speed`, `context-window`, `reasoning` |
| `limit` | number | No | `10` | Number of results (1-20) |
| `min_context` | number | No | — | Minimum context window in tokens |
| `min_release_date` | string | No | — | `YYYY-MM-DD`. Excludes models released before this date |
**Example output**
# | Model | Key Score | Input $/1M | Output $/1M | Context | Released |
1 | openai/o3-pro | SWE 79.5% | $20.00 | $80.00 | 200K | 2025-06-10 |
2 | anthropic/claude-sonnet-4 | SWE 76.8% | $3.00 | $15.00 | 200K | 2025-06-25 |
3 | google/gemini-2.5-pro | SWE 75.2% | $1.25 | $10.00 | 1M | 2025-03-25 |
4 | openai/o4-mini | SWE 73.6% | $1.10 | $4.40 | 200K | 2025-04-16 |
5 | anthropic/claude-opus-4 | SWE 72.5% | $15.00 | $75.00 | 200K | 2025-05-22 |
---
### `compare_models`
Side-by-side comparison for 2-5 models. Best values are **bolded** automatically. Includes a `Released` row so you can spot outdated models at a glance.
**Parameters**
| Name | Type | Required | Default | Description |
|------|------|----------|---------|-------------|
| `models` | string[] | Yes | — | 2-5 model IDs or partial names |
**Example output**
anthropic/claude-sonnet-4 | openai/gpt-4.1 | google/gemini-2.5-pro | |
Input $/1M | $3.00 | $2.00 | $1.25 |
Output $/1M | $15.00 | $8.00 | $5.00 |
Context | 200K | 1M | 1M |
Max Output | 64K | 32K | 65K |
SWE-bench | 76.8% | 55.0% | 75.2% |
Aider Polyglot | 72.1% | 65.3% | 71.8% |
Arena Elo | 1467 | 1492 | 1445 |
Vision | Yes | Yes | Yes |
Tools | Yes | Yes | Yes |
Reasoning | Yes | No | Yes |
Open Source | No | No | No |
Released | 2025-06-25 | 2025-04-14 | 2025-03-25 |
---
### `recommend_model`
Personalized top-3 recommendations. Scores combine weighted benchmarks, pricing, capability bonuses, and a freshness bonus (+3 points for models released within 3 months, +1 within 6 months).
**Parameters**
| Name | Type | Required | Default | Description |
|------|------|----------|---------|-------------|
| `use_case` | enum | Yes | — | `coding`, `math`, `general`, `vision`, `creative`, `reasoning`, `cost-effective` |
| `max_input_price` | number | No | — | Max input price (USD/1M tokens) |
| `max_output_price` | number | No | — | Max output price (USD/1M tokens) |
| `min_context` | number | No | — | Minimum context window in tokens |
| `require_vision` | boolean | No | — | Require image input support |
| `require_tools` | boolean | No | — | Require tool/function calling support |
| `require_open_source` | boolean | No | — | Require open-source license |
| `min_release_date` | string | No | — | `YYYY-MM-DD`. Excludes older models |
**Example output**
Input: $3.00/1M | Output: $15.00/1M | Context: 200K | Released: 2025-06-25 Benchmarks: SWE-bench: 76.8%, Aider: 72.1%, Arena: 1467 Strengths: reasoning, tools, vision
Input: $0.15/1M | Output: $0.60/1M | Context: 1M | Released: 2025-05-20 Benchmarks: SWE-bench: 62.9%, Arena: 1445 Strengths: tools, vision, 1M+ context
Input: $1.10/1M | Output: $4.40/1M | Context: 200K | Released: 2025-04-16 Benchmarks: SWE-bench: 73.6%, Arena: 1430 Strengths: reasoning, tools
---
## Data Sources
All data is fetched in real time from free, public APIs. No authentication required.
| Source | Data | Models | Cache TTL |
|--------|------|--------|-----------|
| [OpenRouter](https://openrouter.ai/api/v1/models) | Pricing, context lengths, modalities, release dates | 300+ | 1 hour |
| [SWE-bench](https://github.com/SWE-bench/swe-bench.github.io) | Coding benchmark (Verified leaderboard) | 30+ | 6 hours |
| [LM Arena](https://lmarena.ai) | Human preference Elo ratings | 314+ | 6 hours |
| [OpenCompass VLM](https://opencompass.org.cn) | Vision benchmarks: MMMU, MMBench, OCRBench, AI2D, MathVista | 284+ | 6 hours |
| [Aider Polyglot](https://aider.chat/docs/leaderboards/) | Multi-language coding pass rate | 63+ | 6 hours |
---
## Context Cost
MCP tool definitions and responses consume your LLM's context window. This server is designed to be lean:
| Component | Tokens |
|-----------|--------|
| All 4 tool definitions | ~1,000 |
| Typical tool response | ~250-400 |
For comparison, most MCP servers that return raw JSON consume 3,000-10,000 tokens per response. Every response from llm-advisor-mcp is pre-formatted Markdown, keeping context costs roughly 10x lower.
---
## Architecture
┌──────────────────────────────────────────────┐ │ MCP Client (Claude, etc.) │ └──────────┬───────────────────────────────────┘ │ stdio (JSON-RPC) ┌──────────▼───────────────────────────────────┐ │ llm-advisor-mcp server │ │ │ │ ┌─────────┐ ┌───────────┐ ┌────────────┐ │ │ │ Tools │ │ Registry │ │ Cache │ │ │ │ (4 tools)│──│ (unified) │──│ (in-memory)│ │ │ └─────────┘ └───────────┘ └────────────┘ │ │ │ │ │ ┌────────────┼────────────┐ │ │ ▼ ▼ ▼ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │Normalizer│ │Percentile│ │ Fetchers │ │ │ │(slug map)│ │ (5 cats) │ │(5 sources│ │ │ └──────────┘ └──────────┘ └──────────┘ │ └──────────────────────────────────────────────┘ │ │ │ OpenRouter SWE-bench Arena / VLM / Aider
- **TypeScript + ESM** — Single entry point, `tsup` build
- **In-memory cache** — TTL-based (1h pricing, 6h benchmarks), stale-while-revalidate
- **Cross-source normalization** — Maps inconsistent model names (e.g. `Claude 3.5 Sonnet` vs `anthropic/claude-3.5-sonnet`) to canonical IDs
- **Percentile computation** — Ranks across 5 categories (coding, math, general, vision, cost efficiency)
- **Freshness scoring** — Recommendation algorithm gives a bonus to recently released models (+3 for <=3mo, +1 for <=6mo)
- **Zero runtime deps** beyond `@modelcontextprotocol/sdk` and `zod`
---
## Roadmap
| Version | Status | Highlights |
|---------|--------|------------|
| v0.1 | Done | `get_model_info` + `list_top_models` via OpenRouter |
| v0.2 | Done | `compare_models` + `recommend_model` + SWE-bench + Arena Elo |
| v0.3 | Done | VLM benchmarks (MMMU, MMBench, OCRBench, AI2D, MathVista) + Aider Polyglot + percentile ranks + 43 tests |
| v0.4 | **Current** | Release date display, date-based filtering, freshness scoring in recommendations + 51 tests |
| v1.0 | Planned | Community contributions, weekly static data snapshots via GitHub Actions |
---
## Development
```bash
git clone https://github.com/Daichi-Kudo/llm-advisor-mcp.git
cd llm-advisor-mcp
npm install
npm run build # Build with tsup
npm run dev # Run with tsx (hot reload)
npm test # Run 51 unit tests (vitest)
npm run test:watch # Watch modesrc/
index.ts # Server entry point
types.ts # Shared type definitions
tools/
model-info.ts # get_model_info tool
list-top.ts # list_top_models tool
compare.ts # compare_models tool
recommend.ts # recommend_model tool
formatters.ts # Markdown output formatters
data/
registry.ts # Unified model registry
cache.ts # In-memory TTL cache
normalizer.ts # Cross-source name normalization
percentiles.ts # Percentile rank computation
fetchers/
openrouter.ts # OpenRouter API
swe-bench.ts # SWE-bench leaderboard
arena.ts # LM Arena Elo ratings
vlm-leaderboard.ts # OpenCompass VLM benchmarks
aider.ts # Aider Polyglot scores
static/
api-examples.ts # API code snippet templatesFork the repository
Create a feature branch
Add tests for new functionality
Run npm test to verify all 51 tests pass
Submit a pull request
MIT — built by Cognisant LLC
Compare 2-5 LLM/VLM models side-by-side: pricing, benchmarks, capabilities. Returns a compact Markdown comparison table (~400 tokens).
| Name | Required | Description | Default |
|---|---|---|---|
| models | Yes | Model IDs or partial names (e.g., ["claude-sonnet-4.6", "gpt-5.2", "gemini-3-pro"]) |
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 key behavioral traits: the tool performs comparison (not creation or modification), returns a Markdown table with specific content areas, and has a token limit (~400 tokens). However, it doesn't mention potential limitations like data freshness, error handling, or authentication needs, leaving some 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 extremely concise and front-loaded, with every sentence earning its place: the first defines the core functionality, and the second specifies the output format and constraints. There's no wasted text or redundancy.
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's moderate complexity (comparing models across multiple dimensions) and lack of annotations/output schema, the description is mostly complete. It covers purpose, scope, and output format but could benefit from mentioning data sources or update frequency. Without an output schema, it helpfully describes the return format (Markdown table).
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%, with the 'models' parameter fully documented in the schema (array of strings, 2-5 items, example values). The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3 without compensating or adding 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?
The description clearly states the tool's purpose with specific verbs ('compare') and resources ('2-5 LLM/VLM models'), specifying what aspects are compared (pricing, benchmarks, capabilities) and the output format (compact Markdown comparison table). It distinguishes from siblings like 'get_model_info' (single model details), 'list_top_models' (ranking), and 'recommend_model' (suggestion).
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 for when to use this tool (comparing multiple models side-by-side) and implies usage by specifying the 2-5 model range. However, it doesn't explicitly state when not to use it or name alternatives like 'get_model_info' for single-model details, which would be needed for a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific LLM/VLM model: pricing, benchmarks, capabilities, and ready-to-use API code example. Returns structured Markdown (~300 tokens).
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Model ID or partial name (e.g., "anthropic/claude-sonnet-4.6", "gpt-5.1", "gemini") | |
| include_api_example | No | Include API usage code example (default: true) | |
| api_format | No | API example format (default: openai_sdk) |
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 output format (structured Markdown) and approximate size (~300 tokens), which is useful behavioral context. However, it lacks details on error handling, rate limits, authentication needs, or whether the operation is read-only (implied by 'Get' but not explicit).
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 efficiently conveys the tool's purpose, content, and output format without unnecessary words. It is front-loaded with the core action and resource, making it easy to scan and understand.
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's moderate complexity (3 parameters, no output schema, no annotations), the description is reasonably complete. It covers the purpose, output format, and content, but could improve by addressing behavioral aspects like error cases or usage guidelines relative to siblings. The lack of output schema means the description should ideally hint at return structure, which it does with 'structured Markdown (~300 tokens)'.
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 the schema fully documents the parameters. The description adds minimal value beyond the schema by mentioning 'pricing, benchmarks, capabilities, and ready-to-use API code example', which loosely relates to parameters but does not provide additional syntax or format details. Baseline 3 is appropriate as the schema handles the heavy lifting.
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 verb 'Get' and the resource 'detailed information about a specific LLM/VLM model', specifying the content (pricing, benchmarks, capabilities, API code example) and output format (structured Markdown). It distinguishes from sibling tools like compare_models, list_top_models, and recommend_model by focusing on a single model's details rather than comparison, listing, or recommendation.
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 usage when detailed information about a specific model is needed, with context about what information is returned. However, it does not explicitly state when to use this tool versus alternatives like compare_models for comparisons or list_top_models for overviews, nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List top-ranked LLM/VLM models for a category. Categories: coding, math, vision, general, cost-effective, open-source, speed, context-window, reasoning. Returns a compact Markdown table (~250 tokens).
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | Category to rank models by | |
| limit | No | Number of models to return (default: 10) | |
| min_context | No | Minimum context window in tokens | |
| min_release_date | No | Minimum release date (YYYY-MM-DD). Excludes older models |
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 adds useful context about the output format ('compact Markdown table ~250 tokens') and the ranking focus, but doesn't cover other behavioral aspects like rate limits, data freshness, or error handling. The description doesn't contradict any annotations, but could be more comprehensive given the lack of structured 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?
The description is extremely concise (two sentences) and front-loaded with the core purpose. Every sentence earns its place: the first defines the action and categories, the second specifies the output format. No wasted words or redundant 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's moderate complexity (4 parameters, no output schema, no annotations), the description is reasonably complete. It covers the purpose, categories, and output format, though it could benefit from more behavioral context. Without an output schema, the description helpfully specifies the return format, but additional details about ranking criteria or data sources would improve completeness.
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 the schema already documents all parameters thoroughly. The description adds marginal value by listing the category options and implying the ranking logic, but doesn't provide additional semantic context beyond what's in the schema. With high schema coverage, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List top-ranked LLM/VLM models'), the resource ('models'), and the scope ('for a category'). It distinguishes from sibling tools like 'compare_models', 'get_model_info', and 'recommend_model' by focusing on ranking and tabular output rather than comparison, detailed info, or personalized recommendations.
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 usage context by listing categories and mentioning the output format, but it doesn't explicitly state when to use this tool versus alternatives like 'compare_models' or 'recommend_model'. No exclusions or prerequisites are provided, leaving the agent to infer appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get personalized model recommendations based on use case, budget, and requirements. Returns top 3 picks with reasoning (~350 tokens).
| Name | Required | Description | Default |
|---|---|---|---|
| use_case | Yes | Primary use case | |
| max_input_price | No | Max input price in USD per 1M tokens | |
| max_output_price | No | Max output price in USD per 1M tokens | |
| min_context | No | Minimum context window in tokens | |
| require_vision | No | Require vision/image input support | |
| require_tools | No | Require function/tool calling support | |
| require_open_source | No | Require open-source license | |
| min_release_date | No | Minimum release date (YYYY-MM-DD). Excludes older models |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and discloses key behavioral traits: it specifies the output format ('Returns top 3 picks with reasoning') and approximate length ('~350 tokens'), though it lacks details on rate limits, error handling, or data sources.
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 appropriately sized and front-loaded, with two concise sentences that efficiently convey the tool's purpose and output without any wasted words or redundancy.
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's moderate complexity (8 parameters, no output schema, no annotations), the description is reasonably complete: it covers purpose and output format, but could benefit from more behavioral context (e.g., data sources, limitations) to fully compensate for the lack of annotations and output schema.
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 the schema fully documents all 8 parameters. The description adds minimal value by mentioning 'use case, budget, and requirements,' which loosely maps to some parameters but does not provide additional semantics beyond what the schema already specifies.
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 with a specific verb ('Get personalized model recommendations') and resource ('model recommendations'), and distinguishes it from siblings by focusing on personalized recommendations rather than comparison, listing, or general information retrieval.
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 usage context through 'based on use case, budget, and requirements,' but does not explicitly state when to use this tool versus alternatives like compare_models or list_top_models, nor does it provide exclusions or 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.
v0.4.2compare_modelsget_model_infolist_top_modelsrecommend_modelScored across 4 tools
Each tool has a clearly distinct purpose: compare_models for side-by-side comparisons, get_model_info for detailed single-model data, list_top_models for category-based rankings, and recommend_model for personalized suggestions. There is no overlap or ambiguity in their functions.
All tool names follow a consistent verb_noun pattern with snake_case (e.g., compare_models, get_model_info). The verbs are distinct and appropriate for each action, making the naming predictable and readable throughout the set.
With 4 tools, the server is well-scoped for its purpose of advising on LLM/VLM models. Each tool earns its place by covering key aspects: comparison, detailed info, rankings, and recommendations, without being too sparse or bloated.
The tool surface provides complete coverage for the domain of LLM/VLM model advising. It includes tools for comparison, detailed retrieval, categorical listing, and personalized recommendations, covering all essential workflows without obvious gaps.
Source-backed AI model pricing, rankings, history, and benchmark data.
Sourced AI-model pricing and capability data — compare and route to the cheapest capable model.
Live LLM API pricing: token prices, comparisons, cheapest-model lookups. No key required.
Live LLM API price + status radar across 11 providers, with public per-model price HISTORY.
