Un hôte d'agent peut avoir besoin d'une connexion qu'il peut configurer. Un développeur d'application peut avoir besoin d'une bibliothèque à importer dans son code. Ces besoins mènent à des surfaces d'intégration différentes.
Que fournit chacun à son appelant ?
Un serveur MCP fournit une interface protocolaire ; un SDK fournit des fonctions et des types pour un langage de programmation.
Le guide d'architecture MCP décrit des serveurs qui exposent des capacités à des clients connectés. Un serveur peut s'exécuter en tant que processus local ou fournir un point d'accès distant.
| Interface | Appelant | Ce que l'appelant utilise | Responsabilité d'exécution |
|---|---|---|---|
| Serveur MCP | Un client MCP dans un hôte d'agent ou une application | Requêtes protocolaires et capacités découvertes | Quelqu'un exécute le processus serveur ou le service distant |
| API SDK | Code applicatif | Méthodes de bibliothèque qui appellent un API | L'application exécute la bibliothèque et gère son intégration |
| MCP SDK | Code implémentant un client ou serveur MCP | Types protocolaires et utilitaires d'implémentation | L'application exécute toujours le client ou serveur résultant |
Un paquet SDK ne devient pas un serveur en cours d'exécution du simple fait que vous l'installez.
Un serveur peut-il utiliser un SDK ?
Oui. Un développeur peut utiliser un SDK protocolaire pour implémenter un serveur MCP, puis utiliser une autre bibliothèque cliente dans ses gestionnaires.
La documentation MCP SDK décrit des bibliothèques pour construire des clients et des serveurs. Ici, SDK désigne du code utilisé pour implémenter le protocole.
Un API SDK a une cible différente : il appelle l'API d'un service. Un serveur de commandes hypothétique pourrait exposer un outil de statut de commande dont le gestionnaire utilise un API SDK pour récupérer la commande.
L'interface MCP externe et l'appel API interne ont des contrats séparés. Prendre en charge une opération API ne l'expose pas automatiquement en tant qu'outil MCP.
Quelles responsabilités restent dans mon application ?
Votre application décide toujours quelles opérations demander. Elle décide aussi comment traiter leurs résultats.
Avec un API SDK, votre code sélectionne une méthode et fournit ses arguments. Avec MCP, l'hôte achemine les requêtes via un client vers les capacités exposées par le serveur.
L'architecture MCP laisse l'utilisation du contexte de modèle par l'hôte en dehors du périmètre du protocole. Une connexion d'outil ne décide pas de vos règles métier, de votre politique d'autorisation ni de vos critères de complétion.
Pour une recherche de commande, recevoir le statut demandé peut suffire à terminer la tâche. Pour l'envoi d'un message, la soumission et la livraison ultérieure sont des résultats distincts.
Comment choisir une intégration Bird ?
Vous pouvez connecter un hôte d'agent compatible au serveur MCP de Bird, ou intégrer du code applicatif via un client API.
Pour la voie bibliothèque, la décision Bird SDK couvre le choix entre un SDK et l'utilisation directe de HTTP. Pour la voie outil, l'inventaire Bird de votre client fournit les noms d'outils disponibles et les schémas d'entrée.
Comparez l'opération dont vous avez besoin sur l'interface que vous comptez utiliser. La présence d'une opération dans une interface n'implique pas sa présence dans une autre.
- Utilisez la connexion MCP lorsque votre hôte doit découvrir et invoquer des outils Bird.
- Utilisez un client API lorsque votre code applicatif sélectionne et invoque les opérations du service.
- Utilisez un MCP SDK lorsque vous implémentez le client ou le serveur protocolaire lui-même.