Skip to main content
Glama
Sign In
littlebigbrains

@littlebigbrain/mcp

by littlebigbrains
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

lbb_embeddings

Read-only

Inspect read-only embedding search setup: list embeddings and graph model with build/backfill status, get one, or preview class candidate facts, coverage, and sample text before planning queries.

Instructions

Search setup, read only: embeddings declared on classes (an embedding on a class covers its subclasses; one model per graph). list shows each embedding's status (serving and building version, backfill progress, lag) and the graph's model; get shows one; preview shows every candidate fact of a class with its coverage and examples, and the exact text of sample instances, and stores nothing. Declare, refresh, or change the model with lbb_embeddings_manage; search with lbb_query mode=search. list is the first step of planning a search (lbb_inspect action=guide has the recipe).

Input Schema

NameRequiredDescriptionDefault
dimNo
fromNopreview/declare: the fields, e.g. ["label", "description", "calls/label"]. Omit for the automatic choice; on an existing embedding, omit to keep its fields.
irisNopreview: the instances to show instead of a sample.
nameNoget: the embedding name.
classNopreview/declare: the class IRI.
graphNoGraph to target; defaults to the connection's graph
modelNomodel: the graph's new model. preview/declare: omit it; a graph has one model (the graph's, or the platform's default for the first embedding).
titleNopreview/declare: the field that names each hit, e.g. "display_name". Omit for the ontology's name property (skos:prefLabel, a property declared rdfs:subPropertyOf rdfs:label, else rdfs:label); on an existing embedding, omit to keep its name. preview reports title_source and, when the labels read as keys, title_suggestion.
actionYes
detailNoResponse detail level. Defaults to compact.
sampleNo
excludeNopreview/declare: fields to drop from the automatic choice.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.16.0
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / dim / maximum
      Added value: +9007199254740991
  2. Addedv0.5.2

TDQS

A4.5/5.0
Behavior5/5

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

Beyond readOnlyHint=true, the description explains that preview stores nothing, describes what list returns (serving/building version, backfill progress, lag, graph model), and clarifies embedding inheritance behavior. These details materially improve the agent's ability to predict behavior.

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 front-loads the purpose and action meanings, and most sentences earn their place by distinguishing actions or alternatives. It is somewhat dense and run-on in the middle, but for a 12-parameter tool the length is justified.

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?

It covers the essential behavior, action semantics, sibling routing, and preview side effects, which is strong given the absence of an output schema. Some parameter details and response-shaping options are left entirely to the schema, so it is not fully exhaustive.

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 75%, so the schema already carries most parameter meaning. The description adds useful semantics for the action parameter by explaining what list, get, and preview do, but it does not add much detail for the other parameters such as dim, sample, detail, iris, or exclude.

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 scope: read-only search setup for class embeddings, including subclass coverage and one-model-per-graph behavior. It then distinguishes the list, get, and preview actions clearly, so an agent can understand 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 routes mutations to lbb_embeddings_manage and search execution to lbb_query mode=search, and it says list is the first step of planning a search. The reference to lbb_inspect action=guide provides a concrete next step for the recipe.

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