---
tags: [MCP]
description: "Serveurs MCP restreints par agent via permissions V2 ; piège des tirets, wildcard excalidraw* retenue."
nature: documentation
projects:
  - [[03_PROJETS/VPS-IA]]
type: note
---
# Permissions MCP par agent — restriction catalogue (OpenCode V2)

**Date :** 2026-10-28 · **Statut :** opérationnel

## Objectif

Réduire la consommation de tokens et le bruit de contexte : les serveurs MCP étaient tous actifs pour tous les agents. Or `vps-admin` (agent par défaut) n'utilise que `silverbullet-ai` + shell ; `grist`, `excalidraw`, `excalidraw-maaker` sont réservés à `pkm-manager`.

## Mise en œuvre (OpenCode V2)

- **Syntaxe V2** : bloc `permissions` au frontmatter de l'agent (source de vérité : `80_CONFIG/IA_AGENTS/vps-admin`), avec **wildcards d'action** :
  ```yaml
  permissions:
    - action: grist*
      resource: "*"
      effect: deny
    - action: excalidraw*
      resource: "*"
      effect: deny
  ```
- **Piège identifié** : les actions MCP conservent les tirets du nom du serveur (`excalidraw-maaker_list_diagram_types`). Un motif `excalidraw_maaker_*` (underscore) **ne matche pas** → préfixer par le nom exact du serveur sans underscore : `excalidraw*` couvre les deux serveurs.
- **Code Mode déjà actif** : les schémas d'outils MCP ne sont pas injectés comme outils natifs (défaut V2) ; le catalogue est un index compact avec `search` à la demande.

## Vérification empirique (28/10, session vps-admin)

- ✅ `grist`, `excalidraw`, `excalidraw-maaker` **retirés du catalogue Code Mode** (confirmé après sync + refresh du service).
- ✅ `silverbullet-ai` (11 outils) + `opencode` (8 outils) restent — profil attendu.
- Mécanisme : quand tous les outils d'un serveur sont niés pour un agent, ses instructions sont omises du prompt système.

## Hygiène

- Retrait du champ V1 `enabled: true` de `/var/lib/opencode/opencode.json` (déprécié, V2 = `disabled`).
- `pkm-manager` : aucun changement (tous les accès conservés).

## Garde-fous / à retenir

- Ne jamais réutiliser la syntaxe V1 `tools: {"mcp_xxx": false}`.
- Après toute modification d'agent : `sync-silverbullet.sh` + redémarrage du service/session.
- Le mécanisme permissions ne supprime pas l'accès shell : un agent peut toujours appeler les CLI des outils → la restriction est une **optimisation de contexte**, pas une barrière de sécurité.