Skip to main content
Glama
Sign In
littlebigbrains

@littlebigbrain/mcp

by littlebigbrains
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

lbb_reviews

Read-only

Retrieve read-only review questions from workflows, agents, and people, including details and grouped patterns, to support human-in-the-loop decisions.

Instructions

Review items, read only: questions for a person (human in the loop) that workflows, integrations, agents and people file. Kinds and their decisions: change (accept an ontology change, identities or facts: accept, reject, cant_tell), value (confirm one value of a property, question.property and question.value: accept, correct with the right value, reject, cant_tell; accept and correct commit the value), choice (pick one of question.options: choose with option, cant_tell), grade (grade question.output on the scale question.options: choose with option, cant_tell), answer (answer question.prompt in words: accept with the text in note, cant_tell). Status is open, answered or withdrawn. Scope is live (default) or test: a test item writes nothing. list returns one page as the server sends it ({object, data, has_more, next_cursor}), the latest update first: pass next_cursor as cursor, with the same filters, for the next page. get reads one item (rev_…) with its question, evidence, answer and effects. patterns groups the live items that ask one decision, the largest first. Evals files the questions of model checks (origin_id evals:checks), calibration sessions (evals:calibration), golden queries (evals:golden) and the values the two arms of an experiment differ on (evals:datasets) as grade and choice items; eval_id keeps the items of one record (for evals:datasets, the dataset), and their answer is the record's label. An item of evals:datasets asks whether one value is right or wrong, and the origin names the dataset item, the property and the value. File, answer, comment on or withdraw items with lbb_reviews_manage.

Input Schema

NameRequiredDescriptionDefault
idNoget: the item's id, rev_… (or the sg_… of a change).
keyNolist: the items filed under this producer key, or these keys (at most 100).
runNolist: the items of the run that asked.
kindNolist: one kind, or a list of kinds.
typeNopatterns: only the patterns of this kind of suggestion.
graphNoGraph to target; defaults to the connection's graph
limitNolist: items per page, at most 5, 20 or 100 by detail (compact, standard, full) and by default that many, so the page comes back whole.
scopeNolist: live (the default) or test.
actionYes
cursorNolist: the next_cursor of the page before.
detailNoResponse detail level. Defaults to compact.
statusNolist, patterns: only the items in this state.
eval_idNolist, patterns: the items Evals filed for one record (eval.id): a calibration session, a model call's check, a golden, a dataset.
workflowNolist: the items of the workflow that asked.
origin_idNolist, patterns: the producer's id, for example starter:areas.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.17.0
    • changedInput schema / properties / eval_id / description
      Previous value: -"list, patterns: the items Evals filed for one record (eval.id): a calibration session, a model call's check, a golden."New value: +"list, patterns: the items Evals filed for one record (eval.id): a calibration session, a model call's check, a golden, a dataset."
  2. Addedv0.16.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, and the description stays consistent while adding real operational context: list returns one page shaped as {object, data, has_more, next_cursor} with newest first, cursor must be reused with the same filters, scope=test writes nothing, and limit is capped by detail level. These are behaviors not derivable from 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 with useful information, but it arrives as one long run-on paragraph mixing purpose, decision taxonomy, pagination, and Evals provenance. It is front-loaded on purpose but not scannable; splitting the kind/decision table from the paging contract would cost nothing and gain a lot.

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 15-parameter, three-action tool with no output schema, the description covers the return shape of list, the contents of get (question, evidence, answer, effects), and the grouping behavior of patterns, which is what an agent needs before calling. Minor gaps remain around how filters compose across key/run/workflow/origin_id.

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 coverage is 93%, so the baseline is 3, but the description adds genuine meaning on top: what cursor must be paired with, that scope=test is non-writing, what the decisions mean per kind (accept/correct/reject/cant_tell and their commit effects), and that eval_id scopes to one record. The graph parameter and some filter interplay remain schema-only.

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 ('Review items, read only') and then enumerates the five item kinds with their decisions, which is far beyond restating the name. It also explicitly separates itself from the sibling that mutates: 'File, answer, comment on or withdraw items with lbb_reviews_manage.' An agent can pick this over lbb_reviews_manage 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 Guidelines4/5

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

The read-only boundary and the routing to lbb_reviews_manage for all writes is an explicit when-not rule. It also explains each of the three actions (list/get/patterns) and the pagination contract. It does not differentiate this from adjacent read siblings such as lbb_evals or lbb_inspect, which is the remaining gap.

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