Skip to main content
Glama
@littlebigbrain/mcp

@littlebigbrain/mcp

lbb_model_choice_manage

Test candidate models on checked calls, compare scores and cost, then switch, revert, or set workflow model choices only after user confirmation.

Instructions

Model choice, writes. start tests a candidate model on the uses in jobs (without jobs, every use it can do that has checked calls): the server answers those checked calls again with the candidate and scores it and the model in use against the same ground truth. It changes no model and spends at most the trial budget ($3.00 by default) of model and judge cost; an open trial of the same use and candidate comes back as it is. Pick candidates from lbb_model_choice action=options (provider anthropic with an effort, or typesafe jev-latest). A trial runs by itself: poll lbb_model_choice action=trial until its status is no longer running. stop ends a trial; it keeps what it compared. switch makes the trial's use run its candidate on this graph from the next call on; only a trial that qualifies and compared with the model in use switches (ask to a Claude model, route to a Jev model). Show the user the trial's report (score, difference and interval, cost per call, time) and switch only what the user confirmed. revert puts the use back on LBB's model. put_choice chooses the model of a workflow use (use extract or decide, provider, model, effort) for the environment, or for one workflow with workflow: the next calls run it. Pick the model from the row's options in lbb_model_choice action=choices, show the user the price per million tokens of the model in use and of the new one, and set only what the user confirmed. delete_choice removes a choice: the use runs the environment's choice, else its default; it answers {id, object, deleted: true}. Both change only the model of future calls and remove no data, so neither asks for approval.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>"
    },
    "name": "lbb_model_choice_manage"
  }
}

Input Schema

NameRequiredDescriptionDefault
jobNorevert: the use to put back on LBB's model.
useNoput_choice / delete_choice: the workflow use.
daysNostart: the days the trial takes new checks (default 14).
jobsNostart: the uses to test it on.
graphNoGraph to target; defaults to the connection's graph
modelNostart / put_choice: the model id, e.g. claude-haiku-5-5 or jev-latest.
actionYes
detailNoResponse detail level. Defaults to compact.
effortNostart / put_choice: the effort of a Claude model.
targetNostart: the calls to compare (default 40).
providerNostart: the candidate's provider; put_choice: the model's provider (mock only on a local server).
trial_idNostop / switch: the trial id.
workflowNoput_choice / delete_choice: a named workflow of the graph; absent for the environment.
experimentNoput_choice: an experiment (exp_…) whose B this choice applies, with workflow; use and the model are B's change. The workflow must still run the experiment's A, else experiment_outdated; when it runs B already, nothing changes.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.17.0
    • addedInput schema / properties / experiment
      Added value: +{
      +  "description": "put_choice: an experiment (exp_…) whose B this choice applies, with workflow; use and the model are B's change. The workflow must still run the experiment's A, else experiment_outdated; when it runs B already, nothing changes.",
      +  "type": "string"
      +}
  2. Changed11 schema fields changedv0.16.0
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedInput schema / properties / action / enum
      Previous value: -[
      -  "start",
      -  "stop",
      -  "switch",
      -  "revert"
      -]New value: +[
      +  "start",
      +  "stop",
      +  "switch",
      +  "revert",
      +  "put_choice",
      +  "delete_choice"
      +]
    • changedInput schema / properties / effort / description
      Previous value: -"start: the effort of a Claude candidate."New value: +"start / put_choice: the effort of a Claude model."
    • removedInput schema / properties / job / $ref
      Removed value: -"#/properties/jobs/items"
    • addedInput schema / properties / job / enum
      Added value: +[
      +  "ask",
      +  "route",
      +  "rerank",
      +  "fit",
      +  "label"
      +]
    • addedInput schema / properties / job / type
      Added value: +"string"
    • changedInput schema / properties / model / description
      Previous value: -"start: the candidate model id, e.g. claude-haiku-5-5 or jev-latest."New value: +"start / put_choice: the model id, e.g. claude-haiku-5-5 or jev-latest."
    • changedInput schema / properties / provider / description
      Previous value: -"start: the candidate's provider."New value: +"start: the candidate's provider; put_choice: the model's provider (mock only on a local server)."
    • changedInput schema / properties / provider / enum
      Previous value: -[
      -  "anthropic",
      -  "typesafe"
      -]New value: +[
      +  "anthropic",
      +  "typesafe",
      +  "mock"
      +]
    • addedInput schema / properties / use
      Added value: +{
      +  "description": "put_choice / delete_choice: the workflow use.",
      +  "enum": [
      +    "extract",
      +    "decide",
      +    "embed"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / workflow
      Added value: +{
      +  "description": "put_choice / delete_choice: a named workflow of the graph; absent for the environment.",
      +  "type": "string"
      +}
  3. Addedv0.14.0

TDQS

A4.4/5.0
Behavior5/5

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

With annotations setting readOnlyHint=false and destructiveHint=false, the description adds substantial extra context: start changes no model and spends at most the trial budget ($3.00 by default), stop keeps comparisons, switch only applies to qualifying trials, and put_choice/delete_choice change only the model of future calls and remove no data. This is behaviorally rich and consistent with the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is dense but largely earns its place across six actions and fourteen parameters. However, it is delivered as a single run-on paragraph without delimiters or bullets between actions, which makes it harder to scan than necessary for a multi-action tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex 14-parameter, six-action tool with no output schema, the description covers the important action behaviors, budget limit, polling workflow, confirmation policy, and delete_choice's return shape. It does not explain return values for most other actions, but the annotations and high-coverage schema fill much of the remaining gap.

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 93%, and the schema already maps each parameter to its relevant actions and explains enums. The description reinforces that action mapping in prose but adds little parameter meaning beyond what the schema already provides, so the high-coverage 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?

The description opens with a specific domain ('Model choice, writes') and then enumerates each action's verb and resource: start tests a candidate model, stop ends a trial, switch makes a use run its candidate, revert puts a use back, put_choice chooses a workflow model, and delete_choice removes a choice. It also distinguishes this write-oriented tool from the read-oriented sibling lbb_model_choice, which supplies options, choices, and trial status.

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?

The description gives action-specific when-to-use guidance and names the alternatives: pick candidates from lbb_model_choice action=options, poll lbb_model_choice action=trial until status is no longer running, and use switch only for a qualifying trial with the correct Claude/Jev pairing. It also states confirmation requirements for switch and put_choice, so the agent knows both when and how to invoke each action.

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