How do I use anythingllm-rag?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@anythingllm-rag Pull any existing project context for this repo from our RAG." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

anythingllm-rag

by smnspz

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

rag-workflow

A thin MCP server plus an agent workflow that gives every coding session memory: project context is retrieved from an AnythingLLM RAG at task start and written back, human-approved, when a task establishes durable facts.

The server wraps the AnythingLLM Developer REST API with five workflow-shaped tools instead of a generic chat proxy. The kit (workflow/) is the read/write procedure as two agent skills, plus a session-start trigger.

Requirements

Node >= 24 (target the latest locally installed nvm version).
A running AnythingLLM instance (self-hosted or desktop) with a Developer API key (Settings -> Developer API).

Related MCP server: mcp-rag

Tools

Tool	Endpoint	Purpose
`rag_find`	`GET /v1/workspaces`	Match a repo (`owner/repo`) to its workspace by exact display name
`rag_search`	`POST /v1/workspace/{slug}/vector-search`	Scored semantic chunks, no LLM generation
`rag_create_workspace`	`POST /v1/workspace/new`	Onboard a repo
`rag_write`	`POST /v1/document/raw-text`	Embed a curated markdown doc; upserts by title
`rag_forget`	`POST /v1/workspace/{slug}/update-embeddings`	Delete the doc under a title

Identity is the workspace name, never the slug: AnythingLLM strips / and rewrites . to -dot- in slugs, so slugs collide. Doc titles are compared extension-stripped because stored titles lose their extension (.md -> .txt). Both rules are proven in docs/resolver-spec.md and docs/context-schema.md.

Install

pnpm install
pnpm build

{
  "mcpServers": {
    "anythingllm-rag": {
      "command": "node",
      "args": ["/absolute/path/to/rag-workflow/dist/index.js"],
      "env": {
        "ANYTHINGLLM_BASE_URL": "http://your-anythingllm-host",
        "ANYTHINGLLM_API_KEY": "your-developer-api-key"
      }
    }
  }
}

Keep the API key out of version control.

Workflow kit

workflow/ holds the procedure that turns the five tools into session memory, written for the pi coding agent but portable to any agent with skills plus a prompt-injection hook:

skills/find-context/SKILL.md — read path: identify repo (git origin, cache fallback), find workspace, search per concern, adopt or propose onboarding.
skills/write-back/SKILL.md — write path: draft curated docs per docs/context-schema.md, get per-doc human approval, upsert.
extensions/rag-trigger.ts — injects the context-check instruction on the first prompt of each session in a git repo.
AGENTS.md — standing instructions, fallback when no hook is available.

Install by copying the skills and extension into your agent's discovery paths (pi: ~/.agents/skills/, ~/.pi/agent/extensions/).

Verify

Against a live instance, exercising all five tools and the upsert/no-stale rule:

ANYTHINGLLM_BASE_URL=... ANYTHINGLLM_API_KEY=your-key pnpm smoke

License

MIT

Available Tools

5 tools

rag_create_workspaceCreate RAG workspaceA

Create an AnythingLLM workspace named after the repo (e.g. 'owner/repo'). Returns {name, slug}.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Repo identity, e.g. 'owner/repo'

TDQS

A3.7/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It does state the return value ({name, slug}), which is useful, but it doesn't disclose whether the operation is idempotent, what happens if the workspace already exists, whether it requires authentication, or any side effects. For a creation tool, this is a moderate gap.

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 sentences with no wasted words. It front-loads the action, gives a concrete naming example, and states the return shape. Every sentence earns its place.

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?

For a single-parameter creation tool with no output schema, the description covers the core action, naming, and return value. However, it lacks behavioral details like idempotency or error behavior (e.g., duplicate workspace). Given the simplicity, it's adequate but not complete.

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 the 'name' parameter as 'Repo identity, e.g. 'owner/repo''. The description reinforces this with the same example but adds no new meaning beyond the schema. Baseline 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 action ('Create an AnythingLLM workspace'), the naming convention ('named after the repo, e.g. 'owner/repo''), and the return value ('Returns {name, slug}'). This distinguishes it from sibling tools like rag_find, rag_search, rag_write, and rag_forget, which all perform different operations.

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 creating a workspace tied to a repo, but it does not explicitly state when to use it versus alternatives. It doesn't mention prerequisites (e.g., whether the workspace must not already exist) or when a sibling like rag_write would be more appropriate. The naming convention gives some context, but no explicit when/when-not guidance.

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

rag_findFind RAG workspace for a repoA

Check whether an AnythingLLM workspace exists for a repo. Matches on exact display name (e.g. 'owner/repo'). Returns {exists, workspace|null, all}.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Repo identity, e.g. 'owner/repo'

TDQS

A3.6/5.0

Behavior4/5

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

With no annotations provided, the description carries the behavioral burden itself. It discloses that this is a non-mutating existence check, that matching is exact, and it explicitly describes the returned shape ({exists, workspace|null, all}). It does not state auth requirements, but for a simple existence check the core behavior is transparent.

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 three short sentences that front-load the main action, then add matching semantics and return shape. Every sentence contributes useful information with no padding.

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 low complexity, single parameter, and absent output schema, the description covers the important return contract and matching behavior. It does not tell the agent when this should be used over sibling tools, but the tool itself is simple enough that the omission is not fatal.

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%, so the schema already documents the `name` parameter. The description adds the useful detail that matching happens against the exact display name, which slightly enriches the schema semantics, but it mostly restates the parameter example rather than introducing substantial new meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool checks existence of an AnythingLLM workspace for a repo, and names the exact matching behavior. It is distinct enough from the creation/search/write/forget siblings, though it does not explicitly name a sibling or call out the difference from rag_search.

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?

There is no guidance on when to use this tool rather than rag_search or rag_create_workspace, and no mention of prerequisites or fallbacks. The reader can infer it might be useful before creating a workspace, but that is not stated.

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

rag_forgetDelete a doc from a workspaceA

Remove the embedded doc whose canonical title matches (extension-insensitive). Used when a doc is split or retired so the stale title leaves no retrievable embedding. Returns {forgotten, title|locations}.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	Workspace slug
`title`	Yes	Exact canonical doc title to delete

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses the deletion behavior and extension-insensitive matching, and mentions the return shape. However, it does not state irreversibility, permission requirements, or behavior when the title is not found, which would be valuable for a destructive 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 sentences with no wasted words. It front-loads the action and matching rule, then explains the use case and return value.

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 two-parameter destructive tool with no output schema and no annotations, the description covers the action, matching semantics, purpose, and return shape. It lacks failure behavior and irreversibility details, but is otherwise sufficient for correct invocation.

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 coverage is 100%, so the baseline is 3. The description adds meaningful nuance by clarifying that matching is 'extension-insensitive' and that the title is the canonical title, going beyond the schema's 'Exact canonical doc title to delete.'

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 uses a specific verb and resource: 'Remove the embedded doc whose canonical title matches (extension-insensitive).' It clearly distinguishes this deletion/forgetting tool from siblings like rag_find, rag_search, rag_write, and rag_create_workspace.

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?

It explicitly states when to use the tool: 'Used when a doc is split or retired so the stale title leaves no retrievable embedding.' It does not explicitly list alternatives or when-not-to-use conditions, but the context is clear enough for an agent to select it appropriately.

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

rag_searchVector search a workspaceA

Semantic search over a workspace's embedded docs. No LLM generation. Default scoreThreshold 0.2 (the native embedder scores low). Returns matching chunks with scores.

ParametersJSON Schema

Name	Required	Description
`slug`	Yes	Workspace slug (from rag_find)
`topN`	No
`query`	Yes
`scoreThreshold`	No

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that no LLM generation occurs, gives a default scoreThreshold of 0.2 with a rationale, and states the return shape. It does not mention side-effect safety, sorting behavior, or possible failure/empty-result behavior, leaving some burden uncovered.

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?

Three short sentences, front-loaded with the core purpose. Every clause adds a distinct fact: what it searches, that it is not generation, the threshold default, and the return format. There is no filler or redundancy.

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 straightforward search tool with no output schema, the description is largely complete: it explains the operation, non-generation behavior, threshold default, and return output. It could be more complete by naming alternative sibling tools or describing topN semantics, but the essential invocation details are covered.

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 low (25%), so the description must compensate. It does add real value for scoreThreshold (default and why) and query semantics, but topN is left entirely to inference from its name and schema constraint. The description partially compensates for the schema gap but not fully.

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 action and object: 'Semantic search over a workspace's embedded docs.' It also disambiguates from generation tools by stating 'No LLM generation' and clarifies the output ('Returns matching chunks with scores'). This clearly differentiates it from sibling write/forget/find tools.

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 usage is implied rather than explicit: it is a semantic retrieval tool, not an LLM-generation call, and the threshold default gives some context for tuning. However, it never names alternatives like rag_write or rag_find, nor does it state when not to use this tool.

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

rag_writeWrite curated context to a workspaceA

Embed a curated markdown doc into a workspace (raw-text + auto-embed). If overwrite=true (default), removes any existing embedding with the same title first to avoid stale duplicates.

ParametersJSON Schema

Name	Required	Description
`slug`	Yes	Workspace slug (from rag_find/rag_create_workspace)
`title`	Yes	Canonical doc name, e.g. 'architecture.md'
`content`	Yes	Markdown content
`overwrite`	No

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations provided, the description carries the behavioral disclosure burden. It does well by stating that overwrite=true is the default and that existing embeddings with the same title are removed first to avoid stale duplicates. It also mentions 'raw-text + auto-embed' as the write behavior, though it does not cover failure modes or return values.

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?

Two concise sentences with no filler. The primary action and format are front-loaded, and the important overwrite behavior is stated immediately after in a clear conditional.

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 write tool with no annotations or output schema, the description covers the essential behaviors: what is written, how it is embedded, and the default overwrite semantics. It does not explain return values or error cases, but the description is reasonably complete for an agent to select and invoke the tool correctly, especially with the schema covering required parameters.

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 75%, leaving the overwrite parameter semantically bare. The description compensates by explicitly stating that overwrite defaults to true and by explaining its effect: removing an existing embedding with the same title before writing. This is high-value meaning beyond 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 identifies a write/embed operation for a curated markdown doc into a workspace, with the verb 'embed' and the resource 'workspace.' It is obviously distinct from sibling tools like rag_find/rag_search (reads), rag_forget (deletion), and rag_create_workspace (workspace creation), even though those names are not explicitly mentioned.

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?

Usage is implied: this tool is for writing or curating context into a workspace. However, there is no explicit guidance about when to choose rag_write over rag_forget or rag_create_workspace, nor are alternatives named or exclusions stated.

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.

5 tool updatesv0.1.0Sep 14, 2026
- First observedrag_create_workspace
- First observedrag_find
- First observedrag_forget
- First observedrag_search
- First observedrag_write

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored 2026-09-14 17:05 across 5 tools

Disambiguation4/5

Each tool targets a distinct operation: lookup, creation, semantic search, document injection, and document removal. The only minor overlap is that rag_write can remove stale embeddings via overwrite, but the intent (write vs. forget) is clearly separated in the descriptions.

Naming Consistency4/5

All tools share a consistent rag_ prefix and use lowercase snake_case verbs. However, create_workspace includes an object while find, search, write, and forget are bare verbs, so the pattern is not perfectly uniform.

Tool Count5/5

Five tools is a well-scoped set for a focused RAG/workspace utility. Each tool covers a distinct part of the workflow without redundancy or bloat.

Completeness4/5

The core RAG lifecycle is covered: find/create workspaces, write docs, semantic search, and forget docs. The main gap is the lack of a workspace deletion tool, which prevents full lifecycle cleanup.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

agentbay-mcp AOAuth
io.github.thomasjumper
Persistent memory and knowledge management for AI agents with semantic search and 50+ tools.
Knowledge & Memory Autonomous Agents Agent Orchestration
21
TeamShared C
io.github.xhad
Shared memory for coding agents. Stop re-explaining your codebase every session.
Knowledge & Memory Developer Tools
1331
ContextStream MCP ServerOAuth
io.github.contextstream
Project memory, semantic code search, and grounded agent context.
Knowledge & Memory Code Analysis RAG Systems
143
OneLoreOAuth
ai.onelore
Shared project context for AI agents and teams: docs, tasks, and messages that stay current.
Project Management Documentation Access
2

Related MCP Servers

ContextAtlas
RAG Systems Code Analysis
codefromkarl
A
license
Not graded
quality
D
maintenance
Enables AI coding agents to retrieve and manage code context with hybrid search, project memory, and observability via MCP tools.
Updated 3 months ago (2026-06-02 06:10 UTC)
29
MIT
mcp-rag
RAG Systems Knowledge & Memory
LXVault
A
license
A
quality
C
maintenance
Enables per-project, traceable access to a RAG knowledge base, with tools for searching and adding knowledge chunks.
Updated 3 months ago (2026-06-25 03:11 UTC)
4
MIT
project-lore-mcp
Documentation Access RAG Systems Search
tamas-fm
A
license
Not graded
quality
A
maintenance
Routes coding agents to the most relevant project documentation (decisions, intent, constraints) with provenance and freshness, providing tools for task routing, knowledge search, and document context.
Updated 2 months ago (2026-07-26 06:15 UTC)
28 npm
MIT
shelfmark
RAG Systems Knowledge & Memory Search
LucasSantana-Dev
A
license
A
quality
A
maintenance
Enables coding agents to query local notes, decisions, docs, and code with hybrid retrieval (BM25 + embeddings + reranking) and get path:line citations. It provides tools like rag_query for full-corpus search and search_knowledge for project-scoped knowledge recall.
Updated a month ago (2026-08-12 21:11 UTC)
2
1
MIT