Put Recovery Service context in your AI client
When a database team needs a quick view of protection health, redo shipping, backup use, or recovery readiness, the first step is often finding the right OCI details across compartments and tools. The OCI Recovery Service MCP Server makes those read-oriented Recovery Service and Database Service operations available to an MCP-compatible AI client.
This guide gets you connected and gives you four prompts to try: create a dashboard, create a posture report, onboard a database with guided steps, and check a database’s recovery status. The server provides read-oriented OCI data and non-destructive dashboard and onboarding guidance; it does not create, update, or delete OCI resources.
Connect the server
Add the Recovery MCP server from the settings of the AI app where you want to use it. Open that app, go to its MCP servers, tools, or integrations settings, and choose the option to add a server. The setting name and configuration screen vary by app. The example below is for apps that accept an MCP server configuration in JSON.
The server runs locally through uvx, which downloads the published package from PyPI and starts it in an isolated cached environment; you do not need to clone the repository. Install Python 3.13 or later and `uv` on the same computer as your AI app first. The uvx command comes with uv.
Before adding the server, prepare the OCI profile it will use on that computer. The server reads ~/.oci/config and uses the DEFAULT profile unless you select another one. For API-key authentication, that profile must contain your OCI user, tenancy, fingerprint, key file, and region. For session-token authentication, sign in with the OCI CLI first:
oci session authenticate --profile-name DEFAULT
If the add-server form has separate fields, enter uvx as the command, oracle.oci-recovery-mcp-server as the argument, and choose stdio as the transport. Add OCI_CONFIG_PROFILE with the value DEFAULT as an environment variable. If your app instead uses a JSON configuration file, add this entry. If the file already has an mcpServers object, place only the oci-recovery item inside it:
{
"mcpServers": {
"oci-recovery": {
"type": "stdio",
"command": "uvx",
"args": ["oracle.oci-recovery-mcp-server"],
"env": {
"OCI_CONFIG_PROFILE": "DEFAULT"
}
}
}
}
If you use a profile other than DEFAULT, set OCI_CONFIG_PROFILE in the env block to that profile’s name. The server selects session-token authentication automatically when the chosen profile declares a security_token_file; otherwise it uses API-key authentication. If your MCP client cannot find uvx, replace “uvx” in the command field with the full path to it (on macOS or Linux, run which uvx in a terminal to find that path).
Save the configuration, then restart or reload the AI app if it asks you to. In the app’s MCP or integrations settings, check that oci-recovery is connected and its tools are enabled. To use the server, open a chat in that same app with the Recovery MCP tools available and enter one of the prompts below. Replace bracketed values with your compartment, region, database name, or OCID. The project also supports hosted Streamable HTTP deployments authenticated through OCI IAM; the local configuration above is the simplest way to get started.
Four prompts to try
1. Create a Recovery Service dashboard
Create a Recovery Service dashboard view for compartment [compartment name or OCID] in [region]. Use the Recovery MCP dashboard guidance and current OCI data. Include clear sections for protected database health, redo shipping status, backup space used, and backup destinations. Show key counts and affected database names where available, flag items that need attention, and finish with the most useful next checks. Present the dashboard here in the chat; do not change OCI resources.
The server provides dashboard guidance and summary tools for protected-database health, redo status, backup-space use, and backup destinations. The prompt asks the AI client to assemble those results into a dashboard view in the conversation.
2. Create a Recovery Service posture report
Create a Recovery Service posture report for compartment [compartment name or OCID] in [region]. Summarize protected databases, protection health, redo shipping, backup space, backup destinations, and applicable protection policies. Group findings by status, identify databases with gaps or risks, and include the evidence behind each finding. Note any data you could not retrieve. Use read-only tools and do not change OCI resources.
Use this report to review protection coverage across a compartment and identify which databases need attention. The MCP server can gather the underlying health, redo, backup, destination, and policy details.
3. Onboard a database to Recovery Service
Guide me through onboarding database [database name or OCID] in compartment [compartment name or OCID], region [region], to OCI Recovery Service. Review the database, available protection policies, and Recovery Service subnets. Give me the prerequisites, the recommended policy and subnet options with reasons, and an ordered checklist of the actions an OCI administrator needs to complete. Identify anything you cannot verify. Do not make changes; provide guidance for me to review and carry out.
The server includes a non-destructive onboarding guidance tool and read access to databases, protection policies, and Recovery Service subnets. It can prepare the onboarding steps, while an OCI administrator reviews and performs them.
4. Check database recovery status
Check the recovery status of database [database name or OCID] in [compartment name or OCID], [region]. Find its protected-database record and report its protection policy and health, latest available backup information, redo shipping status, and any relevant restore work requests. Explain anything you could not verify and list the next read-only checks. Do not start a recovery operation.
This prompt narrows the posture view to one database and asks for evidence across the server’s protection, backup, redo, and restore-status tools.
Get more from each prompt
Name a compartment and region when you know them. If you have a database or protected-database OCID, include it; some list tools can resolve a compartment display name, while resource retrieval tools require an OCID. For a compartment tree, ask to include child compartments when that is appropriate and your OCI permissions allow it.
Review the returned resource names, identifiers, timestamps, and status values before acting on them. The MCP server supplies OCI data and guidance to your client; use your normal operational approval process for any change or recovery action.
