OCI MCP Server: Compute, Autonomous DB, Storage
Manage OCI with the MCP server: Python-based control for Compute, Autonomous DB and Object Storage, read-heavy with safe start/stop/reset actions.
npx -y @karthiksuku/oci-mcpOverview
The OCI MCP Server is a lightweight Python-based service for managing Oracle Cloud Infrastructure (OCI) resources using a Model Context Protocol (MCP) style API. It focuses on three core resource families — Compute instances, Autonomous Databases, and Object Storage — and exposes safe, read-heavy endpoints for querying state and performing limited lifecycle operations like start, stop, and reset. The design emphasizes predictable operations and avoids destructive actions such as delete, making it suitable for automation pipelines and tooling that need to control resource state without broad privileges.
This server is useful for developers and automation engineers who want a small, self-hosted control plane for OCI resources. You can deploy it alongside CI/CD tooling, use it behind an internal API gateway, or integrate it into chatops and model-based orchestration systems that need programmatic access to instance and database lifecycle operations as well as object listing and retrieval.
Features
- Manage OCI Compute (instances): list, get details, start, stop
- Manage OCI Autonomous Database: list, get details, start, stop, reset
- Access OCI Object Storage: list buckets, list objects, get object metadata and download
- Read-heavy API design: most endpoints are safe GETs; state-changing endpoints are limited to start/stop/reset
- Authentication via standard OCI practices (config file, environment, instance principal)
- Simple HTTP JSON endpoints suitable for automation and integration
- Optional dry-run mode and structured logging for safe operations
Installation / Configuration
Prerequisites:
- Python 3.8+
- OCI Python SDK
- OCI credentials (config file at ~/.oci/config or instance principal)
Clone and install:
Configuration (example yaml):
# config.yaml
oci:
auth_type: config_file # or instance_principal
config_file: ~/.oci/config
profile: DEFAULT
region: us-ashburn-1
server:
host: 0.0.0.0
port: 8080
dry_run: true # set false to actually perform lifecycle changes
log_level: INFO
compartment_id: ocid1.compartment.oc1..example
Start the server:
# direct run (example)
Run via Docker (example):
Available Resources
The MCP server exposes a small set of HTTP endpoints. All responses are JSON. Example endpoints and supported actions:
| Resource | Endpoint | Methods | Notes |
|---|---|---|---|
| Compute list | GET /mcp/compute | GET | List instances in configured compartment |
| Compute details | GET /mcp/compute/{instanceId} | GET | Get instance metadata and lifecycle state |
| Compute action | POST /mcp/compute/{instanceId}/action | POST | Body: {“action”:“start” |
| Autonomous DB list | GET /mcp/autonomous | GET | List Autonomous DBs |
| Autonomous DB details | GET /mcp/autonomous/{dbId} | GET | Get DB metadata |
| Autonomous DB action | POST /mcp/autonomous/{dbId}/action | POST | Body: {“action”:“start” |
| Buckets | GET /mcp/storage/buckets | GET | Lists buckets in compartment and namespace |
| Objects | GET /mcp/storage/buckets/{bucket}/objects | GET | Lists objects; supports prefix query param |
| Object download | GET /mcp/storage/buckets/{bucket}/objects/{object} | GET | Streams object |
Example request bodies for actions:
Use Cases
CI/CD instance management
- Scenario: A deployment pipeline needs to start a compute instance to run heavy integration tests and then stop it.
- Example:
Scheduled DB resets for testing
- Scenario: A QA workflow resets an Autonomous DB snapshot nightly to a clean state.
- Example:
Read-only reporting and audits
- Scenario: An operations dashboard lists instances, DBs, and storage usage without risk of accidental mutation.
- Example:
Programmatic object access for models
- Scenario: An ML training pipeline retrieves input data from Object Storage via the MCP API instead of direct SDK calls, centralizing access and audit.
- Example (download):
Notes and Best Practices
- The server is intentionally read-heavy and conservative about changes; enable dry_run=false only after validating in a safe environment.
- Use OCI least-privilege policies for the credentials used by the server (only allow list/read and manage actions on required resources).
- Place the MCP server behind an authenticated gateway when exposing it to users or automation to control who can perform state-changing calls.
Source code and issues: https://github.com/karthiksuku/oci-mcp