@lobstack/mcp

Official

by Lobstack-ai

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Preview routing and cost

lobstack_route_preview

Read-onlyIdempotent

Score a prompt to preview which model the router would pick and what it would cost, without running inference or needing an API key.

Instructions

Score a prompt and report which model the Lobstack router would serve it with, and what that would cost. Runs no inference, spends nothing, and NEEDS NO API KEY — use it to pick a model before calling lobstack_chat, or to show what the gateway does on a machine with no key configured. Token counts are estimates; the billed figure comes from the provider's usage block on the real call.

Input Schema

TableJSON Schema

Name	Required	Description
`prompt`	Yes	The prompt to score. Scored, never sent to a model.
`plan_tier`	No	Plan id, which sets the ceiling the router may reach. Defaults to the pro ceiling.
`requested_model`	No	A model key to compare against, e.g. "claude-opus-5". Defaults to "auto".
`conversation_length`	No	Messages already in the conversation; it feeds the complexity score.
`expected_output_tokens`	No	How long the reply is expected to be. Defaults to half the prompt, which is the common chat ratio.

Output Schema

TableJSON Schema

Name	Required	Description
`tier`	Yes
`reason`	Yes
`routed`	Yes	True when the router would serve something other than what was requested.
`baseline`	Yes	Only present when a model was named and the router moved away from it — the "named" case.
`provider`	Yes
`estimated`	Yes	Always true. These are estimates, not a bill.
`complexity`	Yes
`served_label`	Yes
`served_model`	Yes	The model this prompt would actually be routed to.
`token_estimate`	Yes
`requested_model`	Yes
`estimated_cost_usd`	Yes	Null when the registry cannot price the model.
`estimated_cost_display`	Yes
`managed_key_configured`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 11, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description goes well beyond them by disclosing that it runs no inference, spends nothing, and requires no API key. It also flags that token counts are estimates and that the authoritative billed figure comes from the provider's usage block on the real call, which is exactly the caveat an agent needs.

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?

Three sentences, zero filler, with the cost/safety guarantee and the keyless property front-loaded before the usage routing. Every sentence earns its place.

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?

An output schema exists, so return values need no explanation, and the description still covers the safety profile, key requirement, cost semantics, and estimate-vs-billed distinction. Nothing an agent needs in order to call this correctly 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 each parameter already carries its own explanation including defaults for plan_tier and requested_model. The description adds only the estimate caveat around token accounting, so the baseline of 3 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?

States a specific verb and resource ('Score a prompt and report which model the Lobstack router would serve it with') plus the second output dimension, cost. It explicitly contrasts with the sibling that actually performs inference, lobstack_chat, so an agent can route between them without opening either schema.

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?

Gives two concrete selection conditions: pick a model before calling lobstack_chat, and demonstrate gateway behavior on a keyless machine. It names the alternative explicitly and the circumstance that picks it, so no inference about when to invoke this tool is required.

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

Deploy Server