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, 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?
The readOnlyHint annotation already marks this as safe, and the description adds useful behavioral context by stating it reports credential validity, auth method, endpoint, project/region, and write status. It also says missing credentials explain absent tools, which clarifies what the status check means. It doesn't explicitly describe network/read behavior, but the annotation plus 'report' wording make the safety profile clear.
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 carry a full purpose statement, a detailed list of outputs, and a usage rule. The key diagnostic trigger ('Call this first when a tool you expected is not listed') is placed second and is memorable. No word is wasted.
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?
For a tool with no parameters, no siblings, and no output schema, the description is self-sufficient: it tells the agent what information the tool produces and when to invoke it. The only omitted detail, the exact configuration values to set, is precisely what the tool's output is described as providing.
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?
There are zero parameters, so there is nothing to document beyond the empty schema. The description still clarifies the kind of status data returned, which is consistent with a no-input diagnostic tool. Baseline 4 is appropriate for a 0-parameter definition.
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?
The description opens with a specific verb and resource: 'Report whether this server has working OVHcloud credentials,' then enumerates exactly what is reported (auth method, endpoint, default project/region, write enablement). This is unambiguous and fully distinguishes the tool from any conceivable alternative, even though no siblings are listed.
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?
It gives an explicit call heuristic: 'Call this first when a tool you expected is not listed,' and even frames the diagnostic interpretation ('an absent tool here means missing configuration, not a bug'). This tells an agent not only when to run it but how to interpret the result.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
With only one tool, there is no possibility of confusion between tools. The single tool's purpose is clearly defined and distinct.
The lone tool name follows a clean snake_case verb_noun pattern. With only one tool, there are no inconsistencies to evaluate.
A single status-check tool is drastically insufficient for a server named 'mcp-ovh-api' covering the OVH cloud API. The count represents an extreme mismatch between the server's implied scope and its actual surface.
The server exposes no operations beyond an authentication status check. Any actual OVH API functionality is absent, making the tool surface severely incomplete for the stated domain.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
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.
MCP server for Product Management
Related MCP Servers
- AlicenseAqualityDmaintenanceMCP server for AWS S3 — list buckets, browse objects, upload/download files, and generate presigned URLs.7904MIT
- AlicenseNot gradedqualityDmaintenanceMCP server for uploading, listing, and retrieving files on S3-compatible storage (AWS S3, DigitalOcean Spaces) with public/private access and temporary URLs.15MIT
- FlicenseNot gradedqualityCmaintenanceRead-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.
- AlicenseAqualityDmaintenanceMCP server for Oracle Cloud Infrastructure (OCI) that provides tools to manage Compute, Object Storage, Block Storage, Networking, Autonomous Database, and IAM via the official OCI SDK.2367MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mgcrea/mcp-ovh'
If you have feedback or need assistance with the MCP directory API, please join our Discord server