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., "@ravendb-mcp show available collections in the current 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.
A Model Context Protocol (MCP) server that enables AI assistants to interact with RavenDB databases through a standardized interface.
This MCP server allows AI assistants to perform common RavenDB operations including:
Connection management
Database selection
Collection listing
Index management
Document operations (get, store, delete)
RQL queries
Related MCP server: MCP Toolkit
Node.js 16+
RavenDB 7.x
Authentication using non-secured mode (no authentication)
# Install globally
npm install -g ravendb-mcp
# Or run directly with npx
npx ravendb-mcpConfigure the server using environment variables or a .env file:
# Authentication Method (Only non-secured mode is supported)
RAVENDB_AUTH_METHOD=none
# Connection
RAVENDB_URL=http://your-ravendb-server:port
# Optional settings
RAVENDB_QUERY_TIMEOUT=30000 # Query timeout in milliseconds (optional)To configure this MCP server for use with Cline AI, add the following to your MCP configuration:
{
"mcpServers": {
"github.com/johnib/ravendb-mcp": {
"disabled": false,
"timeout": 60,
"command": "npx",
"args": ["-y", "ravendb-mcp"],
"env": {
"RAVENDB_AUTH_METHOD": "none",
"RAVENDB_URL": "http://your-ravendb-server:port"
},
"transportType": "stdio"
}
}
}You can customize the environment variables based on your specific RavenDB setup.
Establishes a connection to a RavenDB server.
{
"server_url": "https://your-ravendb-server:port",
"database": "YourDatabase"
}Switches to a specific database context.
{
"database": "AnotherDatabase"
}Lists all collections in the current database.
{}Lists all indexes in the current database.
{}Retrieves a document by ID.
{
"id": "employees/1"
}Creates or updates a document.
{
"document": {
"name": "John Doe",
"email": "john@example.com",
"department": "Engineering"
},
"id": "employees/1" // Optional, will be generated if not provided
}Deletes a document by ID.
{
"id": "employees/1"
}Executes RQL queries with results handling.
{
"query": "from Employees where department = 'Engineering'"
}Here's a typical workflow for interacting with the RavenDB MCP server through an AI assistant:
Connect to the database
Use the initialize-connection tool to connect to your RavenDB serverExplore the database structure
Use show-collections to see what collections are availableRetrieve documents
Use get-document to fetch specific documents by IDRun queries
Use query-documents to execute RQL queriesModify data
Use store-document to create or update documents
Use delete-document to remove documents# Install dependencies
npm install
# Build the project
npm run build
# Run in development mode
npm run dev
# Test with the MCP inspector
npm run inspectorMIT
Delete a document by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the document to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states that it deletes a document, which implies a destructive action. It does not mention whether the deletion is permanent, if any related data is affected, or what the response looks like.
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?
The description is a single sentence with no wasted words. It is as concise as possible while conveying the core purpose.
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 simple delete tool with no output schema, the description gives the essential information (action and parameter). However, it lacks details on success/failure indicators, idempotency, or error conditions, which would be helpful for a complete context.
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 input schema has 100% coverage (the one parameter 'id' is described). The description adds no additional meaning beyond the schema, as it simply repeats the concept of 'by ID'. Baseline score of 3 is appropriate.
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?
The description clearly states the action (delete) and resource (document by ID). It is specific enough to distinguish from sibling tools like get-document or store-document, but does not elaborate on the scope or permanence of the deletion.
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 provides no guidance on when to use this tool versus alternatives, or any prerequisites or restrictions. It implies the tool should be used when you need to remove a document, but does not mention when not to use it (e.g., if you need to delete multiple documents).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a document by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the document to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits beyond the basic read operation. It does not mention potential failures, auth requirements, or response behavior, which is insufficient for a tool with no annotation support.
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?
The description is a single concise sentence with no unnecessary words, fitting the tool's simplicity.
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?
Given the lack of an output schema, the description should clarify the return format (e.g., 'Returns the document as a JSON object') but does not. Missing error handling and other context reduces completeness.
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 100% for the parameter 'id', so the baseline is 3. The description adds no extra meaning beyond what the schema already provides.
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?
The description 'Retrieve a document by ID' uses a specific verb and resource, clearly indicating the action. It distinguishes well from siblings like 'delete-document' or 'query-documents'.
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 explicit guidance on when to use this tool versus alternatives. However, the name and sibling contexts imply its use for single-document retrieval by ID, which is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connect to a RavenDB server
| Name | Required | Description | Default |
|---|---|---|---|
| server_url | Yes | The URL of the RavenDB server | |
| database | Yes | The database to connect to |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It fails to mention any side effects, authentication requirements, idempotency, or whether the connection is persistent or one-time. The agent is left guessing about important behavioral traits.
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?
The description is a single sentence with no wasted words. It is front-loaded and concise. However, it could be slightly expanded to include critical information without losing conciseness.
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?
Given the lack of output schema and annotations, the description is insufficiently complete. It omits return behavior, error handling, and connection lifecycle details. The agent would need external documentation to use this tool confidently.
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?
Both parameters are described in the input schema with 100% coverage. The description adds no new semantics beyond 'connect', so it meets the baseline. No additional formatting, constraints, or example values are provided.
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?
The description clearly states the tool's action: 'Connect to a RavenDB server'. This is specific and distinguishes it from sibling tools that operate on documents or queries. However, it lacks any additional context about the connection lifecycle or what 'initialize' entails.
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 is provided on when to use this tool versus alternatives like 'select-database' or under what circumstances a connection should be initialized. The description does not mention prerequisites, order of operations, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute RQL queries with results handling
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The RQL query to execute |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavioral traits. It does not indicate whether the query is read-only or mutating, what side effects occur, or any security/rate-limit implications. 'Results handling' implies some processing but is unspecified, leaving a significant gap.
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?
The description is a single sentence, very concise and front-loaded. However, it sacrifices clarity for brevity; while efficient, it could benefit from a few more words to improve understanding without becoming verbose.
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?
Given the presence of sibling tools like 'initialize-connection' and 'select-database', the description omits critical context such as dependencies, return value format, or error behavior. With no output schema, the agent is left uninformed about what 'results handling' produces, making it incomplete.
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 input schema has one parameter 'query' with a description 'The RQL query to execute'. Since schema coverage is 100%, the description adds no additional meaning beyond what the schema already provides, resulting in an average score per guidelines.
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?
The description 'Execute RQL queries with results handling' names the specific language RQL but 'results handling' is vague and does not differentiate from get-document (which also returns results) or other query-like operations. It lacks a clear scope of what 'handling' entails, making it only somewhat distinct.
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 is provided on when to use this tool versus siblings like 'select-database' or 'get-document'. It does not state prerequisites (e.g., connection initialization) or conditions under which it should be preferred, forcing the agent to guess context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Switch to a specific database context
| Name | Required | Description | Default |
|---|---|---|---|
| database | Yes | The database to select |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks disclosure of behavioral traits beyond the basic action. With no annotations, it should explain what 'switch to' entails (e.g., is it stateful? Errors on invalid db?). It only states the action without side effects or requirements.
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?
Single sentence with no wasted words, but could be restructured to include context like usage conditions. Slightly too brief for a tool that affects state.
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?
Given the simplicity (one param, no output), the description is minimal. It doesn't explain the effect on subsequent operations (e.g., query-documents) or error handling, leaving some gaps in completeness for a state-changing 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?
Schema description covers the sole parameter (100% coverage), and the tool description adds no additional meaning beyond 'database to select'. Baseline score of 3 applies as schema already explains the parameter adequately.
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?
The description uses a specific verb ('Switch to') and resource ('database context'), clearly stating the action and what it affects. It distinguishes itself from sibling tools like 'query-documents' or 'initialize-connection' by focusing on context switching.
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 explicit guidance on when to use this tool versus alternatives, such as needing an initialized connection first or when to select a different database. Siblings like 'initialize-connection' suggest a prerequisite, but this is not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available collections in the current database
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It correctly implies a read-only operation but does not disclose potential error conditions or dependencies on prior tool calls.
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?
The description is a single, clear sentence with no redundancy. Essential information is front-loaded.
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?
The description describes the action adequately but omits context like prerequisites (e.g., 'select-database' must have been called first) or what happens when no collections exist.
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 has zero parameters and 100% schema coverage. The description adds no parameter info, but baseline for zero parameters 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?
The description 'List available collections in the current database' clearly states the verb (list), resource (collections), and context (current database). It effectively distinguishes from sibling tools like 'show-indexes'.
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 provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites such as requiring an active database connection or prior initialization.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available indexes in the current database
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only states the purpose, omitting details like read-only nature, dependency on a database connection, or return format in edge cases.
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?
The description is a single sentence with no unnecessary words, efficiently conveying the tool's function. Ideal conciseness for a simple tool.
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 zero-parameter tool with no output schema, the description is nearly complete. It could explicitly mention the requirement of a database connection, but the context of 'current database' implies it. Minor gap.
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 input schema has zero parameters, so schema coverage is 100% trivially. The description does not need to add parameter meaning, and the baseline score of 4 is appropriate.
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?
The description 'List available indexes in the current database' clearly specifies the action (list), resource (indexes), and scope (current database), distinguishing it from siblings like show-collections.
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 is provided on when to use this tool versus alternatives, such as when to examine indexes before querying. The description is minimal and lacks context for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create or update a document
| Name | Required | Description | Default |
|---|---|---|---|
| document | No | The document to store | |
| id | No | Optional document ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Lacks annotations and fails to disclose behavioral traits beyond mutation. No mention of idempotency, overwrite behavior, or any side effects.
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?
Single sentence is concise and to the point. No unnecessary words, but could benefit from slightly more structure.
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?
Given no output schema and sibling tools, description lacks completeness. No details on return values, error cases, or required setup.
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 descriptions are minimal and the tool description adds no extra meaning. With 100% schema coverage, baseline is 3.
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?
Description clearly states 'Create or update a document', specifying the action (upsert) and resource. It distinguishes from sibling tools like delete, get, and query.
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 tool versus alternatives. Does not mention when to use store vs delete or get, or prerequisites like connection initialization.
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.
v0.0.1delete-documentget-documentinitialize-connectionquery-documentsselect-databaseshow-collectionsshow-indexesstore-documentScored across 8 tools
Each tool targets a distinct operation: CRUD on documents, connection management, database selection, and metadata listing. No two tools have overlapping purposes.
All tools follow a consistent verb_noun pattern with lowercase and hyphens (e.g., delete-document, get-document, show-collections). No mixing of styles.
8 tools is well-scoped for a RavenDB server: core CRUD, query, connection setup, database selection, and metadata listing. Not excessive or insufficient.
Covers basic document operations (create/read/delete), query, connection, and metadata. Missing explicit index management and bulk operations, but core workflows are complete.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
