Skip to main content
Glama
littlebigbrains

@littlebigbrain/mcp

lbb_inspect

Read-only

Read graph context and exact facts: inspect entities, edges, state, history, and validate ontology conformance.

Instructions

Read graph context and exact graph facts. Actions: guide, ontology, ontology_conformance, schema, schema_preview, schema_audit, rules, ontology_search, metadata, entity, edges, state, history, transitions, why, traverse. entity returns one node's metadata, scalar attributes, current state, edges, history, and observations — its edge/history arrays are a display sample capped at the detail limit (counts holds the true totals), so on a high-degree node the response carries an edge_sample block with the capped totals and ready-to-run paged reads; follow those (or call edges/history directly, paged by row_limit/offset with direction/relation filters and an as_of/as_of_commit_seq pin) to read the full set — total_count tells you when to stop. transitions returns the ordered state-transition log of an entity's relation with dwell time at each value (cycle-time/process analysis). metadata includes temporal_coverage — check it before attempting as-of/daily views: as_of_valid_time_degenerate or single_commit_time means every point-in-time query returns the same snapshot. Use ontology_conformance to check the live data against the ontology's own capped-cardinality rules (derived SHACL sh:maxCount, whole-snapshot, never blocks a write) — distinct from schema_audit, which runs the separately-published SHACL shape bundle.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNo
as_ofNoValid-time snapshot pin (RFC3339): reproduce the node as of this instant.
graphNoGraph to target; defaults to the connection's graph
queryNoOntology concept, term, or relation to search
top_kNo
actionYesSelects the variant (one of: guide, ontology, ontology_conformance, schema, schema_audit, rules, schema_preview, ontology_search, metadata, entity, edges, state, history, why, traverse, transitions).
branchNoBranch to target; defaults to the connection's branch
cursorNoOpaque cursor from the previous page's `next_cursor`. The response is the unified list envelope { object:'list', data, has_more, next_cursor, total_count }; page a high-degree node (entity detail hard-caps its edge sample) by feeding next_cursor back here until has_more is false. Each row carries valid_time for a per-edge timeline.
detailNoResponse detail level. Defaults to compact.
offsetNoLegacy alias for `cursor` (still accepted); prefer paging with `cursor`.
shapesNo
max_hopsNo
ontologyNo
relationNoFilter to a single relation name.
directionNoEdges out of / into / touching the entity (default both).
entity_idNoEntity id (hex); alternative to entity_type+name
relationsNo
row_limitNoMax edges returned this page (server caps at 1000; default 150).
entity_typeNo
source_nameNo
source_typeNo
target_nameNo
target_typeNo
desired_modeNo
as_of_commit_seqNoSnapshot pin: reproduce the node (state, edges, history) as of this commit_seq.
base_shapes_versionNo
base_ontology_versionNo
Behavior5/5

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

The description goes well beyond the readOnlyHint annotation by detailing paging behavior (edge_sample block, capped totals, cursor usage), mutation safety ('never blocks a write'), and temporal behavior (as_of_valid_time_degenerate). It fully discloses operational traits without contradicting annotations.

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 front-loaded with the core purpose and a concise list of actions. Subsequent details are necessary given the tool's complexity, but some sentences could be trimmed (e.g., the long parenthetical about as_of_valid_time_degenerate). Overall, every sentence adds value.

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?

Given 27 parameters, no output schema, and complex nested objects, the description explains the key workflows (paging, action selection, temporal queries). It omits descriptions for a few parameters but compensates with schema descriptions. The distinction between ontology_conformance and schema_audit adds necessary context.

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?

With 48% schema description coverage, the description adds significant meaning by explaining the 'action' enum variants in detail, the paging parameters (row_limit, offset, cursor, direction, relation), and the purpose of 'entity' vs 'edges' vs 'history'. However, several parameters (name, graph, branch) are not discussed, relying on schema descriptions.

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 opens with 'Read graph context and exact graph facts,' establishing a clear verb and resource. It lists 15 distinct actions, making the scope specific. It is not a tautology of the name 'inspect,' and it provides enough detail to understand what the tool does, though it does not explicitly contrast with sibling tools.

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 description offers explicit guidance for specific actions, e.g., 'Use ontology_conformance to check the live data against the ontology's own capped-cardinality rules... distinct from schema_audit.' It also advises checking 'metadata includes temporal_coverage' before using as-of views. However, it lacks a general when-to-use vs. alternatives statement for the tool as a whole.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/littlebigbrains/lbb-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server