Skip to main content
Glama
StudioPlatforms

aistupidlevel-mcp

by StudioPlatforms
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Ask via Smart Router

ask_router

Route a prompt to the appropriate LLM and get the answer plus the model, provider, routing reason, and latency. Set sandbox true for a free mock answer.

Instructions

Send a prompt through the AI Stupid Level Smart Router and return the answer, together with which model answered, its provider, why the router chose it and the latency. The router calls the model with the provider keys saved in the user's ASL account, so a real call is billed by that provider and counts against the router plan; set sandbox: true for a free mock answer. Needs a router key (ASL_ROUTER_KEY).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoRouting mode (default auto = the strategy saved in the account): auto-best (highest combined score), auto-coding, auto-reasoning, auto-tooling (top model on that benchmark), auto-task (reads the prompt and picks the benchmark), auto-value, auto-value-coding, auto-value-reasoning, auto-value-tooling (most points per measured dollar among models within 5 points of the best), auto-fastest-quality, auto-consistent (fastest or steadiest near-top model), auto-fastest, auto-cheapest (no quality bar).
promptYesThe user message to send.
systemNoAn optional system message.
sandboxNoSandbox: run the real routing as if the account had a key for every provider and return a mock answer. Nothing is called, spent or counted.
pin_modelNoPin a specific model id (for example gpt-6-sol) instead of a routing mode.
max_tokensNoUpper bound on the answer length in tokens.
reasoning_effortNoReasoning effort for models that support it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior5/5

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

With annotations covering only the safety profile, the description carries substantial extra burden and delivers: it names the auth requirement (ASL_ROUTER_KEY), discloses billing and quota consequences of a live call, explains the sandbox escape hatch, and enumerates the response fields (model, provider, routing reason, latency).

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?

Three dense sentences, front-loaded with the action and its return value before cost and auth caveats. Slightly long but each sentence adds distinct information (output, billing, sandbox, key), so little is wasted.

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?

For a 7-parameter open-world execution tool with no output schema, the description covers the two things an agent most needs before calling: the auth prerequisite and the cost/mutation implications, plus the shape of the result. Nothing essential is missing.

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

Parameters3/5

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

Schema description coverage is 100% and the mode enum is documented in exhaustive detail inside the schema, so the schema does the heavy lifting. The description only surfaces sandbox in prose, adding little beyond structured data; baseline 3 is appropriate.

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?

States a specific verb and resource ('send a prompt through the AI Stupid Level Smart Router and return the answer') plus the return payload, so the agent knows this is the execution tool. It is distinguishable from the get_* siblings, but it never names its closest sibling, preview_route, which is the natural confusion point.

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?

Offers real usage context: a live call is billed by the provider and counts against the router plan, while sandbox: true gives a free mock. However, it gives no explicit when-to-use-vs-alternative guidance, notably no 'use preview_route first to inspect the decision without spending' routing.

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