Requête d'outil gouvernée
MCP Gateway

Gouvernez chaque appel d'outil de vos agents

Les agents ont besoin de plus qu'un simple proxy. Odock place un MCP gateway gouverné entre vos agents et chaque serveur en amont — en appliquant l'authentification, les politiques d'accès, les limites de dépenses et les enregistrements d'audit avant l'exécution de tout outil.

Une seule voie gouvernée pour chaque appel d'outil.

mcp-gateway.request
MCP Gateway
>POST /v1/mcp/tools/callruntime agent
01Accès agentvalidé
02Droits outil...
03Scan politique...
04Budget réservé...
05Route amont...
06Usage journalisé...
Transports
SSE, HTTP, STDIO
Contrôles
Politique, budget, audit
Cycle de vie des requêtes MCP

Chaque appel d'outil suit un chemin gouverné

Aucune requête n'atteint un serveur en amont sans passer par l'authentification, les contrôles d'accès, l'inspection et les limites de coût. Chaque résultat est enregistré.

01

Authentifier

Valider la clé API virtuelle.

02

Autoriser

Confirmer les droits d'accès et le scope du serveur.

03

Inspecter & appliquer

Filtrer les outils, les charges utiles et les politiques.

04

Réserver le budget

Vérifier les budgets et quotas avant l'exécution.

05

Transporter

Proxifier en amont via HTTP, SSE ou STDIO.

06

Enregistrer le résultat

Journaliser l'outil, la latence, le statut et le coût.

Exemple de requête bloquéeRefusée par la gouvernance
{
  "apiKey": "vk_agent_prod_support",
  "mcpServer": "github-tools-http",
  "method": "tools/call",
  "tool": "delete_file",
  "reason": "blocked_tool",
  "status": 403
}
Ce que vous configurez

Une surface de contrôle MCP complète, pas juste un proxy

Odock couvre tout ce dont les équipes platform ont besoin pour opérer les serveurs MCP en production : enregistrement des serveurs, configuration du transport et de l'authentification, gouvernance au niveau des outils, tarification, et enregistrements d'utilisation lisibles par votre équipe sécurité.

Vues MCP
Vue sélectionnée

Enregistrez des serveurs depuis un catalogue de confiance ou ajoutez-les manuellement. Vérifiez le transport, la configuration d'authentification, le scope et le statut d'activation avant qu'un agent puisse y accéder.

catalogue-&-configuration.mcp
En direct
github-tools-http
Catalogue de confiance
TransportSTREAMABLE_HTTP
AuthBEARER
Scopeteam:support
Accès12 clés autorisées
internal-ops-sse
Configuration manuelle
TransportSSE
AuthOAUTH2
ScopeapiKey:vk_ops_prod
Accès1 clé autorisée
filesystem-agent
Configuration manuelle
TransportSTDIO
AuthNONE
Scopeorg-wide
Accès4 clés autorisées
slack-tools-http
Catalogue de confiance
TransportSTREAMABLE_HTTP
AuthBEARER
Scopeteam:success
Accès8 clés autorisées
notion-knowledge-http
Catalogue de confiance
TransportSSE
AuthOAUTH2
ScopeapiKey:vk_product_ai
Accès3 clés autorisées
postgres-ops-stdio
Configuration manuelle
TransportSTDIO
AuthNONE
Scopeorg-wide
Accès2 clés autorisées
Un seul endpoint

Vos agents appellent Odock, pas le serveur en amont

Pointez chaque agent vers `/v1/mcp/{slug}`. Odock authentifie l'appelant, confirme les accès, injecte les credentials en amont, exécute les contrôles de gouvernance et enregistre le résultat. Le serveur en amont ne reçoit jamais de requête non gouvernée.

Ce que le gateway gère

  • Appelez n'importe quel serveur par son slug, sans URL en amont dans le code agent.
  • Clé API virtuelle obligatoire avant qu'un outil soit accessible.
  • Auth en amont injectée après validation des contrôles de gouvernance.
  • HTTP, SSE et STDIO via un seul endpoint gouverné.
tools-list.sh
1# Appeler Odock plutôt que le serveur MCP en amont
2curl "$ODOCK_GATEWAY_URL/v1/mcp/github-tools-http" \
3 -H "Authorization: Bearer $ODOCK_API_KEY" \
4 -H "Content-Type: application/json" \
5 -d '{
6 "jsonrpc": "2.0",
7 "id": "tools-list-1",
8 "method": "tools/list",
9 "params": {}
10 }'
FAQ

Les questions que les équipes posent sur les passerelles MCP

Ce sont les questions récurrentes qui émergent lorsque les équipes passent d'un accès direct aux serveurs MCP à une couche de passerelle gouvernée.

Vos agents ont besoin d'une passerelle, pas juste d'un proxy

Si vos agents peuvent appeler des outils, vous avez besoin du même niveau de contrôle que vous attendez déjà pour le trafic de modèles. Odock gouverne les deux depuis un seul chemin de requête.

tools-list.sh
# Appeler Odock plutôt que le serveur MCP en amontcurl "$ODOCK_GATEWAY_URL/v1/mcp/github-tools-http" \  -H "Authorization: Bearer $ODOCK_API_KEY" \  -H "Content-Type: application/json" \  -d '{    "jsonrpc": "2.0",    "id": "tools-list-1",    "method": "tools/list",    "params": {}  }'