Skip to main content
Glama
Wally-Ahmed

openrouter-subagents

by Wally-Ahmed

ask_openrouter

Configure and send prompts to OpenRouter models as a subagent, with reasoning controls, temperature, and optional multi-model Fusion synthesis.

Instructions

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.

Input Schema

TableJSON 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.
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.

Install Server

Other Tools

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