Skip to main content
Glama
Sign In

brainkb

by org.brainkb
OverviewDiscussionsAdmin

brainkb_sparql

Run an arbitrary SPARQL query. Requires an Admin/SuperAdmin role (the sparql_admin capability) — for ordinary questions prefer brainkb_search, brainkb_read_space, or the provenance/delta tools, which need no admin role.

Large results come back a page at a time. A SELECT without its own
LIMIT/OFFSET returns at most `limit` rows (0 = the server's page size, 500 by
default) starting at `offset`; the response's `page` says whether there is
more (`has_more`) and where to continue (`next_offset`). Add ORDER BY for
stable pages. A query that sets its own LIMIT runs as written. Any result
too big for one response is cut to its leading rows with a `truncated` note.
Prefer COUNT(*) first when you only need to know how much there is.

Input Schema

NameRequiredDescriptionDefault
limitNo
offsetNo
sparql_queryYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / limit
      Added value: +{
+  "default": 0,
+  "title": "Limit",
+  "type": "integer"
+}
    • addedInput schema / properties / offset
      Added value: +{
+  "default": 0,
+  "title": "Offset",
+  "type": "integer"
+}
  2. First observed

TDQS

A4.7/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses the admin-role requirement, pagination behavior (limit default 0 = server page size of 500, offset, has_more, next_offset), interaction with query LIMIT, truncation with a note, and a COUNT(*) optimization tip. However, it does not explicitly state whether the tool is read-only or can modify data, nor does it mention execution timeouts or error behavior, which are relevant for an arbitrary query tool.

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 front-loaded with purpose, role requirement, and alternatives, then moves to pagination details. Every sentence adds useful information with no filler, and the structure is logical for an agent scanning for key constraints.

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 the absence of annotations, output schema, and schema descriptions, the definition covers auth, alternatives, pagination, and truncation well. It does not explain the exact shape of the returned data beyond the page envelope (e.g., bindings, boolean, or graph structures), nor does it clarify the dataset or graphs that can be queried, which is a minor gap for a complex arbitrary-query tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It thoroughly explains limit (0 = server page size, 500 by default) and offset (starting point), and how they interact with a query's own LIMIT/OFFSET clause. The sparql_query string parameter is adequately conveyed by 'arbitrary SPARQL query' itself.

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: 'Run an arbitrary SPARQL query.' Distinguishes itself from siblings by naming brainkb_search, brainkb_read_space, and provenance/delta tools as alternatives for ordinary questions, and by requiring Admin/SuperAdmin. An agent can identify its niche without opening other schemas.

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?

Explicitly says when to prefer alternatives ('for ordinary questions prefer brainkb_search, brainkb_read_space, or the provenance/delta tools, which need no admin role') and the prerequisite admin role. It also advises using COUNT(*) first when only a count is needed, giving clear usage context.

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

All brainkb toolsInspect
Try in Browser
Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources