Skip to main content
Glama
Sign In
BoteX

BoteX

by kubainter
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

recommend_models

Fetches benchmark-based OpenRouter model recommendations to help you pick a suitable model ID before running a subagent, balancing cost and quality.

Instructions

[EN] Fetches the most cost-effective and capable models from OpenRouter based on live benchmarks.
USE THIS TOOL BEFORE calling `run_subagent` if you are unsure which model ID to use or want to optimize for cost/quality.
include_free=True also admits ':free' variants (non-ZDR — prompts may be
logged/trained on); they require allow_non_zdr or the openrouter-free
provider to actually run.

[PL] Pobiera rekomendacje modeli z OpenRouter na podstawie benchmarków.
Użyj tego narzędzia ZANIM wywołasz `run_subagent`, jeśli nie znasz dokładnego ID modelu.
include_free=True dopuszcza warianty ':free' (non-ZDR — prompty mogą być
logowane/trenowane); do uruchomienia wymagają allow_non_zdr albo
providera openrouter-free.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "recommend_models"
  }
}

Input Schema

NameRequiredDescriptionDefault
tierNoauto
limitNo
recipeNo
profileNo
providerNo
task_typeNocoding
include_freeNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.1.2
    • addedInput schema / properties / profile
      Added value: +{
+  "default": "",
+  "title": "Profile",
+  "type": "string"
+}
    • addedInput schema / properties / provider
      Added value: +{
+  "default": "",
+  "title": "Provider",
+  "type": "string"
+}
    • addedInput schema / properties / recipe
      Added value: +{
+  "default": "",
+  "title": "Recipe",
+  "type": "string"
+}
    • addedInput schema / properties / tier
      Added value: +{
+  "default": "auto",
+  "title": "Tier",
+  "type": "string"
+}
  2. Changed1 schema field changedv1.0.1
    • addedInput schema / properties / include_free
      Added value: +{
+  "default": false,
+  "title": "Include Free",
+  "type": "boolean"
+}
  3. First observedv1.0.0

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description still discloses the genuinely important behavior: include_free admits ':free' variants that are non-ZDR, meaning prompts may be logged or trained on, and that they require allow_non_zdr or the openrouter-free provider. That is real safety/privacy context an agent could not infer from the schema. It stops short of full behavioral coverage (no note on defaults, result ordering, or what the degradation is if a free model is rejected), so not a 5.

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 English portion is well front-loaded and tight, but the entire block is then duplicated verbatim in Polish, roughly doubling length for zero informational gain to a model agent. The include_free caveat, which matters most, is buried at the bottom of the English paragraph.

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?

An output schema exists, so return-value explanation is rightly omitted, and the workflow trigger is covered. But for a 7-parameter tool with 0% schema coverage and no annotations, six parameters receive no semantic guidance at all, leaving an agent unable to choose a tier, recipe, or profile.

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?

Schema description coverage is 0% across 7 parameters, so the description must carry the load — but it only explains include_free. Meaning and valid values for tier, recipe, profile, provider, task_type, and limit (the default tier is 'auto', task_type defaults to 'coding' — what else is allowed?) are left completely opaque in both schema and prose.

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?

"Fetches the most cost-effective and capable models from OpenRouter based on live benchmarks" gives a specific verb, resource, data source, and selection criterion. The description also names the downstream sibling (run_subagent), so an agent can place it precisely in a workflow rather than guessing among the many memory/task siblings.

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?

It states an explicit trigger: call this BEFORE run_subagent if you don't know the model ID or want cost/quality optimization. That is a concrete when-to-use condition tied to a named alternative, not an implied usage pattern.

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

Deploy Server

Other Tools