Skip to main content
Glama

AI Compass

Describe what you're building, get the right AI model in 30 seconds.

AI Compass screenshot

Try it live →

ai-compass MCP server


Example

Input: "I want to build a chatbot that summarizes legal documents. Budget is $100/month."

Top recommendation: Claude Sonnet 4

Why: Best balance of long-context reasoning, summarization quality, and structured output within the stated budget.

Tradeoff: Higher cost than lightweight models, but better fit for document-heavy workflows.

Recommendation output


Related MCP server: whichmodel-mcp

The Problem

Choosing an AI model is still a messy manual workflow. Teams jump between provider pricing pages, benchmark dashboards, and blog posts, then make an important decision based on incomplete information.

The hard part is not finding model data — there are now 100+ models across 30+ providers. The hard part is mapping a real use case ("cheap legal document analysis", "fast customer support copilot") into the right tradeoff across cost, latency, context window, and capability.

The Solution

AI Compass turns a plain-English use case into a ranked set of model recommendations.

Instead of showing a generic comparison table, it: interprets the use case, identifies the most important constraints, scores model fit across capability/cost/tradeoffs, and returns top recommendations with reasoning.

Covers 62 models across 8 categories from 29 providers:

Category

Example models

Text & Code

GPT-4o, Claude Sonnet, Gemini Pro, Llama, Mistral

Image

DALL-E 3, Midjourney, Stable Diffusion, Flux

Video

Sora, Runway Gen-3, Kling, Veo 2

Voice

ElevenLabs, OpenAI TTS/Whisper, Deepgram

Music & Embedding

Suno, Udio, text-embedding-3

Two ways to use it:

  • Web app — paste your use case, get recommendations. Free tier (5/day) or bring your own Anthropic API key for unlimited use.

  • MCP server — plug into Claude Desktop, Cursor, or any MCP-compatible client. Get model recommendations without leaving your IDE.

Why MCP?

The web app is for humans exploring model choices visually.

The MCP server exists for developer workflows where model selection needs to happen inside tools like Claude Desktop or Cursor — without leaving the IDE. Same recommendation engine, different interface.

Technical Decisions & Tradeoffs

Why Claude as the ranking engine, not a scoring algorithm? A static scoring formula can't interpret "I need something cheap that handles legal documents" — it doesn't know that "legal" implies long context, high accuracy, and low hallucination risk. An LLM can read the dataset, understand the intent, and reason about fit. The tradeoff: every recommendation costs an API call (~$0.01), and results aren't deterministic. Temperature 0.3 keeps variance low.

Why BYOK (Bring Your Own Key)? I didn't want to eat API costs for every visitor, but I also didn't want to paywall the whole thing. The guest path (5 free/day via server-side key) lets people try it immediately. The BYOK path (dangerouslyAllowBrowser: true) sends requests directly from the browser to Anthropic — the key never touches my server.

Why no database? The entire model dataset is a JSON file (62 entries). No user accounts, no saved history. All state lives in localStorage (API key, usage count, query cache with 24h TTL). This keeps the architecture dead simple and the Vercel bill at $0.

What I cut:

  • Real-time pricing scraping — too fragile, too many providers with different page structures. Manual dataset updates with a daily GitHub Action refresh instead.

  • User accounts and saved recommendations — added complexity for unclear value at this stage.

  • Model comparison UI — started building it, decided the ranked cards with tradeoff explanations were clearer than a feature matrix.

Architecture

One dataset. One recommendation engine. Two interfaces. The core recommend() function in packages/core is the only path — both the web API route and the MCP tool call it directly.

┌─────────────────────────────────────────────────────┐
│                    User's Browser                    │
├──────────────────┬──────────────────────────────────┤
│   BYOK Path      │        Guest Path                │
│                  │                                  │
│  Browser ──────► │  Browser ──► /api/recommend ───► │
│  Anthropic API   │             (Next.js route)      │
│  (direct)        │             Anthropic API        │
└──────────────────┴──────────────────────────────────┘

┌─────────────────────────────────────────────────────┐
│                   MCP Server                         │
│  Claude Desktop / Cursor ──► recommend_models tool   │
│  Fetches latest dataset from GitHub (1h cache)       │
│  Falls back to bundled snapshot                      │
└─────────────────────────────────────────────────────┘

Monorepo:
  packages/core      → recommend() engine, Claude prompt, response parser
  packages/dataset   → 62 models, pricing, strengths/weaknesses
  apps/web           → Next.js 16 frontend + API route
  apps/mcp-server    → MCP stdio server for IDE integration

Known Limitations

  • Recommendations are only as good as the curated dataset. Pricing and benchmark data can drift as providers update models.

  • Some use cases — especially compliance-heavy or highly domain-specific workflows — still require human judgment beyond the recommendation output.

What I Learned

  • Prompt engineering is product design. The system prompt went through ~10 iterations. The biggest improvement was adding explicit cost math instructions (input_cost_per_1m is per 1M tokens, not per 1K words) — without it, Claude inflated cost estimates by 750x.

  • Monorepo friction is real but worth it. Turborepo + pnpm workspaces took real debugging (Turbopack doesn't resolve .js extensions in TypeScript imports, outputFileTracingRoot is required for Vercel monorepo deploys). But sharing types and the recommend engine between the web app and MCP server made it worth the setup cost.

  • MCP is surprisingly easy. The entire MCP server is ~100 lines. Zod schemas for tool inputs, StdioServerTransport, done. The hard part was the recommend engine, and that's shared code.

  • dangerouslyAllowBrowser: true is a feature, not a hack. For BYOK apps where the user provides their own API key, browser-direct calls mean the key never touches your server. It's actually more secure than proxying through a backend.

Tech Stack & Setup

Stack: Next.js 16 · Tailwind CSS · Anthropic Claude API · MCP SDK · Turborepo · pnpm · Vercel

Prerequisites: Node.js 22+, pnpm

# Clone and install
git clone https://github.com/kalraakshit042/ai-compass.git
cd ai-compass
pnpm install

# Add your Anthropic API key
echo "ANTHROPIC_API_KEY=sk-ant-..." > apps/web/.env.local

# Run the dev server
pnpm dev

# Run tests
pnpm test

MCP Server — add to your Claude Desktop config (claude_desktop_config.json):

{
  "mcpServers": {
    "ai-compass": {
      "command": "node",
      "args": ["path/to/ai-compass/apps/mcp-server/dist/index.js"],
      "env": {
        "ANTHROPIC_API_KEY": "sk-ant-..."
      }
    }
  }
}

Roadmap

See ROADMAP.md for planned improvements.


Built by Akshit

Available Tools

1 tool
recommend_modelsD
ParametersJSON Schema
NameRequiredDescriptionDefault
use_caseYesNatural language description of what you want to build or do with an AI model

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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. Dates show when Glama detected each change.

  1. 1 tool updatev0.1.0
    • First observedrecommend_models

TDQS

D1.6/5.0
Disambiguation4/5

With only one tool available, there is no possibility of confusing it with another tool. However, the complete absence of a description leaves the exact scope and intended use of 'recommend_models' undefined.

Naming Consistency4/5

The single tool follows a clear verb_noun pattern (recommend_models), which aligns with recommended conventions. Consistency across a set cannot be fully verified with only one sample, but the chosen pattern is sound.

Tool Count2/5

A single tool is insufficient for the implied scope of an 'ai-compass' server, which would typically require capabilities like listing available models, retrieving specifications, or comparing options. The guidelines specifically flag a single tool as 'too few' for most scopes.

Completeness2/5

The surface covers only the recommendation action with no supporting tools for model discovery, detail retrieval, or filtering. The lack of a description further exacerbates the gap, leaving agents uncertain about required parameters and return formats.

Maintenance

ActivityInactive
ResponsivenessUnresponsive

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kalraakshit042/ai-compass'

If you have feedback or need assistance with the MCP directory API, please join our Discord server