【OCI】Database Tools MCP Server における認可実装を確認する In May 2026, Oracle Cloud Infrastructure's Database Tools service gained MCP Server functi…

On May 12, 2026, Oracle Cloud Infrastructure expanded its Database Tools service by adding MCP Server functionality, opening a new pathway for AI agents and developer tools to interact with Oracle databases through the Model Context Protocol. While the release note announcement was brief, the authorization model underpinning that access deserves careful scrutiny — and that is precisely what this article sets out to examine.

Database Tools is an OCI managed service that has long handled the complexity of database connectivity: it stores connection profiles, manages credentials through OCI Vault, and abstracts network routing so developers do not need to wrestle with low-level JDBC configuration. Layering an MCP Server on top of this existing infrastructure is a logical progression. The service already knows how to broker a database connection securely; MCP simply exposes that brokering capability to AI runtimes that speak the protocol, enabling tool calls such as listing schemas, describing tables, and executing SQL queries.

The authorization question is the most consequential design decision in any MCP implementation. Based on what is publicly known about the OCI platform, the Database Tools MCP Server appears to integrate with OCI IAM for both authentication and policy-based access control. Clients connecting to the MCP endpoint would be expected to present valid OCI credentials — an API key, an instance principal token, or a resource principal — and IAM policies would then govern which connection profiles those clients are permitted to use. This approach avoids introducing a separate credential type specific to MCP and aligns with how other OCI services enforce least-privilege access.

Secret management is the other critical layer. OCI Vault integration, a feature that Database Tools has offered since earlier releases, likely ensures that database passwords are retrieved server-side at connection time rather than being passed through the MCP message stream. This design choice meaningfully reduces the risk that a compromised MCP session exposes raw database credentials to an unauthorized party.

The broader ecosystem context adds useful perspective. Since late 2025, all major cloud providers have been releasing MCP-compatible services at a rapid pace. AWS has added MCP support to Bedrock and Lambda integrations, Azure has experimented with MCP endpoints for Cosmos DB and SQL Server, and Google Cloud has published MCP-compatible tooling for BigQuery. The authorization strategies diverge considerably: some implementations use OAuth 2.0 bearer tokens exchanged at the MCP handshake level, while others bind authorization tightly to the platform's native IAM system — the path OCI appears to have chosen.

Each approach carries trade-offs. IAM-native authorization offers deep integration with existing cloud governance policies and audit trails, but it can introduce friction for clients that originate outside the cloud environment, such as a developer's local IDE or a third-party AI assistant that does not natively understand OCI principals. OAuth-based approaches are more portable but require an additional token-exchange layer and careful lifecycle management of token scopes and expiry.

The MCP specification itself has been a moving target. Its authorization section in particular has been revised multiple times as the open-source community negotiates a consensus model, and commercial implementors have sometimes made pragmatic choices that do not fully align with the latest draft. This makes implementation-level reviews like the one described in this article genuinely useful: the gap between specification intent and production behavior is not always visible in documentation alone. For teams considering MCP-based database access on OCI, understanding the exact authorization boundary — including whether individual tool calls can be gated separately under IAM policy — is essential groundwork before committing to a production architecture.