How do I use anythingllm-mcp?

1. Click on "Install 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 Score 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 workspaces

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

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. Dates show when Glama detected each change.

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

Install Server

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

TDQS

Score is being calculated.

Maintenance

ActivityMaintained

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

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 4 months ago (2026-04-26 07:10 UTC)
16
631
MIT
AnythingLLM MCP Server
AI & Machine Learning RAG Systems
andreperez
A
license
A
quality
D
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 6 days ago (2026-09-03 17:13 UTC)
34
6
MIT
AnythingLLM Control Plane MCP
RAG Systems AI & Machine Learning
TheNovaNodes
F
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 3 days ago (2026-09-05 21:32 UTC)
5
1
-
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 a month ago (2026-08-11 18:19 UTC)
MIT

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/DezGDNY/anythingllm-mcp'

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

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

TDQS

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

MinerU Document Explorerofficial

AnythingLLM MCP Server

AnythingLLM Control Plane MCP

mcp-rag-bridge

Latest Blog Posts

MCP directory API