@littlebigbrain/mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.4.2
Disambiguation5/5
Each tool targets a distinct phase of the knowledge-graph workflow: querying, inspecting, model-data access, writing, configuration, branching, and observation. Even the two read-focused tools are cleanly separated by SPARQL/expert queries versus graph context and exact facts.
Naming Consistency5/5
All tools share the uniform lbb_ prefix and use short, lowercase, action-oriented names. The convention is predictable and easy to scan, with no mixed casing or synonymous verb clutter.
Tool Count5/5
Seven tools is well-scoped for a knowledge-graph server with query, inspection, commit, configure, branch, and memory workflows. Each tool earns its place and the count keeps the surface navigable despite each tool carrying several internal modes.
Completeness4/5
The surface covers the core lifecycle: read, write, retract, inspect, configure ontology, branch, merge, and capture observations. A minor gap is the lack of an explicit branch listing/deletion tool outside of merge consuming the source branch, but inspection and state actions partially cover this.
Average 3.9/5 across 7 of 7 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 15 commits in the last 12 weeks
- Last stable release on August 24, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is not read-only (readOnlyHint=false) and not strictly destructive (destructiveHint=false). The description adds that schema publication is atomic and does not validate the whole graph, which is a useful behavioral trait. However, it omits other important details like error handling, rollback behavior, or permission requirements.
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 concise at two sentences, with the first stating the overall purpose and the second adding a specific behavioral note. No redundant information. However, it could be slightly better structured with bullet points or clearer separation of the three actions, especially given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 parameters, nested objects, no output schema), the description is far too brief. It does not explain what the tool returns, how to construct the 'ops' array for different operations, or cover error scenarios. An agent would need to infer much from parameter names alone, which is insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 36% schema description coverage, the description should compensate by explaining key parameters, but it does not. It mentions the 'action' enum values but offers no additional meaning for the 'ops' array, 'graph', 'branch', or other parameters. The schema itself provides some descriptions (e.g., for ops items), but the description fails to add value beyond that.
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 clearly states the verb 'mutate' and the resource 'graph configuration', and lists three specific actions (define_ontology, evolve_ontology, publish_schema). This distinguishes it from siblings like lbb_commit (data mutations) and lbb_search (queries). However, it does not elaborate on the unique purpose of each action, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a specific behavioral note for publish_schema (atomic activation, no full graph validation) but gives no guidance on when to use this tool versus alternatives, such as when to evolve vs. define an ontology. There is no mention of prerequisites, context, or exclusions, so an agent has little support for choosing this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true, so no contradiction. Description adds context about operating 'over one pinned published snapshot' and explains action-specific behavior (shadow_eval body, dataset returns bounded examples). This adds value beyond 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?
Two sentences with no wasted words, but the information could be better structured (e.g., separating action types into a list). Still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so description should clarify return values, but it doesn't. It also omits explanation of the 'limit', 'graph', 'branch', and 'detail' parameters. While it covers the two action groups, it is incomplete for a 7-parameter tool with nested objects.
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 43%, so the schema leaves gaps. The description partially compensates by explaining the 'shadow_eval' action requires the body parameter and that dataset actions use an optional signal split, but does not cover graph, branch, limit, or detail parameters.
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 clearly states the tool reads model-training inputs or compares retrieval configurations, using verbs like 'Read' and 'compare'. It distinguishes from sibling tools by focusing on model-training and snapshots, but could be more specific about the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like lbb_query or lbb_inspect. The description lacks explicit context for selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation is consistent with the description's 'Read' framing. The description adds useful behavioral detail beyond the annotation: schema does not run validation, ontology_conformance serves a durable report, and entity returns a bounded edge neighborhood. These specifics help the agent predict side effects and scope.
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 compact and front-loaded with the primary purpose. Each sentence adds either action enumeration, behavioral clarification, or routing guidance. The action list is somewhat redundant with the schema enum, but it is not padded with filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 11 action variants and 16 parameters and no output schema, the description leaves many actions unexplained, including guide, ontology, metadata, state, history, transitions, and why. It also does not describe return shapes or parameter combinations. The description is not complete enough to guide correct invocation across the full action space.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 50%, the description needed to compensate for undocumented parameters such as name, top_k, relation, entity_type, source_name, source_type, target_name, and target_type. It does not address these, instead focusing on action-level meaning. The description adds some high-level context for action selection but leaves many parameter semantics unresolved.
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 opens with a specific verb and resource ('Read graph context and exact graph facts') and enumerates all 11 action variants, giving the agent a clear sense of the tool's domain. It also distinguishes the tool from lbb_query. However, 'graph context' is somewhat vague, and the action list alone does not fully define what each action returns.
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 explicitly directs the agent to lbb_query for precise SPARQL property path selection, which serves as a clear when-not-to-use signal. It also gives targeted usage context for schema, ontology_conformance, and entity actions. It does not explain when to use the remaining actions, but the core routing guidance is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the minimal annotations (readOnlyHint=false, etc.). It explains the branching model, the anchoring vs. needs_review outcomes, the auto-merge with SHACL validation, and the server flag dependency. No contradictions with 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 well-structured and front-loaded with the main purpose. All sentences add value, though some technical details (e.g., auto_merge behavior) could be slightly more streamlined. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters and no output schema, the description covers the core logic (anchoring, confidence, auto-merge) and mentions the server flag. However, it does not describe the return format or error conditions, leaving agents to infer the response structure.
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 100%, providing baseline parameter documentation. The description adds interpretive context (e.g., 'omit with extract:false to store the episode only', 'confidence >= 0.8 to mint new entities'), but does not fully explain all parameters beyond what the schema already states.
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 clearly states the tool's purpose: storing conversation turns verbatim as an EPISODE evidence entity and anchoring/gating facts on an observe branch. It uses specific verbs ('remember', 'store', 'anchor', 'gate') and distinguishes it from siblings by highlighting the observe branch and the fact anchoring behavior.
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 provides context on when to use the tool (for adding facts without poisoning the main graph) and explains the anchoring logic and confidence threshold. However, it lacks explicit 'when not to use' or direct comparisons to sibling tools like lbb_commit or lbb_ground.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with readOnlyHint=true, the description adds substantial behavioral detail: content-addressed entities should be anchored by label, SPARQL IRIs are auto-lowercased with a notes entry, uppercase local names silently match nothing, body-level as_of is rejected while top-level works, and only SELECT/ASK are accepted. These quirks are critical to correct invocation and are disclosed clearly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The free-text description is four dense sentences with no filler, front-loading the tool's purpose and core constraint. The long examples live inside the body schema where they are needed, rather than bloating the main description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Structured and SPARQL modes are documented in depth with examples, constraints, and response hints like row_page.total and value_keys. But analyze mode is only named, and the analyze-oriented parameters (metric, chart, field, top_k) are unexplained, leaving a material invocation gap. With no output schema, the description is not fully self-sufficient.
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?
The body and query parameters receive exhaustive semantic treatment with complete runnable examples, type wrappers, and grouping/filter semantics. However, 5 of 15 parameters (chart, field, metric, top_k, sparql) have no meaningful explanation, and the analyze mode they likely serve is not described, so the parameter surface is not fully covered.
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 opens with 'Analytical and expert reads' and states 'SPARQL is the only query surface', making clear this is a read/query tool. It names three modes (structured, sparql, analyze) and gives URI conventions, so an agent can identify the resource being queried. It does not explicitly position itself against siblings beyond mentioning lbb_inspect for ontology discovery, so it stops short of 5.
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 mode-selection guidance: structured mode rejects UNION/OPTIONAL/MINUS/EXISTS combinators and directs the agent to SPARQL text, and it instructs using lbb_inspect action=ontology to discover relation/type names. Snapshot pinning preference is also stated (`prefer the top-level as_of / as_of_commit_seq`). No comprehensive when-not-to-use guidance is given, but within-tool alternation is well covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals critical behavioral traits: merge replays as one commit, SHACL validation is performed, conflicts are reported, and delete_source is destructive. This goes beyond the annotations which only indicate readOnlyHint=false, destructiveHint=false. No contradiction with 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 concise, with one dense paragraph covering all aspects. It front-loads with 'Branch lifecycle' and then details actions. While packed with information, it remains clear and avoids redundancy, though slightly more structure could improve readability.
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?
Given the tool's complexity (6 parameters, 2 required, no output schema), the description provides comprehensive coverage: actions, parameter roles, validation behavior, conflict handling, and destructiveness. It equips an agent to use the tool correctly without missing critical 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?
All 6 parameters have schema descriptions (100% coverage). The tool description adds extra context for parameters like 'from_branch' (explains role in create vs. merge) and 'delete_source' (explains it consumes the branch), enhancing understanding beyond the schema definitions.
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 clearly specifies the tool handles the branch lifecycle with two distinct actions ('create' and 'merge'), each explained with sufficient detail. It differentiates from sibling tools by focusing on branching operations, while siblings like lbb_query or lbb_commit serve different purposes.
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 explains when to use create vs. merge, including specifics like 'merge: replay a child branch onto its fork parent' and 'delete_source consumes the merged branch.' It does not explicitly state when not to use it or mention alternatives, but the context of branching is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses meaningful behavioral details: explicit idempotency_key wins, otherwise MCP derives a content hash for dedupe; facts mode defaults edge_idempotency to append; skip_unchanged is recommended for re-runnable backfills; retract removes current edges while keeping history for as-of reads. These details align with the idempotentHint and destructiveHint annotations rather than contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but efficient: four sentences cover all three modes, idempotency behavior, feedback grading, and backfill guidance. Every sentence carries operational value, and the most important mode distinction is front-loaded.
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 12-parameter, three-mode mutation tool with no output schema, the description covers mode selection, idempotency, retract semantics, and backfill behavior well. It does not broadly describe the response/return shape outside a mention of written_properties in the entity_properties parameter, so a small completeness gap remains.
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 58% schema coverage, the description compensates for several sparse parameters by explaining mode semantics, idempotency_key behavior, edge_idempotency defaults, observed_at backfill usage, and feedback grade meanings. Some parameters like graph, branch, and triplets still rely on the schema, but the description adds substantial meaning beyond the raw JSON 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 opens with a specific verb and resource: 'Write graph facts, retract them, or label ranked results.' It then enumerates the three modes (facts, retract, search_feedback) with concrete actions, making the tool's purpose unmistakable and clearly distinct from read-only siblings like lbb_query and lbb_inspect.
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 gives clear mode-level guidance: use facts for writing triplets/embeddings/properties, retract for removing wrongly-added facts without a full reset, and search_feedback for storing relevance labels. It does not explicitly name sibling alternatives or say when not to use the tool, but the mode selection guidance is strong enough for an agent to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![lbb-mcp MCP server](https://glama.ai/mcp/servers/littlebigbrains/lbb-mcp/badges/card.svg)](https://glama.ai/mcp/servers/littlebigbrains/lbb-mcp)

Score Badge

Copy to your README.md:

[![lbb-mcp MCP server](https://glama.ai/mcp/servers/littlebigbrains/lbb-mcp/badges/score.svg)](https://glama.ai/mcp/servers/littlebigbrains/lbb-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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