@littlebigbrain/mcp

lbb_fit_sources_manage

Declare, dry-run, or refresh text-based fit sources to preview model proposals without filing changes, then run the job and track progress until suggestions are reviewed.

Instructions

Declare, dry-run or refresh a fit source (fit from text). Run lbb_fit_sources action=preview first and show the user the text the fit reads. dry_run runs the models on the first part of up to 3 instances (at most 60 s; truncated when one did not finish) and returns every proposal with its quote, its support score and what the checks made of it; it files nothing but spends model budget. declare sets the class, the fields and the context; the job then reads every instance and files suggestions (an existing source changes only what you name). refresh asks the job to run now and returns the status at once; the job also runs by itself after each published commit, so poll lbb_fit_sources action=get for progress. Nothing changes the ontology until a person accepts a suggestion.

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

Input Schema

Name	Required	Description
`from`	No	preview/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.
`name`	No	The fit source name (refresh: required).
`class`	No	preview/declare/dry_run: the class IRI whose instances hold the text.
`graph`	No	Graph to target; defaults to the connection's graph
`action`	Yes
`detail`	No	Response detail level. Defaults to compact.
`context`	No	preview/declare/dry_run: one sentence about the text, e.g. "interviews with employees about their work processes" (at most 500 characters).
`exclude`	No	preview/declare/dry_run: fields to drop from the automatic choice.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.16.0Oct 29, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
Addedv0.14.0Oct 14, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations only cover the read-only/destructive/open-world axes, and the description adds real behavioral depth on top: dry_run files nothing but costs model budget and truncates at 60s/3 instances, declare files suggestions and only rewrites named fields, refresh returns immediately while the job also self-triggers after commits. The crucial safety fact — 'Nothing changes the ontology until a person accepts a suggestion' — is stated explicitly and is consistent with destructiveHint=false.

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?

It is front-loaded with the verb triad and each sentence adds a distinct operational fact, so little is wasted. It is, however, a single dense run-on paragraph with semicolon-chained clauses, which makes it harder to scan than a short bulleted action breakdown would be.

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?

With no output schema, the description steps in and sketches the returns for both dry_run (proposals with quote, support score, check results) and refresh (immediate status), plus the async follow-up via lbb_fit_sources action=get. Combined with the mutation/side-effect disclosure, an agent has everything needed to call this correctly.

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 88%, so the schema already documents `from`, `name`, `class`, `context`, `exclude` and `detail` well. The description adds only indirect hints ('sets the class, the fields and the context', 'only what you name'), leaving `graph` and `detail` unaddressed beyond the schema. Baseline 3 is appropriate when the schema carries the parameter burden.

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?

Opens with a specific verb triad plus resource ('Declare, dry-run or refresh a fit source') and then defines each action separately, so the agent knows exactly what the tool does. It does not name the sibling `lbb_fit_sources` as the alternative preview surface in a way that distinguishes them cleanly — it only says to 'Run lbb_fit_sources action=preview first', which is a reference rather than a differentiation.

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?

Gives an explicit prerequisite sequence ('Run lbb_fit_sources action=preview first and show the user the text'), when to pick each action, and how to follow progress ('poll lbb_fit_sources action=get'). It also warns that dry_run spends model budget, which is a use-vs-avoid condition, not just a description.

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