SingleStore

SingleStore MCP-Server

[Model Context Protocol]((https://modelcontextprotocol.io/introduction) (MCP) ist ein standardisiertes Protokoll zur Verwaltung des Kontexts zwischen großen Sprachmodellen (LLMs) und externen Systemen. Dieses Repository stellt einen Installer und einen MCP-Server für SingleStore bereit und ermöglicht so eine nahtlose Integration.

Mit MCP können Sie Claude Desktop, Claude Code, Cursor oder jeden kompatiblen MCP-Client verwenden, um mit SingleStore in natürlicher Sprache zu interagieren und komplexe Vorgänge mühelos durchzuführen.

💡 Profi-Tipp: Sie sind unsicher, was der MCP-Server alles kann? Rufen Sie einfach den Prompt /help in Ihrem Chat auf!

Voraussetzungen

• Python >= v3.10.0
• uvx in Ihrer Python-Umgebung installiert
• VS Code, Cursor, Windsurf, Claude Desktop, Claude Code, Goose oder ein anderer MCP-Client

Erste Schritte

Erste Schritte

Installieren Sie zunächst den SingleStore MCP-Server mit Ihrem Client.

Die Standardkonfiguration funktioniert in den meisten Tools:

{
  "mcpServers": {
    "singlestore-mcp-server": {
      "command": "uvx",
      "args": [
        "singlestore-mcp-server",
        "start"
      ]
    }
  }
}

Keine API-Schlüssel, Tokens oder Umgebungsvariablen erforderlich! Der Server übernimmt die Authentifizierung beim Start automatisch über den Browser-OAuth.

uvx singlestore-mcp-server init --client=claude-desktop

uvx singlestore-mcp-server init --client=claude-code

claude mcp add singlestore-mcp-server uvx singlestore-mcp-server start

uvx singlestore-mcp-server init --client=cursor

uvx singlestore-mcp-server init --client=vscode

code --add-mcp '{"name":"singlestore-mcp-server","command":"uvx","args":["singlestore-mcp-server","start"]}'

uvx singlestore-mcp-server init --client=windsurf

uvx singlestore-mcp-server init --client=gemini

uvx singlestore-mcp-server init --client=lm-studio

Docker verwenden

HINWEIS: Bei der Verwendung von Docker ist ein API-Schlüssel erforderlich, da der OAuth-Ablauf für Server, die in Docker-Containern ausgeführt werden, nicht unterstützt wird.

{
  "mcpServers": {
    "singlestore-mcp-server": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm", "--init", "--pull=always",
        "-e", "MCP_API_KEY=your_api_key_here",
        "singlestore/mcp-server-singlestore"
      ]
    }
  }
}

Sie können das Docker-Image selbst erstellen:

docker build -t singlestore/mcp-server-singlestore .

Für mehr Sicherheit empfehlen wir die Verwendung von Docker Desktop zur Konfiguration des SingleStore MCP-Servers – siehe diesen Blogbeitrag für Details zum neuen MCP-Katalog von Docker.

Komponenten

Tools

Der Server implementiert die folgenden Tools:

• get_user_info: Ruft Details zum aktuellen Benutzer ab

  • Keine Argumente erforderlich
  • Gibt Benutzerinformationen und Details zurück

• organization_info: Ruft Details zur aktuellen Organisation des Benutzers ab

  • Keine Argumente erforderlich
  • Gibt Details der Organisation zurück

• choose_organization: Auswahl aus verfügbaren Organisationen (nur verfügbar, wenn die Umgebungsvariable für den API-Schlüssel nicht gesetzt ist)

  • Keine Argumente erforderlich
  • Gibt eine Liste der verfügbaren Organisationen zur Auswahl zurück

• set_organization: Legt die aktive Organisation fest (nur verfügbar, wenn die Umgebungsvariable für den API-Schlüssel nicht gesetzt ist)

  • Argumente: organization_id (String)
  • Legt die angegebene Organisation als aktiv fest

• workspace_groups_info: Ruft Details zu den für den Benutzer zugänglichen Arbeitsbereichsgruppen ab

  • Keine Argumente erforderlich
  • Gibt Details der Arbeitsbereichsgruppen zurück

• workspaces_info: Ruft Details zu den Arbeitsbereichen in einer bestimmten Arbeitsbereichsgruppe ab

  • Argumente: workspace_group_id (String)
  • Gibt Details der Arbeitsbereiche zurück

• resume_workspace: Setzt einen angehaltenen Arbeitsbereich fort

  • Argumente: workspace_id (String)
  • Setzt den angegebenen Arbeitsbereich fort

• list_starter_workspaces: Listet alle für den Benutzer zugänglichen Starter-Arbeitsbereiche auf

  • Keine Argumente erforderlich
  • Gibt Details der verfügbaren Starter-Arbeitsbereiche zurück

• create_starter_workspace: Erstellt einen neuen Starter-Arbeitsbereich

  • Argumente: Konfigurationsparameter für den Arbeitsbereich
  • Gibt Details des erstellten Starter-Arbeitsbereichs zurück

• terminate_starter_workspace: Beendet einen bestehenden Starter-Arbeitsbereich

  • Argumente: workspace_id (String)
  • Beendet den angegebenen Starter-Arbeitsbereich

• list_regions: Ruft eine Liste aller Regionen ab, die Arbeitsbereiche unterstützen

  • Keine Argumente erforderlich
  • Gibt eine Liste der verfügbaren Regionen zurück

• list_sharedtier_regions: Ruft eine Liste der Shared-Tier-Regionen ab

  • Keine Argumente erforderlich
  • Gibt eine Liste der Shared-Tier-Regionen zurück

• run_sql: Führt SQL-Operationen auf einem verbundenen Arbeitsbereich aus

  • Argumente: workspace_id, database, sql_query und Verbindungsparameter
  • Gibt die Ergebnisse der SQL-Abfrage in einem strukturierten Format zurück

• create_notebook_file: Erstellt eine neue Notebook-Datei in SingleStore Spaces

  • Argumente: notebook_name, content (optional)
  • Gibt Details des erstellten Notebooks zurück

• upload_notebook_file: Lädt eine Notebook-Datei in SingleStore Spaces hoch

  • Argumente: file_path, notebook_name
  • Gibt Details des hochgeladenen Notebooks zurück

• create_job_from_notebook: Erstellt einen geplanten Auftrag aus einem Notebook

  • Argumente: Auftragskonfiguration einschließlich notebook_path, schedule_mode usw.
  • Gibt Details des erstellten Auftrags zurück

• get_job: Ruft Details eines bestehenden Auftrags ab

  • Argumente: job_id (String)
  • Gibt Details des angegebenen Auftrags zurück

• delete_job: Löscht einen bestehenden Auftrag

  • Argumente: job_id (String)
  • Löscht den angegebenen Auftrag

• stage_list_files: Listet Dateien und Ordner im Dateisystem einer Stage-Bereitstellung auf

  • Argumente: deployment_id (String), path (String, optional)
  • Gibt Ordnerinhalte einschließlich Dateien und Unterordner zurück

• stage_get_file: Ruft eine Datei aus Stage anhand des Pfads ab

  • Argumente: deployment_id (String), path (String), return_type (String: 'metadata', 'url' oder 'content')
  • Gibt Dateimetadaten, eine Download-URL oder Textinhalt zurück

• stage_create_folder: Erstellt einen Ordner in Stage

  • Argumente: deployment_id (String), path (String)
  • Gibt den Erstellungsstatus zurück

• stage_upload_file: Lädt eine Datei mit Textinhalt in Stage hoch

  • Argumente: deployment_id (String), path (String), content (String), local_path (String)
  • Gibt den Upload-Status zurück

• stage_move: Verschiebt oder benennt eine Datei oder einen Ordner in Stage um

  • Argumente: deployment_id (String), source_path (String), destination_path (String)
  • Gibt den Verschiebestatus zurück

• stage_delete: Löscht eine Datei oder einen Ordner aus Stage

  • Argumente: deployment_id (String), path (String)
  • Gibt den Löschstatus zurück

Hinweis: Die Tools zur Organisationsverwaltung (choose_organization und set_organization) sind nur verfügbar, wenn die Umgebungsvariable für den API-Schlüssel nicht gesetzt ist, was eine interaktive Organisationsauswahl während der OAuth-Authentifizierung ermöglicht.

Entwicklung

Voraussetzungen

• Python >= 3.11
• uv für die Abhängigkeitsverwaltung

Einrichtung

1. Repository klonen:

git clone https://github.com/singlestore-labs/mcp-server-singlestore.git
cd mcp-server-singlestore

1. Abhängigkeiten installieren:

uv sync --dev

1. Pre-Commit-Hooks einrichten (optional, aber empfohlen):

uv run pre-commit install

Entwicklungsworkflow

# Quick quality checks (fast feedback)
./scripts/check.sh

# Run tests independently
./scripts/test.sh

# Comprehensive validation (before PRs)
./scripts/check-all.sh

# Create and publish releases
./scripts/release.sh

Tests ausführen

# Run test suite with coverage
./scripts/test.sh

# Or use pytest directly
uv run pytest
uv run pytest --cov=src --cov-report=html

Codequalität

Wir verwenden Ruff sowohl für Linting als auch für Formatierung:

# Format code
uv run ruff format src/ tests/

# Lint code
uv run ruff check src/ tests/

# Lint and fix issues automatically
uv run ruff check --fix src/ tests/

Release-Prozess

Releases werden über Git-Tags und automatisierte PyPI-Veröffentlichung verwaltet:

1. Release erstellen: ./scripts/release.sh (interaktives Tool)
2. Automatische Veröffentlichung: Wird durch das Pushen von Version-Tags ausgelöst
3. Keine manuellen PyPI-Uploads – vollständig automatisierte Pipeline

Siehe scripts/dev-workflow.md für eine detaillierte Workflow-Dokumentation.