What can you do with this server?

The VeritasGraph server provides an on-premise GraphRAG engine with the following core capabilities: * Ingest Documents: Upload raw text into the knowledge graph — the server chunks the content, extracts entities and relationships using a local Ollama model, and records source chunk references for verifiable attribution. * Query the Knowledge Graph: Ask natural-language questions and receive graph-grounded, multi-hop answers with [doc#chunk] citations and a full reasoning path, with configurable traversal depth and subgraph size limits. * Search Entities: Perform fast, LLM-free graph lookups to retrieve relevant entities, relationships, and subgraphs for a given query topic. * Retrieve Full Graph: Export the entire knowledge graph — all nodes, edges, and statistics — for inspection or downstream processing. * Clear the Graph: Destructively wipe all stored nodes and edges to reset the knowledge graph.

Which integrations are available for this server?

Provides an MCP bridge integration for Unity, allowing AI agents to interact with Unity applications or data through the VeritasGraph server.

VeritasGraph

by bibinprathap

Overview Schema Related Servers Score Discussions

Python

Hybrid

# VeritasGraph — The Governed, On-Prem GraphRAG & Agent Framework

Stop chunking blindly. Combine Tree-Search structure with Knowledge-Graph reasoning — and wire it into governed AI agents. Runs 100% locally or in the cloud.

PyPI version Python 3.10+ License: MIT GitHub Stars

🎯 Traditional RAG guesses based on similarity. VeritasGraph reasons based on structure. Don't just find the document — understand the connection, then act on it with governed agents.

⭐ Star · 🍴 Fork · 💬 Discuss · 🐛 Report a bug

📚 Featured Guide — Build Governed AI Agents On-Prem

A complete walkthrough of designing, wiring, and shipping governed AI agents entirely on your own infrastructure.

📄 Read the guide: Build Governed AI Agents On-Prem (PDF)

Build Governed AI Agents On-Prem — walkthrough Import Any graph.json into VeritasGraph Studio — Walkthrough

▶️ Watch the walkthrough on YouTube

Related MCP server: GraphRAG MCP

🚀 Quick Start (2 lines, no GPU)

pip install veritasgraph
veritasgraph demo --mode=lite

That's it — an interactive demo using cloud APIs (OpenAI/Anthropic), no local models required.

Mode	Best For	Requirements
`--mode=lite`	Quick demo, no GPU	OpenAI/Anthropic API key
`--mode=local`	Privacy, offline use	Ollama + 8GB RAM
`--mode=full`	Production, all features	Docker + Neo4j

export OPENAI_API_KEY="sk-..."        # Lite: cloud APIs, zero setup
veritasgraph demo --mode=lite

veritasgraph demo --mode=local --model=llama3.2   # 100% offline with Ollama
veritasgraph start --mode=full                    # full GraphRAG pipeline

Useful links: ⚡ Live docs · 🎮 Live demo · 📖 Article · 📄 Research paper

🛠️ VeritasGraph Studio — Build, wire & test governed agents locally

Studio is a local Agent Build Workspace (FastAPI + single-page UI) that lets you build a knowledge graph from your own documents and wire it into agents alongside tools, memory, data logging, guardrails, and headroom-style context budgeting — then chat with those agents live and watch every stage of the orchestration pipeline. Everything runs 100% locally against Ollama.

🎮 Try the Studio Live — stable URL that always redirects to the current running studio tunnel.

Run it:

pip install -r requirements.txt
ollama serve & ollama pull qwen3:latest          # any local chat model
STUDIO_DATA_DIR="$PWD/studio_api/data" \
  uvicorn studio_api.main:app --host 127.0.0.1 --port 8200 --log-level warning
# Studio UI → http://localhost:8200/studio   ·   API docs → /docs

One-command end-to-end demo (builds a graph + drives a fully-wired agent through graph reasoning, memory recall, PII redaction, and a guardrail block):

python3 demos/agent-studio/sample_pipeline.py --model qwen3:latest

🧩 Knowledge Graph builder & explorer — ingest text, extract entities/relationships locally, inspect nodes/edges with grounded evidence.
🔎 Graph Q&A with citations — multi-hop answers backed by [doc#chunk] source attribution.
🤖 Agent workspace — create/edit agents with model selection, prompt/persona settings, and per-agent capability toggles.
🔀 Governed orchestration pipeline — per-turn flow of Guardrails → Memory → Knowledge Graph → Headroom budget → Tools → Data log, with full trace visibility.
🧰 Editable tools catalog — add, edit, enable/disable, test, and delete tools directly in Studio.
🌐 External real tool support — call real HTTP endpoints with configurable method, auth header, and custom headers.
🔌 MCP bridge integrations — local MCP proxy connectors (e.g. Chrome DevTools MCP, Unity MCP) with health-aware probing.
🛡️ Guardrails — PII redaction and policy-block controls with visible guardrail-block metrics.
🧠 Memory + Data logs — per-agent short-term memory and interaction-log persistence.
📈 Evaluation & fine-tune simulation — run eval suites, track pass-rate trends, and queue/monitor fine-tune jobs.
💬 Playground — run governed agent conversations live and inspect the pipeline trace.
📊 KPI dashboard — active agents, connected tools, eval pass rate, and guardrail-block counters.

See studio_api/README.md for API and architecture, and docs/STUDIO_ENTERPRISE_TEST.md for enterprise test scenarios.

📋 Examples

#	Example	What it demonstrates	Run
1	`sample_pipeline.py`	Studio agent pipeline — ingests a company brief → builds KG → multi-hop Q&A with citations → memory recall → PII redaction → guardrail block → audit log.	`python3 demos/agent-studio/sample_pipeline.py`
2	`sample_tools_explorer.py`	Tool catalog seeder — registers 17 tools and creates sample explorer agents. Idempotent.	`python3 demos/agent-studio/sample_tools_explorer.py`
3	`clinical-kg/`	Medical AI — Clinical Knowledge Graph — de-identifies notes (Safe Harbor), extracts entities, detects contradictions, normalizes to ICD-10/RxNorm/SNOMED/LOINC, builds patient KG with citations.	`cd clinical-kg/backend && python run.py`
4	`municipality-incident-chatbot/`	DMT Inspection System — citizen incident reporting with CV validation (YOLO/VLM), KG-grounded routing, evidence fusion, case registration.	`cd municipality-incident-chatbot && python cli.py`

Turn unstructured clinical notes into a governed, citable knowledge graph — fully on-prem.

The 7-step pipeline:

Step	What it does
De-identify	Safe Harbor regex redaction with a sealed `SurrogateVault` for audited re-identification
Extract	Section-aware NER, med-sig / lab-value parsing, ConText axes (negation, certainty, temporality, experiencer)
Reconcile	Groups mentions by concept; detects contradictions across notes (e.g. "no diabetes" in HPI vs "T2DM" in problem list)
Normalize	Maps mentions → coded concepts (ICD-10-CM, RxNorm, SNOMED CT, LOINC)
Knowledge Graph	Patient / Encounter / Condition / Medication / LabResult nodes with `EVIDENCED_BY` provenance edges
Query	NL → structured `CohortQuery` → multi-hop traversal with `[doc#chunk]` citations
Governance	k-anonymity over released cohorts

# Backend (FastAPI on :8300)
cd clinical-kg/backend
pip install -r requirements.txt
python run.py

# Frontend (Next.js dashboard on :3200)
cd clinical-kg/frontend
npm install && npm run dev

Open http://localhost:3200 → click Load sample notes → run queries. The UI has 6 tabs: Cohort Query, Ingest Note, Patients, Contradictions, Graph, Re-ID Risk.

AI chatbot for citizens to report civic incidents, validated by computer vision and grounded by a knowledge graph.

Pipeline flow: citizen photo + description → KG classification → CV validation (YOLO/VLM) → cross-check (CCTV, location, prior reports) → evidence fusion → case registration.

Supported incidents: trash overflow · abandoned vehicles · overcrowding · illegal parking (extensible)

cd municipality-incident-chatbot
pip install -r requirements.txt

# Interactive CLI
python cli.py
#   you> trash overflowing near the market | photo=garbage_overflow.jpg | zone=downtown

# Test suite
python -m pytest -q

Component	File
Knowledge graph (grounding + routing)	`app/knowledge_graph.py`
CV validation (YOLO + VLM)	`app/cv_service.py`
Evidence fusion & scoring	`app/fusion.py`
Chatbot orchestrator	`app/orchestrator.py`
Architecture docs	`01_architecture.md`

Enterprise scenario — follow the Northwind Bank compliance test playbook for a guided walkthrough using realistic financial-services data.

For API-level examples and curl recipes, see studio_api/README.md.

🌳 + 🔗 Graph + Tree: the ultimate retrieval

Why choose? VeritasGraph includes the hierarchical "Table of Contents" navigation of PageIndex PLUS the semantic reasoning of a Knowledge Graph.

Document Root
├── [1] Introduction
│   ├── [1.1] Background ←── Tree Navigation
│   └── [1.2] Objectives
├── [2] Methodology ←───────── Graph Links
│   └── relates_to ──────────→ [3.1] Findings
└── [3] Results

📊 Feature comparison

Feature	Vector RAG	PageIndex	VeritasGraph
Retrieval type	Similarity	Tree search	🏆 Tree + Graph reasoning
Attribution	❌ Low	⚠️ Medium	✅ 100% verifiable
Multi-hop reasoning	❌	❌	✅
Tree navigation (TOC)	❌	✅	✅
Semantic search	✅	❌	✅
Cross-section linking	❌	❌	✅
Visual graph explorer	❌	❌	✅ Built-in UI
100% local/private	⚠️ Varies	❌ Cloud	✅ On-premise
Open source	⚠️ Varies	❌ Proprietary	✅ MIT license

🎬 See it in action

VeritasGraph Master Demo

💡 What you're seeing: a query triggers multi-hop reasoning across the knowledge graph. Nodes light up as connections are discovered, showing exactly how the answer was found — not just what was found.

🔌 MCP Server — connect your IDE agent to VeritasGraph

VeritasGraph ships a dedicated Model Context Protocol server — the first zero-trust, air-gapped Enterprise GraphRAG server for MCP. Connect Claude Desktop, Cursor, VS Code, Windsurf, Cline, or Continue directly to the GraphRAG engine over JSON-RPC 2.0 stdio, with zero external data egress.

python -m veritasgraph_mcp     # from repo root (needs local Ollama for ingest/query)

Tools: veritasgraph_ingest_document, veritasgraph_query (multi-hop answers with [doc#chunk] citations), veritasgraph_search_entities, veritasgraph_get_graph, veritasgraph_clear_graph. See veritasgraph_mcp/README.md for IDE registration snippets.

🏥 VeritasGraph-MCP Use Case — Production Medical AI on Azure

Real-world deployment: VeritasGraph MCP server running on Azure Functions with Azure AI Foundry, delivering GraphRAG-powered clinical decision support with verifiable citations and compliance-ready architecture.

The Challenge: 90% of Azure AI demos work. Most never ship. The gap isn't the model — it's architecture, security, state management, and compliance.

The Solution: VeritasGraph deployed as a remote MCP server that Azure AI Foundry agents call to answer clinical questions with:

✅ Multi-hop GraphRAG reasoning — assembles answers from separate graph edges
✅ Verifiable citations — every claim traces to [doc#chunk] sources
✅ Production-grade architecture — externalized state, identity at boundary, observability
✅ Compliance-ready — region-pinned, PHI-aware guardrails, semantic-layer RBAC

Architecture highlights:

Foundry Agent / MCP client
   → Identity (Entra ID + function key)
      → Azure Functions (Flex Consumption, 4 mcpToolTrigger tools)
         → veritasgraph-mcp + graphrag_engine
            → Azure OpenAI (extraction + reasoning)
            → Knowledge Graph
         → Durable Azure Files mount (externalized state)
         → Storage + App Insights (observability)

Key production lessons learned:

State externalization — Flex Consumption wiped in-memory graphs; fixed with mounted Azure Files share
Identity at boundary — Carry Entra identity; enforce Power BI RLS / Dataverse roles on-behalf-of user
Self-correcting agents — Feed errors + schema back; retry up to 3× (e.g., DAX generation)
Compliance by design — Foundry guardrails block PHI-leaking requests before reaching the model
Observability layers — Application Insights + Foundry Traces + Evaluations + Alerts

Example query flow:

{
  "question": "Should we adjust warfarin for patient 4471 on amiodarone?",
  "answer": "Reduce the warfarin dose because amiodarone inhibits CYP2C9...",
  "citations": ["doc_warfarin_note#0", "doc_warfarin_note#1"],
  "reasoning_path": ["Amiodarone → CYP2C9", "CYP2C9 → Warfarin", "Warfarin → Bleeding Risk"]
}

Technical stack:

Compute: Azure Functions (Flex Consumption) — scales to zero, fast event-driven scale-out
State: Azure Files mount — survives cold starts and scale events
Inference: Azure OpenAI (gpt-4-turbo/gpt-5-mini, swappable)
Identity: Entra ID + function/system key
Observability: Application Insights + Foundry Traces
Compliance: Region-pinned deployments, PHI-aware guardrails, Key Vault secrets

Deployed systems:

Medical MCP Server — Clinical knowledge graph with multi-hop reasoning and [doc#chunk] citations
Power BI Natural-Language Agent — Validates OAuth token → discovers schema → generates DAX → executes via executeQueries REST API with row-level security enforced by the platform

Watch: VeritasGraph MCP on Azure AI Foundry

▶️ Watch the deployment walkthrough on YouTube

Resources:

📄 Read the full guide: From Proof of Concept to Production: Azure AI That Actually Ships — Complete walkthrough covering architecture, deployment, GraphRAG reasoning, auditability, semantic-layer access control, resilience, observability, and compliance.
💻 Azure AI Foundry + VeritasGraph Implementation Repository — Production deployment code, configuration, and examples.

Production-ready checklist:

✓ Grounded — answers cite your data ([doc#chunk])
✓ State externalized — no reliance on serverless memory
✓ Identity at boundary — Entra + keys; on-behalf-of for data
✓ Entitlements enforced — RLS/roles before data reaches model
✓ Resilient — handles bad params, throttling, tool failures
✓ Observable — logs, traces, evals, cost alerts
✓ Region-pinned & compliant — inference in-tenant, PHI-aware
✓ Secrets in Key Vault — managed identity, least privilege
✓ Reproducible deploy — remote build, pinned config

💡 Key insight: The gap between POC and production is architecture, not the model. Ground it, externalize state, secure it, observe it, make it resilient, keep it compliant.

📖 Python API

from veritasgraph import VisionRAGPipeline

pipeline = VisionRAGPipeline()                 # auto-detects available models
doc = pipeline.ingest_pdf("document.pdf")
result = pipeline.query("What are the key findings?")
print(result.answer)

from veritasgraph import VisionRAGPipeline

pipeline = VisionRAGPipeline()
doc = pipeline.ingest_pdf("report.pdf")

# View the document's hierarchical structure (like a Table of Contents)
print(pipeline.get_document_tree())
# Document Root
# ├── [1] Introduction (pp. 1-5)
# │   ├── [1.1] Background (pp. 1-2)
# │   └── [1.2] Objectives (pp. 3-5)
# └── [2] Methodology (pp. 6-15)

# Navigate to a specific section (tree-based retrieval)
section = pipeline.navigate_to_section("Methodology")
print(section['breadcrumb'])   # ['Document Root', 'Methodology']

# Or use graph-based semantic search
result = pipeline.query("What methodology was used?")
# → answer with section context: "📍 Location: Document > Methodology > Analysis Framework"

from veritasgraph import VisionRAGPipeline, VisionRAGConfig

config = VisionRAGConfig(ingest_mode="document-centric")  # tables stay intact!
pipeline = VisionRAGPipeline(config)
doc = pipeline.ingest_pdf("annual_report.pdf")

Mode	Description	Best For
`document-centric`	Whole pages/sections as nodes (default)	Most documents
`page`	Each page = one node	Slide decks, reports
`section`	Each section = one node	Structured documents
`chunk`	Traditional 500-token chunks	Legacy compatibility

CLI

veritasgraph --version                                    # show version
veritasgraph info                                         # check dependencies
veritasgraph init my_project                              # initialize a project
veritasgraph ingest document.pdf --ingest-mode=document-centric   # Don't Chunk. Graph.
veritasgraph ingest https://youtube.com/watch?v=xxx       # auto-extract transcript
veritasgraph ingest https://example.com/article           # extract web article

Installation options

pip install veritasgraph            # basic (includes lite mode)
pip install veritasgraph[web]       # Gradio UI + visualization
pip install veritasgraph[graphrag]  # Microsoft GraphRAG integration
pip install veritasgraph[ingest]    # YouTube & web-article ingestion
pip install veritasgraph[all]       # everything

🏛️ Enterprise Compliance — VeritasGraph + VeritasReason

GraphRAG is brilliant at describing what your documents say. But enterprise questions like "Which purchase orders violated our Segregation-of-Duties policy last quarter?" are rule-evaluation problems over structured records — not similarity search.

For those, VeritasGraph ships a sister module: VeritasReason — a deterministic reasoning engine (forward-chaining + Rete + SPARQL) that fires policy rules over a triplet store and returns auditable answers with W3C PROV-O provenance.

 Policy PDFs ─┐                        ┌─ ingest_structured.py (SQL → triples + text)
              ▼                        ▼
      VeritasGraph GraphRAG      VeritasReason (TripletStore + RuleSet
      (quotes policy text)       + ForwardChainer + PROV-O)
              └──────────┬───────────────┘
                         ▼
             Compliance answer + violators table + clause citations

30-second smoke test (no install, stdlib only)

python tests/test_policy_compliance_demo.py

Seeds a fake ERP into a tiny in-memory triple store, evaluates four SoD rules from rules/sod_policy.yaml, and prints violators with citations:

✓ Reasoner fired. Detected 4 violation(s):
  po:PO-2204 SOD-01   Approved & paid by emp:E118
  po:PO-2301 SOD-02   Requested & approved by emp:E091
  po:PO-2317 SOD-03   $48,750.00 approved by emp:E091 (role:Manager, not Director)
  po:PO-2402 SOD-04   Vendor vendor:V77 related to approver emp:E140

Or install and run the packaged demo:

pip install veritas-reason
veritasreason-policy-demo

The same pattern applies to leave-policy violations (HRIS attendance), expense-report fraud (ledger + receipts), clinical protocol breaches (EHR + guidelines), or KYC/AML (transactions + watchlists). Define the SQL → triple mapping in ingest_structured.py, write rules in rules/*.yaml, and ask in plain English. See veritas-reason/plan.md for a full walk-through.

🔗 Interactive Graph Visualization

VeritasGraph includes an interactive 2D knowledge-graph explorer (PyVis) that visualizes entities and relationships in real time.

Graph Explorer

Feature	Description
Query-aware subgraph	Shows only entities related to your query
Community coloring	Nodes grouped by community membership
Red highlight	Query-related entities shown in red
Node sizing	Bigger nodes = more connections
Interactive	Drag, zoom, hover for entity details
Full graph explorer	View the entire knowledge graph

⚙️ Provider Support (OpenAI-compatible)

VeritasGraph works with any OpenAI-compatible API — mix and match cloud and local:

Provider	API Base	API Key	Example Model
Ollama (default)	`http://localhost:11434/v1`	`ollama`	`llama3.1-12k`
OpenAI	`https://api.openai.com/v1`	`sk-proj-...`	`gpt-4-turbo-preview`
Groq	`https://api.groq.com/openai/v1`	`gsk_...`	`llama-3.1-70b-versatile`
Together AI	`https://api.together.xyz/v1`	your-key	`Meta-Llama-3.1-70B-Instruct-Turbo`
LM Studio	`http://localhost:1234/v1`	`lm-studio`	(model loaded in LM Studio)

Also supported: Azure OpenAI, OpenRouter, Anyscale, LocalAI, vLLM.

cd graphrag-ollama-config
cp settings_openai.yaml settings.yaml
cp .env.openai.example .env       # edit with your provider settings
python -m graphrag.index --root . --config settings_openai.yaml
python app.py

⚠️ Embeddings must match your index. If you indexed with nomic-embed-text (768 dims), you must query with the same model — switching embedding models requires re-indexing. Full details in OPENAI_COMPATIBLE_API.md.

🐳 Deployment

Five-Minute Magic Onboarding (Docker)

Run a full stack (Ollama + Neo4j + Gradio) with one command:

cd docker/five-minute-magic-onboarding
# set your Neo4j password in .env, then:
docker compose up --build

Services: Gradio UI → http://127.0.0.1:7860 · Neo4j → http://localhost:7474 · Ollama → http://localhost:11434. See docker/five-minute-magic-onboarding/README.md.

Method	Duration	Local Ollama	Setup	Best For
`python app.py --share`	72 hours	✅	1 min	Quick demos
Ngrok tunnel	Unlimited*	✅	5 min	Team evaluation
Cloudflare tunnel	Unlimited*	✅	5 min	Team evaluation
Hugging Face Spaces	Permanent	❌ (cloud LLM)	15 min	Public showcase

*Free tier has some limitations.

🏗️ Architecture

graph TD
    subgraph "Indexing Pipeline (one-time)"
        A[Source Documents] --> B{Document Chunking};
        B --> C{"LLM Extraction<br/>(Entities & Relationships)"};
        C --> D[Vector Index];
        C --> E[Knowledge Graph];
    end
    subgraph "Query Pipeline (real-time)"
        F[User Query] --> G{Hybrid Retrieval Engine};
        G -- "1. Vector search for entry points" --> D;
        G -- "2. Multi-hop graph traversal" --> E;
        G --> H{Pruning & Re-ranking};
        H -- "Rich context" --> I{LoRA-Tuned LLM Core};
        I -- "Answer + provenance" --> J{Attribution Layer};
        J --> K[Attributed Answer];
    end
    style A fill:#f2f2f2,stroke:#333,stroke-width:2px
    style F fill:#e6f7ff,stroke:#333,stroke-width:2px
    style K fill:#e6ffe6,stroke:#333,stroke-width:2px

The four stages:

Automated Knowledge Graph construction — chunk documents into TextUnits, extract (head, relation, tail) triplets, assemble nodes + edges in a graph DB (e.g. Neo4j).
Hybrid retrieval engine — vector search finds entry nodes, multi-hop traversal uncovers hidden relationships, pruning & re-ranking keeps the most relevant facts.
LoRA-tuned reasoning core — a locally hosted, LoRA-tuned open model generates attributed answers with efficient fine-tuning for reasoning + attribution.
Attribution & provenance layer — propagates source IDs, chunks, and graph nodes into a structured, traceable JSON output.

Hardware: 16+ CPU cores · 64GB+ RAM (128GB recommended) · NVIDIA GPU with 24GB+ VRAM (A100 / H100 / RTX 4090). Software: Docker & Docker Compose · Python 3.10+ · NVIDIA Container Toolkit. Copy .env.example → .env and populate with environment-specific values.

Why VeritasGraph?

✅ Fully on-premise & secure — 100% control over your data and models.
✅ Verifiable attribution — every claim traces back to its source.
✅ Advanced graph reasoning — answers complex, multi-hop questions.
✅ Hierarchical tree + graph — PageIndex-style TOC navigation with graph flexibility.
✅ Governed agents — guardrails, memory, tools, and context budgeting wired together in Studio.
✅ Open-source & sovereign — MIT-licensed, no vendor lock-in.

Who is it for? Engineers building enterprise search, compliance assistants, research copilots, scientific literature explorers, and agent memory systems — anywhere "the answer" depends on how facts connect, not just whether they appear near each other in a vector index.

🙌 Acknowledgments

Builds on the foundational work of HopRAG, Microsoft GraphRAG, LangChain & LlamaIndex, and Neo4j.

🏆 Awards & Citation

Presented at the International Conference on Applied Science and Future Technology (ICASF 2025) — 📄 Appreciation Certificate.

@article{VeritasGraph2025,
  title={VeritasGraph: A Sovereign GraphRAG Framework for Enterprise-Grade AI with Verifiable Attribution},
  author={Bibin Prathap},
  journal={International Conference on Applied Science and Future Technology (ICASF)},
  year={2025}
}

Star History

Available Tools

5 tools

veritasgraph_clear_graphA

Clear the entire knowledge graph (destructive; removes all data).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

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 fully discloses the destructive nature and data removal. This is transparent, though additional details like irreversibility or required permissions would be beneficial.

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 a single, well-structured sentence that immediately states the action and the critical destructive behavior. No waste.

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 simple no-parameter, no-output tool, the description is complete. It covers what the tool does and its main implication (destructive).

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 tool has zero parameters, and the description correctly omits param details. Schema coverage is 100%, so the baseline is 4.

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 action ('clear') and resource ('entire knowledge graph'), and explicitly marks it as destructive. This distinguishes it from siblings like get_graph (read) and ingest_document (add).

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?

While the description notes the tool is destructive, it does not provide explicit guidance on when to use it (e.g., for resetting the graph) or when to avoid it. No alternatives are mentioned.

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

veritasgraph_get_graphA

Return the full knowledge graph: all nodes, edges, and stats.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations provided, the description bears full responsibility for behavioral disclosure. It only states that the tool returns the graph, which is insufficient. It does not disclose whether the operation is read-only, potential performance impacts for large graphs, or any side effects. The description lacks necessary behavioral context beyond the basic action.

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 a single sentence that is front-loaded with the key verb ('Return') and resource ('full knowledge graph'). It is concise, no filler, and every word adds value. It demonstrates optimal conciseness for a simple tool with no parameters.

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 no output schema, the description should outline what the return value includes. It states 'all nodes, edges, and stats', which is helpful but could be more detailed (e.g., format, structure, size limits). For a simple tool with no parameters, it is adequate but not fully complete. The agent knows it gets a full graph, but lacks specifics.

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 tool has no parameters, so the description naturally adds no parameter-level detail. The baseline for zero-parameter tools is 4, as the schema covers all necessary information. The description correctly confirms the tool takes no arguments, aligning with the 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 clearly states the tool returns the full knowledge graph with all nodes, edges, and stats. It distinguishes from siblings like 'veritasgraph_clear_graph' (clears), 'veritasgraph_ingest_document' (adds), 'veritasgraph_query' (specific queries), and 'veritasgraph_search_entities' (entity search). The verb 'Return' and resource 'full knowledge graph' are specific and unambiguous.

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 implies usage when the entire graph is needed, but provides no explicit guidance on when to use this tool versus alternatives. It does not mention when not to use it (e.g., for specific queries or small subsets) or reference siblings. The agent has to infer usage from the tool's name and general knowledge.

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

veritasgraph_ingest_documentA

Ingest a document into the VeritasGraph knowledge graph. Chunks the text, extracts entities and relationships with a local model, and records the source chunk behind every node/edge for verifiable attribution.

ParametersJSON Schema

Name	Required	Description
`text`	Yes	Full document text to ingest.
`model`	No	Local Ollama model to use (defaults to $VERITASGRAPH_MODEL).
`title`	No	Human-readable document title.

TDQS

A3.9/5.0

Behavior4/5

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

The description discloses key behavioral traits: chunking, extraction with a local model, and attribution. Since annotations are absent, the description carries the full burden, and it provides reasonable insight into the tool's operation. However, it does not mention side effects like graph mutation, performance implications, or error handling.

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 concise with two sentences. The first sentence states the core purpose, and the second elaborates on the process. No extraneous information; every sentence adds value.

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?

The description covers the input and process but omits output/return value, error conditions, or performance considerations. Given the tool's complexity and no output schema, more details would improve completeness.

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 coverage is 100% with clear parameter descriptions. The description adds context on how 'text' is processed (chunking, extraction) but does not add significant meaning beyond the schema for 'model' or 'title'. Baseline 3 is appropriate as the schema does the heavy lifting.

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 verb 'ingest' and the resource 'document into the VeritasGraph knowledge graph'. It details the process (chunks text, extracts entities and relationships, records source chunk for attribution), which is specific and distinguishes this tool from siblings like clear_graph, get_graph, query, and search_entities.

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 explains what the tool does but does not explicitly state when to use it over siblings. There is no mention of when not to use it or alternatives. The usage is implied through the description, but no direct guidance is given.

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

veritasgraph_queryA

Ask a question and get a graph-grounded, multi-hop answer with verifiable [doc#chunk] citations and the reasoning path used.

ParametersJSON Schema

Name	Required	Description
`model`	No	Local Ollama model to use (defaults to $VERITASGRAPH_MODEL).
`question`	Yes	Natural-language question.
`max_depth`	No	Max graph hops (default 2).
`max_nodes`	No	Max subgraph nodes (default 25).

TDQS

A3.6/5.0

Behavior3/5

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

No annotations provided. Description adds context about output (citations, reasoning path) and multi-hop traversal, but doesn't disclose potential side effects, required permissions, or behavior for empty graphs/ambiguous questions.

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?

A single sentence that is front-loaded with the key outcome. However, it could be split into a brief overview followed by output details for better readability.

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?

No output schema exists, so description should explain return format. It mentions citations and reasoning path but not structure (text, JSON). Missing error scenarios and behavior for edge cases.

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 coverage is 100% with descriptions for all 4 parameters. The tool description does not add further meaning beyond what is already in the schema, so baseline score applies.

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 verb 'Ask a question' and output: 'graph-grounded, multi-hop answer with verifiable citations and reasoning path.' It distinguishes from siblings like veritasgraph_search_entities, which likely retrieves entities without multi-hop reasoning.

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?

No explicit when-to-use or when-not-to-use guidance. Implied usage for multi-hop queries, but doesn't mention alternatives for simpler queries (e.g., search_entities) or graph exploration (get_graph).

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

veritasgraph_search_entitiesA

Retrieve the subgraph most relevant to a query (entities, relationships, seeds) without invoking the LLM. Fast graph lookup.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Search query / topic.
`max_depth`	No	Max graph hops (default 2).
`max_nodes`	No	Max subgraph nodes (default 25).

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It states the tool retrieves a subgraph without invoking the LLM and is fast, but lacks details on side effects, required permissions, or what happens with missing queries. Behavior is partially disclosed.

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 concise with two sentences, front-loading the main action and key differentiator (no LLM). Every sentence adds value without redundancy.

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?

With no output schema and no annotations, the description is somewhat complete for a simple search tool but lacks details on output format, error handling, or behavior for edge cases like empty results.

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%, so the schema already documents all parameters. The description does not add extra meaning beyond what the schema provides (e.g., defaults). Baseline score of 3 is appropriate.

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 retrieves a subgraph relevant to a query, explicitly mentioning it does not invoke the LLM, which distinguishes it from sibling tools like veritasgraph_query. The verb 'retrieve' and resource 'subgraph' are specific.

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 usage when fast, non-LLM graph lookup is needed, but does not explicitly state when to use or not use this tool versus alternatives. No when-not or alternative tool references are provided.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv0.1.2Jul 13, 2026
- First observedveritasgraph_clear_graph
- First observedveritasgraph_get_graph
- First observedveritasgraph_ingest_document
- First observedveritasgraph_query
- First observedveritasgraph_search_entities

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: clearing the graph, retrieving the full graph, ingesting documents, querying with reasoning, and searching entities. No ambiguity or overlap.

Naming Consistency4/5

All tools use the 'veritasgraph_' prefix and mostly follow a verb_noun pattern (e.g., clear_graph, get_graph, ingest_document, search_entities). 'query' deviates slightly as a single verb, but it's still clear and consistent in style.

Tool Count5/5

With 5 tools, the set is well-scoped for a knowledge graph server, covering ingestion, retrieval, searching, and clearing without being excessive or insufficient.

Completeness4/5

The tool set covers core operations: create (ingest), read (get_graph, search_entities, query), and delete (clear_graph). Minor gaps include the lack of update or individual entity deletion, but these are reasonable omissions for the intended use case.

Maintenance

ActivityActive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

DocsMint
io.github.HiAi-gg
Self-hosted AI-native knowledge workspace with hybrid search, GraphRAG, and MCP.
Documentation Access RAG Systems Knowledge & Memory
171
Mirror Memory MCP Server
io.github.Tr1ckyMag1ca1
Personal knowledge base MCP server with semantic search, auto-categorization, metadata extraction
Knowledge & Memory Search Note Taking
2
anythingmcp A
io.github.keysersoft
Self-hosted MCP gateway: turn any API, database or MCP server into AI connectors — no code.
Agent Orchestration Data Platforms App Automation
42191
saagarpatel.dev Portfolio A
io.github.saagpatel
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
Search Documentation Access
82

Related MCP Servers

OpenRAG MCP Server
RAG Systems Knowledge & Memory
janik96v
A
license
Not graded
quality
D
maintenance
An open-source MCP server for RAG over personal documents. Supports three parallel strategies — Traditional, Contextual, and Graph RAG — with all data stored locally for privacy.
Updated 5 months ago (2026-03-29 19:12 UTC)
MIT
GraphRAG MCP
RAG Systems Knowledge & Memory Vector Databases
Swissbit92
F
license
Not graded
quality
D
maintenance
A local-first MCP server that transforms crypto whitepapers into a knowledge graph and vector corpus, enabling entity-filtered RAG question answering with optional knowledge graph enrichment.
Updated a year ago (2025-10-21 20:25 UTC)
-
corpus-rag
RAG Systems Knowledge & Memory
monahand1023
A
license
Not graded
quality
A
maintenance
MCP server for local RAG over personal notes, PDFs, and documents, enabling plain-English querying and hybrid search with multi-hop context expansion.
Updated 4 days ago (2026-09-02 16:22 UTC)
MIT
intelligraph-mini
Code Analysis Developer Tools Knowledge & Memory
kfireew
F
license
A
quality
B
maintenance
Local-first MCP graph intelligence server providing RRF hybrid search, multi-hop traversal, source snippets, and rationale nodes for AI agents, without Docker or web UI.
Updated a month ago (2026-07-26 14:15 UTC)
5
-

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/bibinprathap/VeritasGraph'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

📚 Featured Guide — Build Governed AI Agents On-Prem

🚀 Quick Start (2 lines, no GPU)

🛠️ VeritasGraph Studio — Build, wire & test governed agents locally

📋 Examples

🌳 + 🔗 Graph + Tree: the ultimate retrieval

📊 Feature comparison

🎬 See it in action

🔌 MCP Server — connect your IDE agent to VeritasGraph

🏥 VeritasGraph-MCP Use Case — Production Medical AI on Azure

📖 Python API

CLI

Installation options

🏛️ Enterprise Compliance — VeritasGraph + VeritasReason

30-second smoke test (no install, stdlib only)

🔗 Interactive Graph Visualization

⚙️ Provider Support (OpenAI-compatible)

🐳 Deployment

Five-Minute Magic Onboarding (Docker)

Share with your team (free)

🏗️ Architecture

Why VeritasGraph?

🙌 Acknowledgments

🏆 Awards & Citation

Star History

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API