Skip to main content
Glama
Sign In
@littlebigbrain/mcp

@littlebigbrain/mcp

by littlebigbrains
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

lbb_fit_sources

Read-only

Inspect read-only fit sources declared on classes: list or get status, progress, spend, and errors, or preview text fields and sample instances without calling a model.

Instructions

Fit from text, read only: fit sources declared on classes. A fit source names the fields of a class that hold text (transcripts, documents); the server reads every instance, proposes ontology changes (classes, properties, relations) with verbatim quotes, checks them, and files them as ontology suggestions with origin id fit:. list shows each source's status (progress, lag, instances read, proposals kept and dropped, suggestions per status, this month's spend, last error) and the stack's monthly budget; get shows one; preview shows the fields, every candidate field of the class and the text of sample instances, calls no model and stores nothing. Declare, refresh or dry-run with lbb_fit_sources_manage; list the suggestions with lbb_inspect action=ontology_suggestions.

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

Input Schema

NameRequiredDescriptionDefault
fromNopreview/declare/dry_run: the fields that hold the text, as embedding paths (transcript, label, about/label, <https://…>). Omit for the long text facts of the class.
irisNopreview: the instances to show instead of a sample.
nameNoget: the fit source name.
classNopreview/declare/dry_run: the class IRI whose instances hold the text.
graphNoGraph to target; defaults to the connection's graph
actionYes
detailNoResponse detail level. Defaults to compact.
sampleNo
contextNopreview/declare/dry_run: one sentence about the text, e.g. "interviews with employees about their work processes" (at most 500 characters).
excludeNopreview/declare/dry_run: fields to drop from the automatic choice.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.16.0
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Addedv0.14.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already mark it read-only, but the description adds substantial context: the server reads every instance, proposes ontology changes with verbatim quotes, checks them, and files suggestions under origin id fit:<name>. It also discloses that preview calls no model and stores nothing, and explains what list returns, including progress, lag, spend, and budget.

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

Conciseness4/5

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

The description is dense but front-loaded with the core read-only purpose, then moves through list/get/preview and alternatives. It is appropriately sized for a complex 10-parameter tool, though the long semicolon-heavy sentence could be easier to scan.

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?

There is no output schema, so the description does much of the return-value work by explaining list status fields and budget, get behavior, and preview behavior. Combined with the read-only annotation, it gives enough context for correct invocation.

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 80%, so the schema already carries much of the parameter meaning. The description adds useful action-specific context, especially for preview/declare/dry-run fields and the role of context and exclude, though it does not explicitly explain every parameter such as sample or iris beyond the schema.

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 states a specific read-only resource and process: fit sources declared on classes, which read instances and propose ontology changes. It clearly distinguishes list/get/preview behavior and names sibling tools for related operations, so an agent can identify the tool without opening the 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?

It explicitly says to use lbb_fit_sources_manage for declare, refresh, or dry-run, and lbb_inspect action=ontology_suggestions to list suggestions. It also distinguishes preview as a no-model, no-storage operation, giving clear when-to-use guidance versus alternatives.

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