What can you do with this server?

The ModelRouter MCP server provides advisory LLM model recommendations, task and repository analysis, and model registry management for Cursor. All recommendations are advisory — the user must manually select the model. No user data is sent externally. * recommend_model: Advisory model recommendation based on plan and repo metadata, with optional alternatives and config overrides. * analyze_task: Parse a plan document to determine task type, complexity, and requirement vector. * analyze_repository: Inspect repo metadata (file counts, languages, frameworks, diff stats) without reading source file contents. * estimate_cost: Estimate token usage and cost for a specific model given a plan. * list_models: List all models in the registry with basic metadata. * get_model_profile: Fetch the full profile and provenance for a specific model by ID. * sync_metadata: Refresh model metadata from external fixture-based adapters (blocked in privacy mode). * get_telemetry_summary: View local telemetry data — never leaves the machine via outbound HTTP. * generate_cursor_guidance: Generate advisory Cursor guidance snippets — does not automatically apply or enforce model selection.

Which integrations are available for this server?

Integrates Ollama as a local model registry, enabling recommendations for locally hosted Ollama models.

How do I use ModelRouter MCP?

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., "@ModelRouter MCP recommend a model for my Python data science project" 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.

ModelRouter MCP

by MrSolution07

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

ModelRouter MCP

Advisory MCP server for intelligent LLM model recommendations in Cursor.

v1 Capability Statement

Ships:

Advisory recommend_model with schema-validated JSON
Heuristic task analysis (Layer A) + metadata scoring (Layer B)
Static seed registry with user-writable cache (~/.modelrouter)
Live metadata sync by default (Class D inbound fetch when privacyMode: false)
Guidance snippets for Cursor — user manually picks model

Does NOT ship:

Force Composer/Auto model selection
Continuous validation against engineering tasks (Phase 8 — stub only in v0.1)
Cursor.models.list() or any IDE runtime model API
Product HTTP/REST API (stdio MCP only)

Related MCP server: code-review-mcp

Quick Start

npm install
npm run build
MODELROUTER_USE_FIXTURES=1 npm test
npm run validate-schemas
npm run smoke

Cursor MCP Configuration

npm (after publish):

{
  "mcpServers": {
    "modelrouter": {
      "command": "npx",
      "args": ["-y", "modelrouter-mcp"]
    }
  }
}

Local development:

{
  "mcpServers": {
    "modelrouter": {
      "command": "node",
      "args": ["/absolute/path/to/ModelRouter_MCP/dist/index.js"]
    }
  }
}

Efficient usage

Write a plan file (or pass planText inline)
Call recommend_model with planPath or planText (+ optional repoPath)
Manually select the recommended model in the Cursor picker
Call sync_metadata when pricing/models look stale (or wait for 24h background sync)

Tools (10)

Tool	Description
`recommend_model`	Advisory recommendation from plan + repo metadata
`analyze_task`	Task type, complexity, requirement vector
`analyze_repository`	File counts, languages, frameworks, diff stats
`list_models`	Registry model list
`get_model_profile`	Full profile with provenance
`sync_metadata`	Sync from external sources (blocked in privacy mode)
`generate_cursor_guidance`	Advisory snippets — does not apply model
`get_telemetry_summary`	In-process telemetry counters
`estimate_cost`	Cost estimate for a specific model
`run_internal_validation`	Opt-in stub (no LLM calls / no score writes in v0.1)

Benchmark ingest is internal-only (via SweBenchAdapter), not exposed as an MCP tool.

Sync source matrix

Source ID	Behavior
`openrouter_models`	Live HTTP (fixtures when `MODELROUTER_USE_FIXTURES=1`)
`swe_bench_leaderboard`	Live HTTP / fixtures
`anthropic_docs`	Packaged fixture only (no live HTTP yet)
`ollama_local`	Probes localhost; does not write model profiles

Configuration

See schemas/modelrouter-config.schema.json.

Setting	Default	Notes
`privacyMode`	`false`	Blocks outbound HTTP; local recommend still works
`sync.enabled`	`true`	Disable to skip metadata sync
`sync.sources`	all adapters	Enum of source IDs above
`validation.enabled`	`false`	Stub only in v0.1

Environment variables (not in JSON schema):

MODELROUTER_DATA_DIR — override user cache directory (default ~/.modelrouter)
MODELROUTER_USE_FIXTURES=1 — fixtures only, no live HTTP (CI/dev offline)
MODELROUTER_PRIVACY_MODE=1 — startup privacy (blocks outbound sync)

Optional file: ~/.modelrouter/config.json (same schema). Precedence: env → file → defaults.

Privacy

See PRIVACY.md. User plan and repository data are never sent outbound. Optional public model metadata fetch (Class D) occurs when privacyMode: false.

Data Directories

Path	Purpose
Packaged `data/models/`	Read-only seeds (npm install)
`~/.modelrouter/models/`	Writable user cache (sync updates)
`~/.modelrouter/sync-state.json`	Last sync TTL tracking

Single-instance assumption: concurrent writes are not supported.

Troubleshooting

Build errors: Run npm run build before starting MCP
Stale metadata: Call sync_metadata or wait for background TTL sync (24h)
Offline dev: Set MODELROUTER_USE_FIXTURES=1
Privacy: Set MODELROUTER_PRIVACY_MODE=1 or privacyMode: true to block outbound HTTP

Maintainer Scripts

# Optional — requires CURSOR_API_KEY
npm run verify-cursor-ids

# CI denylist check
npm run lint:cursor-denylist

# Record live sync fixtures (network required)
npx tsx scripts/record-sync-fixtures.ts

Implementation status

Phase	Status
Runtime foundation (user dir, async sync)	Complete
Live metadata sync	Partial (see sync matrix)
Registry quality (cursor IDs)	Documented IDs; not all `verified`
Calibration	Provisional
npm publish	Pending pre-publish hardening

Cursor model IDs in the seed registry are documented, not runtime-verified. Calibration is provisional.

See CONTRIBUTING.md for maintainer workflows.

License

MIT — see LICENSE

Available Tools

9 tools

analyze_repositoryA

Analyze repository metadata (file counts, languages, frameworks, diff stats). No source file contents are read.

ParametersJSON Schema

Name	Required	Description	Default
`repoPath`	Yes

TDQS

A3.9/5.0

Behavior4/5

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

Without annotations, the description bears full burden for behavioral disclosure. It explicitly states that source file contents are not read, addressing a key safety concern. However, it does not confirm non-destructiveness or mention other behavioral traits like data retention or performance impact.

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?

Two concise sentences with no unnecessary words. The purpose is front-loaded, and the negative constraint is provided in the second sentence. Every word adds value.

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

Completeness4/5

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

For a tool with one required parameter and no output schema, the description provides the core purpose and a key behavioral constraint. The list of outputs (file counts, languages, frameworks, diff stats) gives a reasonable expectation, though a brief note on the output structure would improve completeness.

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

Parameters2/5

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

The input schema has 0% description coverage, and the tool description does not elaborate on the 'repoPath' parameter (e.g., format, accepted values like URL or local path). The first sentence implies the parameter is a repository path, but lacks sufficient detail for confident use.

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 action ('Analyze repository metadata') and lists specific outputs (file counts, languages, frameworks, diff stats). It also explicitly states what is not done ('No source file contents are read'), distinguishing it from potential sibling tools that might read file contents.

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

Usage Guidelines3/5

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

The description implies usage for obtaining repository metadata without reading source files, but does not explicitly state when to use or provide alternatives. The sibling tools like 'analyze_task' suggest different scopes, but no direct comparison is made.

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

analyze_taskB

Analyze a plan document for task type, complexity, and requirement vector. Advisory analysis only — does not select a model.

ParametersJSON Schema

Name	Required	Description	Default
`planPath`	Yes
`repoPath`	No

TDQS

B3/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behaviors. It states the tool is advisory and does not select a model, but does not mention whether it is read-only, requires permissions, or has any side effects. Limited disclosure.

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

Conciseness4/5

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

The description is brief (two sentences) and front-loads the core purpose. However, it could be slightly more structured to include parameter details or output description.

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

Completeness2/5

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

No output schema exists, yet the description does not explain the structure or format of the analysis results. Combined with missing parameter explanations, the description is insufficient for proper understanding.

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?

Schema description coverage is 0%, and the description does not explain the meaning or expected values of the parameters planPath and repoPath beyond their names. The agent lacks guidance on how to provide these inputs.

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 action ('Analyze a plan document'), the specific outputs ('task type, complexity, and requirement vector'), and distinguishes from siblings by noting it is advisory only and does not select a model.

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

Usage Guidelines3/5

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

The description implies usage for analysis rather than model selection, but does not explicitly state when to use this tool versus alternatives like recommend_model, nor does it provide conditions for when not to use it.

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

estimate_costC

Estimate token usage and cost for a specific model given a plan.

ParametersJSON Schema

Name	Required	Description	Default
`modelId`	Yes
`planPath`	Yes
`repoPath`	No

TDQS

C2.4/5.0

Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It only states the tool estimates cost and token usage, omitting potential side effects, authentication needs, rate limits, or whether it modifies any state. The lack of detail leaves significant unknowns for an AI agent.

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

Conciseness3/5

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

The description is a single 12-word sentence, which is highly concise but sacrifices necessary detail. Every word earns its place, but the brevity leaves out critical information, making it inadequate for an agent to correctly use the tool.

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?

Given the tool has 3 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain the return format, the meaning of 'plan', or the optional repoPath. An AI agent would lack sufficient context to invoke the tool correctly or interpret its results.

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?

The input schema has 0% description coverage, and the description does not explain any of the three parameters (modelId, planPath, repoPath). The term 'plan' in the description hints at planPath, but the purpose of repoPath is unclear. The description fails to add meaning beyond the schema's bare type definitions.

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

Purpose4/5

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

The description clearly states the tool estimates token usage and cost for a specific model given a plan. It uses a specific verb and resource, and it distinguishes from sibling tools like recommend_model or list_models which focus on other aspects. However, it could be more specific about what 'plan' refers to.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives such as recommend_model or get_model_profile. There are no exclusions or context for appropriate use, leaving the agent to infer solely from the brief description.

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

generate_cursor_guidanceC

Generate advisory Cursor guidance snippets. Does not apply or enforce model selection.

ParametersJSON Schema

Name	Required	Description	Default
`config`	No
`planPath`	Yes
`repoPath`	No

TDQS

C2.8/5.0

Behavior2/5

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

No annotations exist; description adds minimal behavioral context (advisory, non-enforcing) but omits side effects, auth needs, or rate limits.

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?

Two sentences, front-loaded with key info, no filler – every word earns its place.

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?

With no output schema, no annotations, and no parameter descriptions, the description alone is woefully inadequate for safe and correct tool use.

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?

Schema coverage is 0% and description mentions no parameters; schema properties (config, planPath, repoPath) have no explanations, leaving agent guessing.

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?

Description clearly states the tool generates advisory Cursor guidance snippets and explicitly distinguishes from enforcing model selection, making purpose distinct from sibling tools.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives; no prerequisites, exclusions (beyond one line), or context cues provided.

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

get_model_profileC

Get full model profile with provenance for a specific model ID.

ParametersJSON Schema

Name	Required	Description	Default
`modelId`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description bears full responsibility. It implies a read operation but lacks details on side effects, auth requirements, rate limits, or error behavior.

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

Conciseness4/5

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

The description is a single, front-loaded sentence with no redundancy. However, for a tool with no annotations and no output schema, it may be too brief.

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

Completeness2/5

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

Given the lack of annotations and output schema, the description is insufficient. It does not describe the return format, error cases, or what 'full profile with provenance' entails, leaving the agent underinformed.

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

Parameters2/5

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

The input schema has 0% coverage, and the description only adds 'for a specific model ID', which provides minimal extra meaning. It does not explain format, constraints, or how to obtain the modelId.

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 action (Get), the resource (full model profile with provenance), and the scope (for a specific model ID). It effectively distinguishes from sibling tools like list_models or recommend_model.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives. The description does not mention when-not to use it or provide comparisons with siblings like list_models.

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

get_telemetry_summaryA

Get local telemetry summary. Data never leaves the machine.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior4/5

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

Without annotations, the description provides a valuable behavioral disclosure: 'Data never leaves the machine,' indicating privacy. However, it does not detail other aspects like the scope of the summary or potential side effects.

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 consists of two brief sentences with no redundancy. Every word is informative and contributes to understanding.

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

Completeness3/5

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

The description is minimal. While it covers the core purpose and a key behavioral trait, it lacks details about what the telemetry summary contains (e.g., metrics, events, errors). This gap could leave the agent uncertain about the tool's output.

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?

There are zero parameters, so the description does not need to add parameter information. The baseline of 4 is appropriate as no additional semantics are required.

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 retrieves a local telemetry summary. The tool name and description together make the purpose unambiguous, and it is distinct from sibling tools like analyze_repository or recommend_model.

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool over alternatives is provided. The description implies it is for obtaining telemetry data, but does not specify context such as prerequisite conditions or contraindications.

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

list_modelsA

List all models in the registry with basic metadata.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior3/5

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

The description implies read-only behavior ('list') but does not explicitly state it's non-destructive or disclose potential issues like pagination, rate limits, or ordering. With no annotations, the description bears the full burden but provides only minimal behavioral context.

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?

A single concise sentence that directly communicates the tool's purpose without extraneous words.

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

Completeness3/5

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

The tool is simple with no parameters, but the description lacks details on what 'basic metadata' includes and does not specify output structure. Given no output schema, more context would be helpful but is not critical for this straightforward listing tool.

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?

There are no parameters, so per guidelines baseline is 4. The description does not add any parameter meaning, but none is needed.

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 'list', the resource 'all models in the registry', and the scope 'basic metadata'. This distinguishes it from sibling tools like get_model_profile (single model) 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.

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like get_model_profile or sync_metadata. There is no mention of prerequisites, limitations, or when not to use it.

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

recommend_modelC

Advisory model recommendation based on plan analysis and registry metadata. User must manually select model in Cursor picker.

ParametersJSON Schema

Name	Required	Description	Default
`config`	No
`planPath`	Yes
`repoPath`	No
`alternativesCount`	No

TDQS

C2.3/5.0

Behavior2/5

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

No annotations are provided, so the description bears full responsibility. It states the tool is 'advisory' but does not clarify whether it modifies any data, what permissions are required, or what the output format is. The behavior is vaguely defined.

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

Conciseness2/5

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

The description is short (two sentences) but lacks critical information about parameters and behavior. Conciseness is not beneficial when it omits essential details.

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?

Given no annotations, no output schema, and no parameter descriptions, the description is highly incomplete. An agent cannot determine inputs, outputs, side effects, or return values from this description alone.

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?

The input schema has 4 parameters with 0% description coverage, and the tool description provides no explanation for any parameter. Terms like planPath, config, repoPath, and alternativesCount are left undefined, severely hindering correct invocation.

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

Purpose4/5

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

The description clearly states the tool's function: 'Advisory model recommendation based on plan analysis and registry metadata.' It distinguishes from siblings like list_models and get_model_profile by indicating it provides a recommendation rather than just listing or profiling.

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

Usage Guidelines2/5

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

The description includes a note that the user must manually select the model in Cursor picker, but provides no guidance on when to use this tool versus alternatives such as list_models or analyze_task. No explicit when-to-use or when-not-to-use criteria are given.

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

sync_metadataC

Sync model metadata from external sources. Blocked in privacy mode.

ParametersJSON Schema

Name	Required	Description	Default
`config`	No

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided; description asserts a sync operation and privacy restriction but does not disclose side effects, authentication needs, or what happens to existing data.

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?

Two sentences with no wasted words. Purpose is front-loaded, constraint follows immediately.

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

Completeness2/5

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

Lacks details on parameter usage, return values, error conditions, or usage context. Incomplete for a tool with a vague parameter and no annotations.

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?

Single parameter 'config' is an object with no schema description or constraints. The description adds no meaning about its structure, keys, or expected values.

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?

Clearly states verb (sync), resource (model metadata), and source (external). Adds constraint (blocked in privacy mode), distinguishing it from analysis and recommendation siblings.

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

Usage Guidelines2/5

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

Mentions a condition when not to use (privacy mode) but provides no guidance on when to use this tool vs. alternatives or prerequisites.

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.

9 tool updatesv0.1.0Jul 9, 2026
- First observedanalyze_repository
- First observedanalyze_task
- First observedestimate_cost
- First observedgenerate_cursor_guidance
- First observedget_model_profile
- First observedget_telemetry_summary
- First observedlist_models
- First observedrecommend_model
- First observedsync_metadata

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

B3.4/5.0

Scored 2026-07-09 12:45 across 9 tools

Disambiguation5/5

Each tool targets a distinct aspect of model routing: repository analysis, task analysis, cost estimation, guidance generation, profile retrieval, telemetry, listing, recommendation, and metadata sync. No two tools have overlapping purposes.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case, such as analyze_repository, estimate_cost, and list_models. This makes the tool set predictable and easy to navigate.

Tool Count5/5

With 9 tools, the server provides a comprehensive yet concise set of capabilities for an advisory model router. Each tool has a clear role, and the count is well within the optimal 3-15 range.

Completeness4/5

The tool surface covers the core workflow of analyzing tasks, recommending models, estimating costs, and retrieving metadata. Minor gaps exist, such as no tool for direct model selection or comparison, but these are intentional given the advisory nature.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
mcp AOAuth
io.scorecard
MCP server providing access to the Scorecard API to evaluate and optimize LLM systems.
RAG Systems Monitoring Testing & QA Tools
3
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
238
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2

Related MCP Servers

repo-memory-mcp
Knowledge & Memory Developer Tools
andyast
A
license
C
quality
D
maintenance
MCP server for sharing source-backed engineering memory across AI coding clients like Cursor and VS Code.
Updated 4 months ago (2026-05-12 00:27 UTC)
30
1
MIT
code-review-mcp
Code Analysis Testing & QA Tools
812Diasp
F
license
Not graded
quality
D
maintenance
Local MCP server for Cursor that analyzes code, finds bugs, generates tests and documentation via OpenRouter.
Updated 6 months ago (2026-03-26 19:39 UTC)
-
reposynapse
Code Analysis Developer Tools
Jul879n
A
license
A
quality
D
maintenance
Universal MCP server that analyzes any codebase and provides structured context to AI assistants. Dynamic, accurate, and token-efficient.
Updated 4 months ago (2026-05-27 15:34 UTC)
18
7 npm
MIT
cursor-mcp-bridge
Agent Orchestration Coding Agents Autonomous Agents
JaimeJunr
A
license
A
quality
B
maintenance
MCP server that lets any agent or MCP host delegate tasks to the Cursor CLI agent for fast, headless execution. Supports task delegation, project discovery, file analysis, and follow-up sessions.
Updated 2 days ago (2026-09-19 04:22 UTC)
3
14 npm
3
MIT