What can you do with this server?

The Index9 MCP Server provides up-to-date information and live testing capabilities for 300+ AI models from OpenRouter, helping you discover, compare, and evaluate models with current pricing, specifications, and performance data. Key Capabilities: * Search and Filter Models: Use natural language queries or specific filters (provider, context window, price, capabilities) to discover relevant models from 300+ options * Get Detailed Specifications: Retrieve comprehensive technical details including pricing (input/output per million tokens), context window limits, capabilities (vision, audio, tool_calling, JSON mode, video), architecture, and per-request limits * Live Model Testing: Execute actual API calls to 1-5 models simultaneously using preset scenarios (quick math, code generation, reasoning, instruction following, tool calling) or custom prompts, measuring output quality, latency, token usage, and costs * Semantic Search: Find models using natural language descriptions with relevance scoring that combines semantic similarity, capability matching, and quality signals * Cost Analysis: Access current pricing and estimate costs for model usage, including extended pricing for image processing, audio, web search, and caching * Compare Models Side-by-Side: View pricing, release dates, architecture details (tokenizer, instruct type), moderation status, and performance metrics * Capability Filtering: Filter models by specific capabilities using AND logic to find models meeting multiple requirements * Pagination and Sorting: Browse results with pagination support and sort by relevance, price, release date, or context window size * Stay Current: Access regularly updated model information, solving the problem of outdated AI assistant knowledge Note: Live testing requires an OpenRouter API key for billing purposes.

How do I use Index9 MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Index9 MCP Server find models with 128k context under $0.50 per million tokens" 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.

de en es ja ko ru zh

Index9 MCP Server

by index9-org

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

@index9/mcp

Discover, shortlist, compare, cost-model, and live-test 300+ AI models from your editor

Per-editor install configs (Cursor, VS Code, Claude Code, Codex): https://index9.dev/#install

Install

npx -y @index9/mcp@latest

Generic MCP client config:

{
  "mcpServers": {
    "index9": {
      "command": "npx",
      "args": ["-y", "@index9/mcp@latest"],
      "env": {
        "OPENROUTER_API_KEY": "sk-or-..."
      }
    }
  }
}

Claude Code one-liner: claude mcp add --transport stdio index9 -- npx -y @index9/mcp.

Related MCP server: ai-model-selector-mcp

OpenRouter API key

Required for live test_model calls. Set OPENROUTER_API_KEY in your MCP client config. dryRun=true works without it.

Tools

list_facets: List available providers, capabilities, modalities, and tokenizers
find_models: Search AI models by semantic query or filters
get_models: Fetch full model metadata for up to 100 IDs or aliases
compare_models: Diff 2-10 models across pricing, context, capabilities, and tokenizer
test_model: Run live inference or dry-run cost estimates on 1-10 models (requires OpenRouter API key)

Response metadata

All tool responses include an _index9 object with:

apiBaseUrl: API base URL used for the request

Error responses also include:

status: upstream HTTP status code
_index9.retryAfterSeconds: present when Retry-After is returned
_index9.rateLimit: present when rate-limit headers are returned (x-ratelimit-limit, x-ratelimit-remaining, x-ratelimit-reset)

Available Tools

3 tools

find_modelsFind AI ModelsA

Search and filter 300+ AI models. Returns ranked results with pricing, context windows, and capabilities.

Call this tool first to discover model IDs, unless the user provides one (format: 'provider/model-name').

Parameters:

query: Natural language search (e.g., 'fast cheap coding model')
provider: Filter by provider(s). Comma-separated for multiple (e.g., 'openai,anthropic')
min_context, max_context, max_price_per_m, capabilities: Exact filters
sort_by: 'relevance' (default), 'price_asc', 'price_desc', 'date_desc', 'context_desc'
limit, offset: Pagination

Scores: Results include a 'score' field (0-150+). Higher = more relevant. Combines semantic similarity, capability matching, and model quality signals. Use for relative ranking, not absolute measurement.

Use model IDs from results with get_model for full specs or test_model for live testing.

ParametersJSON Schema

Name	Required	Description	Default
`query`	No	Natural language search query describing desired model characteristics (e.g., 'fastest coding model under $1', 'vision model with 128k context', 'cheapest tool-calling model'). Uses semantic search with fuzzy matching. Optional - omit to use filters only.
`provider`	No	Filter by provider name(s). Comma-separated for multiple (e.g., 'openai,anthropic'). Case-insensitive.
`min_context`	No	Minimum context window size in tokens (e.g., 8192, 32000, 128000). Filters out models with smaller context windows. Common values: 4096 (small), 32000 (medium), 128000+ (large).
`max_context`	No	Maximum context window size in tokens. Filters out models with larger context windows. Use to find smaller, faster models.
`max_price_per_m`	No	Maximum acceptable price per million input tokens in USD (e.g., 0.5 for $0.50/M tokens). Filters out more expensive models. Note: only considers input pricing for filtering.
`capabilities`	No	Required capabilities array - model must support ALL specified capabilities (AND logic). Examples: ['vision'] for image input, ['tool_calling', 'json_mode'] for structured outputs, ['vision', 'tool_calling'] for multimodal agents. Available: vision, audio, tool_calling, json_mode, video.
`sort_by`	No	Sort order for results. Options: 'relevance' (best semantic match, default), 'price_asc' (cheapest first by input price), 'price_desc' (most expensive first), 'date_desc' (newest models first), 'context_desc' (largest context window first). Defaults to 'relevance'.	relevance
`limit`	No	Maximum number of results to return (1-100). Defaults to 10. Use higher values (20-50) for broad exploration, lower values (5-10) for focused comparisons.
`offset`	No	Number of results to skip for pagination (0-based). Defaults to 0. Example: offset=10 with limit=10 returns results 11-20. Use with 'total' in response for pagination.

Output Schema

ParametersJSON Schema

Name	Required	Description
`total`	No
`results`	Yes

TDQS

A4.7/5.0

Behavior4/5

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 effectively describes key behaviors: the scoring system (0-150+ with explanation of what influences scores), pagination support, and the semantic/fuzzy matching nature of the search. However, it doesn't mention rate limits, authentication requirements, or error conditions, which would be helpful for a search tool with 9 parameters.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and efficiently organized. It starts with the core purpose, then provides usage guidance, parameter overview, scoring explanation, and workflow integration. Every sentence serves a clear purpose with no redundancy. The bullet-point style for parameters makes it scannable while maintaining completeness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (9 parameters, search functionality), the description provides excellent context. It explains the discovery workflow, parameter interactions, scoring interpretation, and integration with sibling tools. With 100% schema coverage and an output schema present, the description focuses on the semantic understanding needed to use the tool effectively rather than repeating schema details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds significant value by explaining parameter semantics beyond the schema: it clarifies that query uses 'semantic search with fuzzy matching,' explains the score field's purpose and interpretation, and provides practical examples for capabilities filtering ('AND logic'). However, it doesn't fully explain the interaction between query and filter parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Search and filter 300+ AI models. Returns ranked results with pricing, context windows, and capabilities.' This specifies the exact action (search and filter), resource (AI models), and scope (300+ models with specific return fields). It distinguishes from siblings by explaining this is the discovery tool to get model IDs for use with get_model and test_model.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance: 'Call this tool first to discover model IDs, unless the user provides one.' It also states when to use alternatives: 'Use model IDs from results with get_model for full specs or test_model for live testing.' This gives clear context about the tool's role in the workflow and when to use sibling tools instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_modelGet Model DetailsA

Get complete specs for a model by ID. Returns pricing, context window, capabilities, architecture, and per-request limits.

Call after find_models to get full details, or when the user provides a model ID (format: 'provider/model-name').

Returns 404 if model not found. Use find_models to discover valid IDs.

ParametersJSON Schema

Name	Required	Description	Default
`model_id`	Yes	Exact model identifier in format 'provider/model-name' (e.g., 'openai/gpt-5.2', 'anthropic/claude-opus-4.5', 'google/gemini-2.5-flash-preview-09-2025'). Case-sensitive. Use find_models first to discover valid model IDs. Returns 404 if model not found.

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes
`name`	Yes
`family`	Yes
`limits`	Yes
`pricing`	Yes
`version`	Yes
`provider`	Yes
`description`	Yes
`architecture`	Yes
`capabilities`	Yes
`is_moderated`	Yes
`release_date`	Yes
`extended_pricing`	Yes
`input_modalities`	Yes
`output_modalities`	Yes
`per_request_limits`	Yes
`supported_parameters`	Yes

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden and does well: it discloses the 404 error behavior, mentions case-sensitivity (though partly in schema), and implies read-only operation through 'Get'. However, it doesn't mention rate limits, authentication needs, or response format details beyond content types.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each earning its place: first states purpose and return values, second provides usage context, third covers error case and alternative. No wasted words, front-loaded with core functionality.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity, 100% schema coverage, and presence of an output schema (which handles return values), the description is complete enough. It covers purpose, usage, error behavior, and sibling differentiation without needing to duplicate structured data.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, providing detailed parameter documentation. The description adds minimal value beyond schema, only reinforcing the format and discovery advice. Baseline 3 is appropriate when schema does heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Get') and resource ('complete specs for a model by ID'), specifying what information is returned (pricing, context window, capabilities, architecture, per-request limits). It distinguishes from sibling 'find_models' by focusing on detailed specs rather than discovery.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit guidance is provided: 'Call after find_models to get full details, or when the user provides a model ID.' It also specifies when not to use it ('Returns 404 if model not found. Use find_models to discover valid IDs.') and names the alternative tool ('find_models').

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

test_modelTest AI ModelsA

Make live API calls to 1-5 models via OpenRouter. Returns output text, latency (ms), token usage, and cost estimates.

Requires OPENROUTER_API_KEY in MCP client configuration. Costs are billed to your OpenRouter account.

Parameters:

model_ids: 1-5 model IDs to test (all receive identical prompts)
test_type: 'quick' (math), 'code', 'reasoning', 'instruction', 'tool_calling'
prompt: Custom prompt (overrides test_type)
max_tokens: Response length limit (default 1000)

Use find_models or get_model first to identify model IDs.

ParametersJSON Schema

Name	Required	Description	Default
`model_ids`	Yes	Array of 1-5 model IDs to test simultaneously in format 'provider/model-name' (e.g., ['openai/gpt-5.1-codex-max', 'anthropic/claude-haiku-4.5']). All models receive identical prompts. Use find_models or get_model first to identify model IDs.
`test_type`	No	Preset test scenario. Ignored if custom 'prompt' provided. Options: 'quick' (simple math, fastest), 'code' (function generation), 'reasoning' (logic puzzle), 'instruction' (following complex directions), 'tool_calling' (function calling capability). Defaults to 'quick'.	quick
`prompt`	No	Custom user message to send to all models. Overrides 'test_type' when provided. Use for debugging specific issues, comparing exact outputs, or testing domain-specific prompts. Example: 'Write a Python function to validate email addresses'.
`max_tokens`	No	Maximum tokens for model response (1-8192). Higher values allow longer outputs but increase cost and latency. Defaults to 1000. Use 100-500 for quick tests, 1000-2000 for code/reasoning, 4000+ for long-form content.
`temperature`	No	Sampling temperature (0-2). Lower values are more deterministic, higher values more creative. Defaults to 0.7.
`system_prompt`	No	System message to set model behavior. Example: 'You are a helpful coding assistant.'

Output Schema

ParametersJSON Schema

Name	Required	Description
`prompt`	Yes
`results`	Yes
`test_type`	Yes

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: authentication requirements ('Requires OPENROUTER_API_KEY'), billing implications ('Costs are billed to your OpenRouter account'), and performance characteristics ('Returns output text, latency (ms), token usage, and cost estimates'). It doesn't mention rate limits or error handling, keeping it from a perfect score.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is perfectly structured and concise: it starts with the core purpose, then covers requirements, parameters with practical guidance, and ends with sibling tool references. Every sentence earns its place with no redundancy or wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (6 parameters, live API calls, billing implications) and the presence of an output schema (which handles return values), the description is complete: it covers purpose, authentication, billing, parameter relationships, practical usage tips, and sibling tool coordination. Nothing essential appears missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the baseline is 3, but the description adds meaningful context beyond the schema: it explains the relationship between test_type and prompt ('prompt overrides test_type'), provides practical guidance on max_tokens usage ('Use 100-500 for quick tests'), and clarifies that all models receive identical prompts. This adds significant practical value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

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 ('Make live API calls', 'Returns output text') and resources ('to 1-5 models via OpenRouter'). It distinguishes from siblings by mentioning 'Use find_models or get_model first to identify model IDs', showing awareness of complementary tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool vs alternatives: 'Use find_models or get_model first to identify model IDs' indicates prerequisites and sibling relationships. It also explains parameter interactions ('prompt overrides test_type') and provides context about billing requirements.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

3 tool updatesv1.0.0Jan 5, 2026
- First observedfind_models
- First observedget_model
- First observedtest_model

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.7/5.0

Scored 2026-04-18 07:55 across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: find_models searches and filters models, get_model retrieves detailed specs for a specific model, and test_model performs live testing. The descriptions explicitly guide usage flow (e.g., 'call this tool first' for find_models), eliminating any ambiguity.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern (find_models, get_model, test_model) with clear, descriptive names. The naming is uniform throughout, using snake_case and straightforward verbs that accurately reflect each tool's function.

Tool Count5/5

With 3 tools, the server is well-scoped for its purpose of AI model discovery and testing. Each tool earns its place by covering distinct aspects: search, detailed retrieval, and live evaluation, providing a complete workflow without being overly sparse or bloated.

Completeness5/5

The tool set offers complete coverage for the domain of AI model exploration: find_models enables discovery, get_model provides full specifications, and test_model allows live validation. There are no obvious gaps, and the tools work together seamlessly to support end-to-end workflows without dead ends.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

modelglass
io.github.Modelglass
Sourced AI-model pricing and capability data — compare and route to the cheapest capable model.
AI & Machine Learning Developer Tools Agent Orchestration
11
Kyma APIOAuth
com.kymaapi
Live model catalog with prices and measured uptime, rankings, credits and spend, spend-capped chat.
AI & Machine Learning Monitoring Payments & Billing
1
AI Pricing Hub A
io.github.gishh
Source-backed AI model pricing, rankings, history, and benchmark data.
AI & Machine Learning Research & Data
112
Store API A
com.store-api
GPT, Claude, Gemini, DeepSeek, Grok, Qwen and GLM through one API key. Pay per token.
AI & Machine Learning Developer Tools
61

Related MCP Servers

LLM-Adviser-Mcp
RAG Systems Search Developer Tools
Daichi-Kudo
A
license
A
quality
D
maintenance
Give your AI assistant real-time LLM/VLM knowledge. Pricing, benchmarks, and recommendations — updated every hour, not every training cycle.
Updated 3 months ago (2026-06-18 04:55 UTC)
4
42 npm
2
MIT
ai-model-selector-mcp
AI & Machine Learning Search Developer Tools
barrymister
A
license
Not graded
quality
D
maintenance
Provides AI assistants with structured access to metadata for 76+ AI models across Ollama, Claude, and OpenRouter, enabling capability queries, compatibility checks, model comparisons, and task-based recommendations.
Updated 6 months ago (2026-03-21 08:02 UTC)
8 npm
MIT
LLM Benchmark MCP Server
AI & Machine Learning Research & Data
AiAgentKarl
A
license
Not graded
quality
D
maintenance
Enables AI agents to compare LLM benchmarks, get pricing, and receive model recommendations for tasks and budgets.
Updated 6 months ago (2026-04-03 16:05 UTC)
1
MIT
AI Model Advisor MCP Server
AI & Machine Learning Autonomous Agents
Semicolon-D
A
license
A
quality
D
maintenance
Enables AI agents to discover, compare, and select the best AI models across multiple providers based on pricing, performance, and capabilities, with real-time cost estimation and benchmarking.
Updated 3 months ago (2026-07-04 01:54 UTC)
9
40 npm
1
MIT