Provides access to Aiven for ClickHouse services, enabling management and interaction with ClickHouse database instances through the Aiven platform
Provides access to Aiven for OpenSearch services, enabling management and interaction with OpenSearch clusters through the Aiven platform
Provides access to Aiven for PostgreSQL services, enabling management and interaction with PostgreSQL database instances through the Aiven platform
Click on "Install 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., "@Aiven MCP Server list all services in my production project"
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 for Aiven.
This provides access to the Aiven for PostgreSQL, Kafka, ClickHouse, Valkey and OpenSearch services running in Aiven and the wider Aiven ecosystem of native connectors. Enabling LLMs to build full stack solutions for all use-cases.
list_projects
List all projects on your Aiven account.
list_services
List all services in a specific Aiven project.
get_service_details
Get the detail of your service in a specific Aiven project.
Related MCP server: Aiven MCP Server
Open the Claude Desktop configuration file located at:
On macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
On Windows: %APPDATA%/Claude/claude_desktop_config.json
Add the following:
{
"mcpServers": {
"mcp-aiven": {
"command": "uv",
"args": [
"--directory",
"$REPOSITORY_DIRECTORY",
"run",
"--with-editable",
"$REPOSITORY_DIRECTORY",
"--python",
"3.13",
"mcp-aiven"
],
"env": {
"AIVEN_BASE_URL": "https://api.aiven.io",
"AIVEN_TOKEN": "$AIVEN_TOKEN"
}
}
}
}Update the environment variables:
$REPOSITORY_DIRECTORY to point to the folder cointaining the repository
AIVEN_TOKEN to the Aiven login token.
Locate the command entry for uv and replace it with the absolute path to the uv executable. This ensures that the correct version of uv is used when starting the server. On a mac, you can find this path using which uv.
Restart Claude Desktop to apply the changes.
Navigate to Cursor -> Settings -> Cursor Settings
Select "MCP Servers"
Add a new server with
Name: mcp-aiven
Type: command
Command: uv --directory $REPOSITORY_DIRECTORY run --with-editable $REPOSITORY_DIRECTORY --python 3.13 mcp-aiven
Where $REPOSITORY_DIRECTORY is the path to the repository. You might need to add the AIVEN_BASE_URL, AIVEN_PROJECT_NAME and AIVEN_TOKEN as variables
Add the following variables to a .env file in the root of the repository.
AIVEN_BASE_URL=https://api.aiven.io
AIVEN_TOKEN=$AIVEN_TOKENRun uv sync to install the dependencies. To install uv follow the instructions here. Then do source .venv/bin/activate.
For easy testing, you can run mcp dev mcp_aiven/mcp_server.py to start the MCP server.
The following environment variables are used to configure the Aiven connection:
AIVEN_BASE_URL: The Aiven API url
AIVEN_TOKEN: The authentication token
This section outlines key developer responsibilities and security considerations when working with Model Context Protocols (MCPs) and AI Agents within this system. Self-Managed MCPs:
Customer Responsibility: MCPs are executed within the user's environment, not hosted by Aiven. Therefore, users are solely responsible for their operational management, security, and compliance, adhering to the shared responsibility model. (https://aiven.io/responsibility-matrix)
Deployment and Maintenance: Developers must handle all aspects of MCP deployment, updates, and maintenance.
AI Agent Security:
Permission Control: Access and capabilities of AI Agents are strictly governed by the permissions granted to the API token used for their authentication. Developers must meticulously manage these permissions.
Credential Handling: Be acutely aware that AI Agents may require access credentials (e.g., database connection strings, streaming service tokens) to perform actions on your behalf. Exercise extreme caution when providing such credentials to AI Agents.
Risk Assessment: Adhere to your organization's security policies and conduct thorough risk assessments before granting AI Agents access to sensitive resources.
API Token Best Practices:
Principle of Least Privilege: Always adhere to the principle of least privilege. API tokens should be scoped and restricted to the minimum permissions necessary for their intended function.
Token Management: Implement robust token management practices, including regular rotation and secure storage.
Key Takeaways:
Users retain full control and responsibility for MCP execution and security.
AI Agent permissions are directly tied to API token permissions.
Exercise extreme caution when providing credentials to AI Agents.
Strictly adhere to the principle of least privilege when managing API tokens.
| Name | Required | Description | Default |
|---|---|---|---|
| project_name | Yes | ||
| service_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no 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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no 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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| project_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no 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?
Tool has no description.
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?
Tool has no description.
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. Dates show when Glama detected each change.
v1.0.0get_service_details1 field changedInput schema / titleAdded value: +"get_service_detailsArguments"list_projects1 field changedInput schema / titleAdded value: +"list_projectsArguments"list_services1 field changedInput schema / titleAdded value: +"list_servicesArguments"get_service_detailslist_projectslist_servicesEach tool has a clearly distinct purpose: get_service_details retrieves specific service information, list_projects enumerates projects, and list_services enumerates services. There is no overlap in functionality, and an agent can easily distinguish between them based on their names and inferred purposes.
All tool names follow a consistent verb_noun pattern using snake_case: get_service_details, list_projects, and list_services. The naming is predictable and readable, with no deviations or mixed conventions.
With only 3 tools, the server feels under-scoped for managing Aiven services, which typically involve operations like creating, updating, deleting, or configuring services and projects. This minimal set lacks essential CRUD operations, making it too thin for the apparent domain.
The tool surface is severely incomplete for cloud service management. It only provides read-only operations (get and list) with no ability to create, update, or delete services or projects. This leaves significant gaps that will cause agent failures in common workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Manage HepCloud (Turkish cloud) servers and managed PostgreSQL from your AI assistant. OAuth 2.1.
Your AI Agent's Infrastructure Layer. Connect Claude, Copilot, Codex, or ChatGPT to 200+ managed open source services. Start databases, pipelines, and applications through natural language.
Query your team's drift, vulnerability, and upgrade data from any AI assistant. OAuth 2.1, 51 tools.
Inspect and control your Northflank projects, services, jobs, and builds from your AI assistant.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ZatesloFL/mcp-aiven'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
