Skip to main content
Glama

OCI MCP Blueprint

Python License

Build, customize, package, and deploy a Python MCP server on Oracle Cloud Infrastructure.

This repository is a blueprint for teams that want to move from a local custom MCP server prototype to a cloud-ready service that can run on OCI Enterprise AI. The goal is to provide both a practical reference implementation and the supporting deployment infrastructure needed to adapt the server to real enterprise use cases.

The project currently includes:

  • a Python MCP server skeleton with a clear project structure;

  • two sample MCP tools that demonstrate the expected extension points;

  • centralized runtime configuration for local and cloud execution;

  • tests and specifications that document the intended behaviour;

  • local development instructions for running and validating the server;

  • a local Agent Factory for building, publishing, and deploying the server to OCI Enterprise AI Hosted Applications.

Project Scope

The blueprint focuses on a custom MCP server implemented in Python. It is meant to be adapted by replacing or extending the sample MCP capabilities while keeping the protocol boundary, configuration, packaging, and deployment flow easy to understand.

The repository is intentionally scoped to:

  • MCP server implementation patterns;

  • sample Python code for tools, resources, and prompts;

  • local validation and automated tests;

  • OCI-compatible packaging and deployment;

  • a factory workflow for OCI Enterprise AI deployments.

It is not intended to become a collection of unrelated agents, clients, framework examples, or deployment targets.

Related MCP server: oci-mcp

Development Model

This project follows a spec-driven development workflow. Meaningful features, protocol changes, deployment changes, and behavioural changes should start with a specification under specs/ before implementation.

The first sample server design is documented in specs/001-sample-fastmcp-server.md. It defines a Python FastMCP server with two example tools, get_schema and get_data, backed by hard-coded fake database metadata and simulated rows.

The expected local Conda environment name is:

conda activate oci-mcp-blueprint

Install the package and development dependencies:

python -m pip install -e ".[dev]"

Optional local environment templates are documented in .env.example. Copy the values you need into an ignored .env file or export them in your shell before starting the local server, client, or deployment factory.

Run the sample MCP server:

python -m oci_mcp_blueprint.server

The server runs with FastMCP Streamable HTTP only. It binds to 0.0.0.0:8080 and serves the MCP endpoint at /mcp by default.

For local-only binding:

MCP_SERVER_HOST=127.0.0.1 python -m oci_mcp_blueprint.server

The same entry point is available as a console script:

oci-mcp-blueprint-server

Test a local or remote MCP endpoint with the command-line client:

oci-mcp-blueprint-client --url http://127.0.0.1:8080/mcp list-tools
oci-mcp-blueprint-client --url http://127.0.0.1:8080/mcp get-schema
oci-mcp-blueprint-client --url http://127.0.0.1:8080/mcp get-data "status == shipped"

For a protected remote deployment:

oci-mcp-blueprint-client \
  --url https://example-hosted-app.example.com/mcp \
  --bearer-token "$MCP_CLIENT_BEARER_TOKEN" \
  list-tools

Run the project checks:

python -m black --check .
python -m pylint src tests
python -m pytest

Run the Docker Compose deployment:

./start_server.sh
oci-mcp-blueprint-client --url http://127.0.0.1:8080/mcp list-tools
./stop_server.sh

OCI Hosted Deployment Factory

The OCI Hosted Deployment Factory is a local web application that helps you deploy this blueprint's MCP server to OCI Enterprise AI Hosted Applications.

It is not part of the deployed MCP runtime. Instead, it is an operator tool that runs on your workstation or jump host and guides the deployment workflow:

  • collects OCI, OCIR, Hosted Application, and MCP runtime settings;

  • validates inputs and OCIR credentials;

  • builds the repository root Dockerfile as the MCP server image;

  • pushes the image to OCI Container Registry;

  • creates or reuses the OCI Enterprise AI Hosted Application;

  • creates a Hosted Deployment from the pushed image;

  • validates the hosted MCP endpoint with the standard MCP list_tools operation;

  • returns the hosted MCP Streamable HTTP URL.

The factory itself has two local services:

  • agent-factory/api: FastAPI backend for deployment orchestration.

  • agent-factory/ui: Next.js UI for guided input and progress tracking.

The deployed runtime remains the Python FastMCP server from src/oci_mcp_blueprint; it exposes Streamable HTTP at /mcp and does not include the factory UI or API.

Start the factory locally:

./start_factory.sh --build

Then open the factory UI at:

http://localhost:3100

The factory builds the root MCP server image, pushes it to OCIR, creates an OCI Enterprise AI Hosted Application deployment, validates the hosted MCP endpoint with list_tools, and returns the hosted /mcp URL. See docs/oci-hosted-deployment-factory.md for details.

Sample Tools

The server is intentionally a sample server. The schema and rows are fake, hard-coded, deterministic data used only to demonstrate how to build a modular MCP server.

get_schema

Returns a structured description of the fake order-management database schema. It supports:

  • table_name: optional table filter;

  • include_sample_rows: optional flag to include fake rows in the schema response.

get_data

Returns simulated rows from the fake database. It accepts:

  • condition: required demo filter expression;

  • table_name: optional table name, default orders;

  • limit: optional row limit, default 10.

The condition is not SQL and is never executed against a database. Supported forms are:

field == value
field != value
field contains value

Example conditions:

status == shipped
customer_name contains acme
total_amount != 0

Project Layout

src/oci_mcp_blueprint/
  client.py
  config.py
  server.py
  domain/
    fake_database.py
    schema_service.py
    data_service.py
  mcp/
    models.py
    tools.py
tests/unit/
specs/
agent-factory/

Domain logic is separated from FastMCP registration so that another MCP server can be created by replacing the domain package and adapting the tool layer.

Runtime transport selection is intentionally not exposed. This blueprint supports only Streamable HTTP because it targets OCI Enterprise AI hosted deployment.

Documentation

Security Notes

Do not commit secrets, private keys, API keys, OCI OCIDs, private endpoints, or environment-specific identifiers. Runtime configuration should use environment variables, ignored local configuration files, or documented placeholders.

The committed .env.example file contains only safe local defaults and empty placeholders. Keep real tokens, passwords, OCIDs, and environment-specific URLs in an ignored .env file or an external secret store.

Current Status

The repository contains the first sample FastMCP implementation and a local Docker Compose deployment. The next major step is the OCI Enterprise AI deployment factory.

Available Tools

2 tools
get_dataA

Return simulated rows from the fake sample database using a small demo condition language. This tool never executes SQL.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of rows to return.
conditionYesDemo condition such as `status == shipped`.
table_nameNoFake table to filter.orders

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses that the tool is simulated, read-only (never executes SQL), and uses a demo condition language. It does not discuss error handling or side effects, but the core behavioral trait (safe simulation) is clearly conveyed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core purpose, and every phrase is informative without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (3 parameters, all documented in schema) and the existence of an output schema, the description provides sufficient context: purpose, simulated nature, example condition, and explicit no-SQL guarantee.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers all 3 parameters with descriptions, achieving 100% coverage. The description adds value by providing an example for 'condition' (e.g., `status == shipped`) and contextualizing the parameters within a fake database environment.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns simulated rows from a fake database using a demo condition language, and explicitly says it never executes SQL. This distinguishes it from the sibling tool 'get_schema', which likely returns schema definitions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context that this tool is for demo/testing purposes (simulated, fake sample database) and that it does not execute real SQL. However, it does not explicitly list when not to use it or alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_schemaA

Return the fake, hard-coded sample database schema used by the OCI MCP Blueprint demo server.

ParametersJSON Schema
NameRequiredDescriptionDefault
table_nameNoOptional fake table name. When omitted, all tables are returned.
include_sample_rowsNoWhether to include hard-coded sample rows.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses the schema is 'fake' and 'hard-coded', which is a key behavioral trait. No other hidden behaviors are mentioned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that efficiently conveys purpose and context, with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool (2 optional params, no nested objects, output schema exists), the description is complete and sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description does not add additional meaning beyond the schema's parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Return' and the resource 'fake, hard-coded sample database schema', distinguishing it from the sibling tool 'get_data'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions it's for the demo server but does not explicitly state when to use this tool versus alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 2 tool updatesv0.1.0
    • First observedget_data
    • First observedget_schema

TDQS

A4.3/5.0
Disambiguation5/5

The two tools have clearly distinct purposes: get_data returns simulated data, while get_schema returns the schema definition. No overlap or ambiguity.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern (get_data, get_schema), making the naming predictable and clear.

Tool Count4/5

With only 2 tools, the server is intentionally minimal as a demo blueprint. While the count is low, it aligns with the server's stated purpose of providing a simple, fake sample database demonstration.

Completeness4/5

The tool set covers the essential operations for a demo database: retrieving the schema and querying data. There are no obvious gaps given the server's limited scope, though it lacks more advanced query or management features.

Maintenance

ActivityStale
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    A production-ready Python template for building MCP servers with enterprise features including registry integration, configuration management, structured logging, and extensible patterns for tools, resources, and prompts.
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    Model Context Protocol (MCP) server exposing Oracle Cloud Infrastructure tools, resources and prompts.
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    MCP server for Oracle Container Engine for Kubernetes (OKE) that enables inspection, querying, and troubleshooting of OKE clusters through safe, composable tools.
    Universal Permissive v1.0
  • A
    license
    A
    quality
    D
    maintenance
    MCP server for Oracle Cloud Infrastructure (OCI) that provides tools to manage Compute, Object Storage, Block Storage, Networking, Autonomous Database, and IAM via the official OCI SDK.
    23
    67
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/luigisaetta/oci-mcp-blueprint'

If you have feedback or need assistance with the MCP directory API, please join our Discord server