Skip to main content
Glama
SusuTawar

ragi

by SusuTawar
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
JavaScript
Local

ragi

Local-first RAG indexing and semantic search MCP server.

Requires Node 22 or newer.

Published/runtime usage is Node-first. bunx is not supported (bunx does not properly install transitive dependencies of published packages).

Quick Start

# Install dependencies
npm install

# Build and start MCP server
npm run build
npm start

# Or use npx without a global install
npx -y @susutawar/ragi@latest

# Or install globally, then run the bin directly
npm install -g @susutawar/ragi
ragi

Related MCP server: mcp-rag-server

Usage

# Initialize skill locally
npx -y @susutawar/ragi@latest init

# Initialize skill globally
npx -y @susutawar/ragi@latest init --global

# Check installations
npx -y @susutawar/ragi@latest init --check

# Refresh MCP definitions to the current @latest package spec
npm run mcp:update

npx -y @susutawar/ragi@latest init now:

  • asks which agent(s) are used in the current project,

  • supports a broader curated harness matrix with full, manual MCP, and skills only support tiers,

  • checks whether the installed ragi skill is missing, current, or outdated before copying,

  • checks whether ragi is already registered with the selected agent host(s) before offering MCP setup,

  • checks ~/.config/ragi/config.json and can scaffold it when missing or invalid,

  • prefers global/user MCP registration by default when the agent's config format is supported,

  • falls back to printing manual MCP registration instructions for unsupported agents.

--force overwrites outdated installed skills during init. Without --force, interactive runs ask before updating and non-interactive runs leave stale installs untouched.

After init edits a writable MCP config, restart that host so it reloads the updated definition. For manual hosts, init now prints the exact next command or UI step to finish setup.

Configuration

The default runtime config lives at ~/.config/ragi/config.json.

Use a project .ragrc only when this repo needs to override the global ragi defaults:

{
  "embedding": {
    "provider": "transformers_js",
    "model": "Xenova/all-MiniLM-L6-v2"
  },
  "providers": {
    "ollama": {
      "baseUrl": "http://localhost:11434"
    },
    "llama_cpp": {
      "baseUrl": "http://localhost:8080"
    }
  }
}

Recommended model choices by provider:

  • ollama: nomic-embed-text

  • transformers_js: Xenova/all-MiniLM-L6-v2

  • llama_cpp: an embedding-capable model served by your llama.cpp instance

The providers.*.baseUrl values control where ragi looks for each local service. When embedding.provider is ollama or llama_cpp and embedding.baseUrl is unset, ragi uses the matching provider-specific baseUrl from the global config.

Or use environment variables (RAGI_* takes precedence):

  • RAGI_VECTOR_STORE

  • RAGI_EMBEDDING_PROVIDER

  • RAGI_EMBEDDING_MODEL

  • RAGI_EMBEDDING_BASE_URL

Troubleshooting

If Node reports a sharp.node error while using the default transformers_js embedding provider:

  • avoid mixing bun install and npm install in the same node_modules

  • reinstall dependencies with the same package manager you plan to run with

  • if you use npx -y @susutawar/ragi@latest, let npm resolve a fresh package install instead of reusing a mixed local install

bunx @susutawar/ragi is not supported because bunx does not install transitive dependencies of published packages. Use npx instead.

When running npx @susutawar/ragi from inside this repo (development), run npm install first — the postinstall script creates a local bin shim so npx resolves correctly on Windows.

Available Tools

3 tools
rag_indexB

Index files/directories for the specified project

ParametersJSON Schema
NameRequiredDescriptionDefault
projectPathYesAbsolute path to the project directory to index
pathsNoSpecific files or directories to index (relative to projectPath). If not provided, indexes entire project.

TDQS

B3.4/5.0
Behavior2/5

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

No annotations are provided, and the description does not disclose any behavioral traits such as destructiveness, permissions required, or effects on existing index. It only states the action without additional context.

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 concise and to the point, containing no extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema and lack of details about return values, side effects, or limitations, the description is insufficient for an indexing tool that may have significant behavioral implications.

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%, but the description adds minimal value beyond stating 'for the specified project'. It does not clarify parameter formats or constraints beyond what the schema provides.

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 'Index' and the resource 'files/directories' for a specific project. It effectively distinguishes itself from sibling tools 'rag_list_projects' and 'rag_search' by specifying the indexing operation.

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 for indexing a project's files but provides no explicit guidance on when to use this tool versus alternatives, nor any conditions or prerequisites.

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

rag_list_projectsA

List available projects or validate a project path

ParametersJSON Schema
NameRequiredDescriptionDefault
projectPathNoOptional project path to validate or get info about. If not provided, shows current working directory info.

TDQS

A3.6/5.0
Behavior2/5

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

No annotations provided, and the description does not disclose behavioral traits such as side effects, authentication needs, or rate limits. It only states the basic function without any additional context beyond the schema.

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?

Extremely concise at two sentences, front-loading the primary purpose. No unnecessary words or repetition.

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?

For a simple list tool with one optional parameter and no output schema, the description is adequate. It covers the main functionality and the parameter behavior, though it could briefly mention what 'available projects' means or the nature of returned info.

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?

Schema description coverage is 100% for the single parameter, and the description adds meaningful context: it explains that omitting projectPath shows current working directory info, which goes beyond the schema's description of 'Optional project path to validate or get info about.'

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?

Clearly states 'List available projects or validate a project path', which is a specific verb and resource. It distinguishes from sibling tools 'rag_index' and 'rag_search' by implying a listing/validation function rather than indexing or searching.

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?

No guidance on when to use this tool versus siblings like rag_index or rag_search. The description only explains behavior when projectPath is provided or omitted, but does not discuss alternatives or prerequisites.

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.

  1. 3 tool updatesv0.1.3
    • First observedrag_index
    • First observedrag_list_projects
    • First observedrag_search
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: indexing files, listing projects, and semantic search. There is no overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with the 'rag_' prefix (rag_index, rag_list_projects, rag_search), making them predictable and easy to understand.

Tool Count4/5

Three tools is a reasonable count for a basic RAG server, covering indexing, project management, and search. It is slightly thin but not insufficient for the apparent scope.

Completeness3/5

The tool set covers core operations (index, search, list projects) but lacks important lifecycle operations like deleting or updating an index, which agents may need.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • mcp-rag-server

    kwanLeeFrmVi
    A
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that indexes documents and serves relevant context to LLMs via Retrieval Augmented Generation (RAG).
    28
    37
    MIT

  • corpus-rag

    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.
    MIT

Latest Blog Posts

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/SusuTawar/ragi'

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