Skip to main content
Glama
Wally-Ahmed

openrouter-subagents

by Wally-Ahmed
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

openrouter-subagents

An MCP server and CLI that exposes a model-agnostic "subagent" tool backed by OpenRouter — one API key, every model. It defaults to OpenRouter Fusion (openrouter/fusion), which runs a panel of models in parallel and has a judge model synthesize them into a single answer. Sibling to gpt-subagents-api (OpenAI API key) and gpt-subagents-subscription (ChatGPT subscription), and it ships the same orchestration patterns system.

Note: Uses an OpenRouter API key (Authorization: Bearer …) against the OpenAI-compatible Chat Completions endpoint. Not affiliated with or endorsed by OpenRouter.

Tools

Tool

What it does

ask_openrouter

Ask any OpenRouter model. model defaults to openrouter/fusion (multi-model synthesis); pass any OpenRouter id to override (e.g. anthropic/claude-opus-latest, openai/gpt-latest, or a fast cheap model). Write instructions (the system prompt) every call. Reasoning is fully controllable (see below). For Fusion only — analysis_models (the panel, 1–8 ids) and judge_model (the synthesizer).

list_patterns / get_pattern

Orchestration patterns for driving the model well (see below).

Fusion cost: a Fusion call bills for every panel model plus the judge. Reach for it when multiple perspectives are worth the spend (research, critique, high cost-of-being-wrong); for quick tactical prompts pass a single model id instead.

Reasoning & sampling controls

Any model's reasoning level can be set — the server exposes OpenRouter's full unified reasoning object, and OpenRouter translates it into whatever the target model natively speaks (OpenAI/Grok effort levels, Anthropic thinking budgets, Gemini thinkingLevel, Qwen thinking budgets, on/off flags for models like DeepSeek/GLM). A level a model doesn't support is mapped to the nearest one it offers.

Param

Meaning

reasoning_effort

Named level, lowest → highest: none, minimal, low, medium, high, xhigh, max. (none disables reasoning. On Anthropic these become budget ratios ≈ 0.1/0.2/0.5/0.8/0.95 of max_tokens, clamped to [1024, 128000]; on Gemini they map to thinkingLevel.)

reasoning_max_tokens

Exact reasoning token budget (Anthropic/Gemini/Qwen-style) for fine-grained control. Mutually exclusive with reasoning_effort.

reasoning_enabled

Turn default-strength reasoning on/off without picking a level or budget.

reasoning_exclude

Model still reasons, but the reasoning tokens aren't returned in the response.

temperature

Sampling temperature, 0–2 (lower = more deterministic). Applied when the model supports it; OpenRouter drops it for models that don't.

Note for agents (MCP or CLI): if a call fails or any error occurs — timeout, rate limit, model rejection, provider outage — retry the exact same call first (waiting briefly for transient errors). If it keeps failing, report the error and ask; do not downgrade or change the configuration the user set (model, reasoning level/budget, temperature, Fusion panel/judge) without their direct say-so. This rule is also baked into the server's MCP instructions and the CLI --help.

Related MCP server: agentloop

CLI

Everything the MCP server does is also available as a plain shell command — same client, same patterns library, but the answer comes back as raw text on stdout with zero JSON-RPC framing. For agents that can run shell commands, this is the token-cheap way to delegate: no MCP envelope in either direction, and piped stdin means large inputs (diffs, logs, files) never have to be echoed through the model's context at all.

npm run build        # compiles dist/cli.js
npm link             # optional: puts `openrouter-subagents` on your PATH

# ask (the subcommand is optional); raw answer on stdout
openrouter-subagents "why is the sky blue?"
openrouter-subagents ask -m anthropic/claude-haiku-4.5 -e xhigh "prove sqrt(2) is irrational"

# piped stdin becomes the prompt — or the context when a prompt is given
git diff | openrouter-subagents ask -p "review this diff for bugs" -e high
openrouter-subagents ask -p "summarize" --context-file big-report.md -m openai/gpt-5-mini

# patterns
openrouter-subagents patterns
openrouter-subagents pattern two-layer-cross-model-expert

Flags mirror the MCP tool: -m/--model, -i/--instructions (defaults to a terse general-purpose prompt), -p/--prompt, -c/--context (each with a --*-file variant), -e/--effort (none…max), --reasoning-tokens <n>, --reasoning on|off, --hide-reasoning, -t/--temperature, and Fusion's --analysis-models / --judge. --help shows the full reference. Exit codes: 0 success, 2 usage error, 1 API/network error.

Orchestration patterns

Patterns are reusable playbooks (Markdown in patterns/) that describe how to drive the expert tool — splitting work, bundling context, calling the expert, verifying its output against ground truth, and aggregating. They're exposed via list_patterns (catalog) and get_pattern("<name>") (full text), read from disk at call time (no rebuild to add one), and the server's instructions nudge the agent to consult them before non-trivial expert work.

name

what it does

two-layer-cross-model-expert

Wrap the OpenRouter expert in verifying Claude subagents so the orchestrator only ever sees parallel, context-cheap, ground-truth-checked conclusions. (Fusion makes the "cross-model" premise even stronger — the expert is a whole panel of model families.)

worker-orchestrator

Fan concrete work out to the OpenRouter worker (ask_openrouter with a fast model) through cheap Sonnet wrapper subagents — validated by execution, not a verification gate.

Both patterns ship a rendered diagram under patterns/html/. See patterns/README.md to add your own.

Setup

Requires Node 18+ (uses the global fetch) and an OpenRouter API key.

npm install
npm run build
cp .env.example .env       # then put your key in .env

Get a key at https://openrouter.ai/keys and set OPENROUTER_API_KEY in .env. .env is gitignored and must never be committed — only .env.example is tracked.

Configuring a default Fusion panel + judge (optional)

By default, openrouter/fusion uses OpenRouter's built-in "Quality" preset. You can override that default for every Fusion call from your .env:

# 1–8 panel models that answer in parallel:
OPENROUTER_FUSION_ANALYSIS_MODELS=anthropic/claude-opus-latest,openai/gpt-latest,google/gemini-pro-latest
# the judge that synthesizes them:
OPENROUTER_FUSION_JUDGE_MODEL=anthropic/claude-opus-latest

Precedence is per-call arg > .env default > OpenRouter preset, resolved independently for the panel and the judge: a per-call analysis_models / judge_model on ask_openrouter overrides the matching .env default, and these defaults apply only to openrouter/fusion (they're ignored for any other model).

Register with Claude Code

claude mcp add -s user openrouter-subagents -- node /absolute/path/to/openrouter-subagents/dist/server.js

(Claude Code reads MCP registrations at startup, so a newly added server appears after a full restart.)

How it works

  1. ask_openrouter builds an OpenAI-style Chat Completions request (system + user messages).

  2. For openrouter/fusion, the panel (analysis_models) and judge (judge_model) are resolved with precedence per-call arg > .env default > OpenRouter's preset, then sent as a plugins: [{ id: "fusion", … }] entry. With none of them set, OpenRouter's built-in Quality preset is used.

  3. The request is POSTed to https://openrouter.ai/api/v1/chat/completions with Authorization: Bearer $OPENROUTER_API_KEY; the answer is choices[0].message.content.

  4. Fusion is slow (parallel panel + synthesis), so the client uses a generous request timeout (~280s).

Security

  • The API key lives in .env (gitignored everywhere); only .env.example (a placeholder) is tracked.

  • Outbound instructions / prompt / context are run through a best-effort secret redactor (API keys, tokens, private keys) before they leave your machine — not a guarantee; don't paste highly sensitive data.

  • Data boundary: with the default openrouter/fusion, a single call fans your input out to several third-party providers at once (e.g. Anthropic, OpenAI, Google) via OpenRouter.

  • Local agent/editor state (.mempalace/, .claude/, CLAUDE.local.md, IDE folders) is gitignored.

License

MIT

Available Tools

3 tools
ask_openrouterA

Ask an OpenRouter model as a subagent. ONE tool for everything: model defaults to 'openrouter/fusion' (a panel of models answers in parallel and a judge fuses them), or pass any OpenRouter model id. Write instructions (its system prompt). Any model's reasoning level can be set: reasoning_effort (none/minimal/low/medium/high/xhigh/max, auto-translated to each model's native scheme) or reasoning_max_tokens (exact budget; not both), plus reasoning_enabled / reasoning_exclude. Optional temperature (0-2) where the model supports it. For Fusion you may set analysis_models (panel, 1-8) and judge_model (synthesizer). Use a single fast model + the worker-orchestrator pattern for concrete code work; use 'openrouter/fusion' or a strong model + reasoning_effort 'high' + the two-layer-cross-model-expert pattern for hard reasoning / architecture / security review. Note: a Fusion call bills for every panel model + the judge. Call list_patterns / get_pattern first for non-trivial work. If a call fails, retry it as-is first; if it keeps failing, report the error and ask — do NOT downgrade or change the user's chosen model/reasoning/temperature config without their direct say-so.

ParametersJSON Schema
NameRequiredDescriptionDefault
modelNoOpenRouter model id. Defaults to 'openrouter/fusion' (multi-model synthesis). Any valid OpenRouter id is accepted, e.g. 'anthropic/claude-opus-latest', 'openai/gpt-latest', or a fast, cheap model for worker tasks.openrouter/fusion
promptYesThe task or question for the model.
contextNoCode snippets, error messages, stack traces, constraints, or other relevant context.
judge_modelNoFusion judge/synthesis model id. Only valid when model is 'openrouter/fusion'.
temperatureNoSampling temperature, 0-2 (lower = more deterministic, higher = more varied/creative). Omit to use the model's default. Applied when the model supports it; OpenRouter drops it for models that don't (e.g. some reasoning-only models).
instructionsYesSystem instructions for the model (required): its role and how to respond. Write these for the task at hand — e.g. a coding-subagent prompt for worker-style work, or a reviewer/architect prompt for analysis.
analysis_modelsNoFusion panel: 1-8 OpenRouter model ids that answer in parallel. Only valid when model is 'openrouter/fusion'.
reasoning_effortNoNamed reasoning level, lowest to highest: none, minimal, low, medium, high, xhigh, max. OpenRouter normalizes this across providers (OpenAI/Grok take it natively; Anthropic gets a proportional thinking budget; Gemini a thinkingLevel); an unsupported level is mapped to the nearest one the model offers, never a hard error. 'none' disables reasoning where the model allows it (some models' reasoning is mandatory and 'none' is ignored). Use 'high' or above for deep audits / architecture review. Mutually exclusive with reasoning_max_tokens.
reasoning_enabledNoEnable reasoning at the model's default strength without picking a level or budget (true = default reasoning on; false = off). Prefer reasoning_effort when you care how much.
reasoning_excludeNoWhen true the model still reasons but the reasoning tokens are not returned in the response (saves context; you still pay for them).
reasoning_max_tokensNoExplicit reasoning token budget (Anthropic/Gemini/Qwen-style budget_tokens) for fine-grained control instead of a named level. Providers clamp to their own limits (e.g. Anthropic [1024, 128000]). Mutually exclusive with reasoning_effort.

TDQS

A4.9/5.0
Behavior5/5

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

No annotations provided, so description fully bears burden. It discloses default behavior (Fusion), reasoning normalization across providers, billing for Fusion calls, mutual exclusion of reasoning params, temperature limitations, and error handling policy. No annotation contradictions.

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?

Description is detailed but well-structured. Every sentence adds value; slight verbosity is justified given 11 parameters and complex interactions. Could be slightly more concise, but earns its length.

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 11 parameters, no output schema, and complex usage patterns, the description is complete. It covers parameter interactions, billing, error handling, and relationship to siblings. Sufficient for an agent to use correctly.

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

Parameters5/5

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

Schema description coverage is 100%, but description adds significant context: default model, reasoning level mapping, Fusion usage restrictions, mutual exclusion rule between reasoning_effort and reasoning_max_tokens, and temperature applicability. Adds meaning beyond raw schema.

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 starts with 'Ask an OpenRouter model as a subagent. ONE tool for everything:' clearly indicating it queries models. It distinguishes from siblings (get_pattern, list_patterns) by implying this is the general-purpose query tool. Scope is unambiguous.

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 on when to use a fast single model vs fusion, and when to call list_patterns/get_pattern first. Also includes error handling instructions (retry, do not change config without user say-so). Provides clear when-to/not-to-use context.

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

get_patternA

Return the full text of an orchestration pattern by name (see list_patterns). Use it to apply the pattern when orchestrating ask_openrouter calls.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesThe pattern name from list_patterns, e.g. 'two-layer-cross-model-expert'

TDQS

A4.2/5.0
Behavior3/5

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 describes a read operation returning text, but does not disclose what happens if the name is not found, any authentication needs, or side effects. The behavior is simple but could be more detailed.

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 sentences with no redundancy. It front-loads the primary purpose and adds usage context in a single line.

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 simple tool with one parameter and no output schema, the description is adequate. It could mention the return format (e.g., plain text) but the context of retrieving 'full text' is sufficient.

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 coverage is 100% and the description adds an example value and notes that the name comes from list_patterns. This provides practical guidance beyond the schema's field description.

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 'Return' and the resource 'full text of an orchestration pattern by name'. It references a sibling tool (list_patterns) for context, distinguishing its purpose from it.

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

Usage Guidelines4/5

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

The description says 'Use it to apply the pattern when orchestrating ask_openrouter calls', providing clear context for when to use the tool. It references list_patterns as a prerequisite but does not explicitly provide exclusions or alternatives.

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

list_patternsA

List available orchestration patterns for driving ask_openrouter. Call this before non-trivial expert work — reviews, audits, threat modeling, large-document analysis — then read the chosen one with get_pattern. Returns each pattern's name, title, summary, and when to use it.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.7/5.0
Behavior4/5

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 the return format (each pattern's name, title, summary, and when to use it). It does not mention any side effects, but as a read-only list operation, this is sufficient. Minor gap: does not explicitly state it is read-only.

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: first states the action and target, second provides usage guidance and return details. No redundant words. Front-loaded and efficient.

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 simplicity (no parameters, no output schema), the description fully covers what the tool does, what it returns, and when to use it. It also integrates well with sibling tools, making the context complete.

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?

The tool has no parameters, and the schema is fully covered. The description adds meaning by explaining what the list contains (name, title, summary, when to use) and the context for using it. Baseline 4 for zero parameters is appropriate.

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 uses a specific verb ('List') and resource ('available orchestration patterns for driving ask_openrouter'). It clearly states what the tool does and differentiates from siblings by mentioning get_pattern as the next step.

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?

Explicitly states when to call this tool ('before non-trivial expert work — reviews, audits, threat modeling, large-document analysis') and what to do next ('then read the chosen one with get_pattern'). Provides clear context for usage.

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. 3 tool updatesv1.0.0
    • First observedask_openrouter
    • First observedget_pattern
    • First observedlist_patterns
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.6/5.0
Disambiguation5/5

Each tool has a clear, distinct purpose: ask_openrouter for executing model queries, get_pattern for retrieving a specific pattern by name, and list_patterns for enumerating available patterns. There is no ambiguity or overlap.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in lowercase snake_case (ask_openrouter, get_pattern, list_patterns), making them predictable and easy to understand.

Tool Count5/5

With only 3 tools, the set is minimal yet complete for the server's purpose: executing model requests and managing orchestration patterns. Each tool is essential and well-scoped.

Completeness5/5

The tools cover the core workflow: list patterns, get a pattern, and ask OpenRouter using those patterns. There are no obvious missing capabilities given the server's stated purpose of subagent orchestration.

Maintenance

ActivityStale
ResponsivenessSyncing

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

  • Perplexity Advanced MCP

    fastmcp-me
    A
    license
    A
    quality
    D
    maintenance
    Advanced MCP server that uses OpenRouter and Perplexity APIs for enhanced query processing with multi-vendor support, query type optimization, file attachments, and robust retry logic.
    1
    MIT

  • agentloop

    luckeyfaraday
    A
    license
    Not graded
    quality
    A
    maintenance
    MCP server that enables AI agents to run a deterministic orchestration loop with decomposition, subagent execution, and review feedback across multiple LLM backends.
    55
    MIT

  • spiderswitch

    hiddenpath
    A
    license
    Not graded
    quality
    B
    maintenance
    MCP server that enables agents to dynamically switch between multiple AI models (OpenAI, Anthropic, Google, etc.) with unified protocol-driven configuration and capability discovery.
    Apache 2.0

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/Wally-Ahmed/openrouter-subagents'

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