Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@anythingllm-mcp ask my rpg-rules workspace how grappling works, then fetch the answer"
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.
A zero-dependency Node MCP (Model Context Protocol) server for
AnythingLLM, exposing async chat and workspace
management over the AnythingLLM REST API. Node stdlib only — no
@modelcontextprotocol/sdk, nothing to break on reinstall, no SDK drift.
This came out of building a strict, no-fabrication RAG setup in AnythingLLM over a large local library (tabletop RPG rulebooks) served by self-hosted Ollama.
To stop the model inventing rules, we moved the fact-retrieval workspace onto a bigger local model (Qwen 32B) for stronger grounding. Bigger local models are slow on modest VRAM (~4-5 tok/s once the model spills to CPU), so a normal answer takes well over a minute.
That collided with a hard limit: the MCP tool-call timeout in Claude Desktop /
Claude Code is ~60 seconds and is not configurable. The timeout field in
claude_desktop_config.json and MCP_TIMEOUT are not honored for per-call
execution (open issues: anthropics/claude-code
#43791,
#22542). Every long
answer from the stock AnythingLLM MCP server's synchronous chat_with_workspace
died at 60s. Only the AnythingLLM web UI, which has no such cap, worked.
The fix isn't a longer timeout (you can't set one) — it's to never block a
call. ask_workspace starts the query and returns a job_id instantly;
get_answer fetches the result when it's ready. No single call is long, so the
timeout never fires, no matter how slow the model.
While replacing the chat path, we also recreated the workspace-management tools
we relied on (list/get/update/create/delete workspaces, list documents, manage
embeddings) directly over the REST API — so this one server fully replaces the
stock anythingllm MCP server, and does it with zero dependencies for
resilience (the stock server had broke on a bad API-key init and a
reinstall-wiped patch; stdlib-only avoids that whole class of problem).
Related MCP server: anythingllm-mcp
Tool | Purpose |
| Start an async chat query. Returns a |
| Fetch a job: |
| All workspaces (slug, name, chatModel, chatMode, topN). |
| One workspace's full settings + embedded documents. |
| Update settings ( |
| Create a workspace. |
| Delete a workspace (destructive). |
| System document/vector file tree ( |
| Add/remove documents in a workspace's embeddings (paths from |
git clone this repo (e.g. to C:\Tools\anythingllm-async-mcp). No npm install needed.
Register it in Claude Desktop's claude_desktop_config.json (see config.example.json):
{
"mcpServers": {
"anythingllm-async": {
"command": "C:\\Program Files\\nodejs\\node.exe",
"args": ["C:\\Tools\\anythingllm-async-mcp\\server.js"],
"env": {
"ANYTHINGLLM_BASE_URL": "http://your-anythingllm-host:3001",
"ANYTHINGLLM_API_KEY": "<YOUR_ANYTHINGLLM_API_KEY>"
}
}
}
}Restart Claude Desktop. It launches/stops the server automatically.
Build the bundle with the official packer and install it via Claude Desktop:
```n
Then double-click `anythingllm-mcp.mcpb` (or Claude Desktop -> Settings -> Extensions -> Advanced -> Install extension), and enter your AnythingLLM Base URL and API key when prompted. A prebuilt `.mcpb` is attached to each GitHub Release. Note: use the config-file method OR the extension, not both at once (they expose the same tools twice).
## Usage
- **Query:** `ask_workspace` with a workspace `slug` + question -> note the `job_id`.
Then `get_answer(job_id)`; if `pending`, wait ~15-30s and call again.
- **Manage:** `list_workspaces`, `get_workspace`, `update_workspace`, etc. return immediately.
## Requirements
- Node.js >= 18 (uses the built-in global `fetch`).
- An AnythingLLM instance with a Developer API key (Settings -> Tools -> Developer API).
## Development
node --check server.js # syntax node test.js # end-to-end smoke test (drives the MCP protocol over stdio)
`test.js` reads the env from your Claude Desktop config for convenience.
## Security
- The API key is read from the `ANYTHINGLLM_API_KEY` environment variable — never hard-coded.
- `.gitignore` excludes `.env`, `claude_desktop_config*.json`, and backups so secrets never get committed.
## License
MIT — see `LICENSE`.Async chat query to an AnythingLLM workspace. Returns a job_id instantly so the call never hits the ~60s MCP timeout (use for slow models like Qwen 32B). Poll get_answer until status is 'done'.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | query=only indexed docs (default); chat=allow model general knowledge | |
| slug | Yes | ||
| question | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does well: it discloses asynchrony, the instant job_id return, the ~60s MCP timeout it avoids, and the polling contract. It omits failure/error behavior and whether the slug must already exist, which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with what the tool does and the return contract before the usage hint. No filler; every sentence carries distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an async tool with no annotations and no output schema, the description covers the essential async contract, the immediate return value, and the polling loop. Residual gaps are the undocumented slug/question parameters and unstated error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% — only 'mode' is documented, and that documentation lives in the schema, not the description. 'slug' and 'question' are undocumented in both places; the description implies a workspace and a query but adds no format, constraints, or defaults, so it does not compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Async chat query to an AnythingLLM workspace') and immediately names the sibling it pairs with ('Poll get_answer'), so an agent can distinguish it from get_answer and the workspace CRUD tools without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a concrete selection condition ('use for slow models like Qwen 32B') and names the required follow-up tool and its terminal state ('Poll get_answer until status is done'). It stops short of stating when a synchronous alternative should be preferred, but the routing guidance is otherwise explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new workspace by name (AnythingLLM derives the slug).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the full behavioral burden for a mutation tool. It adds one useful detail (AnythingLLM derives the slug, so no slug input is needed), but says nothing about permission requirements, duplicate-name handling, reversibility, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the action and resource, and every clause earns its place by clarifying the name/slug relationship.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description omits auth needs, error behavior on duplicate names, and what the created workspace returns. The one parameter is minimally covered, leaving an agent to guess at failure modes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with a single required string 'name', so the description must compensate. It does clarify that this string is the workspace display name and that the slug is derived rather than supplied, but adds no format, length, or uniqueness constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Create') and resource ('workspace') with the identifying input ('by name'). The verb set across siblings (get/update/delete_workspace) makes the action unambiguous, though the description never names a sibling or scope boundary explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus update_workspace or how it relates to list_workspaces/get_workspace. There is no mention of prerequisites (auth, plan limits) or the alternative of creating with pre-set settings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a workspace by slug. DESTRUCTIVE -- removes the workspace and its embeddings.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does add meaningful behavioral context: the operation is destructive and cascades to the workspace's embeddings, which is non-obvious. However, it omits irreversibility, required authorization, and failure behavior for unknown slugs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with zero filler. The destructive warning is front-loaded immediately after the purpose statement, which is exactly where an agent needs it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter destructive mutation with no annotations and no output schema, the description covers the essentials of what and how harmful, but leaves gaps around irreversibility, permissions, and error cases that an agent authorizing/planning the call would want.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single `slug` parameter, but the description clarifies that the slug is the workspace identifier used for lookup. That is real but minimal added meaning; no format or example is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Delete) and resource (workspace) plus the lookup key (by slug). An agent can distinguish this from get_workspace, update_workspace, and create_workspace purely from the verb, and from list_workspaces by the singular-resource scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to choose deletion versus alternatives, no prerequisites, no confirmation or permission requirements. The only signal is the DESTRUCTIVE marker, which is a warning rather than usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch an ask_workspace job by job_id: status pending|done|error, plus answer text and source document titles when done.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does notably well: it enumerates the status values (pending|done|error) and states that answer text and source titles are only populated when done. It omits permission needs and what happens to a job_id after completion, keeping it below a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the highest-value information (what is fetched and what comes back) appears first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description is right to cover return states and conditional fields, which it does. For a one-parameter polling tool this is nearly sufficient; only error-handling and re-polling behavior are left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with one required parameter, so the description must compensate, but it says only 'by job_id' — essentially restating the parameter name without format or origin details. The singular 'job_id' wording hints at one job per call, which is minor added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb ('Fetch') plus resource ('an ask_workspace job') and it names the sibling tool that produces the job, so the agent can distinguish it from ask_workspace itself. The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Referencing 'ask_workspace job by job_id' implies the polling workflow (call after ask_workspace returns a job_id) and the sibling list confirms ask_workspace is the producer. It lacks explicit when/when-not phrasing or guidance on polling cadence, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one workspace's full settings (prompt, model, mode, topN, threshold) and embedded documents.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It usefully states the return contents (settings fields plus embedded documents), which is the key behavioral trait for a read tool, but says nothing about permissions, unknown-slug behavior, or payload size.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence with no filler; the parenthetical field list is dense but earns its place by pre-announcing the payload. Nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by naming what is returned, which is the main thing an agent needs for a simple single-parameter read tool. Only edge cases (missing workspace, auth) are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single 'slug' parameter, and the description never explains it. 'One workspace's' weakly implies the parameter selects a workspace, but the format or source of the slug is undocumented in both the schema and the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one workspace's full settings') and enumerates the settings returned, so the agent knows exactly what it retrieves. It implicitly separates itself from list_workspaces by saying 'one', but never names the sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to call this versus list_workspaces, ask_workspace, or update_workspace, and no prerequisites (e.g. needing a slug that already exists). Usage can only be inferred from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List documents known to the AnythingLLM system (the document/vector file tree under localFiles).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It usefully scopes the result to the localFiles document/vector tree, which clarifies what is enumerated, but says nothing about ordering, pagination, size limits, or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler, appropriately sized for a no-argument list tool, though it is content-light enough that one clause about the returned structure could have been added without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description must stand in for return-value behavior. It identifies the scope of the listing but does not describe the shape of returned entries or whether workspace/embedding metadata is included, leaving a modest gap for a zero-param tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no per-parameter semantics to explain; the baseline for a no-arg schema is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (documents) plus the scope (AnythingLLM's localFiles document/vector tree). An agent can distinguish it from workspace-management siblings like list_workspaces, though it doesn't explicitly name a contrast tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the simple listing semantics and the absence of any competing document-list sibling, but the description gives no explicit when-to-use guidance or relationship to tools like get_answer or update_embeddings that also touch documents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all AnythingLLM workspaces (slug, name, chatModel, chatMode, topN).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a safe read by saying 'List' and discloses which fields come back, but says nothing about pagination, ordering, result size limits, or whether all workspaces are always returned. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with the verb and scope front-loaded and no filler. The parenthetical field list is compact and earns its place by previewing the response shape.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters, no annotations, and no output schema, the description does the useful work of enumerating returned fields so the agent knows what it gets. It stops short of covering pagination or ordering behavior for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing to disambiguate; per the rubric a 0-param tool baselines at 4. The description's field list is informative but does not map to any input arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (all AnythingLLM workspaces), and even enumerates the fields returned (slug, name, chatModel, chatMode, topN). The 'all' scope cleanly distinguishes it from the sibling get_workspace, which is singular.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'List all' implies discovery/enumeration usage, but the description never says when to prefer this over get_workspace or when a slug lookup is more appropriate. No prerequisites or exclusions are stated, so context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add or remove documents in a workspace's embeddings. adds/deletes are arrays of document paths from list_documents/get_workspace.
| Name | Required | Description | Default |
|---|---|---|---|
| adds | No | ||
| slug | Yes | ||
| deletes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that this is a mutation of the embedding index, but says nothing about whether deletions are irreversible, whether re-embedding occurs, how long it takes, or what permissions are needed — a significant gap for a write tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences that front-load the core operation, with the parameter clarification following. No filler, though the phrasing 'adds/deletes are arrays' is slightly informal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter mutation tool with no annotations, no output schema, and 0% schema coverage, the description leaves key gaps: the slug's meaning, required permissions, and the consequences/reversibility of deletes. It is not sufficient for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does compensate partially by explaining that adds/deletes are arrays of document paths sourced from list_documents/get_workspace. However, the required 'slug' parameter is left entirely unexplained in both the schema and the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verbs (add/remove) and the resource (documents in a workspace's embeddings), which is clear enough to distinguish from read-oriented siblings like list_documents and get_workspace. It does not explicitly name a sibling it replaces, but the operation type is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (to modify the embedding set) and usefully points to list_documents/get_workspace as the source of document paths. However, it gives no exclusions, prerequisites, or contrast with alternatives such as update_workspace.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a workspace's settings. settings is an object, e.g. {openAiPrompt, openAiTemp, chatMode, topN, similarityThreshold, chatModel, chatProvider, queryRefusalResponse}.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| settings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden. It says 'update' but never states whether the settings object is merged with existing values or replaces them wholesale, whether fields can be cleared, what permissions are required, or what a successful response contains. For a mutation tool with nested-object input this is a significant gap, and the example key list is the only real behavioral hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with no filler, and the purpose statement is front-loaded before the parameter hint. The example object is dense but earns its place given the 0% schema coverage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with a nested object parameter, no annotations, and no output schema. The description omits merge/replace semantics, key types and ranges, permission requirements, and any error behavior, leaving real gaps for such a complex input.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% with two parameters, so the description must compensate. It does helpfully enumerate the keys accepted inside the opaque 'settings' object (openAiPrompt, openAiTemp, chatMode, topN, etc.), which is meaningful beyond the bare 'type: object' schema. However the required 'slug' parameter goes entirely unexplained, and the example gives no types or acceptable ranges for those keys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (update) and resource (a workspace's settings), which cleanly separates it from siblings like create_workspace, delete_workspace, and get_workspace. It does not, however, differentiate between settings updates and the closely related update_embeddings, so sibling routing is left partly to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool, no prerequisites (e.g. workspace must exist, caller must own it), and no reference to alternatives such as create_workspace for new workspaces. The agent gets a purpose but no selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v2.0.0ask_workspacecreate_workspacedelete_workspaceget_answerget_workspacelist_documentslist_workspacesupdate_embeddingsupdate_workspaceScored across 9 tools
Each tool maps to a distinct resource+action: the ask_workspace/get_answer pair forms a clear async job pattern, and workspace CRUD (list/get/create/update/delete) is unambiguous. The only mild overlap is embedded documents appearing in get_workspace vs list_documents, but descriptions clearly differentiate them.
All names follow a clean verb_noun pattern (list_workspaces, get_workspace, create_workspace, update_workspace, delete_workspace, list_documents, update_embeddings, ask_workspace, get_answer). No convention mixing or vague verbs.
Nine tools is well-scoped for an AnythingLLM management server, with each tool earning its place across workspace management, chat, and embeddings.
Workspace lifecycle is fully covered (list/get/create/update/delete) and the chat flow has a complete async request+poll pair. The one notable gap is document ingestion—there is no tool to create/upload documents, only to list them and attach/remove existing ones, so new content must be added externally.
Your org's AI agents, tasks, runs, search, and brain files as MCP tools and resources.
Shared memory and actions for Claude, Kiro, OpenAI, Cursor, and other MCP-compatible AI clients.
Cross-tool persistent memory and context for AI assistants over MCP.
Agent-native notes, tasks, dev-docs, vaults, sync & handoffs. MCP + OpenAPI dual surface.
