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., "@mcp-everest list database clusters in namespace default"
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.
An unofficial MCP (Model Context Protocol) server implementation for Percona Everest - an open-source cloud native database platform. This server enables AI-powered interaction with Percona Everest database clusters through a standardized protocol.
The MCP server provides the following tools for interacting with Percona Everest:
list_database_clusters(namespace): Lists all available database clusters in the specified namespace
get_database_cluster(namespace, name): Retrieves detailed information about a specific database cluster
get_database_cluster_credentials(namespace, name): Fetches credentials for a specific database cluster
get_database_cluster_components(namespace, name): Gets components information for a specific database cluster
Related MCP server: k8s-mcp-server
Clone the repository:
git clone https://github.com/spron-in/mcp-everest
cd mcp-everest
uv venv
source .venv/bin/activateSet up environment variables:
# Required
export EVEREST_API_KEY="your-api-key"
# Optional with defaults
export EVEREST_HOST="http://localhost:8080" # Everest API base URL
export EVEREST_VERIFY_SSL="true" # SSL verification
export EVEREST_TIMEOUT="30" # Request timeout in seconds
export EVEREST_READONLY="false" # Read-only modeRead Percona Everest documentation to learn more about API. I sent a pull request that explains how to get the API (JWT) key, hope it is going to be accepted soon.
Run the server:
uv run --with mcp-everest mcp-everestTo test the server with the MCP development client:
mcp dev mcp_everest/mcp_server.pyThis requires Node to be installed. It will start a NodeJS MCP Inspector that you can open in your browser and play with.
There is also a client that can be used to interact with the MCP server:
python mcp_client.pyThis is the example of how Large Language Model can talk to an MCP and use its tools. Read more in the blog post.
Official Integration
Work towards making this an official MCP server for Percona Everest
Submit for inclusion in popular MCP server collections
API Coverage Expansion
Implement more GET endpoints from the Everest API
Add support for POST/PUT/DELETE operations (but have read-only mode available)
Add proper types and supported variables from API spec
Include resources and prompts into MCP
Cross-Integration
Integrate with other database MCP servers (MongoDB, PostgreSQL, etc.)
Enable cross-database operations and management
Implement unified monitoring across different database platforms
Contributions are welcome! Feel free to submit issues and pull requests.
Create a new database cluster in the specified namespace.
Args:
namespace: The namespace to create the cluster in
name: Name of the database cluster
engine_type: Type of database engine (e.g. 'pxc')
storage_size: Size of storage using the Mi, Gi suffix
replicas: Number of database replicas
cpu: CPU cores per replica
memory: Memory per replica using the Mi, Gi suffix
allow_unsafe: Allow unsafe configurations
proxy_replicas: Number of proxy replicas
| Name | Required | Description | Default |
|---|---|---|---|
| cpu | No | ||
| name | Yes | ||
| memory | No | 1Gi | |
| replicas | No | ||
| namespace | Yes | ||
| engine_type | Yes | ||
| allow_unsafe | No | ||
| storage_size | No | 10Gi | |
| proxy_replicas | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It confirms mutation ('create') but does not disclose potential side effects, auth requirements, idempotency, failure behavior, or any constraints beyond parameter descriptions.
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 front-loaded with the main purpose, followed by a clear list of parameter descriptions. It is appropriately sized for a tool with 9 parameters, but could be slightly more concise by grouping optional defaults.
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 complexity (9 parameters, no output schema), the description covers parameter meanings fully but lacks details about the return value, asynchronous behavior, or validation rules. It is minimally adequate for a creation 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?
With schema description coverage at 0%, the description compensates by providing meaningful explanations for each parameter, e.g., 'storage_size: Size of storage using the Mi, Gi suffix' and 'cpu: CPU cores per replica'. This adds significant value beyond the schema's type and default.
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 starts with 'Create a new database cluster in the specified namespace,' clearly stating the verb (create) and resource (database cluster). It distinguishes from sibling tools like get_database_cluster and list_database_clusters, which are read-only.
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 this is for creation, but provides no explicit guidance on when to use this tool versus alternatives, such as when to use editing tools. It lacks when-not-to-use or prerequisite conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific database cluster.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| namespace | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read operation, but with no annotations, it fails to confirm idempotency, safety, or any side effects. No mention of output structure or rate limits.
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?
Extremely short, but lacks critical information. Concise at the expense of completeness. The single sentence does not earn its place given missing details.
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, two required params, and no annotations or output schema, this description is insufficient for reliable selection and invocation. It provides almost no context beyond the resource name.
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?
With 0% schema description coverage, the description must compensate, but it provides zero information about the required parameters (namespace, name) or their meanings. The agent gains no insight beyond the parameter names.
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 it retrieves details of a specific database cluster, but does not differentiate from sibling tools like get_database_cluster_components or get_database_cluster_credentials. The verb 'Get details' is somewhat generic.
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 (e.g., get_database_cluster_components). No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get components of a specific database cluster.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| namespace | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It does not mention whether the operation is read-only, what happens if the cluster does not exist, or any side effects. The description lacks essential behavioral context for an AI agent.
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 extremely brief (one sentence), which is concise but borderline under-specified. It front-loads the core action and resource, but the brevity leaves out critical details, making it mediocre rather than optimal.
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, no annotations, and 0% parameter coverage, the description is severely incomplete. It does not explain what the components are, how they are structured, or any constraints like required permissions, making it inadequate for correct tool 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 not explain the purpose or expected values of the 'name' and 'namespace' parameters. It adds no meaning beyond the schema, failing to help the agent understand what values to provide.
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 'Get components' and the resource 'database cluster'. However, it does not explicitly distinguish from sibling tool 'get_database_cluster', which likely retrieves the cluster itself. The specificity is good but could be enhanced by contrasting with similar tools.
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 like 'get_database_cluster' or 'list_database_clusters'. The description provides no context for appropriate usage scenarios or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get credentials for a specific database cluster.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| namespace | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states 'Get', implying a read-only operation, but does not mention potential side effects, required permissions, or sensitivity of credentials. This is insufficient for an agent to understand 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 very short at one sentence, which is concise but at the cost of completeness. It is front-loaded with the core action, but lacks necessary details, making it minimally acceptable.
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 annotations, output schema, and parameter descriptions, the description is insufficient for an agent to use the tool correctly. It does not explain what the returned credentials look like, how to interpret the parameters, or any contextual constraints.
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 two parameters ('name' and 'namespace') with 0% description coverage, meaning the schema provides no descriptions. The tool description only mentions 'a specific database cluster' without explaining how these parameters identify the cluster or what values are expected. No additional meaning is added beyond the parameter titles.
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 the verb 'Get' and specifies the resource 'credentials for a specific database cluster', making the tool's purpose clear. However, it does not differentiate from sibling tools like 'get_database_cluster', which might retrieve cluster metadata, and fails to clarify what exactly 'credentials' entails (e.g., connection string, username/password).
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 usage guidelines are provided. The description does not indicate when to use this tool versus alternatives like 'get_database_cluster' or 'list_database_clusters', nor does it specify prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available database clusters in the specified namespace.
| Name | Required | Description | Default |
|---|---|---|---|
| namespace | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'List available database clusters' which indicates a read operation. It fails to disclose potential behavioral traits such as pagination, authorization requirements, or rate limits.
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, concise and front-loaded. It is efficient but could be more informative without increasing length significantly.
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 list tool with one parameter and no output schema, the description is minimal. It does not mention pagination, filtering, or the structure of the returned data, leaving gaps for an AI agent.
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 schema has one parameter 'namespace' with 0% description coverage. The description only mentions 'in the specified namespace' but adds no additional meaning about the parameter's purpose, format, or allowed values.
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 'List' and the resource 'available database clusters' with a scope 'in the specified namespace'. It distinguishes itself from sibling tools like create, get, get components, and get credentials.
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 usage for listing clusters but provides no explicit guidance on when to use this tool versus alternatives, nor does it mention 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.4create_database_clusterget_database_clusterget_database_cluster_componentsget_database_cluster_credentialslist_database_clustersScored across 5 tools
Each tool has a clear, distinct purpose: create, get details, get components, get credentials, and list. No two tools overlap in functionality.
All tool names follow a consistent verb_database_cluster pattern in snake_case, with predictable suffixes like _components and _credentials for specific sub-features.
Five tools is well-suited for managing database clusters, covering core operations without being excessive or insufficient.
The set covers create and read operations (get, list, components, credentials) but lacks update and delete tools, leaving a notable gap in full lifecycle management.
Xata MCP server lets AI agents interact with your Xata projects, and Postgres database branches.
GibsonAI MCP server: manage your databases with natural language
Cloud-hosted MCP server for secure AI access to enterprise data sources via CData Connect AI.
