MCP en Pratique : Brancher Claude sur tes Données de Marché

Le problème que MCP résout

Un modèle de langage est figé à sa date de coupure. Demandez à Claude le cours d'AAPL aujourd'hui, et il devra deviner — au mieux il refusera poliment. Pendant des années, la réponse fut de câbler des APIs en dur : un client qui sait parler à Yahoo Finance, un autre à votre base de fondamentaux, un troisième à l'EDGAR de la SEC. Chaque source = du code de glue, une authentification spécifique, un format de réponse à reparser. Multipliez par dix sources et vous obtenez un harnais fragile que personne n'ose toucher.

Le Model Context Protocol (MCP) renverse la logique. Au lieu de coder « comment appeler chaque API », vous exposez vos sources derrière un serveur MCP qui décrit lui-même ce qu'il sait faire. Le modèle découvre les capacités disponibles, choisit lesquelles invoquer, et enchaîne les appels tout seul. C'est un standard ouvert — le même serveur fonctionne avec Claude, dans Claude Code, ou dans n'importe quel client compatible. Ce site lui-même tourne sur Claude Code branché sur une gateway MCP DailyTickers, dans des workflows multi-agents. Cet article ouvre la boîte.

Anatomie d'un serveur MCP

Un serveur MCP est un processus qui parle un protocole JSON-RPC bien défini. Il expose trois grandes catégories de primitives — mais pour brancher un agent sur des données de marché, deux comptent vraiment : les outils et les ressources.

Outils (tools)

Des fonctions que le modèle peut appeler, avec effets ou calculs. Chacune a un nom, une description et un schéma d'entrée JSON. Exemple : RunScreener, GetMarketOverview. Le modèle décide quand les appeler.

Ressources

Des données adressables par URI que le client peut lire et injecter dans le contexte — un document, un snapshot de portefeuille, un fichier de config. Lecture passive, pas d'effet de bord.

Prompts

Des gabarits de conversation pré-écrits, paramétrables, que l'utilisateur peut invoquer (« analyse ce ticker selon notre méthodo »). Utile mais optionnel pour un serveur de données.

Outil ou ressource ? La règle simple

Si l'opération fait quelque chose ou prend des paramètres dynamiques (lancer un screen, calculer une VaR, interroger une plage de dates), c'est un outil. Si c'est de la donnée qu'on veut juste lire à une adresse stable (le manifeste des instruments, un fichier watchlist), c'est une ressource. En finance, l'écrasante majorité des capacités utiles sont des outils, parce que les requêtes sont presque toujours paramétrées : un ticker, un horizon, un univers.

Comment le modèle découvre et appelle un outil

C'est le cœur de MCP : le modèle ne connaît pas vos outils à l'avance, il les découvre. Le cycle de vie d'un appel se déroule en quatre temps.

1 · Handshake & capacités

Au démarrage, le client (Claude Code, l'app Claude, une extension IDE) ouvre une session avec le serveur et négocie les capacités. Le serveur annonce : « je sais exposer des outils, des ressources, des prompts ».

2 · Listing — `tools/list`

Le client demande le catalogue. Le serveur renvoie chaque outil avec son name, sa description en langage naturel, et son inputSchema (JSON Schema). Ces descriptions sont injectées dans le contexte du modèle — c'est littéralement ainsi qu'il sait que RunScreener existe.

3 · Décision & appel — `tools/call`

Face à une question (« quels semis cassent leur résistance ? »), le modèle choisit un outil et fabrique un objet d'arguments conforme au schéma. Le client transmet l'appel au serveur via tools/call. Le modèle ne touche jamais à votre base — il émet une intention typée, le serveur l'exécute.

4 · Résultat structuré

Le serveur exécute (requête SQL, appel screener, lecture d'un filing) et renvoie un résultat — texte, JSON structuré, ou les deux. Le modèle lit ce résultat comme un nouveau tour de conversation, raisonne dessus, et décide s'il enchaîne avec un autre outil.

Du côté builder, la beauté c'est que le modèle compose ces appels. Vous ne scriptez pas « appelle A puis B puis C » — vous décrivez bien vos outils, et l'agent orchestre. Voici à quoi ressemble un appel et sa réponse, vus du fil de conversation :

# L'agent émet un appel d'outil (tools/call)
{
  "method": "tools/call",
  "params": {
    "name": "RunScreener",
    "arguments": {
      "universe": "us_equities",
      "filters": "sector == 'Technology' AND rsi14 > 60 AND price > sma50",
      "limit": 15
    }
  }
}

# Le serveur répond avec un résultat structuré
{
  "content": [{ "type": "text", "text": "15 matches" }],
  "structuredContent": {
    "matches": [
      { "ticker": "NVDA", "rsi14": 68.4, "price": 182.10 },
      { "ticker": "AVGO", "rsi14": 63.1, "price": 241.55 }
    ]
  }
}

Le schéma EST la documentation

Le modèle ne lit pas votre code source — il lit la description et l'inputSchema. Un schéma flou (« filters: string ») oblige le modèle à deviner la syntaxe. Un schéma riche, avec une description précise des opérateurs autorisés et un ou deux exemples, fait passer le taux de bons appels de « parfois » à « presque toujours ». On y revient dans la section conception.

Synchrone vs asynchrone : le job polling

Beaucoup d'outils répondent instantanément : un cours, un overview de marché, une ligne de fondamentaux. Mais certains calculs sont longs — un backtest sur dix ans, une matrice de corrélation sur 500 titres, un screen d'options multi-jambes. Bloquer la connexion pendant 90 secondes est une mauvaise idée : timeouts, retries, agent figé.

Le pattern propre, c'est le job asynchrone. L'outil ne renvoie pas le résultat — il renvoie un jobId immédiatement et lance le travail en arrière-plan. L'agent poll ensuite le statut jusqu'à complétion. Sur la gateway DailyTickers, c'est exactement le rôle de CheckJobStatus et ListJobs.

# 1. Lancer un calcul lourd — retour immédiat avec un jobId
RunScreener({ universe: "sp500", backtest: true, years: 10 })
#  → { "jobId": "job_a91f", "status": "running" }

# 2. L'agent poll le statut (synchrone, instantané)
CheckJobStatus({ jobId: "job_a91f" })
#  → { "status": "running", "progress": 0.42 }

# 3. Quelques tours plus tard : terminé
CheckJobStatus({ jobId: "job_a91f" })
#  → { "status": "done", "result": { "equity": [...], "sharpe": 1.8 } }

Synchrone

Réponse en un aller-retour. Idéal pour les lectures rapides : cotation, overview, régime de marché, un instrument. La plupart des outils de données.

Asynchrone (job)

L'outil renvoie un jobId, l'agent poll via CheckJobStatus. Pour tout ce qui dépasse quelques secondes : backtests, optimisations, gros screens.

Suivi global

ListJobs donne une vue d'ensemble des travaux en cours et passés — utile pour reprendre un calcul interrompu ou nettoyer une session.

Piège côté agent

Un agent qui poll trop agressivement gaspille des tours et du budget de tokens. Décrivez dans la description de l'outil un rythme de poll raisonnable (« attends quelques secondes entre deux statuts ») et renvoyez un champ progress : le modèle calibre son attente sur l'avancement plutôt que de spammer le serveur.

La forme d'une gateway de données de marché

Concrètement, à quoi ressemble un serveur MCP pour la finance ? Voici un échantillon représentatif des outils exposés par la gateway DailyTickers, regroupés par usage. C'est la surface qu'un agent voit — et qui suffit à mener une analyse de bout en bout.

Outil	Type	Ce qu'il fait
`GetMarketOverview`	sync	Snapshot macro : indices, secteurs, VIX, breadth. Le point de départ de tout briefing.
`RunScreener`	sync / job	Filtre un univers via une DSL (technique, fondamental, momentum). Rapide en live, asynchrone si backtest.
`QueryData`	sync	Requête générique sur les séries — OHLCV, fondamentaux, dérivés — par ticker et plage de dates.
`GetInstruments`	sync	Référentiel des instruments : tickers, ISIN, secteur, place de cotation, statut.
`GetEarningsCalendarFiltered`	sync	Calendrier de résultats filtrable — pour éviter d'entrer juste avant une publication.
`GetRegimeProbability`	sync	Probabilités de régime (risk-on / risk-off) dérivées du VIX et de la breadth.
`GetCorrelationMatrix`	job	Matrice de corrélation sur un panier — calcul lourd, renvoyé via job polling.
`CheckJobStatus`	sync	Poll le statut d'un travail asynchrone et récupère le résultat une fois prêt.

Pourquoi MCP > APIs câblées en dur, en une phrase

Avec des APIs en dur, ajouter une source = modifier le code de l'agent. Avec MCP, ajouter GetEarningsCalendarFiltered au serveur le rend immédiatement utilisable par l'agent sans toucher au prompt ni au code client : il apparaît au prochain tools/list, le modèle lit sa description, et s'en sert quand c'est pertinent. La capacité vit côté serveur, découverte côté modèle.

Authentification, rate limits et gestion d'erreurs

Un serveur MCP branché sur de la donnée de marché est une surface sensible. Trois sujets à ne jamais laisser de côté.

Authentification

L'auth se règle au niveau du transport (jeton OAuth, clé d'API côté serveur), jamais en passant des secrets dans les arguments d'outil — ces arguments transitent dans le contexte du modèle. Le serveur détient les credentials du fournisseur de données ; le modèle ne les voit jamais.

Rate limits

Les data providers facturent et plafonnent. Le serveur doit absorber ça : cache des réponses récentes, file d'attente, et un retour d'erreur explicite quand la limite est atteinte — pas un timeout opaque.

Gestion d'erreurs

Une erreur d'outil doit être renvoyée comme résultat marqué isError avec un message lisible, pas comme un crash. Le modèle lit le message et corrige son tir — « ticker introuvable », « plage de dates invalide ».

# Bon : une erreur d'outil est un résultat lisible, pas un crash
{
  "content": [{
    "type": "text",
    "text": "Ticker 'APPL' introuvable. Vouliez-vous dire 'AAPL' ?"
  }],
  "isError": true
}

Règle d'or : ne jamais accepter le stub silencieusement

Si l'URL de la gateway n'est pas configurée, certains outils peuvent tomber sur un stub qui renvoie un schéma vide au lieu d'une vraie donnée. C'est pire qu'une erreur : l'agent produit une analyse confiante sur du néant. Faites échouer bruyamment une gateway absente — un serveur de données muet doit lever une erreur, jamais inventer.

Concevoir de bons schémas d'outils

La qualité d'un serveur MCP se joue à 80 % dans ses schémas. Le modèle n'a que la description et l'inputSchema pour décider quand et comment appeler. Quatre principes.

Décrire quand appeler, pas seulement ce que fait l'outil

« Calcule la matrice de corrélation » est moins utile que « Utilise cet outil quand l'utilisateur veut vérifier la diversification d'un panier ou détecter des positions redondantes ». Les modèles récents (Opus 4.8, Sonnet 4.6) déclenchent les outils plus sobrement : un déclencheur explicite dans la description augmente mesurablement le bon taux d'appel.

Typer fort, contraindre par `enum`

Un champ timeframe libre invite aux fautes. Un enum ("1d" | "1w" | "1mo") ferme la porte aux valeurs invalides et guide le modèle. Marquez required uniquement ce qui l'est vraiment.

Donner un ou deux exemples dans la description

Pour une DSL de filtre, un exemple concret ("rsi14 > 60 AND price > sma50") vaut dix lignes de spec. Le modèle calque la forme.

Renvoyer du `structuredContent`, pas juste du texte

Un résultat structuré (JSON typé) est réutilisable par l'agent et chaînable vers un autre outil sans reparser de la prose. Doublez d'un court résumé texte pour la lisibilité.

Un agent analyse un ticker, de bout en bout

Mettons tout ensemble. Un utilisateur demande : « Est-ce que NVDA est un bon achat aujourd'hui ? ». Voici comment un agent — Claude Opus 4.8 dans Claude Code, branché sur la gateway — enchaîne les appels MCP sans qu'on lui dicte la séquence. Chaque résultat structuré nourrit la décision du tour suivant.

1 · Cadrer le marché — `GetMarketOverview` + `GetRegimeProbability`

L'agent commence par le contexte : indices, VIX, breadth, probabilité de régime. Inutile d'acheter du momentum en plein risk-off. Si le régime est dégradé, le verdict en tiendra compte.

2 · Lire le titre — `QueryData` + `GetInstruments`

OHLCV récent, moyennes mobiles, RSI, volume ; et le référentiel pour confirmer le secteur et la place de cotation. L'agent se construit une image technique propre.

3 · Vérifier les risques d'agenda — `GetEarningsCalendarFiltered`

Une publication de résultats dans trois jours change tout : gap risk. L'agent intègre la proximité de l'événement dans son raisonnement plutôt que de l'ignorer.

4 · Tester la corrélation — `GetCorrelationMatrix` (job)

Pour juger si NVDA ajoute de la diversification ou du doublon, l'agent lance un calcul de corrélation contre les positions existantes, récupère le jobId, puis poll via CheckJobStatus jusqu'au résultat.

5 · Synthèse

Avec régime, technique, agenda et corrélation en main, l'agent formule un verdict nuancé — et cite ses chiffres, tous tracés à un appel d'outil précis. Pas d'hallucination : chaque donnée vient d'un tools/call identifiable.

Ce que MCP débloque

Le modèle compose la séquence d'appels — vous décrivez les outils, l'agent orchestre.
Chaque chiffre est traçable à un appel MCP précis : zéro donnée inventée.
Ajouter une source = l'ajouter au serveur ; elle devient utilisable sans toucher au client.
Le même serveur sert Claude, Claude Code, ou tout client compatible — un standard, pas un adaptateur jetable.

Questions fréquentes

MCP est-il propre à Anthropic ?

Non. MCP est un standard ouvert de connexion entre LLM et outils/données externes. Anthropic l'a initié et Claude le supporte nativement — y compris dans Claude Code, avec sous-agents, hooks et workflows multi-agents — mais le protocole est indépendant du modèle.

Quelle différence entre un outil MCP et un « tool use » classique ?

Le tool use de l'API définit les outils dans chaque requête, côté code applicatif. MCP externalise cette définition dans un serveur réutilisable et découvrable : le même serveur sert plusieurs clients et plusieurs sessions, sans redéclarer les schémas à la main. Sous le capot, le client peut convertir les outils MCP en tool use pour le modèle.

Quel modèle utiliser pour piloter ces appels ?

Pour de l'agentique multi-étapes branché sur des données, on privilégie le modèle le plus capable disponible : claude-opus-4-8 par défaut, claude-fable-5 pour les tâches les plus exigeantes en raisonnement long. claude-sonnet-4-6 et claude-haiku-4-5 conviennent aux charges plus simples ou à fort volume.

Comment gérer un outil qui met 2 minutes à répondre ?

Découpez-le en job asynchrone : l'outil renvoie un jobId immédiatement, l'agent poll via un outil de statut (ici CheckJobStatus) en lisant un champ progress. On ne bloque jamais la connexion sur un calcul long.

Et si le serveur de données est indisponible ?

Il doit lever une erreur explicite, jamais renvoyer un schéma vide. Un agent qui reçoit du néant et l'interprète comme une donnée valide produira une analyse confiante et fausse — le pire scénario possible en finance.

Avertissement

Ceci n'est pas un conseil financier. Cet article est un guide technique sur le Model Context Protocol et son usage avec des données de marché. Les noms d'outils et la forme de la gateway sont fournis à titre illustratif. Les exemples de tickers ne sont pas des recommandations. Faites toujours vos propres recherches.