Generates Terraform configuration (HCL) for Oracle Cloud Infrastructure resources, including whole-compartment modules and dependency graphs with provisioning order.
Click on "Deploy 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-oci List all compartments and generate Terraform for the prod compartment."
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 server for Oracle Cloud Infrastructure (OCI). It gives an MCP-capable client (Claude Desktop, Claude Code, Cursor, Copilot, …) the ability to discover live OCI resources, map how they relate, and generate reproducible Terraform — with behaviour controlled entirely by flags.
Think of it as a Playwright-MCP for your cloud: instead of rebuilding infrastructure knowledge by hand, the model can ask "show all VCNs in the prod compartment" and "generate Terraform for this compartment" and get structured, secret-free answers.
Live discovery — compartments, regions, and any resource via OCI Resource Search.
Terraform generation — faithful HCL for known types (VCN, subnet, instance, bucket, compartment) and annotated skeletons for the rest; whole-compartment modules with provider variables.
Dependency graph — nodes/edges plus a suggested provisioning order (dependencies first).
Secrets never reach the model — every payload is redacted before return.
Security flags — access modes, compartment/region allowlists, provisioning gate, dry-run, and JSON audit logging (see below).
Standard auth — OCI config file (~/.oci/config) or instance principals. No credentials stored by the server.
Related MCP server: oci-mcp-server
Concern | Flag | Default | Effect |
What can the server do? |
|
| All shipped tools are read-only. |
Which compartments are in scope? |
| (all) | When set, operations on other compartments are refused. |
Which regions are reachable? |
| (configured region) | When set, only these regions may be targeted. |
Can it run |
|
| Reserved gate for provisioning (not yet shipped). |
Preview without executing |
|
| For future write tools: validate + log intent without executing. |
Audit trail |
|
| Emits a JSON line to stderr per guarded operation. |
Secret redaction | (always on) | — | Secret-shaped fields are replaced with |
Discovery (read): list_compartments, list_regions, search_resources, list_compartment_resources, get_resource
Terraform (read): generate_terraform, generate_compartment_terraform, build_dependency_graph
Published on npm as @dockndevai/mcp-oci. No clone or build needed — your MCP client runs it on demand with npx. Start in read-only mode; see .env.example for every variable and docs/CLIENTS.md for the full per-client guide.
Claude Code (CLI)
claude mcp add oci -e OCI_PROFILE="DEFAULT" -e OCI_MODE="read-only" -- npx -y @dockndevai/mcp-ociClaude Desktop · Cursor · Windsurf — same block in claude_desktop_config.json, .cursor/mcp.json, or ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"oci": {
"command": "npx",
"args": [
"-y",
"@dockndevai/mcp-oci"
],
"env": {
"OCI_PROFILE": "DEFAULT",
"OCI_MODE": "read-only"
}
}
}
}OpenAI Codex CLI — in ~/.codex/config.toml:
[mcp_servers.oci]
command = "npx"
args = ["-y", "@dockndevai/mcp-oci"]
env = { OCI_PROFILE = "DEFAULT", OCI_MODE = "read-only" }VS Code (GitHub Copilot, Agent mode) — in .vscode/mcp.json:
{
"servers": {
"oci": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@dockndevai/mcp-oci"
],
"env": {
"OCI_PROFILE": "DEFAULT",
"OCI_MODE": "read-only"
}
}
}
}Point it at a standard OCI config profile. For safety, use an IAM user/policy with
read-only (inspect/read) permissions on the compartments you want the agent to see.
"List all compartments, then show every resource in the prod compartment."
"Generate Terraform for VCN ocid1.vcn.oc1..…."
"Build a dependency graph for compartment … and tell me the provisioning order."
Prefer the published package above. To run from a clone:
npm install
npm run build
node dist/index.js # with the environment variables setnpm run dev # watch mode
npm test # security policy + terraform generation + graph + redaction
npm run typecheckterraform plan / apply execution behind read-write/admin + OCI_ALLOW_APPLY.
More resource-type mappers (load balancers, databases, DRGs, IAM policies).
Cross-environment drift comparison.
This server ships a server.json for the official MCP registry and an mcpName for npm ownership validation. See PUBLISHING.md for publishing to npm and listing on the MCP registry, Smithery, Glama, Cursor, and PulseMCP.
MIT
Discover a compartment's resources and return a node/edge dependency graph plus a suggested provisioning order (dependencies first).
| Name | Required | Description | Default |
|---|---|---|---|
| compartmentId | Yes | Compartment OCID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the scope ('a compartment's resources') and the derived outputs (graph, suggested order), which is modest added value. However, it does not disclose openWorldHint implications (live cloud inspection) or any rate/latency context.
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?
Single efficient sentence that front-loads discovery and then enumerates the outputs. No filler, though it compresses usage context that could have earned 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?
For a one-parameter read-only tool with no output schema, the description adequately conveys what is returned, and annotations cover safety. Still missing is usage context relative to siblings that also list compartment resources, and any note on the live/openWorld nature of the discovery.
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% with a single well-documented compartmentId parameter (OCID), so the schema already carries full meaning. The description implies compartment scoping but adds no format or syntax details beyond that. Baseline 3 applies.
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?
States a specific verb+resource ('Discover a compartment's resources' / 'Build a resource dependency graph') and clarifies the return artifact (node/edge graph plus provisioning order). It does not differentiate itself from siblings like search_resources or generate_terraform, which also operate on compartments, so it falls short of 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 when-to-use or when-not-to-use guidance is provided. The description never names alternatives like list_compartment_resources or generate_terraform, leaving the agent to infer scope. It implies discovery but offers no routing criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover every resource in a compartment and emit a Terraform module (provider variables + one block per resource) to reproduce it. Unrecognised types become annotated skeletons.
| Name | Required | Description | Default |
|---|---|---|---|
| compartmentId | Yes | Compartment OCID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations supply readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so safety semantics are covered. The description adds genuinely new behavioral context beyond annotations: the output is a Terraform module with provider variables plus one block per resource, and unrecognised resource types are emitted as annotated skeletons. Return shape and edge-case handling are disclosed, which the annotations do not provide.
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, front-loaded with the discovery/emit action, then the output structure, then the fallback behavior. No filler and every clause carries information.
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 single-parameter read-only generation tool, the description covers purpose, output shape (provider variables, one block per resource) and edge-case behavior (unrecognised types become skeletons). No output schema exists, so explaining return structure is the right call; minor gap is that it does not mention how large or malformed compartments are handled.
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?
One parameter (compartmentId) with 100% schema description coverage, so the baseline is high. The description correctly implies the parameter is the compartment to scan and adds scope meaning ('whole compartment'), though it does not restate the OCID format, which the schema already documents.
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?
States a specific verb (Discover/emit) and resource (Terraform module from a whole compartment) with clear scope. A sibling tool named generate_terraform exists, and the phrase 'whole compartment' vs the sibling's likely single-resource scope is the distinguishing signal, though the description doesn't explicitly contrast with it.
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?
Usage is implied by 'whole compartment' and the sibling generate_terraform implies a per-resource variant, but there is no explicit when-to-use or when-not-to-use guidance. The agent must infer that this tool is chosen for bulk compartment conversion rather than single-resource generation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a Terraform (HCL) resource block for a single OCI resource by type and OCID. Fetches the resource's attributes and maps them to the matching oci_* resource.
| Name | Required | Description | Default |
|---|---|---|---|
| ocid | Yes | The resource OCID | |
| resourceType | Yes | OCI resource type, e.g. Vcn, Subnet, Instance | |
| compartmentId | No | Compartment OCID (for scoping) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is clear. The description adds that the tool fetches attributes and maps them to the matching oci_* resource, which is useful process context. However, it does not disclose any rate limits, authentication requirements, or error conditions; a 3 reflects that annotations cover most behavioral aspects and the description adds only moderate value.
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, information-dense sentence with no redundancy or filler. It is front-loaded with the action and outcome, making it easy to parse quickly.
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 read-only, idempotent generation tool with a fully documented schema and no output schema, the description provides enough context to call it correctly. It lacks guidance on when to prefer it over generate_compartment_terraform, which is a minor but noticeable gap given the sibling tool's similar name.
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 description coverage is 100%, so the schema already documents all three parameters. The description reiterates that it uses 'type and OCID', which adds no new syntax or format details beyond the schema. The baseline of 3 is appropriate when the schema fully covers parameter semantics.
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 a specific verb (Generate) and a specific resource (a Terraform HCL resource block for a single OCI resource) and names the inputs (type and OCID). It is clearly distinguishable from the sibling generate_compartment_terraform, which implies a broader scope, and from get_resource, which does not produce Terraform.
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 implicitly conveys that the tool is for a single resource, but does not explicitly state when to use it versus alternatives like generate_compartment_terraform or get_resource. No exclusions or prerequisites are provided, leaving the agent to infer the scope from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch detailed attributes for a resource by type and OCID. Known types (Vcn, Subnet, Instance) return full attributes; others return the identifier. Secrets are redacted.
| Name | Required | Description | Default |
|---|---|---|---|
| ocid | Yes | The resource OCID | |
| resourceType | Yes | OCI resource type, e.g. Vcn, Subnet, Instance | |
| compartmentId | No | Compartment OCID (for scoping) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior, so the safety profile is covered. The description adds non-obvious behavioral details: known types return full attributes while others return only the identifier, and secrets are redacted. These are valuable beyond the structured data, though return format details or error handling remain unstated.
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 waste, front-loaded with the core action and inputs. Every clause adds information without 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?
Given no output schema, the description adequately explains the return behavior (full attributes vs. identifier, redaction). Annotations cover safety. However, it does not mention the optional compartmentId parameter or any scoping behavior, leaving a minor gap for a 3-parameter 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?
Schema description coverage is 100%, so the baseline is 3. The description adds that resourceType accepts known types (Vcn, Subnet, Instance) and that other types are valid but return only the identifier, which is useful semantic context beyond the schema's example enumeration.
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 a specific verb (Fetch) and resource (detailed attributes for a resource), and names the inputs (type and OCID). It also distinguishes itself from siblings by implying it retrieves one resource rather than listing or searching many, though it does not explicitly name alternatives.
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?
Usage is implied by 'by type and OCID' — the agent can infer this is a lookup for a known resource. However, there is no explicit guidance on when to use this versus search_resources or list_compartment_resources, nor any mention of prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enumerate every resource in a compartment (via Resource Search).
| Name | Required | Description | Default |
|---|---|---|---|
| compartmentId | Yes | Compartment OCID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered elsewhere. The description's only additional behavioral signal is the parenthetical '(via Resource Search)', which hints at the backing mechanism but says nothing about cost, latency, pagination, or eventual-consistency behavior that this aggregated query would plausibly have.
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?
One short sentence with the core purpose front-loaded and no filler. It is efficient, though the trailing parenthetical is doing very little work.
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?
With one required parameter, full schema coverage, no output schema, and rich annotations, the description covers the essentials an agent needs to invoke it. Minor gaps remain around scope (all resource types?) and result limits, but nothing blocks correct invocation.
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 is a single parameter (compartmentId) and schema description coverage is 100%, so the schema already documents it as a Compartment OCID. The description adds no format or scope detail beyond that, so the baseline 3 applies.
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 gives a specific verb (enumerate) and resource (every resource in a compartment), so the agent knows exactly what it returns. It does not, however, distinguish itself from the sibling search_resources, which an agent could easily confuse with this tool.
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?
There is no statement of when to use this versus search_resources or list_compartments, and no conditions or exclusions. The implied usage ('to see everything in a compartment') must be inferred entirely by the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List compartments in the tenancy (recursively). Compartments outside the allowlist are filtered out.
| Name | Required | Description | Default |
|---|---|---|---|
| rootCompartmentId | No | OCID to list under (defaults to the tenancy root) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, open-world behavior, so the bar is lower. The description contributes genuinely new behavior: results are recursive and silently filtered by an allowlist, which warns the agent that the returned set may be incomplete.
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 short sentences, zero waste, with the core action front-loaded before the caveat about filtering.
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 single-optional-parameter read tool with a full annotation set, the description covers action, scope, recursion, and result filtering. Minor gaps remain (no mention of pagination or output shape), but nothing critical to correct invocation is missing.
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?
Only one parameter exists and the schema already documents it fully ("OCID to list under (defaults to the tenancy root)"), giving a baseline of 3. The description adds no syntax, format, or default nuance 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?
States a specific verb and resource ("List compartments") plus scope ("in the tenancy") and a mode qualifier ("recursively"). It does not, however, distinguish itself from the close sibling list_compartment_resources, so an agent must infer the difference.
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?
There is no guidance on when to choose this tool over list_compartment_resources, search_resources, or get_resource. The allowlist sentence describes result filtering, not usage context, so the agent gets no routing help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the regions this tenancy is subscribed to.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey read-only, idempotent, and non-destructive behavior. The description adds that results are scoped to this tenancy's subscriptions, which is helpful. It does not describe return format or ordering, but for a zero-parameter read-only list this is acceptable.
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?
A single sentence that states the operation and scoping directly with no filler or repetition. Every word 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?
For a zero-parameter, read-only tool with strong annotations and no output schema, the one-sentence description fully captures the invocation context. There is no missing parameter, prerequisite, or conditional 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?
The tool accepts zero parameters and schema coverage is 100%, so there is no parameter meaning for the description to enrich. The 0-parameter baseline of 4 applies.
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 names the exact action ('List') and the resource ('regions this tenancy is subscribed to'). The scoping also distinguishes it from sibling tools such as list_compartments or list_compartment_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?
The intended use is clear: call this when you need the regions subscribed to by the current tenancy. Thre is no close sibling for listing regions, so explicit alternatives are unnecessary, though none are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search tenancy resources using OCI Resource Search. Provide either a structured query (e.g. "query instance resources where displayName =~ 'prod'") or free text.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Structured query or free-text search string | |
| freeText | No | Treat query as free text instead of a structured query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint and destructiveHint=false, covering the safety profile. The description adds only the backing service and query-mode context; it does not discuss result limits, pagination, or tenancy scope breadth despite openWorldHint implying wide reach.
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, front-loaded with the core action and followed by the invocation mode; every clause earns its place with no 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?
No output schema exists, so return values need not be explained, and the annotations cover the safety posture. The definition is nearly complete for a 2-parameter search tool, with only minor gaps around result scope and pagination.
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%, so the baseline is 3, but the description goes beyond the schema by supplying a concrete structured-query example ('query instance resources where displayName =~ "prod"'), which teaches the actual syntax expected by the query parameter.
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?
States a specific verb+resource ('Search tenancy resources') and names the backing service (OCI Resource Search). It is distinguishable from the list_* siblings by being a query-driven search, but it never explicitly contrasts itself with list_compartment_resources or get_resource.
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 explains two input modes (structured query vs free text) but gives no when-to-use guidance relative to the sibling list/get tools, no exclusions, and no note on when one mode should be preferred over the other.
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.
v0.1.4build_dependency_graph1 field changedInput schema / additionalPropertiesRemoved value: -falsegenerate_compartment_terraform1 field changedInput schema / additionalPropertiesRemoved value: -falsegenerate_terraform1 field changedInput schema / additionalPropertiesRemoved value: -falseget_resource1 field changedInput schema / additionalPropertiesRemoved value: -falselist_compartment_resources1 field changedInput schema / additionalPropertiesRemoved value: -falselist_compartments1 field changedInput schema / additionalPropertiesRemoved value: -falsesearch_resources1 field changedInput schema / additionalPropertiesRemoved value: -falsev0.1.0build_dependency_graphgenerate_compartment_terraformgenerate_terraformget_resourcelist_compartment_resourceslist_compartmentslist_regionssearch_resourcesScored across 8 tools
Most tools have distinct purposes, but search_resources and list_compartment_resources both enumerate resources, and generate_compartment_terraform and build_dependency_graph both discover compartment resources, which could cause slight confusion despite clear descriptions.
All tool names follow a consistent snake_case verb_noun pattern (list_*, get_*, search_*, generate_*, build_*), making the set highly predictable and easy to navigate.
With 8 tools, the set is well-scoped for OCI infrastructure discovery and Terraform generation, covering essential operations without unnecessary bloat.
The surface covers discovery, detailed inspection, Terraform generation, and dependency graphing, but lacks direct resource management operations (create/update/delete) and a tool to list all resource types, which could limit some workflows.
Governed MCP gateway: one endpoint for your tools, with credential custody and audit log.
CloudOracle - 14-tool multi-cloud compliance MCP: AWS, Azure, GCP posture, IAM, configs.
Discover Agents and MCP capabilities with versions, permissions, and real-work trust context.
Authenticated MCP server for ClearPolicy policy and compliance workflows.