Chaque workflow, un outil.

Le serveur MCP writ-cloud transforme votre compte en outils qu’un agent IA peut appeler : vingt-cinq outils intégrés pour les workflows, les données, les crawls, les moniteurs et les automatisations — plus un outil par workflow enregistré. L’authentification est une clé API wt_.

connexion ▸ une seule url

Un serveur pour tout le compte.

Le transport est Streamable HTTP : chaque message est un POST vers /mcp sur api.usewrit.app — JSON-RPC 2.0, un objet unique ou un tableau batch par requête. GET /mcp est une sonde de santé. Authentifiez-vous avec Authorization: Bearer et une clé API wt_ ; cet endpoint n’accepte pas OAuth.

{
  "mcpServers": {
    "writ-cloud": {
      "type": "http",
      "url": "https://api.usewrit.app/mcp",
      "headers": {
        "Authorization": "Bearer wt_xxxxxxxxxxxx"
      }
    }
  }
}

# Confirm the server is reachable and see the tools it exposes
curl -X POST https://api.usewrit.app/mcp \
  -H "Authorization: Bearer $WRIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc": "2.0", "id": 1, "method": "tools/list"}'

outils ▸ vingt-cinq intégrés

Vingt-cinq outils, sur chaque compte.

Le jeu intégré couvre la boucle qu’un agent exécute réellement : trouver un workflow, l’exécuter, lire et chercher ce qu’il a collecté, le planifier, l’exposer, crawler, surveiller, automatiser.

outils ▸ un par workflow

Chaque workflow enregistré est son propre outil.

tools/list porte aussi un outil run_<name> par workflow enregistré, son schéma d’entrée dérivé des entrées déclarées du workflow. Les noms sont slugifiés ; une collision se dédouble en _2, _3 ; les noms intégrés writ_* gagnent toujours. Chaque outil de run accepte les trois mêmes contrôles :

règles ▸ pas de porte dérobée

Un appel d’outil est un appel d’API.

MCP ajoute un protocole, pas une porte dérobée. Chaque appel d’outil s’exécute exactement sous les règles de l’API REST appelée avec la même clé : isolation du tenant, scopes de la clé, limites du plan et facturation s’appliquent sans changement.

publication ▸ /mcp/{slug}

Des serveurs publiés sur /mcp/{slug}.

La publication crée aussi des serveurs MCP autonomes sur /mcp/{slug} — Streamable HTTP sur POST /mcp/{slug}, avec SSE en option sur GET /mcp/{slug}/sse. Ils acceptent une clé wt_ ou un token d’accès OAuth : vous confiez un workflow à un client sans lui confier une clé de compte.

OAuth pour les clients MCP

Un appel refusé répond avec WWW-Authenticate dont le resource_metadata pointe vers …/.well-known/oauth-protected-resource/mcp/{slug} — la découverte OAuth standard de MCP. Les métadonnées du serveur d’autorisation vivent sur GET /api/oauth/.well-known/oauth-authorization-server, et les clients s’enregistrent eux-mêmes via l’enregistrement dynamique RFC 7591 sur POST /api/oauth/register — clients publics PKCE uniquement, sans client secret. Conçu pour les connecteurs personnalisés de Claude, Cursor et tout client qui parle ce flux.

Configuration d’un outil

Chaque outil publié est un petit contrat ; le slug du serveur est toujours dérivé du nom.

Les outils MCP publiés sont plafonnés par plan (la limite max_mcp_tools) — un plafond sur le nombre d’outils publiés, jamais sur la fréquence de leurs appels :

faq

Questions MCP, répondues.

référence ▸ suite

Continuez le câblage.