multi-model-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GEMINI_API_KEY | No | Google Gemini API key | |
| OPENAI_API_KEY | No | OpenAI API key for GPT models | |
| ANTHROPIC_API_KEY | No | Anthropic API key for Claude models | |
| MODELS_CONFIG_PATH | No | Path to models.yaml configuration file |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| ask_modelA | Send a prompt to a single configured model and return its response. Use this for a direct query to a specific provider/model. |
| ask_manyA | Send the same prompt to multiple models in parallel. Returns one response per model. Individual failures are isolated — one model failing does not prevent others from responding. |
| reason_togetherA | Multi-step reasoning workflow across multiple models. Strategies: • independent_then_critique (default): models answer independently, then a critic synthesizes. • debate: models see each other's answers and refine over N rounds, then a critic synthesizes. • red_team: proposer answers, others attack it, proposer revises — repeated for N rounds. Returns a trace, individual responses, and a final synthesized answer. The final answer is presented as synthesis, not ground truth. |
| critique_answerA | Ask one or more models to critique a draft answer to a question. Returns per-model critiques with identified weaknesses and suggested improvements. Useful for improving a draft before finalizing it. |
| pick_best_answerA | Given multiple candidate answers to a question, ask a judge model to rank them and identify the best one. Returns winner, ranking, and explanation. |
| list_modelsA | List all model aliases available in the current models.yaml configuration. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Each tool has a distinct purpose: ask_many for parallel queries, ask_model for single query, list_models for enumeration, critique_answer for critiquing drafts, pick_best_answer for ranking candidates, and reason_together for multi-step reasoning. No two tools overlap in function.
All tool names follow a consistent verb_noun pattern: ask_many, ask_model, critique_answer, list_models, pick_best_answer, reason_together. The verbs are descriptive and the naming style is uniform.
With 6 tools, the surface is well-scoped for a multi-model interaction server. Each tool adds clear value without redundancy or bloat, covering essential operations for querying, critiquing, ranking, and reasoning.
The tool set covers all core workflows: single/parallel queries, critique, ranking, and multi-step reasoning. A minor gap might be a tool for managing model configurations or conversation history, but the set is largely complete for the stated purpose.