Le Model Context Protocol est un standard ouvert qui donne aux LLM un accès structuré aux données et aux outils. On explique son architecture, ses primitives, et pourquoi c'est la bonne approche pour la finance.
Demandez à un LLM « Quel est le cours d'Apple en ce moment ? » et vous obtiendrez une réponse polie mais fondamentalement inutile : « Je n'ai pas accès aux données en temps réel, mais au moment de mon entraînement... ». Le modèle est brillant mais aveugle. Il peut analyser un bilan, expliquer un ratio financier, ou construire un modèle de valorisation — mais il ne sait pas que le S&P 500 vient de perdre 2% dans la dernière heure.
Ce fossé entre capacité de raisonnement et accès aux données est le problème fondamental de l'IA appliquée à la finance. La finance est un domaine où les données changent chaque seconde : prix, volumes, spreads, taux, volatilité. Un modèle qui raisonne sur des données périmées de 6 mois est pire qu'inutile — il est dangereux.
Le LLM cite un cours de 6 mois. Le stock a depuis fait +40% ou -50%.
Earnings, splits, M&A, dividendes — tout ce qui s'est passé après l'entraînement est invisible.
Sans données fraîches, le modèle invente. META à +32% quand la réalité est -15%.
Impossible de filtrer 6000 tickers sur des critères techniques sans accès aux données.
En juin 2026, un agent IA a généré une rétrospective semestrielle sans accès au MCP (le serveur de données était down). Résultat : 100% du palmarès était inventé. META affiché à +32% alors qu'il était à -15%, le secteur énergie annoncé à +36% alors qu'il était à -1%. Chaque chiffre, chaque classement, chaque narrative — tout faux. C'est l'incident qui a motivé la création de la règle MCP HARD STOP : si les données ne sont pas disponibles, on ne publie rien.
La solution semble évidente : donner au LLM un accès aux données. Mais comment ? C'est là que les approches divergent — et que MCP apporte une réponse structurelle.
Le Model Context Protocol (MCP) est un standard ouvert créé par Anthropic fin 2024 pour résoudre exactement ce problème. Son principe est simple : définir un protocole universel par lequel un LLM peut découvrir, appeler et recevoir les résultats d'outils externes — sans que le développeur de l'application ait à écrire du code d'intégration spécifique pour chaque outil.
Pensez à MCP comme à un USB pour l'IA. Avant l'USB, chaque périphérique avait son propre connecteur, son propre driver, sa propre logique d'intégration. L'USB a standardisé tout ça : un seul protocole, un seul connecteur, et n'importe quel périphérique fonctionne avec n'importe quel ordinateur. MCP fait la même chose pour les LLM : un seul protocole, et n'importe quel serveur de données fonctionne avec n'importe quel LLM compatible.
Le standard est ouvert et documenté sur modelcontextprotocol.io. Il est supporté nativement par Claude Code, Cursor, Windsurf, Gemini CLI, et un écosystème grandissant d'outils de développement IA.
Imaginez un assistant qui parle toutes les langues (le LLM) mais qui est enfermé dans une pièce sans fenêtre. MCP, c'est lui donner un téléphone avec un carnet de contacts (les outils). Il peut appeler le « service des prix » pour connaître le cours d'Apple, le « service de screening » pour trouver les actions survendues, ou le « service de news » pour les dernières annonces. Il choisit qui appeler et quand — vous n'avez pas à lui dicter chaque appel.
L'architecture MCP repose sur trois composants distincts qui communiquent via un protocole standardisé basé sur JSON-RPC 2.0 :
L'application qui héberge le LLM. Claude Code, Cursor, un IDE, ou votre propre application. Le Host gère la conversation et décide quand appeler un outil.
Le composant intégré au Host qui parle le protocole MCP. Il découvre les serveurs, maintient les connexions, et route les appels d'outils.
Votre code. C'est là que vivent les outils, les données, et la logique métier. C'est CE QUE VOUS CONSTRUISEZ dans cette série.
Le flux typique est le suivant :
QueryDataQueryData(ticker="AAPL", types=["technicals"]){"rsi_14": 42.3, "ema_20": 189.50, ...}MCP supporte plusieurs modes de transport :
| Transport | Usage | Quand l'utiliser |
|---|---|---|
| stdio | Communication via stdin/stdout | Serveur local lancé par le Host (ex: claude mcp add -- python server.py) |
| SSE (Server-Sent Events) | HTTP unidirectionnel + POST pour les appels | Serveur distant, déploiement web classique |
| Streamable HTTP | HTTP bidirectionnel, stateless | Le nouveau standard recommandé pour les serveurs distants (remplace SSE progressivement) |
Pour un serveur de données financières destiné à être partagé (pas juste local), SSE ou Streamable HTTP est le bon choix. Dans cette série, nous utiliserons SSE via FastAPI — c'est le plus largement supporté à ce jour.
MCP expose trois types de capacités, chacun avec un modèle d'interaction différent :
Fonctions que le LLM peut appeler. Le cœur de MCP. Chaque outil a un nom, une description, un schéma d'entrée (JSON Schema) et retourne un résultat structuré.
Données que le LLM peut lire (mais pas modifier). Fichiers, datasets, configs. Identifiées par des URIs. Pensez à un système de fichiers en lecture seule.
Templates de prompts réutilisables. Le serveur expose des modèles de conversation pré-construits que le Host peut proposer à l'utilisateur.
Un outil MCP est défini par trois choses : un nom, une description en langage naturel (que le LLM lit pour décider quand l'utiliser), et un schéma JSON qui définit les paramètres acceptés.
# Déclaration d'un outil MCP (côté serveur) { "name": "QueryData", "description": "Retrieve financial data for a ticker. Supports quote (current price), bars_daily (OHLCV history), technicals (RSI, EMA, MACD), fundamentals (P/E, EV/EBITDA, margins), and earnings (quarterly results).", "inputSchema": { "type": "object", "properties": { "ticker": { "type": "string", "description": "Stock ticker symbol (e.g. AAPL, MSFT)" }, "types": { "type": "array", "items": { "type": "string", "enum": ["quote", "bars_daily", "technicals", "fundamentals", "earnings"] } } }, "required": ["ticker", "types"] } }
Le LLM lit la description et le schéma, et décide de lui-même quand appeler l'outil. Si l'utilisateur demande « Quels sont les fondamentaux de Microsoft ? », le LLM appellera QueryData(ticker="MSFT", types=["fundamentals"]) sans qu'aucun code côté client ne lui dise de le faire.
Les Resources sont des données statiques ou semi-statiques que le LLM peut consulter. Par exemple :
universe://sp500 — la liste des 500 composants du S&P avec leur secteur et leur poidscalendar://earnings/2026-07 — le calendrier des résultats trimestriels de juillet 2026config://modes — la configuration actuelle des modes de trading (risk params, regime filters)Les Prompts MCP sont moins utilisés en finance mais restent utiles pour standardiser des workflows :
# Prompt template "analyse-ticker" { "name": "analyse-ticker", "description": "Analyse complète d'un ticker (fondamentaux + technique + trade idea)", "arguments": [ { "name": "ticker", "required": true } ] }
Quand l'utilisateur sélectionne ce prompt, le Host injecte un template de conversation pré-rempli qui guide le LLM à travers une analyse structurée : d'abord les fondamentaux, puis les techniques, puis la trade idea. On verra en Partie 6 comment exploiter cette primitive.
On pourrait simplement exposer une API REST et écrire du code qui appelle les endpoints. Pourquoi s'embêter avec MCP ?
| Aspect | API REST classique | MCP Server |
|---|---|---|
| Découverte | Le développeur lit la doc, écrit le code d'intégration | Le LLM découvre les outils automatiquement à la connexion |
| Décision d'appel | Le code décide quand appeler quel endpoint | Le LLM décide (basé sur la description de l'outil et la question de l'utilisateur) |
| Orchestration | À coder manuellement (if/else, state machine) | Le LLM orchestre naturellement (appelle plusieurs outils, enchaîne les résultats) |
| Portabilité | Chaque client doit coder son intégration | Tout Host MCP-compatible fonctionne sans code additionnel |
| Évolution | Ajouter un endpoint = mettre à jour tous les clients | Ajouter un outil = il apparaît automatiquement pour tous les clients |
| UX | Interface codée en dur (boutons, formulaires) | Langage naturel : « montre-moi les actions survendues dans le secteur tech » |
Avec une API classique, le développeur décide quand appeler quel endpoint. Avec MCP, le LLM décide — en fonction de ce que l'utilisateur demande. C'est un changement de paradigme : vous décrivez ce que vos outils font, et le LLM décide quand les utiliser. Vous passez de l'impératif (« appelle cette fonction quand l'utilisateur clique ici ») au déclaratif (« voici mes outils, utilise-les quand c'est pertinent »).
MCP n'est pas la réponse à tout. Dans ces cas, une API classique reste meilleure :
La finance est l'un des domaines où MCP apporte le plus de valeur, parce qu'elle combine trois caractéristiques qui jouent en faveur du protocole :
Les prix changent chaque seconde. Un LLM a besoin de données fraîches, pas de données d'entraînement.
Prix (Yahoo), fondamentaux (SEC), options (CBOE), crypto (Binance), macro (FRED). Un seul serveur les agrège.
Le LLM excelle à combiner des données hétérogènes : « compare les fondamentaux de 3 REITs en ajustant pour le leverage ».
Chaque chiffre est traçable : source de données, timestamp, méthode de calcul. Pas d'hallucination possible.
| Catégorie | Outils typiques | Fréquence d'appel | Cache TTL |
|---|---|---|---|
| Marché | GetQuote, GetBars, GetMarketOverview | Très haute (chaque question prix) | 15s – 12h |
| Technique | GetTechnicals, GetCorrelationMatrix | Haute (analyses, screening) | 1h |
| Fondamentaux | GetFinancials, GetEarnings, GetInsiders | Moyenne (analyses profondes) | 24h |
| Screening | RunScreener, GetTopDiscoveries | Basse (scans quotidiens) | 1h |
| Risk | GetRegimeProbability, CalculateVaR, StressTest | Basse (décisions de portfolio) | 1h – 24h |
| Backtesting | RunBacktest, ValidateStrategy | Rare (R&D) | 24h+ |
Le MCP DailyTickers est le serveur de données qui alimente l'ensemble du système de publication. Il expose 15+ outils couvrant les prix, les fondamentaux, le screening, le backtesting, les options, et l'optimisation de portefeuille.
| Outil | Description | Inputs clés |
|---|---|---|
| QueryData | Point d'entrée universel pour les données ticker | ticker, types[] |
| GetMarketOverview | Snapshot complet : indices, secteurs, VIX, commodities, crypto, forex | Aucun |
| RunScreener | Screening avec DSL de filtres | filters (DSL string) |
| GetRegimeProbability | Régime de marché actuel (Risk-On/Off, Neutral) | Aucun |
| GetCorrelationMatrix | Matrice de corrélation entre tickers | tickers[], period |
| OptimizeSizing | Optimisation de taille de position | tickers[], constraints |
| GetEarningsCalendarFiltered | Calendrier des résultats filtré | from, to, tickers[] |
| RunBacktest | Backtest d'une stratégie | strategy, period, params |
| GetInsiderActivity | Activité des insiders (achats/ventes) | ticker |
| CalculatePortfolioVaR | Value at Risk du portefeuille | positions[], confidence |
Chaque nuit à 23h, le scanner automatisé utilise le MCP dans un pipeline de 10 étapes :
# Pipeline scanner — appels MCP séquentiels # 1. Régime actuel regime = await mcp.call("GetRegimeProbability") # → { "regime": "risk_on", "vix": 14.2, "probabilities": {...} } # 2. Screening (6000+ tickers) candidates = await mcp.call("RunScreener", { "filters": "price > 5 AND volume > 500000 AND rsi_14 < 40 AND ema_20_slope > 0" }) # → 80-120 candidats # 3. Enrichissement par ticker for ticker in candidates: data = await mcp.call("QueryData", { "ticker": ticker, "types": ["quote", "technicals", "fundamentals", "earnings"] }) # → prix, RSI, EMA, P/E, EPS beats, ... # 4. Corrélation intra-basket corr = await mcp.call("GetCorrelationMatrix", { "tickers": selected_tickers, "period": "3m" }) # 5. Sizing optimisé sizes = await mcp.call("OptimizeSizing", { "tickers": selected_tickers, "constraints": { "max_per_position": 0.15, "max_correlation": 0.7 } })
Le LLM ne fait pas ces appels aveuglément. Il raisonne entre chaque étape. Si le régime est « Risk-Off », il ajuste les filtres du screener. Si la corrélation est trop haute, il retire des tickers. Si les earnings sont dans 3 jours, il flag le risque. C'est cette intelligence entre les appels d'outils qui distingue MCP d'une simple séquence de requêtes API.