Skip to main content
Glama
@littlebigbrain/mcp

@littlebigbrain/mcp

lbb_model_choice

Read-only

Inspect which model each graph use runs, review trial comparisons against checked ground-truth calls, and list switches or workflow model choices.

Instructions

Model choice, read only: which model each use of a model on the graph runs, and trials that test other models against the graph's ground truth (the checked calls: a person's review, else the judge's verdict). options shows per use the model it runs now (current), LBB's model (default), a switch (switched), its checked calls, and the models a trial can test with their efforts, prices and whether the server holds their key; available=false with a reason when trials cannot run. trials lists the trials, newest first, each with its report: calls compared, both models' right share, mean score (0 to 1), cost per call and median time, the difference with its 95% interval (delta, ci_low, ci_high), outcome (too_few, better, same, worse) and qualifies (meets the bar: at least 20 calls, at most 5 points worse at the low end, no more failures, cheaper or better). trial reads one trial with its compared calls; trial_call reads one call with both answers and the ground truth. switches lists the switched uses. choices lists the model choices of the workflow uses (extract, decide, embed): without workflow the environment's row of each use and each workflow's own choice; with workflow the row in force for each of its uses (its own, else the environment's, else the default). A row has scope (environment or workflow), model, source (person or default), since, by, the model before, the use's default and options (the models it can run, with efforts, list prices and whether the server holds their key). One page in data: has_more and next_cursor page it with cursor and limit. Start, stop, switch or revert, and set or remove a choice, with lbb_model_choice_manage.

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"
  }
}

Input Schema

NameRequiredDescriptionDefault
jobNotrials: only the trials of this use.
useNochoices: one use.
graphNoGraph to target; defaults to the connection's graph
limitNotrials: at most this many, newest first (default 20); choices: rows per page (default 50).
actionYes
cursorNochoices: the next_cursor of the page before.
detailNoResponse detail level. Defaults to compact.
call_idNotrial_call: a call id from the trial's calls.
trial_idNotrial / trial_call: the trial id.
workflowNochoices: a named workflow: the rows in force for it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.16.0
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedInput schema / properties / action / enum
      Previous value: -[
      -  "options",
      -  "trials",
      -  "trial",
      -  "trial_call",
      -  "switches"
      -]New value: +[
      +  "options",
      +  "trials",
      +  "trial",
      +  "trial_call",
      +  "switches",
      +  "choices"
      +]
    • addedInput schema / properties / cursor
      Added value: +{
      +  "description": "choices: the next_cursor of the page before.",
      +  "type": "string"
      +}
    • changedInput schema / properties / limit / description
      Previous value: -"trials: at most this many, newest first (default 20)."New value: +"trials: at most this many, newest first (default 20); choices: rows per page (default 50)."
    • addedInput schema / properties / use
      Added value: +{
      +  "description": "choices: one use.",
      +  "enum": [
      +    "extract",
      +    "decide",
      +    "embed"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / workflow
      Added value: +{
      +  "description": "choices: a named workflow: the rows in force for it.",
      +  "type": "string"
      +}
  2. Addedv0.14.0

TDQS

A4.5/5.0
Behavior5/5

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

With readOnlyHint=true, the description adds substantial context beyond the annotation: trial eligibility (available=false with a reason), trial outcome categories, qualification thresholds, pagination via has_more/next_cursor, and the exact fields returned per action. It does not contradict the read-only annotation.

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 purpose is front-loaded and no sentence is pure fluff, but the description is a long, dense paragraph that is difficult to scan across six actions and ten parameters. Some phrasing, such as the pagination sentence, could be clearer and more structured.

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 complex ten-parameter read tool with no output schema, the description explains each action's returned data, trial fields, pagination, and failure behavior. It provides enough detail for an agent to call the correct action and interpret the result.

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 high at 90%, but the description adds action-specific meaning: job restricts trials to a use, use restricts choices to one use, trial_id/call_id identify the requested trial or call, and workflow selects rows in force for that workflow. It also clarifies limit/cursor paging behavior beyond the schema descriptions.

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 names the resource (model choice) and states it is read-only, then enumerates the concrete actions: options, trials, trial, trial_call, switches, and choices. It clearly distinguishes this read tool from the mutation sibling lbb_model_choice_manage.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explains what each action returns and explicitly routes start/stop/switch/revert and set/remove operations to lbb_model_choice_manage. It does not give detailed criteria for choosing among the read actions, but their purposes are sufficiently clear from the described outputs.

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