Skip to main content
Glama
littlebigbrains

@littlebigbrain/mcp

lbb_rdf

DestructiveIdempotent

Store complete RDF/OWL documents and extend them with additive SPARQL INSERT DATA edits in Little Big Brain graphs.

Instructions

Store and extend complete RDF/OWL documents through MCP. import accepts Turtle/N-Triples/N-Quads/TriG without conversion; update executes INSERT DATA for additive edits. Replacing/removing axioms is unsupported; use a new versioned LBB graph for a revised document. Named RDF graphs are unsupported; Turtle/N-Triples use the default graph, and dataset formats must contain only default-graph quads. These write graph facts, distinct from lbb_configure's native schema metadata. A first RDF write selects RDF-native storage, which refuses later property-graph commits; choose the write workflow before bootstrap. Retries deduplicate by content unless idempotency_key is supplied. A completed write schedules publication; inspect action=publication and verify using lbb_query entailment=owl. An update with DELETE, CLEAR, DROP, MOVE or COPY asks the person to approve it first; the question quotes the operations that remove. The server asks the person to approve it through the client (MCP form elicitation) and sends nothing when they decline (approval_declined). A client that cannot show the question gets approval_required and nothing is sent, unless the MCP server's environment sets LBB_MCP_DESTRUCTIVE=allow.

Input Schema

NameRequiredDescriptionDefault
graphNoGraph to target; defaults to the connection's graph
actionYesSelects the variant (one of: import, update).
detailNoResponse detail level. Defaults to compact.
formatNo
sourceNoComplete RDF document. Preserves OWL axioms, RDF lists, labels, comments, and external IRIs as graph facts.
updateNoSPARQL INSERT DATA text to add axioms. Submitted unchanged. DELETE/WHERE/CLEAR and named graphs are currently unsupported and fail without mutation.
base_iriNo
idempotency_keyNo
blank_node_scopeNoStable document scope for blank labels across import chunks.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.16.0
    • changedInput schema / additionalProperties
      Previous value: -trueNew value: +{}
  2. Changed1 schema field changedv0.5.2
    • removedInput schema / properties / branch
      Removed value: -{
      -  "description": "Branch to target; defaults to the connection's branch",
      -  "type": "string"
      -}
  3. Addedv0.5.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true and idempotentHint=true, but the description goes well beyond them: it explains content-based retry deduplication unless idempotency_key is set, the irreversible storage-mode selection that refuses later property-graph commits, named-graph rejection, approval gating via MCP form elicitation, and the approval_declined / approval_required / LBB_MCP_DESTRUCTIVE=allow outcomes. This is exactly the extra context annotations cannot carry.

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 core purpose and variant behavior are front-loaded and nearly every sentence adds operational value for a 9-parameter mutation tool. There is mild redundancy in the approval passage, which states twice that the person is asked to approve destructive update operations, and the sentences are long and dense.

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?

For a destructive write tool with no output schema, the description covers storage-mode consequences, format restrictions, approval flows, failure modes (approval_required, approval_declined), and post-write publication verification. An agent has what it needs to call this safely.

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?

At 67% schema coverage the description meaningfully extends the schema: it pins 'update' to SPARQL INSERT DATA, clarifies that 'source' is a complete document preserving OWL axioms, and explains idempotency_key and graph/default-graph constraints. base_iri and detail are not addressed, so it stops short of full coverage.

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?

States a specific verb and resource ('Store and extend complete RDF/OWL documents') and immediately differentiates the two variants (import vs update with INSERT DATA). It also names siblings it is not: 'distinct from lbb_configure's native schema metadata' and 'verify using lbb_query entailment=owl'.

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 explicit when-to-use guidance per variant (import for whole documents, update for additive INSERT DATA) and explicit when-not guidance ('Replacing/removing axioms is unsupported; use a new versioned LBB graph'). It also routes to alternatives (lbb_query for verification, lbb_configure for schema metadata) and warns to choose the write workflow before bootstrap.

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