Skip to main content
Glama

brainkb_ingest_upload

Ingest a file you staged with POST /upload into a named graph.

This is the route for a large local file: your HTTP client streams the bytes
straight to this server over HTTPS, then you name the resulting upload_id here. The
server reads its own staged copy and posts it to the ingest API internally, so
the RDF never passes through a model's context — nothing to transcribe, no
context-window ceiling, and no reason to split the document (splitting breaks
blank-node identity and silently detaches triples, permanently).

Stage a file with any HTTP client — the point is that the LIBRARY reads the file,
so the bytes never pass through a model:

    import requests, hashlib, pathlib
    f = pathlib.Path("review.ttl")
    r = requests.post(
        "https://mcp.brainkb.org/upload",
        params={"filename": f.name,
                "sha256": hashlib.sha256(f.read_bytes()).hexdigest()},
        headers={"Authorization": f"Bearer {TOKEN}"},
        data=f.open("rb"),          # streamed — never loaded into memory
    )
    print(r.json())                 # -> {"upload_id": "up_...", "state": "staged"}

It returns an upload_id and the sha256 the server computed — compare it with your
own before ingesting.

Returns a job_id; poll brainkb_job_status, then reconcile brainkb_delta(job_id)
against the triple count you expected. The staged copy is deleted once the
ingest API has accepted the bytes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
upload_idYes
named_graph_iriYes

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description fully carries the behavioral disclosure burden. It transparently explains the internal server flow (server reads its own staged copy and posts to the ingest API), side effects (staged copy is deleted once accepted), and the risk of splitting (silently detaches triples). It also informs the user about the returned upload_id and sha256 for verification, as well as the need to poll job status. This level of detail exceeds expectations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is thorough but lengthy, containing a full Python code example and repeated emphasis on the 'library reads the file' point. While every sentence provides some value, the structure could be tightened; the code example is somewhat long and the core message is repeated across the first and third paragraphs. It is not as crisp as it could be, but it is not unstructured.

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 and the absence of both annotations and an output schema, the description covers the full lifecycle: staging, ingestion, return value (job_id), follow-up actions (poll brainkb_job_status, reconcile with brainkb_delta), and cleanup (staged copy deletion). This provides the agent with a complete operational picture.

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 schema has no descriptions for the two parameters, and the description compensates by explaining that upload_id comes from the staging step and that the named_graph_iri is the target graph. It provides a concrete example of how upload_id is obtained and implies its format (up_...). However, it does not explicitly define the syntax or constraints for named_graph_iri, so it's not a full 5, but it adds meaningful semantic context.

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, actionable statement: 'Ingest a file you staged with `POST /upload` into a named graph.' This clearly identifies the tool's function (ingesting a staged file), the resource (named graph), and the mechanism (using an upload_id). It also distinguishes itself from sibling tools like brainkb_ingest_text and brainkb_ingest_files by explicitly scoping to large local files staged via upload.

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 strong contextual guidance: 'This is the route for a large local file' and explains that the RDF never passes through a model's context, so there's no context-window ceiling. It also warns against splitting documents because it 'breaks blank-node identity'. However, it does not explicitly name alternative tools or state when not to use this tool beyond the large-file scenario, so it falls short of a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.4/5.0
Disambiguation4/5

Most tools have clearly distinct purposes, such as user management (activate, ban, assign role) vs. space management (create, add member, set visibility) vs. ingest/jobs (ingest_files, job_status, recover). A few pairs like grant_capability vs. grant_role_capability are similar but descriptions clarify the target, so an agent should be able to choose correctly.

Naming Consistency4/5

All tools are prefixed with brainkb_ and the large majority follow a verb_noun pattern (e.g., add_space_member, list_tokens, revoke_token). Some exceptions like brainkb_delta, brainkb_search, brainkb_whoami, and brainkb_capabilities break the pattern, but these are few and still readable.

Tool Count2/5

With 49 tools, the server is far above the 25+ threshold for 'too many'. While the broad scope (user admin, spaces, graphs, ingest, provenance, auth) justifies many operations, the sheer number makes it heavy and potentially unwieldy for an agent to navigate.

Completeness3/5

The tool set covers a wide range of use cases: user/role/capability management, space administration, graph registration, ingest, job monitoring, provenance, search, and SPARQL. However, there are notable gaps such as removing a space member, deleting a space, or updating space metadata, which could leave agents without a way to fully manage the lifecycle of a space.