Skip to main content
Glama

LLM Pricing

by io.github.skakumanu
OverviewDiscussionsAdmin

recommend_model

Recommend the optimal LLM model from a free-text description of your use case — no need to already know the routing engine's task_type vocabulary. Classifies the description into a task type, then runs it through the same routing engine behind /router/recommend (live pricing + benchmark quality, hard filters for cost/quality/context window, scored by quality-per-dollar). Returns the best match plus up to 3 alternatives. Read-only — use predict_cost first if you also want per-model cost estimates for an actual prompt, and optimize_workload if you have several distinct task types to route at once.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
task_typeNoOptional explicit task type, bypassing auto-classification of the description. Options: classification, extraction, summarization, qa, code_generation, translation, chat, content_generation, reasoning, function_calling, data_analysis, rewrite
descriptionYesFree-text description of the use case, e.g. 'summarize long customer support tickets' or 'generate Python unit tests'
ide_contextNoIDE context hint — boosts IDE-native tools: 'copilot' | 'cursor' | 'windsurf' | 'claude_code' | 'jetbrains' | 'amazon_q'
avg_input_tokensNoAverage input tokens per request (default: 500)
avg_output_tokensNoAverage output tokens per request (default: 200)
min_quality_scoreNoMinimum required quality score (0-100)
min_context_windowNoMinimum required context window size (tokens)
monthly_budget_usdNoMonthly spend ceiling in USD. Combined with estimated_monthly_requests, avg_input_tokens, and avg_output_tokens to hard-filter models that would exceed it.
prefer_low_latencyNoPrioritise lower-latency models (default: false)
preferred_providerNoPreferred provider name (10% score boost applied)
max_cost_per_1m_tokensNoMaximum acceptable average cost per 1M tokens (USD)
exclude_reasoning_modelsNoExclude slow thinking/reasoning models (default: false)
estimated_monthly_requestsNoEstimated requests per month (default: 1000)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

No annotations exist, so the description carries the full burden, and it discloses a lot: read-only, the internal classify-then-route pipeline, live pricing plus benchmark quality, hard filters, quality-per-dollar scoring, and the return shape (best match + up to 3 alternatives). It lacks auth, rate-limit, or failure-mode detail, keeping it short of a 5 for a no-annotation tool.

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?

Front-loaded with the core purpose and benefit, then behavior, then routing to siblings. It is a dense single paragraph and slightly long, but essentially every clause carries distinct information; no filler sentences.

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?

With no output schema and 13 parameters, the description steps in to describe the return value (best match plus alternatives) and the decision pipeline. Combined with 100% schema coverage, an agent has everything needed to call it correctly.

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 description coverage is 100%, so the baseline is 3, but the description adds genuine meaning: it explains that task_type is an optional explicit override of the auto-classification, and ties the hard-filter params (cost/quality/context window) to the routing behavior. That exceeds what the schema alone conveys.

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?

States a specific verb (recommend) and resource (LLM model) and immediately scopes it: from a free-text use-case description, without needing the task_type vocabulary. It is cleanly distinguishable from predict_cost and optimize_workload, which it names.

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 routes: 'use predict_cost first if you also want per-model cost estimates for an actual prompt, and optimize_workload if you have several distinct task types to route at once.' The conditions selecting each alternative are stated, not implied.

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

All LLM Pricing toolsInspect
Try in Browser
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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources