SingleStore

Serveur MCP SingleStore

Le [Model Context Protocol]((https://modelcontextprotocol.io/introduction) (MCP) est un protocole standardisé conçu pour gérer le contexte entre les grands modèles de langage (LLM) et les systèmes externes. Ce dépôt fournit un installateur et un serveur MCP pour SingleStore, permettant une intégration transparente.

Avec MCP, vous pouvez utiliser Claude Desktop, Claude Code, Cursor ou tout client MCP compatible pour interagir avec SingleStore en langage naturel, ce qui facilite la réalisation d'opérations complexes sans effort.

💡 Astuce de pro : Vous ne savez pas ce que le serveur MCP peut faire ? Appelez simplement l'invite /help dans votre chat !

Prérequis

• Python >= v3.10.0
• uvx installé dans votre environnement Python
• VS Code, Cursor, Windsurf, Claude Desktop, Claude Code, Goose ou tout autre client MCP

Pour commencer

Tout d'abord, installez le serveur MCP SingleStore avec votre client.

La configuration standard fonctionne dans la plupart des outils :

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

Aucune clé API, jeton ou variable d'environnement requis ! Le serveur gère automatiquement l'authentification via OAuth par navigateur au démarrage.

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

Utilisation de Docker

REMARQUE : Une clé API est requise lors de l'utilisation de Docker car le flux OAuth n'est pas pris en charge pour les serveurs exécutés dans des conteneurs Docker.

{
  "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"
      ]
    }
  }
}

Vous pouvez construire l'image Docker vous-même :

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

Pour une meilleure sécurité, nous recommandons d'utiliser Docker Desktop pour configurer le serveur MCP SingleStore — consultez cet article de blog pour plus de détails sur le nouveau catalogue MCP de Docker.

Composants

Outils

Le serveur implémente les outils suivants :

• get_user_info : Récupère les détails de l'utilisateur actuel

  • Aucun argument requis
  • Renvoie les informations et détails de l'utilisateur

• organization_info : Récupère les détails de l'organisation actuelle de l'utilisateur

  • Aucun argument requis
  • Renvoie les détails de l'organisation

• choose_organization : Choisir parmi les organisations disponibles (disponible uniquement lorsque la variable d'environnement de clé API n'est pas définie)

  • Aucun argument requis
  • Renvoie une liste des organisations disponibles parmi lesquelles choisir

• set_organization : Définir l'organisation active (disponible uniquement lorsque la variable d'environnement de clé API n'est pas définie)

  • Arguments : organization_id (chaîne)
  • Définit l'organisation spécifiée comme active

• workspace_groups_info : Récupère les détails des groupes d'espaces de travail accessibles à l'utilisateur

  • Aucun argument requis
  • Renvoie les détails des groupes d'espaces de travail

• workspaces_info : Récupère les détails des espaces de travail dans un groupe d'espaces de travail spécifique

  • Arguments : workspace_group_id (chaîne)
  • Renvoie les détails des espaces de travail

• resume_workspace : Reprendre un espace de travail suspendu

  • Arguments : workspace_id (chaîne)
  • Reprend l'espace de travail spécifié

• list_starter_workspaces : Lister tous les espaces de travail de démarrage accessibles à l'utilisateur

  • Aucun argument requis
  • Renvoie les détails des espaces de travail de démarrage disponibles

• create_starter_workspace : Créer un nouvel espace de travail de démarrage

  • Arguments : paramètres de configuration de l'espace de travail
  • Renvoie les détails de l'espace de travail de démarrage créé

• terminate_starter_workspace : Terminer un espace de travail de démarrage existant

  • Arguments : workspace_id (chaîne)
  • Termine l'espace de travail de démarrage spécifié

• list_regions : Récupère une liste de toutes les régions prenant en charge les espaces de travail

  • Aucun argument requis
  • Renvoie une liste des régions disponibles

• list_sharedtier_regions : Récupère une liste des régions de niveau partagé

  • Aucun argument requis
  • Renvoie une liste des régions de niveau partagé

• run_sql : Exécuter des opérations SQL sur un espace de travail connecté

  • Arguments : workspace_id, database, sql_query et paramètres de connexion
  • Renvoie les résultats de la requête SQL dans un format structuré

• create_notebook_file : Créer un nouveau fichier notebook dans SingleStore Spaces

  • Arguments : notebook_name, content (optionnel)
  • Renvoie les détails du notebook créé

• upload_notebook_file : Téléverser un fichier notebook vers SingleStore Spaces

  • Arguments : file_path, notebook_name
  • Renvoie les détails du notebook téléversé

• create_job_from_notebook : Créer un travail planifié à partir d'un notebook

  • Arguments : configuration du travail incluant notebook_path, schedule_mode, etc.
  • Renvoie les détails du travail créé

• get_job : Récupérer les détails d'un travail existant

  • Arguments : job_id (chaîne)
  • Renvoie les détails du travail spécifié

• delete_job : Supprimer un travail existant

  • Arguments : job_id (chaîne)
  • Supprime le travail spécifié

• stage_list_files : Lister les fichiers et dossiers dans le système de fichiers d'un déploiement Stage

  • Arguments : deployment_id (chaîne), path (chaîne, optionnel)
  • Renvoie le contenu du dossier incluant les fichiers et sous-dossiers

• stage_get_file : Obtenir un fichier de Stage par chemin

  • Arguments : deployment_id (chaîne), path (chaîne), return_type (chaîne : 'metadata', 'url' ou 'content')
  • Renvoie les métadonnées du fichier, une URL de téléchargement ou le contenu texte

• stage_create_folder : Créer un dossier dans Stage

  • Arguments : deployment_id (chaîne), path (chaîne)
  • Renvoie le statut de création

• stage_upload_file : Téléverser un fichier vers Stage avec du contenu texte

  • Arguments : deployment_id (chaîne), path (chaîne), content (chaîne), local_path (chaîne)
  • Renvoie le statut du téléversement

• stage_move : Déplacer ou renommer un fichier ou dossier dans Stage

  • Arguments : deployment_id (chaîne), source_path (chaîne), destination_path (chaîne)
  • Renvoie le statut du déplacement

• stage_delete : Supprimer un fichier ou dossier de Stage

  • Arguments : deployment_id (chaîne), path (chaîne)
  • Renvoie le statut de suppression

Remarque : Les outils de gestion d'organisation (choose_organization et set_organization) sont uniquement disponibles lorsque la variable d'environnement de clé API n'est pas définie, permettant une sélection interactive de l'organisation lors de l'authentification OAuth.

Développement

Prérequis

• Python >= 3.11
• uv pour la gestion des dépendances

Configuration

1. Cloner le dépôt :

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

1. Installer les dépendances :

uv sync --dev

1. Configurer les hooks de pré-commit (optionnel mais recommandé) :

uv run pre-commit install

Flux de travail de développement

# 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

Exécution des tests

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

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

Qualité du code

Nous utilisons Ruff pour le linting et le formatage :

# 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/

Processus de publication

Les versions sont gérées via des tags git et une publication automatisée sur PyPI :

1. Créer une version : ./scripts/release.sh (outil interactif)
2. Publication automatique : Déclenchée par le push des tags de version
3. Pas de téléversements manuels sur PyPI - pipeline entièrement automatisé

Consultez scripts/dev-workflow.md pour une documentation détaillée du flux de travail.