Skip to main content
Glama
littlebigbrains

@littlebigbrain/mcp

by littlebigbrains
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

lbb_workflows

Read-only

Starter workflows and triggered workflows, read only. A starter workflow is a template; a triggered workflow is a workflow created from one on the graph.

Instructions

Starter workflows and triggered workflows, read only. A starter workflow is a template; a triggered workflow is a workflow created from one on the graph. It watches a class: when a published commit adds or changes instances of the class (or changes the watched fields), the workflow reads them and does its work. search.embed keeps an embedding of the class (the same as lbb_embeddings); ontology.fit reads text fields and files ontology suggestions (the same as lbb_fit_sources); workflow (a developer workflow) sends the new and changed instances to a workflow of the developer's worker as trigger messages, and that code writes the facts the workflow owns. documents.parse reads uploaded PDF files into pages with line boxes, documents.link connects mentions of the same thing across the documents (it writes DocEntry and DocMention instances and links each mention to the entry that defines or describes it), documents.map proposes each link as a FactProposal in the graph's own ontology (fact_subject, fact_predicate, fact_object, fact_confidence, fact_evidence) for a review workflow, and values.extract fills chosen properties from text, each value with a quote; read the files and their pages with lbb_files. starters lists the starter workflows this server offers with their group, settings and whether each can run here. list shows every triggered workflow of the graph with its state (backfilling, ready, paused, failed, unavailable), lag, counters, this month's spend and last error; get shows one (starter and name) with its own status in details (for workflow: the messages sent, the instances waiting, the message in flight and whether it is paused). preview shows what creating one would do (the resolved watch, the instance count and the workflow's own preview; for workflow, the first messages it would send), calls no model and stores nothing. workflows lists the same workflows as workflows with triggers (/v1/workflows/named): each one's target workflow type (LBB's own are lbb.* types), its shards (engine identities starter. and starter..), its routing field, its window, its one watch trigger, its status and each shard's inbox; name for one. queue (name) shows what a workflow's watch has not sent yet: each waiting instance with its shard and its origin (a backfill, a commit range with the watched fields and the requests that changed it, a run now, a schema change), the pass in progress, and per shard its message in flight and its first unfinished turns with their origins; page with after and limit. Message workflows of the workflow engine are not listed here. Create, refresh, pause or resume with lbb_workflows_manage; delete with lbb_workflows_delete.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
irisNopreview: the instances to show instead of a sample.
nameNoget: the triggered workflow's name. preview: the name a new workflow would get. workflows: one workflow's name (omit for all). queue: required.
ownsNopreview/use, developer workflow only: what your code writes. classes it creates instances of, relations it writes as out-edges of the watched instances, properties it writes on them. Owned outputs never trigger the workflow itself.
afterNoqueue: the position to start from (next_after).
batchNopreview/use, developer workflow only: instances per message, 1 to 64 (default 16).
classNopreview/use: the class whose instances the workflow watches (an IRI, or a name the ontology knows). Required unless the starter workflow's watch is fixed.
graphNoGraph to target; defaults to the connection's graph
limitNoqueue: items per page, 1 to 100 (default 50).
actionYes
detailNoResponse detail level. Defaults to compact.
fieldsNopreview/use: the fields whose change triggers the workflow, as embedding paths (transcript, label, about/label, <https://…>). Omit for the starter workflow's own choice.
paramsNopreview/use: the starter workflow's own settings, as listed in its catalog entry: search.embed takes model, dim and title; ontology.fit takes context (one sentence about the text, e.g. {"context": "interviews with employees"}); workflow takes none.
sampleNopreview: how many sample instances to show.
excludeNopreview/use: fields to drop from the automatic choice.
starterNoThe starter workflow's catalog id from action=starters, e.g. search.embed (embeddings on a class), ontology.fit (fit from text) or workflow (a developer workflow: your worker's workflow gets the instances). get/preview/use/refresh: required. pause/resume: omit to name a workflow with triggers.
triggerNodefine: the watch trigger's id (default watch). queue: the trigger whose queue to read.
workflowNopreview/use, developer workflow (starter=workflow) only, required there: the workflow of your worker that receives the messages. Creating it creates the instance starter.<name>.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.14.0

TDQS

A3.8/5.0
Behavior4/5

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

readOnlyHint=true is reinforced by 'read only', and the description adds real behavioral context beyond the annotation: preview 'calls no model and stores nothing', queue exposes in-flight messages and unfinished turns, and message workflows are out of scope. That is more than the annotation alone conveys, though mutating-adjacent behaviors (e.g. what preview's side-effect-free guarantee excludes) are only partially spelled out.

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?

It is front-loaded with the read-only framing and then walks the actions in order, which is good structure. However, the conceptual preamble on class watching and the very dense run-on sentences describing each action's output fields make it considerably longer than needed for a read-only query surface.

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 17-parameter, nested-object, no-output-schema tool, the description covers each action's return shape (state, lag, counters, spend, inbox, waiting instances, origins) reasonably well and pairs with the 94%-covered schema. Minor gaps remain around actions not discussed parameter-wise (graph, detail), but nothing critical to correct invocation 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 94%, so the schema already documents nearly every parameter, including action-specific usage notes. The description reinforces a few of these ('page with after and limit', the starter catalog ids) but adds little syntax or meaning beyond the structured fields. 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?

The description names the resource (starter and triggered workflows) and enumerates every action the tool dispatches (starters, list, get, preview, workflows, queue) with a one-line purpose for each. It explicitly separates itself from lbb_workflows_manage (create/refresh/pause/resume) and lbb_workflows_delete (delete), so an agent can place it among siblings. It loses a point only because the opening frame is a domain lecture rather than a crisp 'what this tool does' verb.

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 gives explicit routing for mutating actions: 'Create, refresh, pause or resume with lbb_workflows_manage; delete with lbb_workflows_delete', and states a scope exclusion ('Message workflows of the workflow engine are not listed here'). What it does not clarify is the boundary between the near-identical 'list' and 'workflows' actions, which an agent must infer for itself.

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