What can you do with this server?

This MCP Server for ArangoDB is a TypeScript-based service that enables interaction with ArangoDB databases through Model Context Protocol tools, offering seamless integration with applications like Claude and VSCode extensions. Key capabilities include: * Execute AQL queries with optional bind variables * Insert documents into collections (with auto-generated keys if needed) * Update existing documents * Remove documents from collections * Backup collections to JSON files * List all collections in the database * Create new collections with customizable type and synchronization behavior

Which integrations are available for this server?

Provides database interaction capabilities with ArangoDB, implementing core operations like executing AQL queries, inserting/updating/removing documents, creating and listing collections, and backing up data to JSON files.

How do I use MCP Server for ArangoDB?

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., "@MCP Server for ArangoDB list all collections in the database" 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.

en es ja ko zh

MCP Server for ArangoDB

by ravenwits

Overview Schema Related Servers Score Discussions

TypeScript

Remote

MCP Server for ArangoDB

A Model Context Protocol server for ArangoDB

This is a TypeScript-based MCP server that provides database interaction capabilities through ArangoDB. It implements core database operations and allows seamless integration with ArangoDB through MCP tools. You can use it wih Claude app and also extension for VSCode that works with mcp like Cline!

Features

Tools

Tool	Category	Read-only	Mutates data/schema	Purpose
`arango_query`	Query	No	Maybe	Execute general AQL with bind variables, bounded results, and query guardrails.
`arango_read_query`	Query	Yes	No	Execute read-only AQL and reject write/DDL keywords.
`arango_validate_query`	Query	Yes	No	Parse and validate AQL without executing it.
`arango_explain_query`	Query	Yes	No	Inspect AQL execution plans, index usage, and optimizer output.
`arango_describe_database`	Discovery	Yes	No	Summarize collections, counts, indexes, and sample fields.
`arango_list_collections`	Discovery	Yes	No	List collections in the configured database.
`arango_get_collection`	Discovery	Yes	No	Return collection properties, count, and indexes.
`arango_create_collection`	Collection	No	Yes	Create document or edge collections.
`arango_drop_collection`	Collection	No	Yes	Drop a collection, requiring `confirm: true`.
`arango_get_document`	Document	Yes	No	Fetch one document by collection and `_key`.
`arango_list_documents`	Document	Yes	No	List documents with `limit` and `offset` pagination.
`arango_count_documents`	Document	Yes	No	Count documents in a collection.
`arango_sample_documents`	Document	Yes	No	Return a small random sample for schema discovery.
`arango_insert`	Document	No	Yes	Insert one document into a collection.
`arango_bulk_insert`	Document	No	Yes	Insert up to 1000 documents in one request.
`arango_update`	Document	No	Yes	Partially update one document by `_key`.
`arango_bulk_update`	Document	No	Yes	Patch up to 1000 documents by `_key` or `_id`.
`arango_remove`	Document	No	Yes	Remove one document by `_key`.
`arango_list_indexes`	Index	Yes	No	List indexes for a collection.
`arango_create_index`	Index	No	Yes	Create persistent, geo, TTL, or inverted indexes.
`arango_list_views`	ArangoSearch	Yes	No	List ArangoSearch and search-alias Views.
`arango_create_search_view`	ArangoSearch	No	Yes	Create an ArangoSearch View linked to a collection.
`arango_search`	ArangoSearch	Yes	No	Search an ArangoSearch View with analyzer-aware BM25 ranking.
`arango_list_analyzers`	Analyzer	Yes	No	List ArangoSearch Analyzers.
`arango_create_analyzer`	Analyzer	No	Yes	Create an ArangoSearch Analyzer.
`arango_list_graphs`	Graph	Yes	No	List named graphs.
`arango_create_graph`	Graph	No	Yes	Create a named graph with one edge definition.
`arango_insert_edge`	Graph	No	Yes	Insert an edge document with `_from` and `_to`.
`arango_traverse`	Graph	Yes	No	Traverse edges from a start vertex using an edge collection or named graph.
`arango_shortest_path`	Graph	Yes	No	Find the shortest path between two vertices using an edge collection or named graph.
`arango_backup`	Backup	No	Filesystem	Backup collections to JSON files under `ARANGO_BACKUP_ROOT`.

All tools return JSON text and structuredContent when successful. Read-heavy tools expose bounded limit parameters to keep responses agent-friendly. Query tools also support guardrails such as memoryLimit, maxRuntime, and failOnWarning where applicable.

Related MCP server: SQL MCP Server

Installation

Installing via NPM

To install arango-server globally via NPM, run the following command:

npm install -g arango-server

Running via NPX

To run arango-server directly without installation, use the following command:

npx -y arango-server

Configuring for VSCode Agent

To use arango-server with the VSCode Copilot agent, you must have at least VSCode 1.99.0 installed and follow these steps:

Create or edit the MCP configuration file:
- Workspace-specific configuration: Create or edit the .vscode/mcp.json file in your workspace.
- User-specific configuration: Optionally, specify the server in the setting(mcp) VS Code user settings to enable the MCP server across all workspaces.
  Tip: You can refer here to the MCP configuration documentation of VSCode for more details on how to set up the configuration file.

Add the following configuration:

{
  "servers": {
    "arango-mcp": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "arango-server"],
      "env": {
        "ARANGO_URL": "http://localhost:8529",
        "ARANGO_DB": "your_database_name",
        "ARANGO_USERNAME": "your_username",
        "ARANGO_PASSWORD": "your_password"
      }
    }
  }
}

Start the MCP server:
- Open the Command Palette in VSCode (Ctrl+Shift+P or Cmd+Shift+P on Mac).
- Run the command MCP: Start Server and select arango-mcp from the list.
Verify the server:
- Open the Chat view in VSCode and switch to Agent mode.
- Use the Tools button to verify that the arango-server tools are available.

To use with Claude Desktop

Go to: Settings > Developer > Edit Config or

MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%/Claude/claude_desktop_config.json

You can check out mcp documentation to set it up too.

To use with OpenCode

Add the following configuration to your OpenCode config file, such as opencode.json or opencode.jsonc:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "arango": {
      "type": "local",
      "command": ["npx", "-y", "arango-server"],
      "enabled": true,
      "environment": {
        "ARANGO_URL": "your_database_url",
        "ARANGO_DB": "your_database_name",
        "ARANGO_USERNAME": "your_username",
        "ARANGO_PASSWORD": "your_password"
      }
    }
  }
}

After restarting OpenCode, ask it to use the arango MCP tools for ArangoDB tasks.

To use with Cline VSCode Extension

Go to: Cline Extension > MCP Servers > Edit Configuration or

MacOS: ~/Library/Application Support/Code/User/globalStorage/cline.cline/config.json
Windows: %APPDATA%/Code/User/globalStorage/cline.cline/config.json

Add the following configuration to the mcpServers section:

{
  "mcpServers": {
    "arango": {
      "command": "npx",
      "args": ["-y", "arango-server"],
      "env": {
        "ARANGO_URL": "your_database_url",
        "ARANGO_DB": "your_database_name",
        "ARANGO_USERNAME": "your_username",
        "ARANGO_PASSWORD": "your_password"
      }
    }
  }
}

You can also use the above configuration to get this server working with WARP

Environment Variables

The server requires the following environment variables:

ARANGO_URL - ArangoDB server URL (note: 8529 is the default port for ArangoDB for local development)
ARANGO_DB - Database name
ARANGO_USERNAME - Database user
ARANGO_PASSWORD - Database password
ARANGO_BACKUP_ROOT - Optional root directory for arango_backup output. Defaults to ./backups.

Usage

You can pretty much provide any meaningful prompt and Claude will try to execute the appropriate function.

Some example propmts:

"List all collections in the database"
"Query all users"
"Insert a new document with name 'John Doe' and email "john@example.com' to the 'users' collection"
"Update the document with key '123456' or name 'Jane Doe' to change the age to 48"
"Create a new collection named 'products'"

Usage with Claude App

Demo of using ArangoDB MCP server with Claude App

Uasge with Cline VSCode extension

Demo of using ArangoDB MCP server with Cline VSCode extension

Query all users:

{
  "query": "FOR user IN users RETURN user",
  "limit": 100
}

Insert a new document:

{
  "collection": "users",
  "document": {
    "name": "John Doe",
    "email": "john@example.com"
  }
}

Update a document:

{
  "collection": "users",
  "key": "123456",
  "update": {
    "name": "Jane Doe"
  }
}

Remove a document:

{
  "collection": "users",
  "key": "123456"
}

List all collections:

{
} // No parameters required

Backup database collections:

{
  "outputDir": "nightly_1", // Safe subdirectory name under ARANGO_BACKUP_ROOT. Absolute paths and slashes are rejected.
  "collection": "users", // Optional. If omitted, all collections are backed up.
  "docLimit": 1000 // Optional. Maximum documents per collection. Defaults to 1000 and is capped at 10000.
}

Set ARANGO_BACKUP_ROOT to choose where backups are stored. The server rejects path traversal, absolute paths, symlink escapes, and existing output files to mitigate arbitrary file write risks.

Create a new collection:

{
  "name": "products",
  "type": "document", // "document" or "edge" (optional, defaults to "document")
  "waitForSync": false // Optional, defaults to false
}

Drop a collection:

{
  "name": "products",
  "confirm": true
}

Note: The server is database-structure agnostic and can work with any collection names or structures as long as they follow ArangoDB's document and edge collection models.

Disclaimer

For Development Use Only

This tool is designed for local development environments only. While technically it could connect to a production database, this would create significant security risks and is explicitly discouraged. We use it exclusively with our development databases to maintain separation of concerns and protect production data.

Development

Contributions are welcome. Please read CONTRIBUTING.md before opening a pull request.

Clone the repository
Install dependencies:
```
npm run build
```
For development with auto-rebuild:
```
npm run watch
```

Debugging

Since MCP servers communicate over stdio, debugging can be challenging. recommended debugging can be done by using MCP Inspector for development:

npm run inspector

The Inspector will provide a URL to access debugging tools in your browser.

Testing

npm test

The test suite includes regression coverage for the arango_backup path handling that prevents absolute paths, traversal, and symlink escapes.

To run the integration smoke test with a local Docker ArangoDB instance:

npm run test:integration

The integration test starts a temporary Docker ArangoDB instance, starts the MCP server over stdio, lists tools, verifies outputSchema, creates a temporary collection, inserts documents, queries with limit, verifies backup output stays under ARANGO_BACKUP_ROOT, rejects an absolute backup path, cleans up the collection, and stops the container.

The test container uses host port 18529 by default to avoid conflicting with a local ArangoDB on 8529. Override it with ARANGO_PORT if needed.

License

This project is licensed under the MIT License - see the LICENSE file for details.

Available Tools

7 tools

arango_backupB

Read-only

Backup collections to JSON files.

ParametersJSON Schema

Name	Required	Description	Default
`outputDir`	Yes	An absolute directory path to store backup files	./backup
`collection`	No	Collection name to backup. If not provided, backs up all collections.
`docLimit`	No	Limit the number of documents to backup. If not provided, backs up all documents.

TDQS

B3.3/5.0

Behavior3/5

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

Annotations declare readOnlyHint=true, indicating a safe read operation. The description adds context about creating backup files (output behavior) but doesn't detail side effects like file system changes, performance impact, or error handling. With annotations covering safety, it adds some value but lacks rich behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.

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 backup tool with readOnlyHint annotation and no output schema, the description is minimally adequate. It covers the core action but lacks details on output format, error scenarios, or integration with sibling tools. Given the complexity and annotation coverage, it's complete enough but with clear gaps.

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 parameters are fully documented in the schema. The description mentions 'collections' and 'JSON files' but doesn't add syntax, format, or usage details beyond what the schema provides. Baseline 3 is appropriate when schema does the heavy lifting.

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 action ('Backup') and target ('collections to JSON files'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'arango_list_collections' or 'arango_query' which might also involve collection data retrieval, though the backup purpose is distinct.

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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, timing considerations, or compare it to sibling tools like 'arango_query' for data extraction. Usage is implied by the name but not explicitly stated.

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

arango_create_collectionB

Destructive

Create a new collection in the database

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Name of the collection to create
`type`	No	Type of collection to create ("document" or "edge")	document
`waitForSync`	No	If true, wait for data to be synchronized to disk before returning

TDQS

B3.3/5.0

Behavior3/5

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

Annotations provide destructiveHint=true, indicating this is a mutation operation. The description adds minimal context by implying a write action ('Create'), but doesn't elaborate on behavioral aspects like permissions required, idempotency, error handling, or system impact beyond what annotations cover. No contradiction with annotations exists.

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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly while conveying the essential action.

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 destructive creation tool with no output schema, the description is minimally adequate. It covers the basic action but lacks details on return values, error conditions, or integration with sibling tools. Given the annotations handle safety profiling, the description meets a bare minimum but doesn't provide rich contextual guidance.

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%, with all parameters (name, type, waitForSync) well-documented in the schema. The description adds no additional meaning about parameters, such as explaining collection naming rules, implications of 'document' vs 'edge' types, or performance effects of waitForSync. Baseline score of 3 is appropriate given the schema does the heavy lifting.

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 action ('Create') and resource ('new collection in the database'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from siblings like 'arango_list_collections' (which lists rather than creates) or 'arango_insert' (which inserts data rather than creating structures), missing full sibling distinction.

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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing database access), compare to siblings like 'arango_list_collections' for checking existing collections, or specify scenarios where collection creation is appropriate versus other operations.

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

arango_insertB

Destructive

Insert a document into a collection

ParametersJSON Schema

Name	Required	Description	Default
`collection`	Yes	Collection name
`document`	Yes	Document to insert

TDQS

B3.3/5.0

Behavior3/5

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

Annotations provide destructiveHint=true, indicating this is a write operation. The description adds minimal context by specifying 'Insert a document,' which aligns with the destructive nature but doesn't elaborate on behavioral traits like error handling, permissions needed, or idempotency. It neither contradicts nor significantly enriches the annotations.

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, direct sentence with zero waste, front-loading the core action. It's appropriately sized for a simple tool, avoiding unnecessary elaboration while clearly stating the purpose.

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?

Given the tool's complexity (simple insertion with 2 parameters), annotations cover destructive behavior, and schema fully documents inputs. However, without an output schema, the description doesn't explain return values or success/failure responses, leaving gaps in completeness for a mutation 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 description coverage is 100%, with clear parameter descriptions in the schema. The description doesn't add meaning beyond the schema, such as explaining document structure constraints or collection naming rules. Baseline 3 is appropriate as the schema handles parameter documentation adequately.

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 action ('Insert') and target ('a document into a collection'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like arango_update or arango_remove, which also modify collections, leaving room for improvement in distinguishing its specific role.

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 offers no guidance on when to use this tool versus alternatives like arango_update or arango_remove, nor does it mention prerequisites such as collection existence. It lacks explicit context for usage decisions, relying solely on the tool name and basic purpose.

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

arango_list_collectionsB

Read-only

List all collections in the database

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/5.0

Behavior3/5

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

Annotations indicate readOnlyHint=true, which the description aligns with by implying a read operation ('List'). The description adds minimal behavioral context beyond this, such as not specifying if it returns system collections or pagination details. No contradiction exists, but with annotations covering safety, the description offers limited extra value.

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, clear sentence with no wasted words. It front-loads the essential information ('List all collections'), making it highly efficient and easy to parse, which is ideal for a simple tool.

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 zero-parameter read tool with annotations, the description is minimally adequate. However, it lacks output details (no schema provided) and doesn't address potential complexities like collection types or ordering. It meets basic needs but could be more informative given the tool's role among siblings.

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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately omits parameter details, focusing on the tool's purpose without redundancy. A baseline of 4 is applied since no parameters exist to explain.

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 action ('List') and resource ('all collections in the database'), making the tool's purpose immediately understandable. However, it doesn't explicitly differentiate from siblings like 'arango_query' which might also list collections, though the verb 'List' suggests a straightforward retrieval operation.

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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, compare to siblings like 'arango_query' for more complex queries, or specify contexts where listing collections is appropriate, leaving usage decisions ambiguous.

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

arango_queryC

Execute an AQL query

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	AQL query string
`bindVars`	No	Query bind variables

TDQS

C2.7/5.0

Behavior2/5

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

Annotations indicate readOnlyHint: false, implying potential mutations, but the description doesn't disclose behavioral traits beyond this. It doesn't explain that AQL queries can be read-only or include writes, what permissions are needed, potential side effects, or error handling. With annotations covering only the read/write hint, the description adds minimal context, leaving significant gaps in understanding the tool's 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 extremely concise with a single sentence, 'Execute an AQL query', which is front-loaded and wastes no words. Every part of the sentence is necessary to convey the core purpose, making it efficient and well-structured for its brevity.

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

Completeness2/5

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

Given the complexity of executing arbitrary AQL queries, the lack of output schema, and minimal annotations, the description is incomplete. It doesn't explain return values, error cases, or how results are structured, which is critical for a query tool. With no output schema and only basic annotations, the description should provide more context to be fully helpful.

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%, with clear documentation for 'query' and 'bindVars' parameters. The description adds no additional meaning beyond what the schema provides, such as examples of AQL syntax or how bindVars are used. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

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

Purpose3/5

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

The description 'Execute an AQL query' states the action (execute) and resource (AQL query), making the purpose clear. However, it doesn't differentiate from sibling tools like arango_insert or arango_update, which also execute database operations but with different intents. The description is vague about what type of execution this involves (e.g., read vs. write queries).

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 guidance on when to use this tool versus alternatives. It doesn't mention that this is for arbitrary AQL queries, while siblings like arango_insert or arango_update are for specific operations, or that it might be preferred for complex queries. There are no explicit when/when-not instructions or named alternatives.

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

arango_removeB

Destructive

Remove a document from a collection

ParametersJSON Schema

Name	Required	Description	Default
`collection`	Yes	Collection name
`key`	Yes	Document key

TDQS

B3.3/5.0

Behavior3/5

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

The annotations already declare 'destructiveHint: true', indicating this is a destructive operation. The description adds minimal value by confirming it's a removal action, but it does not disclose additional behavioral traits such as whether the removal is permanent, if it requires specific permissions, or what happens on failure (e.g., error handling). With annotations covering the destructive nature, a baseline score is appropriate, as the description provides some context but not rich behavioral details.

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, direct sentence ('Remove a document from a collection') that efficiently conveys the core action without unnecessary words. It is front-loaded and wastes no space, making it easy for an agent to parse quickly and understand the tool's intent at a glance.

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?

Given the tool's complexity (a destructive operation with 2 parameters), the annotations cover the destructive hint, but there is no output schema to explain return values. The description is minimal and does not address what the tool returns (e.g., success confirmation, error details) or other contextual aspects like rate limits or side effects. It is adequate as a basic description but lacks completeness for effective agent use without additional inference.

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?

The input schema has 100% description coverage, clearly documenting both parameters ('collection' and 'key') with their types and purposes. The description does not add any semantic details beyond what the schema provides, such as examples or constraints (e.g., format of the key). Since the schema does the heavy lifting, a baseline score of 3 is justified, as the description neither compensates nor enhances parameter understanding.

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 action ('Remove') and the resource ('a document from a collection'), making the purpose immediately understandable. However, it does not differentiate this tool from its sibling 'arango_update' (which might also modify documents) or specify what type of removal occurs (e.g., permanent deletion vs. soft delete), leaving room for improvement in sibling distinction.

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 guidance on when to use this tool versus alternatives like 'arango_update' for modifying documents or 'arango_query' for retrieving them. It lacks context about prerequisites (e.g., needing an existing document key) or exclusions, leaving the agent to infer usage from the tool name and parameters alone.

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

arango_updateB

Destructive

Update a document in a collection

ParametersJSON Schema

Name	Required	Description
`collection`	Yes	Collection name
`key`	Yes	Document key
`update`	Yes	Update object

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, indicating this is a mutation operation. The description adds minimal context by specifying it updates a document, but doesn't elaborate on behavioral traits like whether updates are partial/complete, if it returns the updated document, error handling, or permissions required. With annotations covering the destructive nature, it earns a baseline score for not contradicting them.

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, efficient sentence with zero wasted words. It's front-loaded with the core action, making it easy to parse quickly, which is ideal for conciseness in tool descriptions.

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

Completeness2/5

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

Given the tool's complexity (mutation with 3 params, no output schema) and annotations only covering destructiveness, the description is incomplete. It lacks details on return values, error cases, or how it differs from siblings, leaving gaps for an agent to understand full usage context.

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 fully documents all three parameters (collection, key, update). The description adds no additional meaning beyond what's in the schema, such as examples or constraints on the update object. This meets the baseline for high schema coverage without extra param info.

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 verb ('Update') and resource ('a document in a collection'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like arango_insert or arango_remove, which also operate on documents, so it misses full sibling differentiation.

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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing document key), exclusions, or comparisons to siblings like arango_insert (for creation) or arango_remove (for deletion), leaving the agent with no contextual usage cues.

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

Install Server

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

TDQS

A3.5/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose targeting specific operations in ArangoDB: backup, collection creation, document insertion, listing collections, query execution, document removal, and document update. There is no overlap or ambiguity between these functions.

Naming Consistency5/5

All tools follow a consistent 'arango_verb_noun' pattern with snake_case, such as arango_backup, arango_create_collection, and arango_query. This predictable naming makes it easy to understand and navigate the tool set.

Tool Count5/5

With 7 tools, this server is well-scoped for database operations, covering essential CRUD actions, querying, and backup. Each tool earns its place without feeling too sparse or bloated.

Completeness4/5

The tool set provides strong coverage for core database operations, including CRUD for documents, collection management, and querying. A minor gap is the lack of tools for more advanced features like index management or user administration, but agents can handle basic workflows effectively.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Reddit Discussion

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

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216
Chrysai
com.chrysai.www
Hosted MCP server for AI-driven data ops. Create apps, manage schemas, and CRUD structured data.
Data Platforms Developer Tools App Automation
2
Xata
io.github.xataio
Xata MCP server lets AI agents interact with your Xata projects, and Postgres database branches.
Databases Vector Databases RAG Systems
1

Related MCP Servers

CouchDB MCP Server
Databases Developer Tools
robertoamoreno
F
license
A
quality
D
maintenance
A TypeScript-based MCP server that enables AI assistants to interact with CouchDB databases through a simple interface, providing tools for creating, reading, and querying databases and documents.
Updated 2 years ago (2025-03-01 22:50 UTC)
5
5
SQL MCP Server
Databases Shell Access Developer Tools
t3ta
A
license
Not graded
quality
C
maintenance
A TypeScript implementation of a Model Context Protocol server that enables language models to securely query PostgreSQL databases, including those behind SSH bastion tunnels.
Updated a year ago (2025-04-07 02:51 UTC)
24
1
MIT
MCP TypeScript Demo Server
Search Research & Data Developer Tools
malyalavenu
A
license
B
quality
D
maintenance
A TypeScript implementation of the Model Context Protocol server that enables searching arXiv papers and extracting paper information through standardized client-server communication.
Updated a year ago (2025-06-27 00:08 UTC)
2
10
MIT
MCP Server with SSE and Bearer
Personalcreativelda
-
license
Not graded
quality
Not graded
maintenance
A TypeScript implementation of a Model Context Protocol server that uses Server-Sent Events for real-time communication and Bearer Token authentication to enable secure interaction with LLM clients like Claude Desktop.
Updated a year ago (2025-07-12 08:11 UTC)

Appeared in Searches

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/ravenwits/mcp-server-arangodb'

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