Integration with OVH Nutanix services, allowing management of Nutanix clusters.
Integration with OVH cloud services, providing tools to manage dedicated servers, VPS, cloud projects, billing, IP addresses, load balancers, SSL certificates, DBaaS Logs, and more.
Integration with OVH Veeam Cloud Connect, allowing management of backup and disaster recovery services.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-server-ovh list my dedicated servers"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that provides standardized access to OVH API services. This server enables AI assistants and applications to interact with OVH's cloud infrastructure through a unified, secure interface.
Author: Isaac Campos Mesén Company: RunIT Solutions Repository: GitHub - runitsolutions/mcp-server-ovh
Related MCP server: RL-MCP
Status: 🟢 FULLY OPERATIONAL & TESTED
✅ Build: TypeScript compilation successful
✅ Runtime: Server starts without errors
✅ Schema Validation: Input validation working correctly
✅ MCP Integration: Compatible with MCP clients
✅ CommonJS: Uses require() for module loading
✅ TypeScript: Full type safety with proper declarations
✅ API Endpoints Verified: All endpoints tested against OVH Console
✅ Documentation Updated: README reflects verified endpoints
Last Verified: $(date) OVH Console: https://eu.api.ovh.com/console/
/me - User information ✅
/me/bill - Billing information ✅
/me/payment/method - Payment methods ✅
/service - Services list ✅
/services - Services list (plural) ✅
/dedicated/server - Dedicated servers ✅
/vps - VPS instances ✅
/me/order - Orders ✅
/me/api/application - API applications ✅
/cloud/project - Cloud projects ✅
/ip - IP addresses ✅
/ipLoadbalancing - Load balancers ✅
/dedicatedCloud - Dedicated Cloud ✅
/metrics - Metrics ✅
/license/windows - Windows licenses ✅
/dbaas/logs - DBaaS Logs ✅
/ssl - SSL certificates ✅
/vrack - vRack ✅
/veeamCloudConnect - Veeam Cloud Connect ✅
/nutanix - Nutanix ✅
/me/services - Requires specific API permissions
/domain - Requires domain management permissions
/me/api/logs - Requires audit log permissions
/hosting/web - Requires web hosting permissions
/email/domain - Requires email permissions
/sms - Requires SMS permissions
🔐 Secure Authentication: Support for both API key and OAuth2 authentication methods
🛠️ Standardized Tools: Clean MCP tool interfaces for common OVH operations
✅ Input Validation: Robust validation using Zod schemas
🚀 Modern API: Built with the latest MCP SDK following best practices
📝 TypeScript: Full TypeScript support with strict type checking
🧪 Well Tested: Comprehensive test suite with Jest
📚 Well Documented: Complete documentation and examples
Node.js 18.x or higher
npm or yarn
OVH API credentials (see Setup section)
npm install mcp-server-ovhgit clone https://github.com/runitsolutions/mcp-server-ovh.git
cd mcp-server-ovh
npm install
npm run buildYou need to obtain API credentials from OVH. There are two authentication methods:
Go to OVH Manager
Navigate to API Keys section
Create a new application key
Note down your App Key, App Secret, and Consumer Key
Register your application in OVH's OAuth2 system
Obtain your Client ID and Client Secret
Create a .env file in your project root:
# For API Key authentication
OVH_ENDPOINT=ovh-eu
OVH_APP_KEY=your_app_key_here
OVH_APP_SECRET=your_app_secret_here
OVH_CONSUMER_KEY=your_consumer_key_here
# For OAuth2 authentication (alternative)
OVH_CLIENT_ID=your_client_id_here
OVH_CLIENT_SECRET=your_client_secret_hereThe server communicates via stdio and can be used with any MCP-compatible client.
npm startThe server is designed to work with MCP-compatible clients like Claude Desktop or other AI assistants that support the Model Context Protocol.
Initialize the OVH API client with your credentials.
{
"name": "ovh_initialize_client",
"arguments": {
"endpoint": "ovh-eu",
"appKey": "your_app_key",
"appSecret": "your_app_secret",
"consumerKey": "your_consumer_key"
}
}Initialize with OAuth2 credentials.
{
"name": "ovh_oauth2_initialize",
"arguments": {
"endpoint": "ovh-eu",
"clientID": "your_client_id",
"clientSecret": "your_client_secret"
}
}Make a custom request to any OVH API endpoint.
{
"name": "ovh_request",
"arguments": {
"method": "GET",
"path": "/me",
"data": {} // Optional data for POST/PUT requests
}
}Get information about the authenticated user.
{
"name": "ovh_get_user_info",
"arguments": {}
}Retrieve billing information.
{
"name": "ovh_get_bills",
"arguments": {}
}List all services associated with the account.
{
"name": "ovh_get_services",
"arguments": {}
}Retrieve available payment methods for the account.
{
"name": "ovh_get_payment_methods",
"arguments": {}
}List all orders placed with OVH.
{
"name": "ovh_get_orders",
"arguments": {}
}List all cloud projects associated with the account.
{
"name": "ovh_get_cloud_projects",
"arguments": {}
}List all dedicated servers in the account.
{
"name": "ovh_get_dedicated_servers",
"arguments": {}
}List all VPS instances in the account.
{
"name": "ovh_get_vps",
"arguments": {}
}List all IP addresses associated with the account.
{
"name": "ovh_get_ips",
"arguments": {}
}Get vRack network information.
{
"name": "ovh_get_vrack",
"arguments": {}
}List all load balancers in the account.
{
"name": "ovh_get_load_balancers",
"arguments": {}
}List all SSL certificates.
{
"name": "ovh_get_ssl_certificates",
"arguments": {}
}List all DBaaS Logs services.
{
"name": "ovh_get_dbaas_logs",
"arguments": {}
}This MCP server can be integrated with various IDEs and editors that support the Model Context Protocol. Below are the instructions for popular IDEs.
Cursor supports MCP servers through the Model Context Protocol. You can add this OVH MCP server to your Cursor configuration.
Create a .cursor/mcp.json file in your project root:
{
"mcpServers": {
"ovh-api": {
"command": "npx",
"args": ["mcp-server-ovh"],
"env": {
"OVH_ENDPOINT": "ovh-eu",
"OVH_APP_KEY": "your_app_key_here",
"OVH_APP_SECRET": "your_app_secret_here",
"OVH_CONSUMER_KEY": "your_consumer_key_here"
}
}
}
}Create a ~/.cursor/mcp.json file for system-wide access:
{
"mcpServers": {
"ovh-api": {
"command": "npx",
"args": ["mcp-server-ovh"],
"env": {
"OVH_ENDPOINT": "ovh-eu",
"OVH_APP_KEY": "your_app_key_here",
"OVH_APP_SECRET": "your_app_secret_here",
"OVH_CONSUMER_KEY": "your_consumer_key_here"
}
}
}
}If you're using VS Code with an MCP extension:
Install the MCP extension for VS Code
Configure the server in your MCP settings:
{
"server": "ovh-api",
"command": "npx",
"args": ["mcp-server-ovh"],
"env": {
"OVH_ENDPOINT": "ovh-eu",
"OVH_APP_KEY": "your_app_key_here",
"OVH_APP_SECRET": "your_app_secret_here",
"OVH_CONSUMER_KEY": "your_consumer_key_here"
}
}For other IDEs that support MCP:
Ensure your IDE supports the Model Context Protocol
Configure the server using the command: npx mcp-server-ovh
Set the required environment variables for OVH authentication
Before using the MCP server, you need to set up OVH API credentials:
# Set environment variables
export OVH_ENDPOINT="ovh-eu"
export OVH_APP_KEY="your_app_key"
export OVH_APP_SECRET="your_app_secret"
export OVH_CONSUMER_KEY="your_consumer_key"Or create a .env file in your project directory:
OVH_ENDPOINT=ovh-eu
OVH_APP_KEY=your_app_key_here
OVH_APP_SECRET=your_app_secret_here
OVH_CONSUMER_KEY=your_consumer_key_hereOnce configured, you can use the OVH MCP server in your IDE by:
Asking for OVH information: "What services do I have in OVH?"
Checking account details: "Show my OVH account information"
Billing inquiries: "What are my recent OVH bills?"
Service management: "List all my OVH services"
The AI assistant will automatically use the available OVH tools when relevant to your questions.
src/
├── index.ts # Main server implementation
├── types/
│ └── ovh.d.ts # OVH API type definitions
└── __tests__/ # Test files
├── server.test.ts # Server functionality tests
└── validation.test.ts # Input validation tests# Install dependencies
npm install
# Build the project
npm run build
# Run in development mode (watch mode)
npm run dev
# Run linter
npm run lint
# Fix linting issues
npm run lint:fix
# Run tests (organized by type)
npm test # All tests
npm run test:unit # Unit tests
npm run test:integration # Integration tests
npm run test:e2e # End-to-end tests
# Specific tests
npm run test:endpoints # Verify OVH endpoints
npm run test:server # MCP server tests
npm run test:client # MCP client tests
npm run test:full # Complete integration tests
# Coverage and watch mode
npm run test:coverage # Tests with coverage report
npm run test:watch # Tests in watch mode
# Clean build artifacts
npm run cleanThe test suite is organized in 4 levels:
tests/unit/ - Unit TestsZod schema validation
MCP server functions
Error handling
Response parsing
tests/integration/ - Integration TestsOVH API connectivity
Endpoint verification (17/17 ✅)
Client-server communication
Authentication
tests/e2e/ - End-to-End TestsComplete initialization flow
Full MCP communication
Real tool calls
Response handling
tests/utils/ - UtilitiesTest configuration
Common helpers
Mock clients
# All organized tests
npm test # Complete suite
npm run test:unit # Unit tests only
npm run test:integration # Integration tests only
npm run test:e2e # End-to-end tests only
# Tests by specific functionality
npm run test:endpoints # Verify 17 OVH endpoints
npm run test:server # Server functionality
npm run test:client # MCP client
npm run test:full # Complete integration
# With coverage and watch
npm run test:coverage # Coverage report
npm run test:watch # Watch modeThis project follows strict code quality standards:
ESLint: Configured with TypeScript rules
Prettier: Code formatting (can be added if needed)
Jest: Comprehensive test suite
TypeScript: Strict mode enabled
Pre-commit hooks: Quality checks before commits
The server provides access to OVH's REST API endpoints through both dedicated tools and generic requests:
/me - User account information
/me/bill - Billing information
/me/payment/method - Payment methods
/me/order - Order history
/me/api/application - API applications
/service - Service listings
/services - Service listings (plural)
/cloud/project - Cloud projects
/dedicated/server - Dedicated servers
/vps - VPS instances
/ip - IP addresses
/ipLoadbalancing - Load balancers
/dedicatedCloud - Dedicated Cloud
/metrics - Metrics services
/license/windows - Windows licenses
/dbaas/logs - DBaaS Logs services
/ssl - SSL certificates
/vrack - vRack network
/veeamCloudConnect - Veeam Cloud Connect
/nutanix - Nutanix services
Any OVH API endpoint via the ovh_request tool
Full OVH API compatibility through the console: https://eu.api.ovh.com/console/
/me/services - Requires additional API permissions
/domain - Requires domain management permissions
/hosting/web - Requires web hosting permissions
/email/domain - Requires email permissions
/sms - Requires SMS permissions
The server provides clear error messages for:
Authentication failures
Invalid input validation
API rate limits
Network connectivity issues
Invalid API responses
Be aware of OVH API rate limits. The server includes error handling for rate limit scenarios but doesn't implement automatic retry logic.
Contributions are welcome! Please follow these steps:
Fork the repository
Create a feature branch: git checkout -b feature/amazing-feature
Commit your changes: git commit -m 'Add amazing feature'
Push to the branch: git push origin feature/amazing-feature
Open a Pull Request
Follow the existing code style
Add tests for new features
Update documentation as needed
Ensure all tests pass before submitting PR
Use conventional commit messages
Never commit API credentials to version control
Use environment variables for sensitive data
The server validates all inputs to prevent injection attacks
API keys are stored securely and not logged
This project is licensed under the MIT License - see the LICENSE file for details.
Model Context Protocol - The protocol this server implements
OVH API - OVH's official API documentation
MCP SDK - The SDK used to build this server
GitHub Repository - Source code and issues
Error: "OVH client not initialized"
Solution: Ensure all required environment variables are set
Check: Verify your API credentials are correct and have proper permissions
Error: Network timeout or connection failed
Solution: Check your internet connection and OVH endpoint configuration
Check: Verify the OVH_ENDPOINT matches your account region
Error: API access denied
Solution: Ensure your API keys have the necessary permissions
Check: Review OVH Manager API key permissions
Enable debug logging by setting the environment variable:
export DEBUG=mcp-server-ovhView MCP server logs in your IDE:
Open the Output panel (usually Ctrl+Shift+U)
Select "MCP Logs" from the dropdown
Check for connection errors, authentication issues, or server crashes
// In your MCP-compatible IDE
// Ask: "What OVH services do I have?"
// The AI will automatically use the ovh_get_services tool
// Ask: "Show my OVH account information"
// The AI will use the ovh_get_user_info tool
// Ask: "What are my recent OVH bills?"
// The AI will use the ovh_get_bills tool// Custom API calls
// Ask: "Make a custom API call to /me/service/domain.example.com"
// The AI will use the ovh_request tool with appropriate parametersThis project is licensed under the MIT License - see the LICENSE file for details.
Built with ❤️ by RunIT Solutions using the Model Context Protocol
Get user bills
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden for behavioral disclosure. It only states 'Get user bills' without revealing whether bills are ordered, filtered by status, or paginated. The agent gets no safety or side-effect info.
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?
The description is a single, front-loaded sentence of three words. It wastes no space and is perfectly concise for a simple retrieval operation.
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?
Given no output schema and no annotations, the description is insufficient. It does not mention what data is returned (e.g., bill list, totals, dates), leaving the agent without context to interpret results.
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, and the schema coverage is 100% (empty). According to the guidelines, the baseline is 4 when there are no parameters. The description adds no parameter info because none is needed.
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 'Get user bills' clearly states the verb and resource. It is distinct from sibling tools which target specific resources like cloud projects or servers. However, it lacks elaboration on scope or details, so it is not a 5.
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?
No guidance is provided on when to use this tool versus alternatives. The sibling tools list many related getters, but the description does not explain what distinguishes this one or when to prefer it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get cloud projects
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only says 'Get', implying a read operation, but fails to mention authentication requirements, rate limits, pagination, or error behavior. This is a critical gap for safe operation.
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?
The description is very concise at three words, but this brevity sacrifices explanatory power. It lacks structure (e.g., no paragraphs or bullet points). While short, it could be more informative without being lengthy.
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?
Given no output schema and no annotations, the description is the sole source of context. It does not explain what is returned (e.g., list of project IDs or full metadata), error conditions, or scope. This leaves the agent underinformed for a simple list tool.
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 input schema has zero parameters, and schema coverage is trivially 100%. The description adds no parameter information, but none is needed. A score of 3 is appropriate as the baseline expectation is met without added value.
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 states 'Get cloud projects', which clearly identifies the verb and resource. It is specific enough to distinguish from sibling tools like ovh_get_bills or ovh_get_vps, but lacks any additional context about what cloud projects represent in OVH.
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?
No guidance on when to use this tool versus alternatives. The description does not mention prerequisites, common scenarios, or explicitly exclude other tools. The distinction relies entirely on the resource name, which is insufficient for an agent to decide with confidence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get DBaaS Logs services
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description gives no behavioral information (e.g., read-only, authentication needs, return format). The description carries full burden but says nothing beyond the name.
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?
The description is extremely concise but omits essential information about usage and behavior, making it under-specified for reliable agent use.
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?
Despite the tool's simplicity, the description lacks context about return values and how it differs from related tools like ovh_get_services, making it incomplete for informed selection.
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, and schema coverage is trivially 100%. Baseline is 4; no additional parameter information is needed.
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 clearly states the verb 'Get' and the resource 'DBaaS Logs services', distinguishing it from sibling tools that retrieve other OVH resources.
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?
No guidance is provided on when to use this tool versus alternatives like ovh_get_services or other get tools, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get dedicated servers
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as whether the operation is read-only, pagination behavior, required permissions, or error conditions. The agent receives no safety or side-effect information.
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?
The description is a single clear sentence with no wasted words. It is appropriately sized and front-loaded, earning 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?
Despite low complexity (no parameters), the description omits crucial context about the return value (no output schema), potential filtering, or limitations. The agent cannot determine what the tool returns or how to use the result effectively.
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 has zero parameters and the schema description coverage is 100% (empty schema), so the description adds no parameter semantics. Per scoring guidelines, zero parameters warrant a baseline of 4.
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 clearly states the action 'Get' and resource 'dedicated servers', distinguishing it from sibling tools that retrieve other OVH resources. However, it is essentially a restatement of the tool name, adding little new information beyond what is already obvious from the name.
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?
No guidance is provided on when to use this tool versus alternatives like ovh_get_services or ovh_get_vps. There is no mention of context, prerequisites, or when not to use it, leaving the agent without decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get IP addresses
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description provides no behavioral information. It does not disclose whether the tool is read-only, requires specific authorization, or has any side effects. The agent gains no insight into what happens when this tool is called beyond the bare action.
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?
The description is concise at three words, but it is under-specified. While brevity is valued, the lack of additional context or structure means the description does not fully earn its place; it could be expanded to clarify purpose.
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?
Given the tool has no parameters, no output schema, and no annotations, the description fails to provide sufficient context. It does not explain what 'IP addresses' refers to (e.g., public IPs, private IPs, for which services), leaving the agent uncertain about the tool's scope and usefulness.
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 input schema has no parameters, so the description does not need to add parameter meaning. The baseline for zero parameters is 4, and there is no missing information regarding parameters.
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 states the verb 'Get' and resource 'IP addresses', which is minimally clear but vague. It does not specify the scope (e.g., all IPs associated with the account, or for a particular service), nor does it distinguish from sibling tools that might also involve IPs, such as ovh_get_vps.
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?
No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives, nor does it mention any prerequisites or context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get load balancers
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description simply states the action without disclosing behavioral traits such as whether it is a read operation, potential side effects, or output format.
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?
The description is very concise at three words, front-loading the purpose. However, being too terse may sacrifice clarity.
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?
Given no output schema and no annotations, the description is minimally adequate but lacks details on what is returned or any contextual setup needed.
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?
Schema has zero parameters with 100% coverage, so baseline is 3. Description adds no parameter-specific information, but none is needed.
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?
Description 'Get load balancers' clearly states verb and resource, matching the tool name. It is not a tautology and distinguishes from siblings that target different resources.
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?
No usage guidance is provided. The description does not specify when to use this tool over siblings or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get user orders
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It fails to indicate whether the tool is read-only, requires authentication, or has rate limits. The description provides no transparency beyond the basic action.
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?
The description is a single concise sentence with no wasted words. However, it is extremely brief and could be considered under-specified, but it earns its place by stating the core purpose.
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?
Given the simplicity of the tool (no parameters, no output schema, no annotations), the description is minimal. It does not explain what 'orders' refers to or what the tool returns, limiting contextual completeness.
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 input schema has no parameters, so coverage is trivially 100%. With high schema coverage, baseline is 3. The description adds no parameter semantics, but none are needed. It does not explain the output or any implicit behavior, but this is acceptable for a zero-parameter tool.
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 'Get user orders' clearly identifies the action (get) and the resource (orders). While it lacks specificity about what types of orders are involved, it distinguishes itself from sibling tools like ovh_get_bills or ovh_get_services.
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?
No guidance on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions, leaving the agent to infer usage without support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get user payment methods
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden of behavioral disclosure. It implies read-only retrieval but does not mention authentication needs, rate limits, or behavior when no payment methods exist. The minimal description is insufficient for safe tool invocation.
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?
The description is a single sentence, which is concise but lacks structure and added value. It could be slightly more informative without adding length.
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?
Given no output schema and no annotations, the description is incomplete. It does not describe the return format (e.g., list of objects with fields) or pagination, leaving the agent underinformed about the tool's output.
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 no parameters, so schema description coverage is trivially 100%. Per guidelines, baseline is 4 for 0 params. The description adds no parameter-specific info but is acceptable for a parameterless tool.
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 uses a clear verb ('Get') and resource ('payment methods'), indicating the tool retrieves payment methods. However, it does not distinguish from sibling getters like ovh_get_bills or ovh_get_orders, lacking specificity on what constitutes a payment method.
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?
No guidance is provided on when to use this tool versus alternatives (e.g., ovh_get_orders for order-related payment info). The description is too brief to advise on context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get user services
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. 'Get' implies a read operation, but there is no explicit statement about safety, side effects, or return format. The description is minimally informative.
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?
The description is a single sentence, which is concise, but it lacks the detail needed to be informative. It is not verbose, but it also does not provide meaningful content beyond the tool name.
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?
Given the lack of output schema and annotations, the description should explain what 'services' includes. It does not, leaving the agent without enough context to understand the tool's output or purpose relative to siblings.
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 input schema has 0 parameters and 100% coverage, so no parameter documentation is needed. Baseline is 4, and the description does not need to add param details.
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 'Get user services' states a verb and resource but is too vague to differentiate from 12 sibling 'ovh_get_*' tools. It does not specify what 'services' encompasses, leaving the agent unsure whether this covers general services or a specific subset.
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?
No guidance is provided on when to use this tool versus its siblings like ovh_get_vps or ovh_get_ips. The agent receives no context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get SSL certificates
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided and the description is minimal. It does not disclose any behavioral traits such as scope (e.g., per domain or all), required authentication state, or potential effects. The tool appears to be a read operation but lacks details.
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?
The description is very concise (3 words) but under-specified. It is front-loaded, but the lack of detail makes it insufficient for an agent to understand the tool's capabilities.
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?
The tool has no parameters, no output schema, and no annotations, placing the entire burden on the description. The description does not compensate, leaving key details missing (e.g., return format, prerequisites, scope).
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?
With zero parameters and 100% schema coverage, the description adds no additional meaning. Baseline is 4 for zero parameters, but the description is so brief it fails to provide any context about the tool's behavior, reducing it to a score of 3.
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 'Get SSL certificates' clearly states the action and resource, but does not differentiate from sibling tools that retrieve other OVH resources. It is specific enough to convey the general purpose.
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?
No guidance on when to use this tool versus alternatives like ovh_get_bills or ovh_get_cloud_projects. The sibling list is provided but no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current user information
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states a read operation but omits details on authentication requirements, rate limits, or any potential side effects.
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?
The description is extremely concise at four words, front-loading the purpose with no unnecessary text.
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?
Given no output schema and no annotations, the description fails to explain what user information is returned or any other context, making it incomplete for effective use.
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?
With zero parameters, the description adds value by clarifying that the tool returns information about the current user (implicitly authenticated). This baseline is appropriate.
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 'Get current user information' clearly states the verb (get) and resource (user information), and it distinguishes from sibling tools that focus on other resources like bills or services.
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?
The description provides no guidance on when to use this tool versus alternatives like ovh_get_bills or ovh_get_services. There is no mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get VPS instances
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only implies a read operation but does not disclose behavioral traits such as authentication requirements, rate limits, or what happens if no VPS instances exist.
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?
The description is extremely concise at two words. While it is not verbose, it is arguably too terse and could include a brief sentence to improve clarity. It is front-loaded but lacks substance.
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?
Given the simplicity (no parameters, no output schema), the description should at least hint at the returned data or usage context. It does not mention what a VPS instance represents or any output structure, making it incomplete for an agent to understand the full behavior.
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, and schema coverage is 100% trivially. The description adds no parameter meaning, but with no parameters, the baseline is 4. The description is sufficient for this dimension.
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 states 'Get VPS instances', which clearly indicates the verb and resource. However, it does not differentiate this tool from sibling tools like ovh_get_dedicated_servers or ovh_get_cloud_projects, all of which follow the same 'Get X' pattern. The purpose is clear but lacks specificity.
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?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any prerequisites, context, or when not to use it. Sibling tools exist but are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get vRack information
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only says 'Get vRack information' which implies a read operation, but it does not explicitly state read-only behavior or any other behavioral traits.
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?
The description is a single, efficient sentence with no unnecessary words. It is front-loaded and meets the needs of a simple tool.
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?
The tool is simple (no params, no output schema), and the description is adequate. It could mention that vRack is a private network concept, but the current text is sufficient for basic understanding.
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?
No parameters exist (0 params, 100% schema coverage), so description does not need to add parameter meaning. The baseline for zero parameters is 4.
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 clearly states the verb 'Get' and the resource 'vRack information', making it specific and distinguishable from sibling tools that retrieve other resources.
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?
Though no explicit when-to-use or when-not guidance is given, the resource name alone differentiates it from siblings, and the context (vRack) implies when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Initialize OVH API client with credentials
| Name | Required | Description | Default |
|---|---|---|---|
| appKey | Yes | Application key from OVH | |
| endpoint | Yes | OVH API endpoint (ovh-eu, ovh-us, ovh-ca, etc.) | |
| appSecret | Yes | Application secret from OVH | |
| consumerKey | Yes | Consumer key from OVH |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, yet the description fails to disclose important behavioral traits such as idempotency, side effects on global state, or authentication requirements beyond the parameters.
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?
The description is efficient with a single sentence containing no wasted words, but it could be structured to include more context without harming conciseness.
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 an initialization tool with 4 required parameters, the description is minimally complete but lacks context on usage sequence, setup prerequisites, or whether it configures a global client.
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?
Schema coverage is 100% and adequately describes each parameter; the description adds no additional semantic meaning beyond the schema.
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 uses a specific verb 'Initialize' and resource 'OVH API client with credentials', clearly distinguishing it from sibling tools which perform data retrieval operations.
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?
The description implies initialization should occur before other OVH tools, but it does not explicitly state when to use (e.g., 'call once at start') or when not to use (e.g., 'do not call if already initialized').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Initialize OVH API client with OAuth2 credentials
| Name | Required | Description | Default |
|---|---|---|---|
| clientID | Yes | OAuth2 client ID | |
| endpoint | Yes | OVH API endpoint | |
| clientSecret | Yes | OAuth2 client secret |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It does not mention side effects (e.g., setting global client state), idempotency, or authentication requirements beyond the parameters.
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?
The description is a single concise sentence that directly states the tool's purpose with no filler or redundancy.
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?
The description is too brief for a tool with 3 required parameters and no output schema or annotations. It fails to explain that initialization is likely required before other API calls, and does not describe return values or state changes.
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 schema covers 100% of parameters with basic descriptions. The tool description adds no additional meaning beyond 'OAuth2 credentials', so it meets the baseline but does not enhance understanding.
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 clearly states the action ('initialize') and the resource ('OVH API client with OAuth2 credentials'). However, it does not differentiate from the sibling tool 'ovh_initialize_client', which likely serves a similar purpose but with different authentication methods.
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?
No guidance is provided on when to use this tool versus alternatives like 'ovh_initialize_client'. The description lacks context on prerequisites or invocation order.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make a request to OVH API
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | Request data for POST/PUT requests | |
| path | Yes | API path (e.g., /me, /me/bill, /sms) | |
| method | Yes | HTTP method (GET, POST, PUT, DELETE) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description 'Make a request to OVH API' does not disclose side effects, authentication needs, rate limits, or error behavior. This is insufficient for a tool that interacts with an external API.
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?
The description is a single sentence, concise but not front-loaded with critical info. It essentially restates the tool name without adding value, making it less useful despite brevity.
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, and the description does not explain return values or error handling. Given the generic nature of the tool, more context about expected responses is necessary.
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 input schema has 100% coverage with descriptions for all parameters (method, path, data). The tool description adds no additional meaning beyond what the schema provides, so baseline score 3 is appropriate.
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 clearly states 'Make a request to OVH API', which identifies the tool as a generic API request tool. It implicitly distinguishes it from siblings that are specific to certain resources, but it could be more explicit about being a low-level alternative.
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?
No guidance on when to use this generic tool versus specialized siblings like ovh_get_bills or ovh_get_cloud_projects. The description lacks any context about preferred usage or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.1.9ovh_get_billsovh_get_cloud_projectsovh_get_dbaas_logsovh_get_dedicated_serversovh_get_ipsovh_get_load_balancersovh_get_ordersovh_get_payment_methodsovh_get_servicesovh_get_ssl_certificatesovh_get_user_infoovh_get_vpsovh_get_vrackovh_initialize_clientovh_oauth2_initializeovh_requestMost tools target distinct resources (bills, cloud projects, etc.) and are clearly differentiated. However, the generic `ovh_request` tool overlaps with all specific get tools, causing potential confusion for an agent in choosing between them.
All tools follow a consistent `ovh_` prefix. Get tools consistently use `ovh_get_<resource>`, while initialization and request tools use other verbs but still follow the same prefix and underscore pattern, making the naming predictable.
With 16 tools, the server covers a broad set of OVH resources without being overwhelming. This count is well-suited for an API wrapper, providing focused functionality for common operations.
The tool set is heavily skewed toward read-only operations (all get tools) and lacks any specialized write tools (create, update, delete). The generic `ovh_request` tool can fill some gaps but is not a substitute for dedicated CRUD tools. This leaves significant gaps in the expected lifecycle coverage.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
The Telnyx MCP server is an official implementation of the Model Context Protocol that enables AI clients (like Claude Desktop, Cursor, and OpenAI Agents) to interact with Telnyx's telephony, messaging, and AI assistant APIs. It provides comprehensive capabilities including making and managing phone calls, sending SMS/MMS messages, purchasing and configuring phone numbers, creating AI assistants with custom instructions, managing cloud storage buckets, scraping and embedding website content, and handling integration secrets. The server exists as both a local implementation and a remotely hosted version, allowing developers to integrate real-world communication infrastructure directly into AI applications.
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
MCP server for building and testing AI agents with multi-model experimentation and insights.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/runitsolutions/mcp-server-ovh'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
