# MKB Pilot MCP

Un connecteur en lecture seule : ventes, stock, pricing, dossiers, relance, pointage. Tu te connectes avec ton compte MKB Pilot, tes droits de pôle et ton niveau de rôle s’appliquent tels quels. Aucune écriture n’est possible depuis ce serveur.

## Ce que fait le connecteur

Le connecteur donne à ton assistant IA un accès en lecture au CRM MKB Pilot : il répond en langage naturel à partir des mêmes chiffres que le dashboard. Il est réservé aux membres de MKB, et pour l’instant plus particulièrement à la direction. Un accès pourra être ouvert à d’autres membres ultérieurement.

Un outil répond toujours dans le périmètre du compte connecté : tes droits CRM habituels s’appliquent ici comme dans le dashboard, et le connecteur ne les élargit jamais.

- 42 outils de lecture
- 11 domaines
- 0 outil d’écriture

## Se connecter

Choisis ton client. Les trois passent par la même URL — https://mcp.mkbautomobile.com/mcp — et le même login.

### Claude Desktop (macOS · Windows)

1. Ouvre Réglages, puis Connecteurs.
2. Ajoute un connecteur personnalisé.
3. Colle l’URL, valide, puis connecte-toi avec ton compte MKB Pilot.

### Claude.ai (navigateur)

1. Ouvre Settings, puis Connectors.
2. Ajoute un custom connector.
3. Colle l’URL, puis autorise l’accès depuis la page de connexion.

### ChatGPT (connecteurs)

1. Ouvre Paramètres, puis Connecteurs.
2. Ajoute un serveur MCP distant.
3. Colle l’URL, puis connecte-toi avec ton compte MKB Pilot.

Ton client ne gère pas OAuth ? Il ne pourra pas se connecter à ce serveur — voir « Si ça ne marche pas ».

## Exemples de questions

- Quel est le chiffre d’affaires du mois ?
- Combien de leads sont en attente de prise en charge ?
- Quelles sources marketing ont le mieux converti ce trimestre ?
- Où en est le pipeline commercial du pôle Commercial ?
- Quels dossiers sont en retard aujourd’hui ?
- Quelle est la marge moyenne des véhicules pricés ce mois-ci ?

## Capacités et données

42 outils, tous en lecture. Déplie un domaine pour voir ce que chaque outil répond.

### Reporting direction (3)

- get_call_center_kpis — KPI du centre d'appel sur une période. `appel` = nombre de VRAIS appels passés (interactions de type 'call', comptées par leur date, en UTC). La ventilation par disposition (`interesser`, `nrp`, `a_rappeler`, `mauvais_numero`…) et `total_csv` sont, eux, comptés différemment (contacts dont la disposition de relance a été mise à jour dans la période, faute d'horodatage dédié) : `appel` n'est donc PAS égal à `total_csv` — ils mesurent deux choses distinctes (appels passés vs dispositions mises à jour). `period_key=weekly` = semaine calendaire depuis lundi. Filtrable par source/statut. Ne couvre pas la durée des appels ni les CDR téléphonie brutes.
- get_daily_incoming — Nombre de leads entrants par jour sur une période. Un « lead » = une ligne de la table contacts, comptée sur `contacts.created_at` bucketé par jour UTC ; bornes `from_date`/`to_date` INCLUSES. Inclut les leads ARCHIVÉS et doublons (pas de filtre de statut). Utiliser pour suivre le flux quotidien de nouveaux leads.
- get_global_kpis — Snapshot direction consolidé de 8 domaines en un appel : ventes (tout-temps), stock, relance, contacts, financement, acquisition, marketing, pricing/marge. Chaque bloc porte un `window` indiquant ce qu'il couvre (instant / all_time / range / native). period=this_month (défaut, appliqué par l'API) ou this_year ; ou from+to (YYYY-MM-DD, ensemble) — un intervalle explicite n'affecte PAS acquisition/relance (fenêtre native). acquisition.funnel lit une COHORTE (leads créés dans la période) ; acquisition.salesCount, .revenue et .cac lisent une temporalité différente, en DATE DE VENTE (ventes survenues dans la période, quel que soit l'âge du lead) — acquisition.salesCount compte des lignes `sales`, pas des contacts. acquisition.cac est restreint au périmètre payant et vaut `null` sans vente payante sur la période, jamais 0 €. NE PAS comparer marketing.cac et acquisition.cac, ni acquisition.margin (canaux) et pricing.margin (véhicule) : définitions distinctes. sales.totalQuotedAmount = montant devisé, pas un CA encaissé. Marge réservée CEO/G4. domainStatus.{succeeded,failed} indique la disponibilité par domaine. Agrégat — aucune personne listée.

### Acquisition (7)

- get_acquisition_funnel — Funnel d'acquisition STRATÉGIQUE (distinct du pipe commercial) sur une période enum. Deux temporalités cohabitent : le TUNNEL (étapes lead → mql → sql → appointment → sale, compteurs et taux de conversion) lit une COHORTE — les leads créés dans la période, et jusqu'où ils sont allés à ce jour ; son étape « sale » compte des contacts, pas des ventes. `conversionRate` lit lui aussi la COHORTE : `{sales, leads, rate}` où `sales` compte les leads de la periode convertis avec `type_conversion = 'VENTE'` — donc SANS les recherches personnalisees, ce qui le rend inferieur ou egal a l'etape `sale` du tunnel ; `rate` est un pourcentage a deux decimales, `null` si aucun lead (jamais 0). Les KPI (`kpis.revenue`, `kpis.margin`, `kpis.salesCount`, `kpis.cac`) et `periodSales` lisent en DATE DE VENTE — les ventes survenues dans la période, ventilées par canal d'origine du lead, même si ce lead a été créé bien avant ; `kpis.salesCount` compte des lignes `sales` éligibles, pas des contacts. `kpis.cac` est restreint au périmètre payant (Meta Ads) et vaut `null` si la période n'a aucune vente payante — ne jamais le lire comme 0 €. Renvoie aussi : cartes paid vs organic (leads, sql, taux lead→sql, coût par sql), stats par canal organique, vélocité moyenne (date de vente) + top raison de perte (cohorte), et l'objectif SQL (réalisé vs cible). La MARGE (`kpis.margin`) est réservée CEO/G4 (roleLevel ≤ 2) : `null` sinon. Champ de date = `period` enum (pas de dates libres). MQL/SQL déterminés par le statut CRM.
- get_lead_quality — Indicateurs de QUALITÉ des leads sur une période (RPC marketing). Filtre sur `created_at` (entrée CRM), bornes `start_date`/`end_date` en jour UTC. Agrégat — aucune personne listée. Ne couvre pas la ventilation par source (voir get_marketing_stats) ni le funnel (voir get_acquisition_funnel).
- get_marketing_group_breakdown — Détail marketing POUR une valeur UTM précise (campagne ou medium) sur une période. Filtre sur `created_at` en jour UTC, bornes incluses. `group_by` = dimension (utm_campaign | utm_medium) ; `group_value` = la valeur précise à analyser au sein de cette dimension (REQUIS, ex : le nom de campagne exact). Agrégat — aucune personne listée. Ne couvre pas la liste des leads sous-jacents (voir get_leads_by_utm).
- get_marketing_costs — Coûts marketing saisis sur une période (base du CPL / CAC). Filtre par `start_date`/`end_date` (YYYY-MM-DD). Agrégat — read-only : la saisie des coûts (POST) n'est pas exposée.
- get_leads_by_utm — Liste paginée des leads POUR une valeur UTM précise (campagne ou medium) sur une période. Filtre sur `created_at` en jour UTC, bornes incluses. `group_by` = dimension (utm_campaign | utm_medium) ; `group_value` = la valeur précise à analyser (REQUIS). Pagination `page` 0-based (défaut 0) / `limit` (max 100). Données complètes (coordonnées et notes incluses) — connecteur direction.
- list_incoming_leads — File des leads ENTRANTS à traiter (non encore pris en charge). Renvoie `{ leads, count }` où chaque lead = identité minimale (id, prénom, nom). Avec `count_only=true`, renvoie seulement `{ count }`. Pas de filtre temporel (file d'attente courante). La prise en charge d'un lead n'est pas exposée (mutation).
- get_lead_interactions — Historique paginé des interactions d'un lead/contact (appels, emails, notes, rendez-vous, autres) : type, date, description complète, auteur (userId), pôle/service au moment de la création (snapshot). Tri : date desc puis created_at desc. Contient du texte libre (notes intégrales) — connecteur direction. Endpoint réservé Direction (CEO/G4) côté API : 403 sinon.

### Marketing (3)

- get_marketing_stats — Statistiques marketing agrégées sur une période : volume de leads, conversions et ratios, regroupés par source d'acquisition (ou campagne / medium UTM). COMPTAGE : un « lead » = une ligne de la table contacts ; filtre sur `contacts.created_at` (date d'entrée dans le CRM — PAS la date de dispatch ni de conversion), en jour calendaire UTC ; `start_date` ET `end_date` sont toutes deux INCLUSES. Inclut les leads ARCHIVÉS et les éventuels doublons — les totaux peuvent donc excéder les vues CRM filtrées. `conversions` = leads passés au statut `Converti`.
- get_marketing_timeseries — Évolution temporelle des leads et des ventes sur une période, agrégée par jour, semaine ou mois. Même comptage que get_marketing_stats : leads = lignes contacts par `contacts.created_at` en jour UTC, bornes `start_date`/`end_date` INCLUSES, archivés + doublons inclus ; ventes = statut `Converti`. La somme des buckets est cohérente avec get_marketing_stats sur la même période. Buckets `week` = semaine ISO (lundi).
- get_leads_by_source — Répartition du nombre de leads par source d'acquisition sur une période. Un « lead » = une ligne de la table contacts ; filtre sur `contacts.created_at` en UTC (from inclus à 00:00, to inclus jusqu'à 23:59:59.999). Inclut les leads ARCHIVÉS et doublons. Les sources vides sont regroupées sous `Non spécifié`. Vue agrégée simple (compteurs par source), utile pour comparer les canaux d'acquisition.

### Pipeline et contacts (6)

- list_poles — Liste les pôles accessibles (avec leur ID numérique et leur nom). À appeler en premier pour obtenir le poleId nécessaire à get_pipeline_stats.
- get_pipeline_stats — KPI du pipeline commercial B2C pour un pôle donné : répartition des leads par statut (byStatus), volumes, taux. Nécessite un poleId (utiliser list_poles pour le résoudre). Optionnellement filtrable par service. ABANDON — attention aux taux de conversion : le statut 'Perdu' est sous-utilisé ; l'abandon passe surtout par l'ARCHIVAGE (archivedCount, leads archivés du périmètre EXCLUANT les Perdu, indépendant de includeArchived) et par le transfert en relance. Le dénominateur d'abandon est `somme(byLossReason) + archivedCount` (même périmètre pôle/service/user/commercial) : SANS double-comptage mais PARTIEL, car il n'inclut PAS les leads transférés en relance (sortis du périmètre pôle/service, non quantifiables ici). NE PAS utiliser `byStatus.Perdu` comme dénominateur : il exclut les Perdu archivés et porte les filtres de liste (sources/priorities/tags/age), donc il sous-compte sur une base différente. `byLossReason` = distribution des raisons de perte (out_of_budget/car_unavailable/unreachable/bought_elsewhere/other/unspecified) sur les seuls leads 'Perdu'. Aucun de ces compteurs n'est fenêtrable dans le temps. byStatus filtre sur contacts.status ; thisWeek sur created_at, thisMonth sur dispatched_at (fallback created_at).
- get_contacts_stats — Totaux de la base de contacts : nombre total, particuliers, professionnels. Vue agrégée simple.
- list_contacts — Liste détaillée et paginée des contacts, filtrable par recherche, source, statut, type (pro/particulier) et commercial assigné (assigned_user_id). Données complètes (coordonnées et notes incluses) — connecteur direction.
- list_custom_search — Liste paginée des recherches personnalisées (RP — sourcing véhicule sur-mesure, remplace le tableur) : référence RP-…, statut, budget, critères (marques/modèles, année, km, carburant…), contact et assigné. Filtres : q (texte libre : référence ou contact), status. Réponse { items, total }. Données complètes — connecteur direction.
- get_custom_search — Détail complet d'une recherche personnalisée par son UUID (pas la réf RP-… : celle-ci n'est acceptée que par le paramètre q de list_custom_search) : critères complets, choix de véhicules, annonces proposées. Données complètes — connecteur direction.

### Ventes (1)

- get_sales — Liste paginée des ventes transactionnelles (table sales), filtrable par statut et type de vente, triée par date de création. Renvoie aussi un bloc `aggregates` calculé sur TOUT le périmètre filtré (pas seulement la page) : `countByStatus` (negotiation→order_signed→…→closed), `countBySaleType` (direct_sale/purchase/deposit_sale/trade_in), `totalQuotedAmount` (SUM du prix final ou, à défaut, du devis). `aggregates.revenueComputable=false` signale que le CA RÉALISÉ n'est pas calculable (aucune vente clôturée/payée) — ne pas interpréter un CA à 0 comme « pas de ventes ». Ne couvre pas le CA prévisionnel ni les commissions.

### Pricing et marges (4)

- get_pricing_ranking — Classement des priceurs sur une période : nombre d'annonces postées (table advertisements, par created_at UTC) et part en %. Champ de date = date de publication de l'annonce. Ne couvre pas la marge (voir get_margin_stats).
- get_margin_stats — Marge agrégée sur une période (marge = prix de vente − prix d'achat, par véhicule pricé). Renvoie totalMargin, avgMargin, medianMargin, avgMarginPct et une distribution par tranches (<0/0-1k/1-2k/2-5k/5k+). Champ de date = advertisements.created_at (date de publication de l'annonce, UTC) ; sans from_date, la fenêtre par défaut va du 1er jour du mois en cours à maintenant. dataQuality.ok=false si aucune marge calculable. Seul endroit du SI où la marge est calculable. Ne couvre pas les commissions.
- get_pricing_stats — Statistiques pricing sur une période : véhicules postés (total, aujourd'hui, ce mois via advertisements.created_at UTC), moyenne de posts par collaborateur, meilleur priceur ; plus availableVo (VO disponibles = cars_v2 status='disponible') et carsToPost (à poster). Filtrable par user_id. Ne couvre pas la marge (get_margin_stats). availableVo = stock ACTIF uniquement (status='disponible' ET non archivé), même périmètre que get_vehicle_aging ; `inconsistentArchived` compte les disponibles archivés, exclus de availableVo.
- list_priced_vehicles — Liste paginée des véhicules pricés/postés sur une période : reference, marque, modele, prix d'achat, prix de vente, marge (valeur + %), statut, priceur (nom), localisation, date de publication. Filtres période (sur date de publication, UTC), priceur, recherche. Pagination page/limit (max 100). Données complètes — connecteur direction.

### Stock véhicules (3)

- get_stock_stats — Compteurs du stock véhicules (table cars_v2), à un instant donné — aucun filtre de date. `byStatus` est ventilé par les statuts réels en base : `disponible`, `reserve`, `vendu`, `a-verifier` (voir `statusLabels` pour les libellés FR). L'archivage n'est PAS un statut : c'est le champ `archived` (flag `is_archived`). PÉRIMÈTRE : `total` et `byStatus` (dont `byStatus.disponible`) portent sur TOUTE la table (historique complet : disponibles + réservés + vendus + à vérifier, archivés inclus) — ce n'est PAS le stock actif ; `totalActive` = véhicules non archivés. Ne pas confondre `total` avec les « VO disponibles » du dashboard Pricing (= uniquement statut `disponible`). `dataQuality.ok=false` signale un comptage en échec ou un statut hors référentiel (ne pas interpréter un 0 comme « aucun »). Si des véhicules `disponible` sont aussi archivés (voir `inconsistentArchived`, qui en donne le nombre exact), `byStatus.disponible` dépasse alors le total de get_vehicle_aging et le availableVo de get_pricing_stats, qui excluent les archivés. `sold` = ventes datées via `cars_v2.sold_at` (posé par trigger au passage à 'vendu', UTC) : `last7Days`/`last30Days`/`thisMonth`. `coverage.withSoldAt` (vendus AVEC date) vs `coverage.totalVendu` : tant que `withSoldAt << totalVendu`, l'historique d'avant la migration n'est pas daté — ne pas lire `thisMonth` comme un total historique. `sold=null` si la colonne n'est pas encore déployée.
- get_vehicle_aging — Ancienneté du stock véhicules DISPONIBLE (cars_v2 status='disponible', stock ACTIF : is_archived=false). Ventile par tranches de jours en stock (0-30 / 31-60 / 61-90 / 90+) et renvoie âge moyen et médian. Ancienneté = maintenant − created_at (entrée en stock), en jours UTC. dataQuality.ok=false si stock vide. Ne couvre pas les véhicules vendus/réservés. Le total est donc inférieur au `byStatus.disponible` de get_stock_stats, qui inclut les archivés ; l'écart est donné par `inconsistentArchived`, un champ de la réponse de get_stock_stats — absent de celle de get_vehicle_aging.
- list_vehicles — Liste paginée du stock véhicules (cars_v2). Champs : reference, marque, modele, statut (disponible/reserve/vendu/a-verifier), dateEntreeStock (= created_at, UTC), responsable (nom). Filtres : statut, marque, modele, search (référence), from_date/to_date sur l'entrée en stock (bornes inclusives). Pagination page/limit (max 100). Données complètes — connecteur direction. Ne fournit pas la date de vente (aucune colonne dédiée en base).

### Relance (2)

- get_relance_kpi — KPI de la relance sur une période : compteurs par DISPOSITION de relance (`interesser`, `nrp`, `a_rappeler`) plus `by_relance_status` = ventilation exhaustive de toutes les dispositions présentes (mauvais_numero, pas_interesser, a_deja_son_vehicule, achat_chez_nous… + `none` pour les contacts en file sans disposition). La période filtre sur la DATE D'ENTRÉE EN FILE de relance (rq.created_at_utc), en UTC — pas la date de dernière tentative. `total` = contacts en file sur la période (hors sorties). Utiliser pour suivre l'activité de relance.
- list_relance — Liste détaillée des contacts en file de relance, filtrable par source, statut et recherche. Données complètes (coordonnées et notes incluses) — connecteur direction.

### Dossiers et logistique (5)

- list_cases — Liste paginée des dossiers CRM (feature cases). Couvre la vue ACSG (filtres pole_id/case_type/status) et la vue Logistique (filtre current_step_code = étape courante). Filtres : case_type (POST_SALE/PRE_SALE/REGISTRATION_FRANCE/REGISTRATION_IMPORT_EXPORT/SAV/LITIGATION/CALLBACK_REQUEST/ADMIN_REQUEST), status (open/in_progress/closed/cancelled), priority (low/normal/high/urgent), pole_id, service_id, owner_id, contact_id, sale_id, project_id, overdue (deadline d'étape dépassée), is_blocked, search, from/to, current_step_code (une ou plusieurs étapes), archived (exclude/only). Tri sort_by/sort_dir, pagination page/limit (max 100). Chaque dossier référence un contact. Données complètes — connecteur direction.
- get_case — Détail d'un dossier CRM par son UUID (étapes, commentaires selon l'endpoint). Données complètes — connecteur direction.
- get_cases_kpis — KPIs globaux des dossiers (vue ACSG) : total_open, total_overdue, total_blocked, total_closed_30d (fenêtre figée 30 j), by_case_type. Compteurs instantanés (pas de filtre de période). Agrégat.
- get_logistics_kpis — KPIs de la section Logistique (scopés par étape courante, pas par pôle assigné) : in_transport, in_preparation, overdue. Compteurs instantanés. Agrégat.
- get_overdue_cases — Dossiers en retard (deadline d'étape courante dépassée), triés par urgence. Filtre optionnel pole_id. Données complètes — connecteur direction.

### Financement (3)

- list_financing_requests — Liste paginée des dossiers de financement (project_financing_requests) : statut, produit, montants (amount_requested/project_amount/amount_bdc), courtier, projet + véhicule, contact. Filtres : status, product, broker_user_id, project_id, contact_id, search (réf F-XXXXXXXX OU nom/email contact). Pagination page/limit (max 100), tri sort_by/sort_dir. Données complètes (coordonnées et notes incluses) — connecteur direction.
- get_financing_request — Détail d'un dossier de financement par son UUID (pas la réf F-… : celle-ci n'est acceptée que par le search de list_financing_requests). Renvoie la ligne complète du dossier. Données complètes (coordonnées et notes incluses) — connecteur direction.
- get_financing_stats — Agrégat de pilotage des dossiers de financement sur une période (filtre sur requested_at, UTC, bornes incluses) : countByStatus, countByProduct, totalAmountRequested, approvedAmount, approvalRate (APPROVED / (APPROVED+REJECTED), null si aucun décidé), pendingCount (non décidés), dataQuality. Filtrable par courtier (broker_user_id). Agrégat — aucune personne listée.

### Pointage et RH (5)

- list_time_off — Demandes de congés (Suivi RH). Fournir user_id pour l'historique d'une personne, sinon scope=team (défaut) pour toute l'équipe visible. Filtres : status (PENDING/APPROVED/REJECTED), month (1-12), year. Chaque ligne inclut le collaborateur (nom, email). Données complètes — connecteur direction.
- get_team_time_tracking — Aperçu du temps de travail par personne (aujourd'hui / semaine / mois / année) tel que calculé par l'API, avec session active éventuelle et dernière activité. scope=team (défaut) = toute l'équipe visible ; scope=me = soi-même. search filtre par nom/email. Le MCP ne recalcule rien. Données complètes — connecteur direction.
- get_user_time_tracking — Détail mensuel du temps de travail d'une personne : sessions + totaux mois/année. overtimeMinutes/overtimeFormatted sont calculés par l'API selon sa règle courante d'heures supplémentaires (le MCP ne présume pas la formule). user_id, month (1-12) et year requis. Données complètes — connecteur direction.
- list_time_sessions — Sessions de pointage brutes (clock-in/out) de toutes les personnes, paginées. Filtres : status (ACTIVE/CLOSED), user_search (nom/email), date_from/date_to (comparés au début de session started_at, UTC, bornes incluses ; une date nue = minuit, passer un horaire ISO pour couvrir toute la journée), timezone (égalité exacte sur la timezone stockée). Utiliser offset + limit (max 100) pour la page suivante quand hasNextPage vaut true. Données complètes — connecteur direction.
- list_time_session_audit — Piste d'audit des overrides de pointage (actions admin START/END). Fournir session_id ou target_user_id (au moins un ; fournir les deux applique un ET). limit max 100. Données complètes — connecteur direction.

## Accès et sécurité

- Réservé aux membres de MKB — actuellement la direction. Une ouverture à d’autres membres est envisagée plus tard.
- Tu te connectes avec ton compte individuel MKB Pilot : aucun compte de service partagé.
- Lecture seule : aucune écriture, suppression ou modification n’est possible.
- Chaque appel d’outil est journalisé et soumis à une limite de débit par utilisateur.
- Tes droits CRM habituels s’appliquent : le serveur transmet ton identité à l’API, sans accès élargi.

## Si ça ne marche pas

Quatre échecs possibles. Les trois premiers arrivent après un mot de passe pourtant valide.

### Accès refusé après un login valide

Ton compte est reconnu, mais son niveau de rôle dépasse le plafond autorisé sur le connecteur. Le login réussit, l’accès aux outils non.

> Accès réservé à la direction : ce compte n’a pas le niveau de rôle requis.

- À faire : Écris à l’équipe technique en citant ton pôle et ton rôle.

### Session d’autorisation expirée

Le message parle de relancer la connexion depuis ton client : c’est celui d’où tu es parti — Claude Desktop, Claude.ai ou ChatGPT.

> Session d’autorisation expirée, relance la connexion depuis ton client.

- À faire : Retire le connecteur, rajoute-le, puis reconnecte-toi.

### Trop de tentatives

Le serveur accepte 30 tentatives par minute et par compte, sur une fenêtre glissante : l’accès se rouvre en moins d’une minute.

> Trop de tentatives, réessaie dans un instant.

- À faire : Attends une minute, puis réessaie.

### Ton client ne gère pas OAuth

Ce serveur n’accepte que la connexion OAuth. Un client MCP qui ne la gère pas ne peut pas s’y brancher, quelle que soit l’URL.

> 401 — authentification requise

- À faire : Utilise l’un des trois clients de la section « Se connecter ».

Le connecteur peut aussi répondre : « Impossible de vérifier tes droits : l’API MKB est momentanément indisponible. Réessaie dans quelques minutes, ou préviens l’équipe technique. » — c’est que l’API MKB ne répond pas, pas que ton compte est en cause.

## Surfaces machine

La même documentation existe dans deux formats destinés aux outils. Les descriptions techniques des outils — sémantique des dates, des bornes et des valeurs absentes — y vivent en entier.

- `/llms.txt` — Documentation en Markdown. Cette page en texte, avec la description complète de chaque outil.
- `/docs.json` — Métadonnées de connexion. Endpoint, transport, schéma d’authentification, et la liste des outils avec leur domaine.