Skip to main content
Glama
angrysky56
by angrysky56

wiki_ingest_raw

Reads a raw file from the raw/ directory, processes it through the Synapse semantic pipeline to build a knowledge graph in Neo4j, and generates a summary page in the wiki.

Instructions

Read a raw source file and ingest it into both the knowledge graph and wiki.

Reads from raw/, runs it through the Synapse semantic pipeline, stores in Neo4j, and creates a summary page in wiki/sources/.

Args: filename: Filename inside the raw/ directory.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filenameYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the full burden. It transparently discloses that the operation writes to both Neo4j and a wiki page, and details the pipeline. It does not mention idempotency, error handling, or permissions, but the core write behavior is clear. This is adequate for a single-step ingestion 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 two tight sentences plus an args line, with the core purpose front-loaded. Every sentence earns its place—purpose, pipeline steps, and parameter clarification—without redundancy.

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?

The description is complete for a single-parameter tool with an output schema. It covers the input location, the transformation steps, the output locations, and the parameter semantics. An agent can invoke it correctly without additional 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?

The description adds meaning beyond the schema by specifying that 'filename' refers to a file inside the raw/ directory, which the schema's bare 'Filename' does not convey. For a single parameter, this is sufficient context, though it could be more explicit about accepted formats or extensions.

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 action ('ingest a raw source file') and its destinations (knowledge graph and wiki), with concrete steps (reads from raw/, runs Synapse pipeline, stores in Neo4j, creates summary page). This distinguishes it from siblings like ingest_text and wiki_write_page, which target different inputs or outputs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for files in the raw/ directory, which is a usage context. However, it does not explicitly compare with alternatives (e.g., ingest_text for direct text, wiki_write_page for manual page creation) or state when not to use it. This leaves some ambiguity for an agent choosing between similar tools.

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