How do I use anythingllm-mcp?

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-mcp Ask my AnythingLLM workspace about our refund policy." 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-mcp

by DezGDNY

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

anythingllm-mcp

A small, safe helper that lets an AI assistant (like Claude) search and ask questions about your own documents — the ones you've stored in AnythingLLM.

New to this? No problem. This README explains everything step by step and defines the jargon as it comes up. If you can install an app and copy-paste a few lines, you can use this.

The 30-second version

AnythingLLM is an app that stores your documents and lets you chat with them ("What does my handbook say about vacation days?").
MCP (Model Context Protocol) is a standard way for AI assistants to use outside tools. Think of it as a power strip: an assistant plugs into it and suddenly has new abilities.
This project is one of those plugs. Once connected, your AI assistant can ask your AnythingLLM documents questions and get answers — without you copying and pasting anything.

It is read-only: it can look things up, but it can never change, delete, or mess up your AnythingLLM data. More on that below.

Related MCP server: AnythingLLM MCP Server

What it can do

Once connected, your assistant gains four abilities ("tools"):

Tool	In plain English
`check_auth`	"Am I connected to AnythingLLM correctly?"
`list_workspaces`	"What collections of documents do I have?" (AnythingLLM calls these workspaces)
`list_documents`	"What files are inside this workspace?"
`query_workspace`	"Answer this question using the documents in this workspace." This is the main one.

That's the whole toolbox. Nothing that can write, delete, or reconfigure anything.

Before you start, you need three things

Node.js, version 18 or newer. Node is the program that runs this helper. Check if you already have it by opening a terminal and typing:
```
node --version
```
If you see something like v20.11.0, you're set. If you get an error, install Node here (the "LTS" version is the safe choice).
AnythingLLM up and running, and reachable in your browser (for many people that's http://localhost:3001).
An AnythingLLM API key. An API key is like a password that lets programs talk to AnythingLLM on your behalf. To get one: open AnythingLLM → Settings → Tools → Developer API → create a key, and copy it somewhere safe. You'll paste it into your setup in a moment.
🔒 Treat this key like a password. Don't post it publicly or commit it to GitHub. (This tool is built so the key never has to appear in your chat.)

Install it

In a terminal, download the project and install the pieces it needs:

git clone https://github.com/DezGDNY/anythingllm-mcp.git
cd anythingllm-mcp
npm install

git clone copies the project onto your computer.
npm install downloads the small libraries this project depends on. (npm comes with Node.) You'll see it create a node_modules folder — that's normal.

That's it — there's nothing to "build." The helper is ready to run.

Connect it to your AI assistant

An MCP helper doesn't run on its own; your assistant starts it when needed. You tell the assistant about it by adding a few lines to its configuration file. For example, in Claude Code (.mcp.json) or Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "anythingllm": {
      "command": "node",
      "args": ["/full/path/to/anythingllm-mcp/index.js"],
      "env": {
        "ANYTHINGLLM_BASE_URL": "http://localhost:3001",
        "ANYTHINGLLM_API_KEY": "paste-your-key-here"
      }
    }
  }
}

What each part means:

command / args — how to start the helper: run node on this project's index.js. Use the full path to the file (e.g. on Windows, C:\\Users\\you\\anythingllm-mcp\\index.js — note the double backslashes in JSON).
env — settings passed to the helper when it starts:
- ANYTHINGLLM_BASE_URL — the web address where your AnythingLLM lives. Leave it as http://localhost:3001 unless yours is elsewhere. (You don't need to add /api/v1; the helper adds that for you.)
- ANYTHINGLLM_API_KEY — the key you copied earlier.

Save the file and restart your assistant so it picks up the new helper.

Tip: putting the key in the env block here means it's handled by your assistant, not typed into a chat. If you'd rather not keep the key in this file at all, you can set it as an environment variable on your system instead — the helper reads ANYTHINGLLM_API_KEY from wherever it's provided.

Try it

Ask your assistant something like:

"Use the anythingllm tools to ask my Project Docs workspace what our refund policy is, and show me which documents the answer came from."

Behind the scenes it calls query_workspace, and you get an answer grounded in your actual documents, with the sources listed.

By default, questions run in query mode, which means the answer comes only from your documents (it won't make things up from general knowledge). If you'd rather let the assistant blend in its own knowledge, ask it to use chat mode instead.

If something doesn't work

"Not authenticated" / auth errors — the API key is missing or wrong. Double- check you copied the whole key, and that ANYTHINGLLM_BASE_URL points at your actual AnythingLLM address.

"Failed to connect" in your assistant — the helper couldn't start. The two usual causes:

The assistant can't find node. Some assistants start helpers with a stripped-down environment — a bare setup where the system doesn't know where node is installed. If you hit this, point command at the full path to your node program instead of just "node" (find it by running where node on Windows or which node on macOS/Linux).
The key wasn't passed in. Make sure the env block above is filled in.

Want to see what actually happened? Start the helper by hand to read its messages:

node /full/path/to/anythingllm-mcp/index.js

If it prints anythingllm-mcp ready … and then seems to "hang," that's actually success — it's running and waiting for your assistant to talk to it. Press Ctrl+C to stop. If it prints an error instead, that error tells you what's wrong.

Is it safe? (Yes — here's why)

This helper can only read and ask questions. On purpose, it has no tools that create, delete, or change anything in AnythingLLM — no deleting workspaces, no editing documents, no changing settings. So even if an AI assistant went completely haywire, the worst it could do through this helper is look things up. Your data is safe.

It also keeps no secrets in the code. Your address and key come from the settings you provide, never from this file — which is why it's safe to share and publish.

How it works (optional, for the curious)

It's one small file (index.js). When your assistant starts it, the helper:

reads your AnythingLLM address and key from the environment,
waits for the assistant to ask for one of the four tools,
makes a normal web request to AnythingLLM's API, and
hands the answer back.

It uses the official MCP SDK and Node's built-in networking — no heavy dependencies.

License

MIT — free to use, change, and share. Please keep the copyright line.

Available Tools

4 tools

check_authCheck AnythingLLM authA

Verify the configured API key can reach AnythingLLM. Returns whether authentication succeeded.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/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 full burden of behavioral disclosure. It states the tool tests connectivity and authentication, and that it returns whether authentication succeeded. It does not mention side effects (none expected), error behavior, or rate limits, but for a zero-parameter read-only check this is largely adequate.

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 sentences with no filler. The main action is front-loaded, and the return value is stated. Every word earns its place.

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 auth check with no parameters and no output schema, the description is sufficiently complete: it explains the purpose and the return semantics. It does not specify the exact return format (e.g., boolean vs. message), but 'whether authentication succeeded' implies a boolean. A brief note on when to use it would push this to a 5.

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 schema coverage is 100% (empty schema). Per the baseline for 0-parameter tools, a score of 4 is appropriate. The description adds nothing about parameters because there are none to document.

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 verifies the configured API key can reach AnythingLLM and returns whether authentication succeeded. This distinguishes it from the sibling data-operation tools, which work with workspaces and documents. The verb 'verify' plus the specific resource makes the purpose unambiguous.

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 this is a preflight check for authentication, but it does not explicitly say when to use it or how it relates to the sibling tools. There is no guidance like 'run this before calling query_workspace' or 'use when you encounter auth errors.' The context is clear enough, but explicit instructions are missing.

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

list_documentsList documents in a workspaceB

List the documents currently embedded (searchable) in a workspace. Accepts a workspace name or slug.

ParametersJSON Schema

Name	Required	Description	Default
`workspace`	Yes	Workspace name or slug (from list_workspaces).

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds the detail that documents are 'currently embedded (searchable)', which is useful, but it does not mention whether the operation is read-only, any authentication requirements, output format, pagination, or potential side effects. For a tool with zero annotation coverage, this is insufficient.

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 sentences with no redundancy. The core action and scope are front-loaded, and the parameter note is concise. Every word 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?

The tool is simple (single parameter, no output schema), but the description omits information about the return format and any prerequisites like authentication. While the sibling check_auth hints at auth needs, the description itself does not address it. Adequate but with clear gaps for an unannotated tool.

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% — the workspace parameter is fully documented with 'Workspace name or slug (from list_workspaces)'. The description's 'Accepts a workspace name or slug' repeats the schema without adding meaningful new semantics. Baseline of 3 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 states a specific verb ('List') and resource ('documents') with a clarifying qualifier ('currently embedded (searchable)') that distinguishes it from siblings like list_workspaces and query_workspace. The purpose is unambiguous and differentiated.

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 provides no explicit guidance on when to use this tool versus alternatives. It merely states what it does, leaving the agent to infer appropriate usage from the sibling names. There is no mention of conditions or exclusion criteria.

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

list_workspacesList workspacesA

List all AnythingLLM workspaces with their display name and slug. Use a name or slug from here with the other tools.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

No annotations are provided, so the description carries the burden. It states the tool lists workspaces, implying a read-only operation with no side effects. While it doesn't explicitly mention 'read-only' or lack of side effects, the operation is inherently non-destructive and the description gives no indication of hidden behavior.

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, two sentences, and directly to the point. It includes the essential information without any redundancy or unnecessary detail.

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 tells the agent what the tool does, what it returns (display name and slug), and how to use that output with other tools. This is sufficient for a simple listing operation with no output schema defined.

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, so no parameter explanations are needed. The description's mention of output fields (display name and slug) indirectly clarifies what the tool returns, satisfying the baseline for a parameterless tool.

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 function: listing all AnythingLLM workspaces and returning their display name and slug. This is a specific verb-resource pair that distinguishes it from sibling tools like check_auth, list_documents, and query_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?

The description provides guidance by stating 'Use a name or slug from here with the other tools,' which tells the agent how to utilize the output. However, it doesn't explicitly contrast with alternative tools for situations where this tool is not appropriate, though the zero-parameter simplicity makes misuse unlikely.

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

query_workspaceQuery a workspace (RAG)A

Ask a natural-language question answered from a workspace's embedded documents. Default 'query' mode answers ONLY from the documents (grounded, cites sources); 'chat' mode also allows the model's general knowledge. Read-only.

ParametersJSON Schema

Name	Required	Description	Default
`mode`	No	'query' = answer only from the docs (default); 'chat' = also use general knowledge.	query
`question`	Yes	The question to ask.
`workspace`	Yes	Workspace name or slug (from list_workspaces).

TDQS

A4.2/5.0

Behavior4/5

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

The description explicitly states 'Read-only', which is a key behavioral trait, and elaborates on how 'query' mode grounds answers in documents while 'chat' mode allows general knowledge. No annotations are present, so the description carries the full burden and covers the main safety aspect.

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, front-loaded sentence that immediately states the core purpose, followed by a concise explanation of modes. Every word earns its place; there is no 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 read-only query tool with a well-documented schema and no output schema, the description covers the main aspects: purpose, modes, and safety. It does not specify the return format (e.g., citations structure), but that is not critical for invoking the tool correctly.

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%, and the description adds no new parameter-level information beyond reinforcing the mode behavior already described in the schema. It does not clarify parameter formats or edge cases, so the baseline 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 verb 'Ask' and the resource 'workspace's embedded documents', and differentiates itself from sibling tools like list_documents and list_workspaces by focusing on natural-language questioning. The mention of modes (query/chat) further clarifies its scope.

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 explains the two modes and when each is appropriate (grounded vs general knowledge), but does not explicitly contrast with sibling tools or state when not to use this tool. Context is clear enough for an agent to infer usage, but lacks explicit alternatives.

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.

4 tool updatesv0.1.0Sep 9, 2026
- First observedcheck_auth
- First observedlist_documents
- First observedlist_workspaces
- First observedquery_workspace

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

A4.2/5.0

Scored 2026-09-09 17:35 across 4 tools

Disambiguation5/5

Each tool maps to a distinct resource and action: authentication status, workspace listing, document inventory, and document-grounded querying. There is no functional overlap; list_documents and query_workspace are clearly different in purpose.

Naming Consistency5/5

All four tool names follow the same lower_snake_case verb_noun pattern: check_auth, list_workspaces, list_documents, query_workspace. The naming makes both the action and target predictable.

Tool Count5/5

Four tools is well-scoped for a read/query-focused AnythingLLM server. Each tool covers a necessary step in the workflow with no redundant utilities.

Completeness5/5

For the apparent read-only retrieval scope, the workflow is complete: authenticate, discover workspaces, inspect embedded documents, and ask grounded questions. Write operations like workspace or document management are absent but appear intentionally outside this tool set's purpose.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

OrchaOAuth
io.github.westonhancock
Securely search and manage workspace context files for AI agents and teams.
Search File Systems Knowledge & Memory
1
mcp
com.skopik
Your org's AI agents, tasks, runs, search, and brain files as MCP tools and resources.
Agent Orchestration Knowledge & Memory Search
2
Dewey
com.meetdewey
Agentic search over your Dewey document collections from any MCP-compatible client.
Search Knowledge & Memory RAG Systems
2
docs2mcpOAuth
com.docs2mcp
Query your own PDFs and documents from any MCP client. Every answer cites the page it came from.
RAG Systems Search
1

Related MCP Servers

MinerU Document Explorerofficial
RAG Systems Search
opendatalab
A
license
Not graded
quality
D
maintenance
Enables AI agents to search, deep-read, and build knowledge bases from Markdown, PDF, DOCX, and PPTX documents via MCP tools for retrieval, document navigation, and ingestion.
Updated 5 months ago (2026-04-26 07:10 UTC)
36 npm
635
MIT
AnythingLLM MCP Server
AI & Machine Learning RAG Systems
andreperez
A
license
A
quality
B
maintenance
Enables MCP-compatible clients to interact with AnythingLLM, providing tools for workspace management, chat and thread operations, document operations, vector search, and system inspection.
Updated 17 hours ago (2026-09-28 19:40 UTC)
34
6
MIT
AnythingLLM Control Plane MCP
RAG Systems AI & Machine Learning
TheNovaNodes
A
license
A
quality
B
maintenance
Enables managing and controlling AnythingLLM instances through MCP, providing tools to list, create, and delete workspaces, retrieve system environment settings, and get vector counts.
Updated 24 days ago (2026-09-05 21:32 UTC)
5
1
MIT
mcp-rag-bridge
RAG Systems Search Vector Databases
zyay
A
license
Not graded
quality
B
maintenance
Enables AI agents to query and manage a document knowledge base via MCP, with RAG-powered search and grounded answers with citations.
Updated 2 months ago (2026-08-11 18:19 UTC)
MIT

anythingllm-mcp

The 30-second version

What it can do

Before you start, you need three things

Install it

Connect it to your AI assistant

Try it

If something doesn't work

Is it safe? (Yes — here's why)

How it works (optional, for the curious)

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

MinerU Document Explorerofficial