Click on "Install 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., "@AI Consultant MCP Server review this Python function for performance improvements"
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.
A Model Context Protocol (MCP) server that enables AI agents to consult with multiple AI models through OpenRouter. Features intelligent model auto-selection, conversation history, caching, and robust error handling.
This MCP server allows your AI assistant (like Claude Desktop) to consult with various AI models (GPT, Gemini, Grok, etc.) through a single interface. It automatically selects the best model for your task or lets you choose a specific one.
Related MCP server: Senior Consult MCP
npm install -g ai-consultant-mcpYou'll need an OpenRouter API key. Get one at OpenRouter.
Edit your MCP client configuration file:
For Claude Desktop:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"ai-consultant": {
"command": "npx",
"args": ["-y", "ai-consultant-mcp"],
"env": {
"OPENROUTER_API_KEY": "your-openrouter-api-key"
}
}
}
}For other MCP clients:
Configure according to your client's documentation, using npx -y ai-consultant-mcp as the command.
Clone the repository:
git clone https://github.com/filipkrayem/ai-consultant-mcp.git
cd ai-consultant-mcpInstall dependencies:
npm installBuild the project:
npm run buildConfigure your MCP client:
{
"mcpServers": {
"ai-consultant": {
"command": "node",
"args": ["/absolute/path/to/ai-consultant-mcp/dist/index.js"],
"env": {
"OPENROUTER_API_KEY": "your-openrouter-api-key"
}
}
}
}OPENROUTER_API_KEY (required): Your OpenRouter API key
VERBOSE_LOGGING (optional): Set to true or 1 to enable detailed logging. Default: false
gemini-2.5-pro: Google's Gemini 2.5 Pro - general purpose tasks and quick questions
gpt-5-codex: OpenAI's GPT-5 Codex - coding tasks, debugging, and refactoring
grok-code-fast-1: xAI's Grok Code Fast 1 - code review, complex reasoning, and analysis
🤖 Multiple AI models - Access GPT, Gemini, Grok, and more through one interface
🎯 Smart model selection - Automatically picks the best model for your task
💬 Conversation history - Maintain context across multiple questions
⚡ Response caching - Reduces API calls and costs
🔄 Automatic retries - Handles transient failures gracefully
🛡️ Circuit breaker - Prevents cascading failures
📊 Token tracking - Monitor usage for each consultation
Once configured, your AI assistant can use these tools:
consult_ai - Ask questions to AI models (auto-selects or specify a model)
list_models - See all available models and their capabilities
Simply ask your AI assistant to consult with AI models. For example:
"Consult this change with Grok and Codex"
"Have Grok review your code first"
Contributions are welcome! Please feel free to submit a Pull Request.
MIT
Consult with an AI model via OpenRouter. You can either specify a model or let the system auto-select based on your task. For sequential multi-model consultation, use the 'models' parameter to specify multiple models.
| Name | Required | Description | Default |
|---|---|---|---|
| clear_history | No | Optional: Set to true to clear the conversation history for the given conversation_id before processing this request. | |
| conversation_id | No | Optional: Conversation ID to maintain context across multiple consultations. Use the same ID for follow-up questions. | |
| model | No | Optional: Specific model to use (e.g., 'gemini-2.5-pro', 'gpt-5-codex', 'grok-code-fast-1'). If not specified, the best model will be automatically selected based on the task. | |
| models | No | Optional: Array of models to consult sequentially (e.g., ["gemini-2.5-pro", "gpt-5-codex"]). When specified, the prompt will be sent to each model in order and responses will be aggregated. This parameter takes precedence over 'model'. | |
| prompt | Yes | The question or task to send to the AI model | |
| task_description | No | Optional: Brief description of the task type to help auto-select the best model (e.g., 'coding task', 'complex analysis', 'quick question') |
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 key behavioral traits: the ability to auto-select models, sequential multi-model consultation, and that 'models' parameter takes precedence over 'model'. However, it lacks details on rate limits, authentication needs, response format, or error handling. For a complex AI consultation tool with no annotations, this is adequate but leaves significant 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 perfectly concise and front-loaded: two sentences that efficiently cover the core functionality and key usage patterns. Every sentence earns its place by providing essential information without redundancy or fluff.
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 complexity (AI consultation with multiple parameters and no output schema), the description is minimally complete. It covers the basic purpose and usage but lacks details on response format, error conditions, or practical constraints. With no annotations and no output schema, the description should do more to compensate, but it provides just enough to be functional.
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 6 parameters thoroughly. The description adds marginal value by explaining the auto-selection logic and precedence of 'models' over 'model', but doesn't provide additional semantic context beyond what's in the schema. Baseline 3 is appropriate when schema does 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 tool's purpose: 'Consult with an AI model via OpenRouter.' It specifies the action ('consult') and resource ('AI model'), though it doesn't explicitly differentiate from the sibling tool 'list_models' (which presumably lists available models rather than consulting them). The description is specific but lacks sibling differentiation for a perfect score.
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 usage context: 'You can either specify a model or let the system auto-select based on your task.' It also mentions an alternative approach: 'For sequential multi-model consultation, use the 'models' parameter to specify multiple models.' However, it doesn't explicitly state when NOT to use this tool or compare it to the sibling 'list_models', preventing a score of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available AI models with their descriptions and best use cases
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 mentions what data is returned (descriptions and use cases) but doesn't cover critical aspects like whether this is a read-only operation, potential rate limits, authentication needs, or response format. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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, efficient sentence that directly states the tool's purpose without any redundant or unnecessary words. It is front-loaded with the core action and resource, making it highly concise and well-structured.
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 simplicity (0 parameters, no output schema, no annotations), the description is adequate as a basic overview. However, it lacks details on behavioral traits and usage context, which are needed for full completeness, especially without annotations to fill those gaps.
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 tool has 0 parameters, and the schema description coverage is 100%, so there are no parameters to document. The description appropriately doesn't discuss parameters, which is correct for this case, earning a high score as it doesn't need to compensate for any gaps.
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 ('List') and resource ('all available AI models'), specifying what information is returned ('with their descriptions and best use cases'). However, it doesn't differentiate from the sibling tool 'consult_ai', which might be a related AI interaction tool, so it doesn't reach the highest score.
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 no guidance on when to use this tool versus the sibling 'consult_ai' or any alternatives. It lacks context about prerequisites, timing, or exclusions, offering only a basic statement of function without usage instructions.
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. Dates show when Glama detected each change.
v1.0.0consult_ailist_modelsThe two tools have completely distinct purposes: consult_ai is for executing AI consultations, while list_models is for retrieving model information. There is no overlap in functionality, making it impossible for an agent to confuse them.
Both tools follow a consistent verb_noun pattern (consult_ai, list_models) with clear, descriptive names. The naming convention is uniform and predictable across the set.
With only two tools, the server feels under-scoped for an 'AI Consultant' domain. While the tools cover consultation and model listing, there are likely missing operations like managing consultation history, configuring model parameters, or handling feedback, making the set feel incomplete for the stated purpose.
For an AI consultant server, the tool surface is severely incomplete. It lacks essential operations such as saving or retrieving past consultations, adjusting consultation settings, or providing feedback on model performance. The current tools only cover the most basic consultation flow, leaving significant gaps that will hinder agent workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A second opinion for AI agents: one prompt across several live Gonka models + roles, one call.
AI routing, memory, guardrails, and governance. Routes across Claude, GPT, Gemini.
AI model routing on your own vendor keys: pick the best model per prompt, or route and run it.
The OpenRouter MCP server plugs OpenRouter into the AI tools you already use. Once connected, your assistant can pull live OpenRouter data (models, prices, your credits, rankings, and docs) and send quick test messages, all without leaving your editor.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/GoldenPathAI/ai-consultant-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
