Serveur MCP

Treize outils pour qu'un agent vérifie ses données, entraîne, prédise, prévoie et boucle sans quitter sa conversation. Le serveur est hébergé par Spavik : rien à installer, rien à faire tourner de votre côté.

Se connecter

Le serveur répond à l'adresse https://mcp.spavik.co. Il parle Streamable HTTP, le transport de la révision courante du protocole (2026-07-28) : un seul point d'entrée, POST /, sans session à entretenir. Chaque requête se suffit à elle-même : un redémarrage, d'un côté ou de l'autre, ne produit jamais d'erreur de « session inconnue ».

Chaque requête porte votre clé d'API dans l'en-tête Authorization :

Authorization: Bearer sk-spv-api-...

C'est toute l'authentification. Le serveur vérifie la clé par une lecture gratuite auprès de l'API, puis l'emploie telle quelle pour les outils que vous appelez, sur votre propre espace de travail. Il ne conserve rien. Une requête sans cet en-tête, ou avec une clé d'administration, reçoit un 401.

Ce qui change d'un client à l'autre, c'est l'endroit où s'écrivent l'adresse et l'en-tête.

Claude Code

claude mcp add --transport http spavik https://mcp.spavik.co \
  --header "Authorization: Bearer sk-spv-api-..."

.mcp.json

// Claude Code, versionné avec le projet
{
  "mcpServers": {
    "spavik": {
      "type": "http",
      "url": "https://mcp.spavik.co",
      "headers": { "Authorization": "Bearer sk-spv-api-..." }
    }
  }
}

Cursor

// .cursor/mcp.json pour un projet, ~/.cursor/mcp.json pour tous
{
  "mcpServers": {
    "spavik": {
      "url": "https://mcp.spavik.co",
      "headers": { "Authorization": "Bearer ${env:SPAVIK_API_KEY}" }
    }
  }
}

VS Code

// .vscode/mcp.json : la clé racine est "servers", la clé d'API est demandée une fois
{
  "inputs": [
    { "type": "promptString", "id": "spavik-key", "description": "Clé d'API Spavik", "password": true }
  ],
  "servers": {
    "spavik": {
      "type": "http",
      "url": "https://mcp.spavik.co",
      "headers": { "Authorization": "Bearer ${input:spavik-key}" }
    }
  }
}

Codex CLI

# ~/.codex/config.toml, ou .codex/config.toml pour un projet de confiance
[mcp_servers.spavik]
url = "https://mcp.spavik.co"
bearer_token_env_var = "SPAVIK_API_KEY"

Garder la clé hors du fichier

Cursor lit ${env:SPAVIK_API_KEY} dans votre environnement, VS Code demande la valeur d'un ${input:...} et la range dans son propre coffre, et Codex nomme la variable à lire avec bearer_token_env_var. Préférez ces formes à une clé collée dans un fichier que vous risqueriez de versionner.

Claude.ai et Claude Desktop

L'écran des connecteurs personnalisés demande l'adresse du serveur et, en option, des identifiants OAuth. Il ne propose aucun champ pour un en-tête Authorization fixe : le serveur Spavik ne peut donc pas y être ajouté pour l'instant. Passez par l'un des clients ci-dessus.

La page de distribution, get.spavik.co/mcp, reprend ces extraits prêts à copier.

Ce que l'agent apprend en arrivant

Au premier échange, le serveur envoie ses instructions, que le client ajoute au contexte du modèle : ce que fait Spavik, le parcours, où va l'argent. Un agent sait donc, avant son premier appel d'outil, qu'une table se vérifie avant de servir à entraîner, qu'une prédiction se facture à la ligne, et qu'une valeur réelle se remonte avec le request_id gardé au moment de prédire.

Le parcours que décrivent ces instructions :

1. validate_data sur la table, gratuit : les données tiennent-elles, quoi corriger en premier, le moteur y trouve-t-il un signal.
2. train_model sur la même table, gratuit. Garder l'identifiant du modèle et les colonnes qu'il renvoie.
3. predict sur de nouvelles lignes, facturé à la ligne. Garder chaque request_id.
4. Plus tard, submit_outcomes avec ce qui est réellement arrivé, puis model_performance pour le verdict, puis refresh_model si le modèle tient.

Pour une série : backtest_forecast d'abord, gratuit, puis forecast, facturé.

Les treize outils

Outil	Ce qu'il fait	Coût
validate_data	vérifie une table avant l'entraînement, avec le verdict du moteur	gratuit
train_model	crée un modèle et l'entraîne sur une table	gratuit
predict	score des lignes avec un modèle entraîné	les crédits du moteur par ligne, 1 sur le moteur par défaut
backtest_forecast	dit si une série vaut une prévision, en rejouant son historique	gratuit
forecast	prévoit une série temporelle, sans conserver de modèle	horizon x séries
submit_outcomes	remonte ce qui est réellement arrivé, dans actual	gratuit
model_performance	compare la performance réelle à l'entraînement, avec un verdict	gratuit
refresh_model	intègre les vérités remontées dans une nouvelle version	gratuit
prediction_history	liste les prédictions passées avec leur request_id	gratuit
list_models	liste les modèles du workspace, actifs ou archivés	gratuit
account_usage	lit le plan, le solde et la consommation	gratuit
archive_model	arrête un modèle et libère sa place dans le plan	gratuit
restore_model	remet en service un modèle archivé	gratuit

Chaque outil facturable annonce son coût dans sa description, là où le modèle le lit avant de choisir, et le répète dans son résultat avec le solde restant. predict et forecast acceptent aussi dry_run: true : le même appel n'envoie alors rien, ne débite rien, et répond avec ce qu'il coûterait face à ce qui reste. Un essai à blanc vérifie aussi que les lignes portent les colonnes du modèle, quand l'API les enregistre.

Les données voyagent dans l'appel

Le serveur tourne à distance et ne peut pas lire un fichier sur votre machine. Un chemin est refusé, avec l'explication. train_model, validate_data, forecast et backtest_forecast prennent le contenu du fichier dans data : du CSV avec sa ligne d'en-tête, ou un tableau JSON d'objets. L'agent lit le fichier et passe le texte. predict et submit_outcomes acceptent jusqu'à cinquante lignes en direct (rows, outcomes) et prennent le même contenu data au-delà.

Les paramètres, en bref

train_model et validate_data prennent data et target, le nom de la colonne à prédire ; name, engine et auto_update sont facultatifs. Le résultat de train_model nomme la tâche, la cible, les colonnes attendues et le moteur employé ; l'API remplit le moteur par défaut quand aucun n'est donné.

predict prend model_id et les lignes, dont les clés sont les colonnes attendues. Chaque prédiction revient avec son request_id.

forecast et backtest_forecast prennent data, target et horizon ; timestamp nomme la colonne de temps et item_id celle qui distingue plusieurs séries. Plusieurs séries en un appel coûtent le même prix que des appels séparés et donnent les mêmes valeurs. forecast accepte aussi quantiles, les niveaux à renvoyer.

submit_outcomes prend model_id et les vérités : la valeur observée dans actual, plus le request_id de la prédiction d'origine ou la ligne complète dans features. refresh_model, model_performance (avec days, 30 par défaut), prediction_history (avec limit), archive_model et restore_model prennent model_id. list_models prend archived: true pour lister ce qui peut être restauré.

Ce que disent les résultats

Chaque résultat commence par la réponse en mots ordinaires, puis les détails. Le verdict vient en premier quand il y en a un : validate_data dit si les données sont exploitables, trop belles pour être vraies (une colonne donne probablement la réponse) ou sans signal ; backtest_forecast dit si la prévision vaut la peine d'être payée ; model_performance dit si le modèle tient, faiblit ou a décroché, avec le geste à faire. Les scores restent dans le corps pour qui les veut.

Un appel refusé revient avec isError: true, pour que le modèle sache qu'il doit corriger et réessayer, et non comme un texte qui passerait pour un succès. Le texte dit pourquoi : données refusées avant tout envoi, colonnes manquantes, quota du plan atteint avec la sortie, crédits insuffisants avec le solde et le montant requis.

Ressources et prompts

Trois ressources complètent le tableau sans consommer de budget d'outils : spavik://operations liste les outils dans l'ordre du parcours avec leur coût, spavik://models le catalogue du workspace, spavik://engines les moteurs sur lesquels un modèle peut être construit. Trois prompts proposent le parcours comme des entrées que l'utilisateur choisit : build_model, score_rows, close_the_loop. Plusieurs clients ignorent ressources et prompts, donc rien d'essentiel n'en dépend : les outils et les instructions portent tout.

Modèles, quota et archivage

Les plans limitent le nombre de modèles actifs. Quand train_model est refusé pour cette raison, le refus dit quoi faire : list_models montre les modèles actifs, archive_model libère une place. Un modèle archivé cesse de servir mais conserve tout, et restore_model le remet en service, en reprenant une place. Rien ici ne supprime un modèle pour de bon.

Ce que le serveur respecte du protocole

• Chaque outil porte ses annotations : aucun n'est destructeur, aucun n'ouvre sur le monde extérieur, six sont en lecture seule.
• La liste des outils sort dans un ordre stable, pour que les clients puissent la mettre en cache.
• Les requêtes sont sans état : aucun identifiant de session, un seul point POST, des réponses JSON.
• Origin et Host sont contrôlés.

Ce qui n'est pas exposé, et pourquoi

Ni suppression de compte, ni suppression de modèle, ni gestion des clés, ni facturation, ni administration, ni webhooks. Un agent qui se trompe ne doit pas pouvoir faire de dégât irréversible. Le serveur ne sait pas non plus ouvrir de session web : un agent n'a pas à manipuler un lien de connexion.

Pourquoi treize et pas cinquante

Au-delà d'une quarantaine d'outils, la sélection se dégrade nettement : le modèle choisit moins bien, et certains clients plafonnent de toute façon à ce nombre. Exposer un outil par route rendrait le serveur inutilisable. Les treize retenus couvrent le périmètre moteur, là où un agent a vraiment quelque chose à faire, à raison d'un outil par concept : un outil ne mélange jamais deux choses pour réduire le compte.