Explore, create, and troubleshoot Oracle Cloud Infrastructure Internet of Things Platform resources, including domains, digital twin models, adapters, instances, relationships, and device publish flows. Use when requests involve OCI IoT bootstrap, digital twin inspection, safe lifecycle operations, or translating OCI IoT docs and samples into concrete commands.
Explore, create, and troubleshoot Oracle Cloud Infrastructure Internet of Things Platform resources, including domains, digital twin models, adapters, instances, relationships, and device publish flows. Use when requests involve OCI IoT bootstrap, digital twin inspection, safe lifecycle operations, or translating OCI IoT docs and samples into concrete commands.
OCI IoT Platform
Quick Start
Confirm the user is working with Oracle Cloud Infrastructure Internet of Things Platform.
Ask for the minimum context needed before giving commands:
IOT_DOMAIN_ID when available
OCI_CLI_PROFILE
OCI_CLI_AUTH when the selected profile needs it, such as security_token
OCI_REGION if it cannot be derived from the domain
intended operation: inspect, create, update, delete, or publish test telemetry
Prefer this execution order:
discover the domain and current state
inspect the relevant model, adapter, or twin
check local CLI capability with oci ... --help when using newer filters or gateway/raw-command options
make the smallest required change
verify the result with a fresh read
Default Workflow
Start with read-only OCI CLI discovery.
Use scripts/derive_domain_context.sh when the user only has IOT_DOMAIN_ID.
Use references/platform-surface.md when the task needs orientation on OCI IoT resource families, data flow, connectivity types, or which surface to use.
Use references/mcp-optional-use.md only when an OCI IoT MCP server is already available in the user's environment. Keep CLI as the fallback and never require MCP for public workflows.
Use references/platform-surface.md to explain how domains, domain groups, models, adapters, twins, relationships, work requests, raw commands, and data access fit together.
Use references/resilience-guidance.md to keep operator responses bounded, active-resource focused, and explicit about final-state evidence.
Use references/mcp-optional-use.md to recognize optional OCI IoT MCP tool families, gateway-aware helper behavior, Data API wrappers, and safety rules.
Guardrails
Do not assume internal tenancy names, profiles, network access patterns, or private tooling.
Treat Oracle product docs and official samples as the source of truth for platform behavior.
Prefer read-only commands first and verify current state before recommending mutations.
When suggesting create, update, or delete operations, include a verification command immediately after the mutation.
Bound large reads with filters and --limit before using --all.
Treat asynchronous acceptance, including raw-command 202, as incomplete until final state is verified.
For digital twin instance creation, never use INDIRECT as a shortcut to avoid auth setup. Use INDIRECT only when the user explicitly asks for a gateway/downstream topology or provides a gateway routing requirement. Otherwise clarify connectivity or proceed with DIRECT when a publishing device is implied.
Keep MCP guidance optional. Do not make MCP installation or private MCP bootstrap part of the public workflow.
When MCP is already available, treat it as an accelerator for joined context, selector resolution, bounded pagination, gateway topology, Data API summaries, and polling; always be ready to fall back to CLI or SDK commands.
Treat device publishing auth modes separately:
vault-secret-backed basic auth
certificate-based mTLS
Do not imply OCI IoT is a general-purpose MQTT broker.
