mcp-catalog-oracle

An obot MCP catalog containing an Oracle Database connector.

Laid out the same way as obot-platform/mcp-catalog: one flat <service>.yaml per MCP server at the repository root, no folder per entry.

Entry	oracle.yaml
Upstream server	hdcola/mcp-server-oracle (MIT, PyPI mcp-server-oracle)
Runtime	uvx — obot runs the PyPI package directly; no image to build
Credential	ORACLE_CONNECTION_STRING (sensitive)

Adding it to obot

Point an obot MCP catalog at this repository, or copy oracle.yaml into an existing catalog. obot reads every *.yaml at the root and turns each into an MCPServerCatalogEntry.

Entry format

Fields map 1:1 onto obot's MCPServerCatalogEntryManifest (apiclient/types/mcpserver.go). Required for every entry:

Field	Notes
name	Display name
entryKey	Stable unique key — do not change once published
serverUserType	singleUser or multiUser
shortDescription	One line, shown in the catalog list
description	Markdown; the connect instructions users actually read
icon	Absolute URL
runtime	uvx · npx · containerized · remote · composite

Then exactly one runtime block: uvxConfig, npxConfig, containerizedConfig, remoteConfig, or compositeConfig. Optional: repoURL, metadata.categories, env[], toolPreview[].

env[] entries take key, name, required, sensitive, description. Mark anything containing a secret sensitive: true — obot then stores it as a credential and never displays it back.

Why uvx rather than containerized

Every entry in the upstream obot catalog is containerized or remote, because obot builds and publishes an image for each one (ghcr.io/obot-platform/mcp-images/...). This catalog has no such build pipeline, so pointing at an image under that namespace would name something that does not exist.

uvx is a first-class obot runtime and needs no image: obot runs uvx mcp-server-oracle and speaks to it over stdio. If you later publish your own image, swap the last two lines of oracle.yaml for:

runtime: containerized
containerizedConfig:
  image: ghcr.io/<your-org>/mcp-images/oracle:1.0.1
  port: 8099
  path: /
  args:
    - mcp-server-oracle

A note on write access

The upstream server exposes exec_dml_sql, exec_ddl_sql and exec_pro_sql — it can modify data and drop objects. The catalog entry says so plainly at the top of its description. The real control is the database account in the connection string: scope it to what you intend to allow, and prefer a read-only user for analysis work.

Validating

node scripts/validate.mjs

Checks every *.yaml for the required fields, a known runtime, a matching runtime config block, unique entryKeys, and that any env var whose name suggests a secret is marked sensitive.

Other Oracle MCP servers considered

• oracle/mcp — Oracle's own repo (UPL-1.0). Includes dbtools-mcp-server (SQL via OCI Database Tools), oracle-db-doc-mcp-server, plus ~25 OCI service servers. First-party, but the database server installs from source (pip install -r requirements.txt) and expects OCI CLI profile configuration, so it needs a published image before it fits a catalog entry.
• hdcola/mcp-server-oracle — used here. Community, MIT, published to PyPI, one connection-string variable, direct SQL. Installs with uvx and needs no OCI account.

If you want the first-party Oracle server instead, build an image around dbtools-mcp-server and use the containerized block above.