SQLite MCP : d’abord sonder une base de test en lecture seule, puis décider d’écrire

À qui s’adresse

Pour celles et ceux qui veulent exécuter du SQL sur un fichier SQLite local, voir des données métier et laisser un insight memo. Les preuves indiquent : ce MCP fournit interaction base et intelligence métier via SQLite ; il peut exécuter du SQL, analyser des données métier et générer automatiquement des mémos d’insight.

Vous devez fournir un fichier SQLite pointé par --db-path et accepter que le processus le lise, voire le modifie. L’exemple officiel est ~/test.db. N’utilisez pas une base de production pour le premier essai.

La page se trouve sous servers-archived. Les preuves n’indiquent pas à part l’état de maintenance ni une liste de clients ; la couverture s’arrête à : vous pouvez exécuter mcp-server-sqlite avec uv dans ce répertoire.

Réussir le premier essai en 3 minutes

Suivez le chemin principal uv ; ne prenez pas Docker comme installation principale. Dans le client, configurez :

"command": "uv",
"args": [
  "--directory",
  "parent_of_servers_repo/servers/src/sqlite",
  "run",
  "mcp-server-sqlite",
  "--db-path",
  "~/test.db"
]

Remplacez --directory par un chemin local réel, et --db-path par une base de test jetable.

Préconditions : uv est installé ; vous avez le droit de créer ou d’ouvrir la base de test. Cela accède à des fichiers locaux ; ce n’est pas un bac à sable sans lecture locale.

Emplacement de configuration : command / args MCP du client.

Premier appel à faible risque : sondez d’abord sans changer les tables—utilisez « exécuter des requêtes SQL / analyser des données métier » de l’énoncé d’identité pour voir le contenu déjà présent, ou lisez seulement la ressource memo://insights. Les preuves indiquent six outils cœurs, mais ce locator ne liste pas les noms et paramètres en lecture seule. N’appelez pas d’abord le write_query pleinement développé : il exécute INSERT, UPDATE ou DELETE et renvoie { affected_rows: number }. N’exécutez pas non plus append-insight en premier ; il change le mémo.

Signal de succès : une fois le serveur lancé, vous obtenez un résultat de requête sur la base de test, ou lisez le contenu actuel de memo://insights. Si le processus ne démarre pas, vérifiez d’abord uv et le répertoire ; ne passez pas à Docker.

Cas d’usage

Cas 1 : Consulter une fois les données métier sur la base de test. Exécutez une requête ou une analyse SQL d’après la preuve d’identité. Les signatures en lecture seule des six outils ne sont pas développées dans le locator ; restez à « vous pouvez interroger/analyser la base pointée par --db-path » et n’inventez ni noms d’outils ni paramètres de filtre.

Cas 2 : Lire le insight memo et décider d’ajouter. La ressource memo://insights agrège en continu les insights trouvés pendant l’analyse et se met à jour automatiquement quand append-insight s’exécute. Lisez d’abord cette ressource. Ajouter change le mémo ; les preuves n’ont pas d’undo et n’écrivent pas les paramètres. N’appelez qu’après avoir accepté la réécriture et passé un point de confirmation. write_query change les données de table—un autre effet de bord que le mémo ; ne l’utilisez pas dans ce cas.

Limites d’usage

Le chemin principal est uv run mcp-server-sqlite --db-path <file>. L’exemple Docker est docker run --rm -i -v mcp-test:/mcp mcp/sqlite --db-path /mcp/test.db ; ne le prenez pas comme chemin principal. write_query change des lignes sans annulation officielle. append-insight met à jour memo://insights. Hormis write_query et append-insight, la plupart des noms et paramètres des six outils ne sont pas développés dans le locator. L’accès aux fichiers locaux et l’écriture de la base ne sont pas à risque zéro. Les preuves n’écrivent ni sauvegarde, ni rollback de transaction, ni remplacement après archivage.