mcp-ovh-api
@mgcrea/mcp-ovh-api
Un servidor Model Context Protocol para la API de OVHcloud, centrado en Object Storage: buckets, objetos, usuarios de proyecto, credenciales S3 y las políticas de almacenamiento que los unen.
El servidor es de solo lectura por defecto. Las herramientas de mutación no solo se rechazan cuando los escritos están desactivados — nunca se registran, por lo que un agente no puede llamarlas en absoluto.
Características
Herramientas seleccionadas sobre la API
/1.0de OVHcloud con descripciones que explican sus trampas (ver Trampas que conviene conocer).Solo lectura por defecto.
OVH_ALLOW_WRITES=1añade las herramientas de escritura; las destructivas requieren además unconfirm: trueexplícito en cada llamada.Los tres métodos de autenticación de OVH, elegidos automáticamente según las variables de entorno presentes: cuenta de servicio OAuth2 (recomendada), clave de aplicación + clave de consumidor (firmada con SHA1, con corrección automática de desviación de reloj), o un token de acceso estático.
Presets de políticas — incluyendo
write-only, que el atajo de roles de OVH no ofrece.Los resultados de listas se resumen, y el array
objects[]obsoleto por bucket de OVH (que incrusta todos los objetos del bucket) se suprime en ambos extremos.X-Ovh-QueryIDse muestra en cada error, porque es lo primero que pide el soporte de OVH.Una vía de escape
ovh_requestpara el resto de la API (solo GET a menos que los escritos estén habilitados).fetchnativo, sin dependencias de ejecución más allá del SDK de MCP y Zod.
Related MCP server: saveformedearai
Instalar
pnpm install
pnpm buildConfigurar
Elige un método de autenticación.
(A) Cuenta de servicio OAuth2 — recomendada
Crea una cuenta de servicio IAM en https://www.ovh.com/manager/#/iam/service-account.
Adjunta una política IAM que le conceda tu proyecto de cloud público (para object storage:
publicCloudProject:apiovh:*en el recurso del proyecto).Copia el client id y el secreto en
.env.
Los tokens duran una hora y se almacenan en caché y se renuevan antes de que expiren.
(B) Clave de aplicación + clave de consumidor
Crea el trío de una sola vez en https://eu.api.ovh.com/createToken/. Las reglas de acceso que enumeres allí quedan fijas para siempre — una clave de consumidor no se puede ampliar después, así que concede lo que necesites desde el principio:
GET /cloud/project/*
POST /cloud/project/*
PUT /cloud/project/*
DELETE /cloud/project/*
GET /meLas solicitudes se firman con SHA1 sobre secret+consumerKey+METHOD+URL+BODY+TIMESTAMP. Un reloj
más de ~30s desviado del de OVH hace fallar todas las llamadas con un engañoso Invalid signature,
por lo que el servidor sondea /auth/time una vez al inicio y corrige la diferencia.
(C) Token de acceso estático
Establece OVH_ACCESS_TOKEN y se envía como Authorization: Bearer.
cp .env.example .envVariable | ¿Requerida? | Descripción |
| no |
|
| (A) | Cuenta de servicio IAM. Su presencia selecciona OAuth2. |
| (B) | Par de claves de aplicación. |
| (B) | Clave de consumidor emitida junto a ellas. |
| (C) | Token de portador pre-generado. |
| no | Forzar |
| no | Proyecto por defecto — el |
| no | Región de almacenamiento por defecto, en mayúsculas ( |
| no | Establecer a |
| no | Sobrescribir la URL base de la API por completo. |
| no | Presupuesto de reintentos para 401 / 429 / 5xx. Por defecto |
| no | Renovar el token OAuth2 este tiempo antes de que expire. Por defecto |
| no | Establecer a |
Ejecutar
pnpm start # speaks JSON-RPC over stdioConectar con Claude Code
Añade a .mcp.json (proyecto) o ~/.claude.json (global):
{
"mcpServers": {
"ovh": {
"command": "node",
"args": ["/absolute/path/to/mcp-ovh-api/dist/cli.js"],
"env": {
"OVH_CLIENT_ID": "...",
"OVH_CLIENT_SECRET": "...",
"OVH_CLOUD_PROJECT": "abcdef0123456789abcdef0123456789",
"OVH_REGION": "UK"
}
}
}
}Inspeccionar las herramientas
npx @modelcontextprotocol/inspector node dist/cli.jsTrampas que conviene conocer
Todas están integradas en las descripciones de las herramientas, pero explican la forma de este servidor:
OVH no tiene políticas de bucket — solo políticas de usuario. Un único documento JSON en bruto por usuario de proyecto, y ese documento es toda la superficie de control de acceso. Establecer una política reemplaza todo lo que ese usuario podía hacer antes, en todos los buckets.
Una política no puede restringir al propietario del bucket. OVH recurre a las ACL y el propietario tiene
FULL_CONTROL: "si el usuario es el propietario del bucket y aunque no haya un allow explícito en el archivo de política, el usuario estará autorizado". Por lo tanto, una clave restringida debe pertenecer a un nuevo usuario de proyecto que no haya creado el bucket.ovh_provision_s3_usercomprueba elownerIddel bucket y se niega cuando lo apuntas al propietario.La misma regla se aplica por objeto. Quien sube un objeto lo posee y obtiene
FULL_CONTROLsobre él a través de la ACL del objeto. Así que simplemente omitirs3:GetObjectno impide que una clave de solo subida pueda leer todo lo que escribió — verificado contra la API en vivo, donde una política de lista de allows desnuda servía a la clave sus propias subidas mientras denegaba correctamente todos los objetos que otro había subido. UnDenyexplícito es necesario, y sí supera a la ACL. Por eso el presetwrite-onlyincluye una declaraciónDenyen lugar de una lista de allows desnuda.
Dos más pequeñas. s3:PutObject solo aún permite la sobrescritura ciega de claves existentes
dentro del prefijo permitido — una clave "write-only" no es una clave de solo añadir, lo cual es una
buena razón para activar el versionado en el bucket. Y los cambios de política tardan hasta ~30
segundos en propagarse: una prueba ejecutada cinco segundos después de ovh_set_storage_policy
todavía muestra el comportamiento anterior, lo que se lee exactamente como una política que falló
en silencio.
Herramientas
Cada herramienta con ámbito de proyecto acepta un project opcional, y cada herramienta de
almacenamiento un region opcional, sobrescribiendo OVH_CLOUD_PROJECT / OVH_REGION por llamada.
Las herramientas marcadas con W existen solo cuando OVH_ALLOW_WRITES=1; las marcadas con ⚠️ son
destructivas y además requieren confirm: true.
Empieza con ovh_whoami. Informa de qué método de autenticación está activo, qué cuenta eres y
la diferencia de reloj con OVH — que es de lo que casi siempre trata un 401 en el método de firma.
Área | Herramientas |
Meta |
|
Buckets |
|
Objetos |
|
Usuarios y claves |
|
Políticas |
|
Vía de escape |
|
ovh_presign_object es la única forma de mover bytes: el servidor nunca hace de proxy del contenido
de los objetos, sino que genera una URL S3 presignada con límite de tiempo. Con los escritos desactivados
firma solo GET.
Presets de políticas
ovh_preview_policy, ovh_set_storage_policy y ovh_provision_s3_user comparten tres presets,
todos acotables a un prefijo de clave:
Preset | Concesiones |
| Permitir |
|
|
| ambos, más |
Los roles integrados de OVH (admin, deny, readOnly, readWrite, vía ovh_grant_bucket_access)
no tienen equivalente de solo escritura — por eso existe la ruta de política en bruto. El par de
multipart se incluye deliberadamente: todo SDK de S3 cambia automáticamente a multipart por encima de
~8-16MB, y sin abort/list una subida fallida deja partes huérfanas que el titular de la clave no puede
limpiar y por las que sigue pagando.
OVH valida las acciones de las políticas contra un enum fijo y rechaza el documento completo con
un 400 si una es desconocida — s3:GetObjectVersion y s3:DeleteObjectVersion existen en AWS pero
no allí. Los presets usan solo acciones aceptadas, y una prueba lo fija.
Entregar una clave de subida de solo escritura
El caso motivador: una aplicación incrusta una clave S3 en un binario distribuido, por lo que la clave debe poder subir y nada más, mientras que la clave de lectura/escritura queda en manos del desarrollador.
ovh_get_bucket bucket=dev-rgis-ar → note ownerId
ovh_preview_policy bucket=dev-rgis-ar preset=write-only prefix=uploads/
ovh_provision_s3_user bucket=dev-rgis-ar preset=write-only prefix=uploads/ \
description=ar-app-uploader confirm=trueEso crea un nuevo usuario de proyecto (nunca el propietario del bucket), aplica la política, y solo entonces genera credenciales — una clave que existe antes de su política es una clave que brevemente tuvo lo que el valor por defecto permita. El secreto se devuelve una sola vez.
Verifica contra la API S3 real antes de entregarla — una política que se lee correctamente puede seguir siendo ensombrecida por la propiedad, y espera ~30s después de establecerla o estarás probando la política anterior:
export AWS_ACCESS_KEY_ID=... AWS_SECRET_ACCESS_KEY=...
# An array, not a string: zsh does not word-split an unquoted $var, so the
# `S3='aws ...'` form you would write in bash silently becomes "command not found".
S3=(aws --endpoint-url https://s3.uk.io.cloud.ovh.net --region uk s3api)
"${S3[@]}" put-object --bucket dev-rgis-ar --key uploads/probe.txt --body /dev/null # 200
"${S3[@]}" get-object --bucket dev-rgis-ar --key uploads/probe.txt /dev/null # 403
"${S3[@]}" list-objects-v2 --bucket dev-rgis-ar # 403
"${S3[@]}" delete-object --bucket dev-rgis-ar --key uploads/probe.txt # 403
"${S3[@]}" put-object --bucket dev-rgis-ar --key elsewhere/probe.txt --body /dev/null # 403La línea get-object es la que importa: es la comprobación que detecta la trampa 3, y pasa solo
gracias al Deny del preset.
Desarrollar
pnpm dev # tsdown --watch
pnpm test # vitest
pnpm typecheck
pnpm lint
pnpm formatLicencia
MIT
Available Tools
1 toolovh_auth_statusOVHcloud: Auth StatusARead-only
Report whether this server has working OVHcloud credentials, which auth method and endpoint it uses, the default project and region, whether writes are enabled, the OVH_SECRET_DIR that secretFile paths are confined to, and — when something is missing — exactly what to set. Call this first when a tool you expected is not listed: an absent tool here means missing configuration, not a bug.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say readOnlyHint=true; the description adds real substance on top: the full set of reported facts, the confinement of `secretFile` paths to OVH_SECRET_DIR, the write-enabled flag, and prescriptive remediation ("exactly what to set") when something is missing. That is behavior an agent could not infer from the annotation alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler, with the diagnostic use case front-loaded after the enumeration. The first sentence is dense with comma-separated items but every item is a distinct reported fact that earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description carries the return-value burden — and it does so by enumerating every reported field plus the remediation behavior for missing config. For a zero-parameter, read-only diagnostic tool this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter semantics to explain; baseline applies. The description correctly spends none of its length on inputs and instead covers what the no-arg call reports.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Uses a specific verb ("report") with a precisely enumerated payload: credential validity, auth method, endpoint, default project/region, write-enablement, and the OVH_SECRET_DIR constraint. An agent knows exactly what this tool returns and why it exists without consulting other fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger — "Call this first when a tool you expected is not listed" — plus the interpretation rule that an absent tool means missing configuration, not a bug. It stops short of stating when *not* to call it (e.g., routine polling), so it lands just under a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.1.0- First observed
ovh_auth_status
TDQS
Scored across 1 tool
There is only one tool, so there is no possibility of confusing it with another. Its purpose is clearly stated as an authentication/configuration diagnostic.
The single tool name `ovh_auth_status` follows a clear snake_case domain-action pattern. With only one tool, there is no inconsistency to assess.
The server claims to be an OVHcloud API server but exposes only a single diagnostic tool. This is an extreme mismatch between the broad implied domain and the one available operation.
The surface contains only an auth-status check and no OVHcloud resource operations such as listing projects, managing instances, or any CRUD lifecycle. It is effectively a diagnostic stub rather than a usable API toolset.
Maintenance
Related MCP Connectors
An MCP server for the STRG.com s3-compatible object storage network for all management operations
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Governed MCP gateway: one endpoint for your tools, with credential custody and audit log.
Read-only MCP server for AIStatusDashboard status, incidents, metrics, and fallback recommendations.
Related MCP Servers
- AlicenseAqualityFmaintenanceMCP server for AWS S3 — list buckets, browse objects, upload/download files, and generate presigned URLs.7103 npm4MIT
- AlicenseAqualityDmaintenanceMCP server for uploading, listing, and retrieving files on S3-compatible storage (AWS S3, DigitalOcean Spaces) with public/private access and temporary URLs.40MIT
- FlicenseNot gradedqualityDmaintenanceRead-only MCP server for browsing and reading S3 objects, with tools for listing buckets/objects, reading text and binary files, and extracting text from PDFs.-
- AlicenseAqualityAmaintenanceEnables management of Scaleway IAM (applications, API keys, policies, permission sets) and Object Storage bucket policies through an MCP server.11726 npmMIT