Forem: Mark Nelson

Managed MCP in Autonomous AI Database: remote, governed tools per database

Mark Nelson — Thu, 21 May 2026 10:32:46 +0000

This is article 4 of 8 in my Oracle Database Skills series.

Key Takeaways

Managed MCP moves the action surface into the database itself. Tools run under real database identities with existing network controls, VPD policies, and audit trails already in force — no separate trust stack to build.
Custom tools are database objects. You define the logic in PL/SQL and register it with DBMS_CLOUD_AI_AGENT.CREATE_TOOL, so governance travels with the tool definition rather than depending on each caller to do the right thing.
The five questions security teams ask — who acted, under which identity, from what network path, against which tool, and where is the audit record — are answerable by design when the endpoint is managed by the database.

Most teams begin where Article 3 ended: a single developer running a local MCP (Model Context Protocol) server to prove out tools and workflows. That’s perfect for a solo experiment and brittle the moment work becomes shared. As soon as you put an IDE on a shared sandbox or add a second teammate, you need identity that isn’t “whoever is at the laptop,” network boundaries that aren’t home Wi‑Fi, and an audit trail your security team can actually review. Autonomous AI Database’s managed MCP server gives you those primitives without rebuilding your trust stack. Each database exposes its own HTTP MCP endpoint. Clients authenticate as a database user. Tools are defined and governed inside the database. Existing controls—roles, Access Control Lists (ACLs) or Private Endpoint reachability, Virtual Private Database (VPD)/redaction, and Unified Auditing—stay in the path for every tool call.

If you liked the local model—small, named tools; least‑privilege credentials; proof after the fact—you keep it. What changes is location and blast radius. The server runs with the database service. Calls execute with a database user’s roles. Network policy and auditing you already rely on continue to apply over streamable HTTP.

Sources: consult the Autonomous Database MCP documentation for concepts, enablement, security, and troubleshooting:

Version scope and assumptions

This article focuses on Autonomous Database Serverless (Autonomous AI Database) with its managed, per‑database HTTP MCP endpoint and on custom tool registration with DBMS_CLOUD_AI_AGENT. It does not cover on‑premises databases, self‑hosted proxies, or alternative deployment topologies. For authentication, follow the documented OAuth and short‑lived bearer token flows supported at publish time. The examples assume you can modify an Autonomous AI Database in Oracle Cloud Infrastructure (OCI) and create PL/SQL in your schema. Private Endpoint deployments require clients to run within, or be routed into, the VCN. Availability is documented as exclusive to Oracle Autonomous AI Database (versions 26ai and 19c) on the “About MCP Server” page; verify your environment against current docs before starting.

What you’ll need (prerequisites)

An Autonomous AI Database (Serverless) you can modify in OCI.
Permission in OCI to update free‑form tags on that database (enablement uses a tag).
A database user to authenticate to MCP (least‑privilege strongly recommended).
Database privileges to create/compile PL/SQL in your schema and to execute DBMS_CLOUD_AI_AGENT (DBA can grant EXECUTE on the package).
Network posture set appropriately:
- Public endpoint constrained by ACLs to known IPs/CIDRs, or
- Private Endpoint with clients running inside or routed/peered into the VCN.
An MCP‑aware client that supports streamable HTTP (e.g., Claude Desktop via mcp-remote; VS Code with Cline). Ensure the client’s transport is set to streamable HTTP per its configuration schema.
To view audit trails, privileges such as AUDIT_VIEWER (or equivalent access to UNIFIED_AUDIT_TRAIL) and any required unified audit policies per your security team.

Why move from local to managed

Local MCP gets you speed but leaves basic enterprise questions unanswered: Who ran this? Under which roles? From where? What policy filtered the result? Where’s the audit record? A managed MCP endpoint answers them by design. Identity is a database user, so tools run with that user’s roles and any VPD or redaction policies. Network is first‑class: public endpoints honor ACLs; Private Endpoint confines reachability to your VCN. Evidence lives with the data in Unified Auditing, and—if your organization uses it—Oracle Data Safe can centralize review. You don’t assemble a separate trust stack for assistants; you reuse the one already protecting your data.

Enable the per‑database MCP endpoint

Enabling MCP is an OCI operation. You turn it on per database with a free‑form tag. After a brief delay, the database details page shows the MCP URL. Use that exact URL; Private Endpoint deployments will reflect your VCN in the hostname. The documented public endpoint pattern is:

https://dataaccess.adb.{region-identifier}.oraclecloudapps.com/adb/mcp/v1/databases/{database-ocid}

For Private Endpoint databases, the documented pattern uses the database Private Endpoint hostname prefix:

https://{hostname_prefix}.adb.{region-identifier}.oraclecloudapps.com/adb/mcp/v1/databases/{database-ocid}

In the OCI Console, open your Autonomous AI Database (Serverless) and add this free‑form tag:

Name: adb$feature
Value: {"name":"mcp_server","enable":true}

Tighten network posture before you connect. For public endpoints, restrict inbound IPs with an ACL. For Private Endpoint, keep the MCP URL accessible only within your VCN; clients must run in or have routed/peered reachability to that network. The enablement and security pages in the docs provide step‑by‑step screens for both configurations.

Authenticate to the managed MCP endpoint

The managed server accepts OAuth or short‑lived bearer tokens as documented. Tokens are issued per database and presented on every request as a bearer header over streamable HTTP.

Token endpoint path (documented): /adb/auth/v1/databases/{database-ocid}/token
Present the token in client requests as: Authorization: Bearer <token>
Tokens are typically valid for approximately one hour; confirm the current duration and request body in the Use MCP Server page before automating refresh.

Client configuration varies slightly:

Claude Desktop via mcp-remote: configure a remote MCP server using your database’s MCP URL and add the Authorization: Bearer ... header in the bridge’s HTTP headers field. Set the transport to streamable HTTP as required by your client (for example, a setting named streamable-http or streamableHttp).
VS Code with Cline: add a remote HTTP MCP server pointing to the MCP URL and set Authorization: Bearer ... in the request headers section. Ensure the transport is explicitly set to streamable HTTP.

A minimal Cline-style configuration looks like this, with placeholders for your database URL and bearer token:

{
  "mcpServers": {
    "adb-managed-mcp": {
      "type": "streamableHttp",
      "url": "https://dataaccess.adb.{region-identifier}.oraclecloudapps.com/adb/mcp/v1/databases/{database-ocid}",
      "headers": {
        "Authorization": "Bearer <token>"
      }
    }
  }
}

If your database uses a Private Endpoint, make sure the client host has network reachability into the VCN. Valid credentials against an unreachable hostname still fail.

Publish a custom tool the database can govern

Unlike local MCP servers that host code beside the client, the managed server looks up tools defined in the database. You create small, purposeful functions in your schema and register them with DBMS_CLOUD_AI_AGENT.CREATE_TOOL. That keeps control centralized: the definitions live in the database, metadata is queryable from views, and execution inherits database roles and policy.

To keep the example easy to reason about, we’ll publish a read‑only tool that returns a paginated JSON array of objects in a given schema that are visible to the executing database user and are not in Oracle‑maintained schemas. This variant excludes Oracle‑maintained schemas using ALL_USERS.ORACLE_MAINTAINED. The Oracle docs also include a sample that filters on ALL_OBJECTS.ORACLE_MAINTAINED = 'N'; either approach works on Autonomous Database.

First, create and compile the function:

CREATE OR REPLACE FUNCTION list_objects_json (
  p_schema IN VARCHAR2,
  p_offset IN NUMBER DEFAULT 0,
  p_limit  IN NUMBER DEFAULT 20
) RETURN CLOB
AS
  v_json  CLOB;
BEGIN
  SELECT COALESCE(
           JSON_ARRAYAGG(
             JSON_OBJECT(
               'SCHEMA_NAME' VALUE owner,
               'OBJECT_NAME' VALUE object_name,
               'OBJECT_TYPE' VALUE object_type
             ) RETURNING CLOB
           ),
           '[]'
         )
    INTO v_json
    FROM (
      SELECT o.owner, o.object_name, o.object_type
      FROM   all_objects o
      WHERE  o.owner = UPPER(p_schema)
      AND    EXISTS (
               SELECT 1
               FROM   all_users u
               WHERE  u.username = o.owner
               AND    u.oracle_maintained = 'N'
             )
      ORDER  BY o.object_name
      OFFSET p_offset ROWS FETCH NEXT p_limit ROWS ONLY
    );
  RETURN v_json;
END;
/

Check for compilation errors before registering a tool:

SHOW ERRORS FUNCTION list_objects_json;

-- Or:
SELECT name, type, line, position, text
FROM   user_errors
ORDER  BY name, sequence;

Next, register the function as an MCP tool. Use the attribute names exactly as shown in the documentation for DBMS_CLOUD_AI_AGENT.CREATE_TOOL.attributes; mismatches can cause registration or invocation errors. Common keys include instruction, function, and tool_inputs. For this example, rely on the PL/SQL defaults defined in the function and do not include unverified default values in the tool_inputs JSON.

BEGIN
  DBMS_CLOUD_AI_AGENT.CREATE_TOOL(
    tool_name  => 'LIST_OBJECTS',
    attributes => q'~{
      "instruction": "Return a JSON array of objects visible to the executing database user for the given schema (excluding Oracle-maintained schemas). Always respect p_limit and p_offset.",
      "function": "LIST_OBJECTS_JSON",
      "tool_inputs": [
        { "name": "p_schema", "type": "string", "required": true,  "description": "Schema name (case-insensitive)" },
        { "name": "p_offset", "type": "number", "required": false, "description": "Row offset for pagination" },
        { "name": "p_limit",  "type": "number", "required": false, "description": "Max rows to return" }
      ]
    }~'
  );
END;
/

Verify that registration succeeded by querying the registry view. Column sets differ by version, so keep the check simple:

SELECT tool_name
FROM   user_cloud_ai_agent_tools
ORDER  BY tool_name;

If you see “insufficient privileges,” ask your DBA to grant EXECUTE on DBMS_CLOUD_AI_AGENT to your user and retry.

Note: DBMS_CLOUD_AI_AGENT supports both custom PL/SQL‑backed tools and built‑in tool types. For the current list of built‑in types and parameters, see the package reference:

https://docs.oracle.com/en-us/iaas/autonomous-database-serverless/doc/dbms-cloud-ai-agent-package.html

Also note: MLE JavaScript is not supported for MCP tools. Java can be used via PL/SQL calling Java stored procedures when JAVAVM is enabled on the database (see the docs for details).

Connect a client and try the tool

Once authentication works and the tool is registered, connect an MCP‑aware client and ask it to use the tool. In Claude Desktop, add a remote MCP server that points to your database’s MCP URL, include the Authorization: Bearer <token> header, and set transport to streamable HTTP per the client’s schema. In a fresh chat, prompt the assistant: “Use the LIST_OBJECTS tool to list 5 objects in the HR schema.” You should see the assistant invoke the tool and stream back JSON. In VS Code with Cline, add the same MCP URL in the extension’s settings, supply the same header, and ensure the streamable HTTP transport is selected; then request LIST_OBJECTS with p_schema=HR and p_limit=5.

A representative response from the tool looks like this (truncated):

[
  { "SCHEMA_NAME": "HR", "OBJECT_NAME": "COUNTRIES", "OBJECT_TYPE": "TABLE" },
  { "SCHEMA_NAME": "HR", "OBJECT_NAME": "EMPLOYEES", "OBJECT_TYPE": "TABLE" },
  { "SCHEMA_NAME": "HR", "OBJECT_NAME": "JOBS", "OBJECT_TYPE": "TABLE" }
]

On Private Endpoint databases, run those clients from a host inside the VCN or with routed/peered access. Lack of reachability is the most common reason a seemingly correct configuration fails.

Observe the audit trail (roles permitting)

Unified Auditing on Autonomous Database records activity under your database user. Exact fields and event names depend on your version and your organization’s audit policy. With appropriate privileges (for example, AUDIT_VIEWER or equivalent access to UNIFIED_AUDIT_TRAIL), you can review a time‑bounded window of recent activity:

SELECT event_timestamp, dbusername, action_name, return_code, obj_privilege, unified_audit_policies
FROM   unified_audit_trail
WHERE  event_timestamp >= SYSTIMESTAMP - INTERVAL '15' MINUTE
AND    UPPER(dbusername) = UPPER(USER)
ORDER  BY event_timestamp DESC
FETCH FIRST 50 ROWS ONLY;

Autonomous Database retains unified audit data for about 14 days by default; if you need longer retention or centralized reporting, integrate Oracle Data Safe. When you author VPD or audit policies for MCP, do not rely on SESSION_USER. Use MCP context attributes instead—for example, sys_context('MCP_SERVER_ACCESS_CONTEXT','USER_IDENTITY') as shown in the Security docs. Some concept pages may refer to the MCP context container using slightly different naming in prose; follow the exact string in the Security examples. Your security team may also enable additional unified audit policies to capture MCP‑specific attributes.

Operate safely and clean up

Treat tools as product surface area. Keep them small and read‑heavy at first; add write paths only when you can articulate least privilege and validate inputs. Prefer schemas you own to avoid accidental privilege sprawl. Version tool registrations as code and require review before deployment.

When a tool is no longer needed, remove both the registration and the underlying function:

BEGIN
  DBMS_CLOUD_AI_AGENT.DROP_TOOL(tool_name => 'LIST_OBJECTS');
END;
/

DROP FUNCTION list_objects_json;

As you expand usage, periodically re‑check ACLs on public endpoints and confirm Private Endpoint posture remains correct, especially after network changes. Rate limiting is enforced by the managed service; consult current release notes for behavior and limits.

Troubleshooting

Most issues fall into a few buckets:

Compilation and registration: fix PL/SQL errors (SHOW ERRORS, USER_ERRORS) before registering. Ensure your user has EXECUTE on DBMS_CLOUD_AI_AGENT. If registry queries fail with unknown columns, select only tool_name and consult versioned docs for metadata.
Connectivity: verify you’re using the MCP URL exactly as shown in the console. For public endpoints, confirm your IP/CIDR is in the database ACL. For Private Endpoint, confirm the client host has routed/peered access to the VCN.
Authentication: obtain tokens from /adb/auth/v1/databases/{database-ocid}/token and present them as Authorization: Bearer <token>. Copy the exact request body and lifetime from the current docs. Place headers where your client expects them.

If a client claims to connect but tool calls fail, double-check that attribute keys in CREATE_TOOL match the documentation exactly; case mismatches cause registration or invocation errors.

What comes next

With a per-database MCP endpoint, one governed tool, and a way to verify activity in Unified Auditing, you can expand safely. Start with a small set of read-heavy tools your team actually needs. Introduce narrow write paths with explicit inputs and clear privileges. Treat tool definitions like code: review them, version them, and track changes.

The next article moves from action surfaces to reasoning scope: Select AI and AI Profiles. That is where you decide what natural-language-to-SQL should be allowed to see, how generated SQL should be inspected, and how to keep an assistant’s query generation inside a deliberate profile instead of a broad database connection.

Freshness note

Content validated against the Autonomous Database MCP documentation on 2026-05-08. Re-check the Use MCP Server and Security pages for any changes to endpoint paths, JSON key names, token lifetimes, and audit details before publishing or automating.

Controlled Oracle Actions with SQLcl MCP

Mark Nelson — Tue, 19 May 2026 12:07:51 +0000

This is article 3 of 8 in my Oracle Database Skills series.

Kay Takeaways

The assistant connects using a saved connection name, not a pasted password. Credentials stay in the SQLcl store and out of prompts, so the model sees the name but never the secret.
Restrict levels define the tool surface at runtime. Starting at the most restrictive setting limits what the assistant can do; you widen the surface deliberately as the use case earns it.
Session tagging and the MCP activity log give a DBA verifiable proof of what ran. Evidence comes from the database, not the chat transcript — that distinction matters when someone asks what the assistant actually did.

In the last piece, you routed Oracle prompts through db/SKILL.md to keep intent explicit (see Article 1 and Article 2 in this series). Now it’s time to act—locally, with guardrails, and with an evidence trail your DBA can verify. SQLcl MCP gives you that posture. You launch it as a local process (sql -mcp); it exposes a small catalog of named tools over stdio; it connects through saved connections you control; it starts in a highly restricted mode by default; and it leaves database‑native traces you can query later. That’s the right shape for early assistant experiments on a developer machine.

Citations for versioned behavior are in Oracle’s SQLcl documentation (for example, “Using SQLcl MCP Server,” “SQLcl MCP Server tools,” “Starting and managing SQLcl MCP Server,” “Restrict Levels,” “Preparing your environment,” and “Saving connections” in the 25.4 and 26.1 editions). Treat any version‑sensitive claim here as “verify against your installed docs.”

What you need before you start

SQLcl 25.2.0 or newer with MCP support
Java 17 or 21 available to SQLcl (per “Preparing your environment”)
A non‑production Oracle Database (19c+ suffices for this demo)
A least‑privilege, read‑only database user for testing
A saved SQLcl connection that includes a stored password, created with -save and -savepwd (required for non‑interactive MCP connects)
Permission to query V$SESSION for evidence, or access to an equivalent DBA‑provided view that exposes MODULE and ACTION for your sessions
If you use TNS aliases, configure Oracle Net as usual (for example, set TNS_ADMIN to your tnsnames.ora directory). If your MCP client launches sql -mcp with a custom environment, pass TNS_ADMIN there as needed.

Security note: Storing passwords is a prerequisite for non‑interactive MCP connects. Keep this to a sandbox, use a read‑only account, and lock down your local SQLcl store (commonly under ~/.dbtools) per your organization’s secrets policy.

Why SQLcl MCP is the right local action layer

A tempting shortcut is to paste credentials into a prompt and let a model “try something.” That’s exactly what you want to avoid. SQLcl MCP flips the pattern: you launch sql -mcp locally and expose a small set of structured tools. Your client can list saved connections, connect by name, run SQL, and disconnect. The MCP connect path uses saved/named connections; the tool does not accept raw credentials in the call. For non‑interactive use, the password must be saved (-savepwd). You decide which saved connections exist and what privileges they carry.

Restrict levels are SQLcl’s runtime safety gates that limit which features and commands are allowed. In MCP mode the server defaults to restrict level 4 (most restrictive) unless you override it with -R, so the surface stays small until you intentionally broaden it. That’s a posture you can explain to a DBA and adjust deliberately as you earn trust.

References: SQLcl MCP overview and startup; Saved connections; Restrict levels (25.4/26.1 docs).

How the server behaves under the hood

When your client launches sql -mcp, SQLcl starts a small server over stdio and advertises a catalog of named tools. Message envelopes vary by client, but tool names and arguments follow the SQLcl MCP documentation. As of the 26.1 docs, commonly listed tools include:

list-connections
connect
disconnect
run-sql
run-sqlcl

Some builds also include schema-information. Tool availability and argument shapes can vary by version/build; verify against your installed docs.

Connections are discovered from your local SQLcl store (for example, ~/.dbtools). To make a connection usable without a prompt, save it with a stored password. Oracle documents this as a prerequisite for hands‑off connection by name.

Restrict levels shape what the process can do. In MCP mode, the server defaults to restrict level 4 (most restrictive) unless you override it with -R. Outside MCP, generic SQLcl defaults to restrict level 0 (unrestricted) unless you pass -R; always verify the “Restrict Levels” page for your exact build.

References: SQLcl MCP tools; Saved connections; Restrict levels and -R flag (25.4/26.1 docs).

Traceability you can prove (monitoring and governance)

Before you run anything, plan how you’ll show what happened. The most portable approach is to tag your session with DBMS_APPLICATION_INFO and then confirm it in V$SESSION. The tag appears in performance tooling and helps a DBA correlate what ran and why. By default, SQLcl MCP records the execution history of requests in DBTOOLS$MCP_LOG (per Oracle docs). Access, owner/schema, and privileges vary by environment, so confirm presence and permissions with your DBA.

Tagging mechanism: DBMS_APPLICATION_INFO.SET_MODULE and SET_ACTION (documented in Oracle Database PL/SQL packages)
Evidence view: V$SESSION (privilege‑gated; ask a DBA for a scoped alternative if you lack access)
Logs: DBTOOLS$MCP_LOG records requests by default; access and retention are environment‑specific

References: DBMS_APPLICATION_INFO; V$SESSION; SQLcl MCP monitoring/logging pages (25.4/26.1 docs).

Version scope and environment notes

Keep SQLcl at 25.2.0+ for MCP features and run it with Java 17 or 21 (per “Preparing your environment”).
The tool catalog and defaults can evolve; the 25.4 and 26.1 guides capture current behavior, but verify against your installed version.
The demo assumes Oracle Database 19c or later and avoids database features tied to 26ai.
Some clients (for example, SQL Developer for VS Code) can launch and manage the MCP server for you; follow your client’s documentation for its configuration format and capabilities, which can change by version.

A small, traceable demo you can run today

This walkthrough saves a single read‑only connection, launches the MCP server, validates that the connection is discoverable, connects by name, tags its session, runs one read‑only discovery query, and disconnects. Each step includes copy‑paste commands and why the step matters.

1) Save a named connection for a read‑only sandbox user

Open SQLcl, connect once interactively, and persist the connection with a stored password so MCP can use it without a prompt.

sql /nolog
# If you connect by service name:
conn demo_ro@//host:1521/service -save demo_ro -savepwd
# If you connect by TNS alias (ensure Oracle Net is configured and tnsnames.ora is discoverable):
# conn demo_ro@ALIAS -save demo_ro -savepwd

When prompted, enter the password interactively. The -save and -savepwd flags persist the named connection (commonly in ~/.dbtools) with a stored password so MCP can use it non‑interactively. Use a sandbox‑only, least‑privilege account and follow your org’s secrets policy for local credential storage.

2) Start the MCP server (keep the default restrict level)

Launch SQLcl in MCP mode and leave the terminal open. Unless your client does this for you, this process is the local server your MCP‑aware client will talk to.

sql -mcp

By default, restrict level 4 applies. If you ever see broader capability than expected, confirm that the process was not started with a lower restrict level (for example, -R 0). For early experiments, stick with the default level 4.

3) Point your MCP‑aware client at SQLcl

Configure your client to launch sql -mcp.

Representative MCP server configuration for a desktop client. Field names and file locations vary by client; follow your client’s documentation for the exact schema.

{
  "mcpServers": {
    "sqlcl": {
      "command": "sql",
      "args": ["-mcp"],
      "env": {
        "TNS_ADMIN": "/path/to/network/admin"
      }
    }
  }
}

4) Verify that the saved connection is discoverable

Before you connect, ask the server to list saved connections. Seeing demo_ro here confirms that the server can use it non‑interactively.

Representative MCP tool call; adapt to your client’s message envelope (for example, a surrounding "type": "call_tool"), server name, and argument key names as defined by your client and the SQLcl MCP tools page for your installed version.

[
  { "tool": "list-connections", "arguments": {} }
]

If demo_ro does not appear, revisit the conn ... -save -savepwd step and make sure you created the connection under the same OS user/profile that SQLcl is using.

5) Connect by name and tag the session

Connect using the saved name, then tag the session with MODULE and ACTION so you can find it later in performance views and, if accessible, MCP logs.

Representative MCP tool call; adapt to your client’s envelope and argument names. Note: some clients use name, others connectionName or connection_name.

[
  { "tool": "connect", "arguments": { "name": "demo_ro" } },
  { "tool": "run-sql", "arguments": { "sql": "BEGIN DBMS_APPLICATION_INFO.SET_MODULE('sqlcl-mcp','schema-discovery'); END;" } }
]

Tagging is optional but strongly recommended. It creates a human‑readable breadcrumb for exactly this experiment.

6) Run one read‑only discovery query

To keep the example universal, start with a query against objects you own:

Representative MCP tool call; adapt to your client’s envelope and argument names.

{ "tool": "run-sql", "arguments": { "sql": "SELECT table_name FROM user_tables ORDER BY table_name FETCH FIRST 5 ROWS ONLY" } }

If your account has cross‑schema visibility, you can adjust the query to ALL_TABLES:

Representative MCP tool call; adapt to your client’s envelope and argument names.

{ "tool": "run-sql", "arguments": { "sql": "SELECT owner, table_name FROM all_tables WHERE owner = UPPER('<YOUR_SCHEMA>') ORDER BY table_name FETCH FIRST 5 ROWS ONLY" } }

Keep the action read‑only while you learn the surface and review the evidence with a DBA partner.

Optional: Some clients also expose run-sqlcl for SQLcl console commands (for example, DESC). At restrict level 4, many SQLcl commands are disabled; simple describe operations may work depending on your build—verify in your environment. If enabled in your version and posture, a representative call looks like:

Representative MCP tool call; adapt to your client’s envelope and argument names.

{ "tool": "run-sqlcl", "arguments": { "command": "DESC USER_TABLES" } }

Treat this as optional; the minimal surface for early tests is run-sql.

7) Disconnect when you are done

Disconnecting is good hygiene and makes your test’s boundaries clear.

Representative MCP tool call; adapt to your client’s envelope and argument names.

{ "tool": "disconnect", "arguments": {} }

Prove what happened

Evidence checks depend on privileges. If your account cannot query performance views, ask your DBA for a scoped alternative that exposes MODULE and ACTION for your sessions.

See the tag in a live session view:

SELECT module, action, username, machine
FROM   v$session
WHERE  module = 'sqlcl-mcp';

By default, SQLcl MCP records requests in DBTOOLS$MCP_LOG. You can review recent entries there as well. Presence is standard per the docs, but owner/schema and access vary by setup; in some environments the table resides under a DBA‑owned schema. Treat the query below as an example and ask your DBA for the owner or a scoped view if needed.

SELECT id, mcp_client, model, end_point_type, end_point_name, log_message
FROM   DBTOOLS$MCP_LOG
ORDER  BY id DESC
FETCH  FIRST 10 ROWS ONLY;

If neither view is available to you directly, a DBA can run the checks or provide a narrow view limited to your test user.

When something goes wrong

If the client prompts for a password, the saved connection likely lacks a stored secret. Recreate it with both -save and -savepwd so MCP can connect non‑interactively. When the tool catalog looks unfamiliar or is missing entries, you may be on a different SQLcl version; check the MCP tools page for your installed build (the 25.4 and 26.1 docs capture current behavior). If you don’t see your session tag in V$SESSION, it’s probably a privilege boundary rather than a failure to tag; ask for a scoped view or a one‑time verification. If the server shows more capability than your risk posture allows, confirm the restrict level and restart without any -R override so the default restrictive posture applies.

Why this posture earns DBA trust

DBAs reasonably resist assistants that can write to production. SQLcl MCP avoids that leap of faith. You connect through named entries you control. You default to a restrictive mode. You tag your sessions with MODULE and ACTION so activity shows up cleanly in performance tooling. And, where available, MCP logs give an after‑the‑fact record. The point is not speed; it’s reversibility and evidence. In a world where models sometimes propose creative fixes, that’s the currency that gets you permission to try again tomorrow.

What’s intentionally out of scope here

This article focuses on local SQLcl MCP on a developer workstation, read‑only sandboxes, and minimal evidence checks. It does not cover managed or remote MCP hosting, enterprise audit/policy, advanced reasoning patterns (for example, Select AI or AI Profiles), vector‑native RAG, or change‑management workflows. Those topics are addressed next when we move beyond a single machine.

Where this leaves you next

You now have a local, developer‑friendly path for safe, traceable Oracle actions. Previously in this series: Article 1 (routing) and Article 2 (route‑to‑action bridge). Next up: Article 4, where we carry these guardrails into a managed path with audit, policy, and team controls so you can scale without losing the evidence and restraint you established here.

Freshness Note: Version‑sensitive behavior (tool catalog, defaults, restrict levels) should be verified against your installed SQLcl documentation (notably the 25.4 and 26.1 editions).

Route, Don’t Flood: Using db/SKILL.md to Steer Oracle‑Aware Assistants

Mark Nelson — Fri, 15 May 2026 12:21:32 +0000

If you’ve tried to make an assistant “Oracle‑aware,” you’ve likely hit the same wall: you paste a stack of links, the model blends vendor‑neutral habits with stale Oracle guidance, and the answers get vague when you need precision. The fix isn’t more context—it’s better routing. One Oracle skill at a time, in the right order, so every next move follows Oracle’s own sequence.

In Article 1 we outlined an operating model for AI on Oracle Database: route → act → trust. This piece goes deep on the first verb. It shows how to use db/SKILL.md in the public Oracle Database Skills repository as your front door; how to route by persona or by task; and how to enforce progressive discovery so your assistant loads exactly one file at a time. This is a no‑execution article; we stay in the routing lane and leave tools to Article 3 (SQLcl MCP). Prerequisite: you only need to browse https://github.com/oracle/skills in a web browser.

Why routing beats context dumping

Dumping a pile of links into a prompt feels thorough, but it blurs version lines and lets generic “SQL” patterns overrule Oracle‑specific guidance. It also bloats token budgets without improving the next decision. db/SKILL.md fixes this by providing a maintained map of Oracle Database skills, pointing you to the right starting file for common jobs, and encoding short, opinionated sequences for multi‑step workflows. The goal is not to read everything; it’s to pick the next file, digest it, and decide whether one more file is warranted. When you’re actually ready to execute a command, you’ve left routing and entered “act” (Article 3 covers SQLcl MCP).

Treat db/SKILL.md as the front door

db/SKILL.md is the router for the Database domain. It opens with a routing table and guidance to keep context tight—begin at the table, then read only the specific file or category you need.

It also shows the shape of the Database skills, including these directories:

db/agent
db/features
db/frameworks
db/performance
db/security
db/devops
db/migrations
db/sqlcl

Two parts matter most on your first pass. First, the file highlights concrete entry points for real jobs—where performance triage begins, where SQLcl basics and MCP server entries sit (setup is deferred to Article 3), how to approach schema migrations, and which agent behaviors (like schema discovery) must be understood before you write anything. Second, it outlines common sequences that act as guardrails. Examples include RAG (skills under db/features: ai‑profiles → vector‑search → dbms‑vector), slow‑query diagnosis (skills under db/performance: explain‑plan → wait‑events → optimizer‑stats → awr‑reports), and agent‑safe schema change (skills under db/agent and db/migrations: schema‑discovery → destructive‑op‑guards → idempotency‑patterns → schema‑migrations). There’s also an MCP setup path you’ll use later when you move from routing to action: sqlcl‑basics → a least‑privilege/privilege‑management skill in db/security → sqlcl‑mcp‑server.

Starting here changes how your assistant behaves. Instead of grabbing whatever looks related on the internet, it asks, “What’s the next Oracle‑authored file?” The result is fewer wrong turns and shorter, more reviewable prompts.

Route by persona when you’re scoping a project

When you’re defining scope rather than responding to a ticket, match your role and load one file. Don’t skim the whole repository first—route, read, and decide.

App developer

If you’re wiring a service to Oracle, start with frameworks and then layer on application‑specific skills. The db/frameworks directory anchors guidance for stacks such as Spring, Django, and SQLAlchemy: connection configuration, driver/dialect selection, data type mapping, and recommended connection patterns. Once the framework is set, dip into app‑dev skills for JSON, Spatial, Text, or pooling nuances you actually need. Doing it in this order avoids needless trial and error—you adopt the Oracle‑tested path before you customize.

AI engineer

Begin in db/agent and db/features. The agent skills cover behaviors that matter when a model touches a database: discover schema before DML, guard against destructive operations, make steps idempotent so retries don’t double‑apply, and identify clients for traceability. The features skills introduce Oracle’s AI‑native building blocks—Select AI and AI Profiles for governed NL2SQL, and AI Vector Search/DBMS_VECTOR for retrieval and RAG. Version gate: check each feature’s documentation. DBMS_VECTOR and many Select AI/AI Profiles examples are documented for 26ai; several AI capabilities are also available in Autonomous Database. Do not assume 19c availability unless a skill or doc explicitly states it.

DBA

The fastest way to get Oracle‑native outcomes from an assistant is to route through db/performance and then db/security. Performance skills teach the assistant to obtain and read the plan that actually executed (for example, via DBMS_XPLAN.DISPLAY_CURSOR(NULL, NULL, 'ALLSTATS LAST')), interpret row sources and cardinality, and pivot at the right moment from plan reading to wait events and then, if warranted, to AWR. Security skills ground privilege design, auditing, and encryption in Oracle’s vocabulary so “least privilege” becomes an actionable design rather than a slogan.

Migration lead

Treat db/migrations and db/devops as two halves of one job. Migration skills help with assessment and translation; devops skills handle delivery mechanics such as schema change workflows, online operations, Edition‑Based Redefinition, and testing. Loading one file at a time keeps heterogeneous estates from collapsing into generic, lowest‑common‑denominator advice.

Route by task when you’re on the clock

When a ticket arrives with a single job, follow the ordered sequences in the repository. Oracle’s diagnostics and defaults are opinionated for a reason; ignoring their order usually costs time.

RAG on Oracle Database

Start with AI Profiles, because that’s where you choose a provider and model and, crucially, define which database objects the model may see. Only after scope and governance are set should you learn retrieval patterns in vector‑search and then orchestrate pipelines with DBMS_VECTOR. The payoff is a governed RAG flow that can be inspected (SHOW SQL) and tightened (OBJECT_LIST and data access controls), rather than a bag of embeddings taped onto a database.

Route (skills under db/features): ai‑profiles → vector‑search → dbms‑vector
Reference: Select AI examples (SHOW SQL, OBJECT_LIST, and data access controls): https://docs.oracle.com/en/database/oracle/oracle-database/26/selai/examples-using-select-ai.html
Version note: Follow the feature docs. DBMS_VECTOR and many Select AI/AI Profiles examples are documented for 26ai; several AI capabilities are also available in Autonomous Database. Do not assume 19c availability unless a skill or doc explicitly states it.

Slow‑query diagnosis

Begin by reading the plan that actually ran. In Oracle that means capturing the executed plan from the cursor (for example, DBMS_XPLAN.DISPLAY_CURSOR(NULL, NULL, 'ALLSTATS LAST')), not relying solely on an EXPLAIN PLAN estimate. If the plan looks sane but runtime stalls, pivot to wait events. If rows and joins are misestimated, fix statistics and cardinality before widening the window with AWR.

Route (skills under db/performance): explain‑plan → wait‑events → optimizer‑stats → awr‑reports
Availability note: AWR/ASH access depends on environment and licensing.

Agent‑safe schema change

Discover what exists before you propose change, add loss‑prevention so a single bad predicate can’t harm a table, and make each step idempotent so a retry won’t double‑apply. Only then move into an audited migration workflow.

Route (skills under db/agent and db/migrations): schema‑discovery → destructive‑op‑guards → idempotency‑patterns → schema‑migrations

A compact prompt that enforces progressive discovery

A small prompt can prevent freelancing by enforcing a loop: route, read one file, summarize, decide. That discipline keeps the context precise and affordable.

Prompt

Open db/SKILL.md. I’m [persona or task].
Which single skill file should I load next, and why?
Summarize that file in 5 bullets, then propose the next decision (read another file or stop).
Do not execute any actions.

Progressive routing loop

Mini demos (no DB access, no execution)

These prompts validate routing behavior before you connect any tools. They’re deliberately constrained to “read and decide.”

Demo A: Persona‑first route for a Spring app developer

Prompt

Open db/SKILL.md. I’m wiring a Spring Boot service to Oracle.
Which single frameworks/appdev skill should I load next, and why?
Summarize that file in 5 bullets, then propose the next decision.
Do not execute any actions.

Example assistant response

Next file: A Spring Data JPA with Oracle skill under db/frameworks/.
Why: It covers Oracle-specific connection configuration, driver/dialect selection, pooling, and type mapping.

Summary:
- Recommended Oracle JDBC URL formats and service naming for Spring Boot
- Dialect/driver selection and common DataSource pitfalls
- Transaction, batching, and fetch-size options tuned for Oracle
- LOB, DATE/TIMESTAMP, and NUMBER mapping considerations
- Starter checks and links to follow-up appdev skills

Next decision:
- If you need pooling/retry/circuit specifics, read a connection/pooling skill next.
- Otherwise, stop and apply these configuration steps before proceeding.

Demo B: Task‑first route for diagnosing a slow query

Prompt

Starting from db/SKILL.md, list the ordered skill files for slow-query triage.
Load only the first file, summarize it in 5 bullets, then recommend whether to read the next file or stop.
Do not execute any actions.

Example assistant response

Ordered files:
1) The explain-plan skill in db/performance/
2) The wait-events skill in db/performance/
3) The optimizer-stats skill in db/performance/
4) The awr-reports skill in db/performance/

Loaded: explain-plan

Summary:
- Obtain the executed plan from the cursor (vs. EXPLAIN PLAN estimates) and where to find it
- Read row sources and cardinality; spot misestimates and join-order issues
- Recognize anti-patterns (forced full scans, skewed histograms, implicit conversions)
- Interpret plan notes for adaptive features and parallel decisions
- Decide when to pivot from plan analysis to wait-event inspection

Recommendation:
- Read wait-events next if the plan looks reasonable but runtime stalls.
- If the plan is clearly wrong, stop and fix plan issues before proceeding.

Notes:

The “explain‑plan” skill in this route teaches capturing and reading the actual cursor plan, not just the EXPLAIN PLAN estimate.
AWR/ASH may not be available in all environments and may require licensing.

Version scope and context‑budget discipline

Assume Oracle Database 19c as the baseline unless a skill states a higher requirement. For AI features, check per‑feature documentation: DBMS_VECTOR and many Select AI/AI Profiles examples are documented for 26ai; several AI capabilities are also available in Autonomous Database. Do not assume 19c availability unless a skill or doc explicitly states it. Label those steps clearly when you route.

Two habits keep assistants accurate and affordable:

Load one file or short index at a time, then summarize in five bullets.
Decide whether to stop, read one more, or hand off to action (SQLcl MCP in Article 3). Don’t blur routing with execution.

Why “route, don’t flood” holds up under pressure

Teams tend to bulk‑load context when deadlines loom. Ironically, progressive discovery pays off most when time is tight. db/SKILL.md compresses Oracle experience into short routes you can trust: read the executed plan before hunting waits, scope an AI Profile before experimenting with retrieval, and prove discovery and guards before you accept any schema change. Staying inside those lanes doesn’t slow you down; it eliminates the detours that burn days.

Make the front door easy to reach. The simplest path is to browse the repository in a web browser and open db/SKILL.md. If you prefer a local copy, install the Database domain directly:

npx skills add oracle/skills/db

This puts the domain files in your working directory so you can open db/SKILL.md immediately. Then set your assistant’s “Oracle Database” system prompt to begin with “Open db/SKILL.md,” and keep the progressive‑discovery loop in place until the next decision is truly to act.

Conclusion

Oracle Database Skills is not a PDF dump for models. It’s an operating method that starts with routing. Use db/SKILL.md as your first touch, load one file at a time, and stop before you wander into execution. In Article 3, we’ll introduce SQLcl MCP as the bounded action surface that pairs naturally with this approach. Until then: route → read one → summarize → decide.

Sources

Oracle Database Skills repository root: https://github.com/oracle/skills
Database router (db/SKILL.md): https://github.com/oracle/skills/blob/main/db/SKILL.md
Frameworks directory: https://github.com/oracle/skills/tree/main/db/frameworks
Performance directory: https://github.com/oracle/skills/tree/main/db/performance
Select AI examples (SHOW SQL, OBJECT_LIST, and data access controls): https://docs.oracle.com/en/database/oracle/oracle-database/26/selai/examples-using-select-ai.html
DBMS_XPLAN.DISPLAY_CURSOR (19c): https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/DBMS_XPLAN.html
Licensing Information User Manual (AWR/ASH availability/licensing): https://docs.oracle.com/en/database/oracle/oracle-database/19/dblic/index.html
DBMS_VECTOR (26ai): https://docs.oracle.com/en/database/oracle/oracle-database/26/arpls/DBMS_VECTOR.html

AI agents know SQL. Oracle Database Skills teach them Oracle

Mark Nelson — Wed, 13 May 2026 14:02:12 +0000

This is article 1 of 8 in my Oracle Database Skills series.

Most assistants can write SQL. That’s not the same as knowing Oracle Database. The difference shows up in production. A model that learned generic patterns can assume another vendor’s isolation semantics, borrow date arithmetic that silently miscounts in Oracle, rely on hints that “fix” one plan but fight the optimizer elsewhere, or forget Edition‑Based Redefinition (EBR) during a migration. Give that assistant a live connection and those differences turn into risk.

Oracle Database Skills change the operating model. Instead of hoping a generalist remembers every Oracle rule, you route it—one decision at a time—to Oracle‑authored, source‑backed instructions. When action is appropriate, you expose only small, named tools via Oracle MCP servers (MCP = Model Context Protocol), never a blank connection string. And you keep Oracle’s governance in the path so identity, scope, and evidence ride with every request. In short: route first, act through bounded tools, and let the database prove what happened.

Why generic SQL knowledge fails on Oracle Database

Large models generalize across vendors; your database does not. Oracle’s transaction semantics, time idioms, plan management, and governance are exactly where generic advice goes sideways.

Isolation and consistency are different in Oracle. Many public answers treat isolation levels as dials that change write visibility. Oracle’s multi‑version read consistency gives readers a clean snapshot but doesn’t use the same language or behavior as those engines. Ask a generalist assistant to “make this serializable” and you can get a non‑Oracle explanation—or an irrelevant fix. See Oracle Database Concepts on consistent reads for details.
Time math bites hard. DATE/TIMESTAMP/INTERVAL semantics and NLS/time zone interactions vary by vendor; Oracle requires vendor‑specific idioms. Skills provide tested patterns for Oracle SQL and PL/SQL so an assistant doesn’t have to guess which expression respects your NLS settings, time zones, and interval choices.
Plan stability demands a different order of operations. Oracle recommends maintaining accurate optimizer statistics and using SQL Plan Management (baselines) for stability; avoid over‑reliance on ad‑hoc hints in application code. Skills teach that progression so the assistant recommends fixes that survive the next gather‑stats job.
Governance cannot be an afterthought. “Connect and run” examples usually ignore Virtual Private Dat
abase (VPD), Unified Auditing, Fine‑Grained Auditing, Data Redaction, Transparent Data Encryption (TDE), and network ACLs/private endpoints. In Oracle, those are how you make AI access presentable to a DBA, a security reviewer, or an auditor. If you want to ship, keep those controls in the path.

Route first with Oracle Database Skills (progressive discovery)

The oracle/skills repository is not a doc dump. It’s installable operating instructions, loaded sparingly—one file at a time—so assistants (and humans) can make the next decision correctly without carrying 200 pages of context. The Database domain (oracle/skills/db) is organized the way you work: agent safety; features like Select AI, AI Profiles, and Vector Search; app frameworks; performance; DevOps and migrations; SQLcl; and security. The front door is a routing file: db/SKILL.md.

Progressive discovery narrows the model’s attention to what moves the work forward, preserves version truth, and leaves a clean review trail. Because the assistant reads only the next skill, it doesn’t mix versions or unrelated features. Skills mark Oracle Database 19c as the baseline and flag when you need Autonomous Database (Serverless) or Oracle Database 23ai/26ai features. Teams can see which Oracle sources the assistant consulted, in what order, and why.

A concrete path makes this real. Suppose you’re building retrieval‑augmented generation on Oracle. The route in db/SKILL.md steers you through Select AI profiles (to set provider and scope), then Vector Search basics (to choose the right data model and index), then DBMS_VECTOR (to make retrieval programmable). You don’t need AWR or EBR on day one. The route keeps you focused until you do.

Act through bounded tools: Oracle’s MCP surfaces

Sometimes the assistant must do more than explain. It needs to run a read‑only query, inspect a schema, or check a plan. That’s where Oracle’s MCP servers help: they expose small, named capabilities rather than hand the assistant a general‑purpose connection.

Local development: SQLcl MCP server. Built into SQLcl, it exposes a concise set of named tools—for example, to list saved connections, connect using a saved connection, and run SQL—and supports configurable “restrict levels,” with higher numbers enforcing tighter limits. As of SQLcl 25.4, the MCP server defaults to restrict level 4 (most restrictive). Confirm your version and configuration. Teams can set the most restrictive mode for local experiments. SQLcl MCP can also leave evidence when configured: it can log activity (for example, to a DBTOOLS$MCP_LOG table), set V$SESSION.MODULE and V$SESSION.ACTION to identifiable values (such as the MCP client and a client‑provided model/agent label), and tag LLM‑generated statements with a comment. See the SQLcl MCP docs linked below for version‑specific details.
Managed, governed execution: Autonomous Database (Serverless) MCP server. Enable it on a specific Autonomous Database (via an OCI free‑form tag) and you get a per‑database HTTP endpoint and authentication that serve built‑in tools or custom tools you define with DBMS_CLOUD_AI_AGENT.CREATE_TOOL. Identity and roles apply as usual. So do network ACLs and private endpoints, VPD policies, and Unified Auditing and Fine‑Grained Auditing when configured. If your team wants a controlled tool surface without hosting anything, this is the right shape: the database remains the control plane for what tools exist and who can use them.

The shared property is restraint. In both cases, the assistant gets the minimum set of named actions appropriate for the task, and Oracle‑native controls keep doing their job.

Keep Oracle governance in the path (trust and evidence)

Oracle’s governance features aren’t an appendix; they are the safety net that lets you ship. Roles and least privilege define what an assistant can reach. Network ACLs and private endpoints restrict egress. VPD enforces row‑level policies you already rely on. Unified Auditing and Fine‑Grained Auditing can be configured to record the activity you care about. Data Redaction and TDE protect sensitive data at query time and at rest. These controls are available and can be configured; they are not enabled by default in every environment.

The benefit for AI work is simple once you see it: your proof is in the database. When actions go through SQLcl MCP or the Autonomous Database (Serverless) MCP server, the same identity, scoping, and auditing options that protect your applications also protect your assistant. The question becomes less “Can we trust the agent?” and more “Show me the database evidence.”

Mini demo: install skills and open the routing door

Begin without touching a database or setting up MCP. Fetch the Database Skills domain and open the routing file. From there, pick the path that matches your role and objective.

You only need internet access, Node.js installed, and a text editor. This step does not connect to a database, handle credentials or secrets, or change any MCP restrict levels.

npx skills add oracle/skills/db

This installs the Database domain into your working directory. Open db/SKILL.md in your editor. If you’re an app developer wiring a Spring app, follow the frameworks route. If you’re an AI engineer, start with the agent and features routes (Select AI, AI Profiles, Vector) before you let any assistant write SQL. If you’re a DBA, begin with performance and security so the assistant speaks AWR/ASH/optimizer and respects governance. Keep the habit: load only the next file you need, then stop. That discipline keeps model context clean and your review surface small.

Where to find this in Oracle docs and repos

The instruction layer is the skills repo itself, with db/SKILL.md acting as the router. The controlled action layer is documented for both entry points: SQLcl MCP (restrict levels, tool catalog examples, saved connections, monitoring, activity logging and tagging) and the Autonomous Database (Serverless) MCP server (enablement via OCI free‑form tag, per‑database endpoint and authentication, custom tool publication, and governance integration). The trust layer is the familiar security stack: roles and privileges; network ACLs and private endpoints; VPD; Unified Auditing and Fine‑Grained Auditing when configured; Data Redaction; encryption. Each is a first‑class Oracle feature you can point to in docs and verify in your environment.

Source links:

Skills repo and routing (start at db/SKILL.md)
SQLcl MCP (using the server; logging/tagging; restrict levels)
Autonomous Database (Serverless) MCP server (enable and use)
Oracle Database Concepts — Consistent Reads/MVRC
Oracle SQL Language Reference — Data Types (DATE/TIMESTAMP/INTERVAL and NLS)
Optimizer statistics and SQL Plan Management
Oracle Database Security Guide (19c baseline)

Version scope and environment notes

Most skills target Oracle Database 19c as the baseline. Files that require features from Autonomous Database (Serverless) or newer Oracle Database 23ai/26ai releases—such as Select AI, AI Profiles, Vector Search, or the Autonomous Database (Serverless) MCP server—are labeled in the repo. If you work in a mixed‑version estate, treat those labels as gates and route accordingly. For hands‑on tries in this opener, you need only a local machine with git and a text editor. MCP client steps and database connectivity come later, when action is appropriate.

What’s out of scope (in this opener)

Enabling or configuring the Autonomous Database (Serverless) MCP server
Connecting to any database or handling credentials
Changing SQLcl MCP restrict levels
Configuring Unified Auditing or Fine‑Grained Auditing
Demonstrating Select AI or Vector Search live

A short story from the field

A team asked an assistant to “optimize a daily sales query.” The first answer added an index and a couple of hints that looked fine in isolation. The skills route would have sent it somewhere else: read the explain-plan and optimizer-stats files first; check cardinalities and stale stats; consider a plan baseline if volatility is the real problem. That path took longer but avoided chasing a hint that didn’t survive the next gather‑stats job. The difference wasn’t model IQ—it was having Oracle‑specific operating instructions and the habit of loading only what came next.

Where this series goes from here

Everything you need to begin is in your editor: the skills repo, the routing file, and the mental model—route, act, trust. We’ll build outward from that front door, showing how local and managed MCP surfaces work when action is warranted, and how Select AI and Vector Search improve reasoning close to your data. Expect short, source‑backed posts that follow the same grammar:

Route: pick a path in db/SKILL.md for your role and task.
Act: use SQLcl MCP locally or the Autonomous Database (Serverless) MCP server when you need controlled actions.
Guardrail: keep roles, ACLs/private endpoints, VPD, and auditing in‑path for evidence and scope.

The eight posts are organized into four groups:

Foundation 1 — this post; 2 — Route, Don’t Flood Mental model and db/SKILL.md as routing layer
Action 3 — SQLcl MCP; 4 — Managed MCP in Autonomous AI Database Local and remote bounded action surfaces
Intelligence 5 — Select AI and AI Profiles; 6 — Vector‑Native RAG NL2SQL reasoning quality and in‑database retrieval
Rollout 7 — Agent‑Safe Change Delivery; 8 — The Trust Layer Safe change workflows and enterprise governance

Conclusion: a safer default for Oracle‑backed AI

If your assistant can touch Oracle Database, “just let it connect” isn’t an acceptable plan. Put the skills repo between the model and the problem so it learns to work the Oracle way. When execution is appropriate, send it through SQLcl MCP or the Autonomous Database (Serverless) MCP server so actions are small, named, and governed. Keep Oracle’s controls—roles, ACLs, VPD, auditing, redaction, encryption—in the path so every action is scoped and traceable.