Model Context Protocol (MCP): From Local Tools to Reusable AI Integrations

1. What Is MCP?

Model Context Protocol, or MCP, is an open standard that gives AI applications a consistent way to connect with:

• External tools

• Databases

• Files

• APIs

• Cloud services

• Enterprise systems

The easiest analogy is:

MCP is like USB-C for AI applications.

USB-C provides one common connection for different devices. Similarly, MCP provides one common protocol through which different AI applications can discover and use external capabilities.

2. The Problem MCP Solves

Before MCP, every AI application needed custom integration code for every external system.

If there are:

• N AI applications

• M external systems

Developers may need to build and maintain as many as:

N × M custom integrations

For example, four AI applications connecting independently to five systems could require many separate integration paths.

MCP introduces a common layer:

AI Applications 
      ↓ 
MCP Clients 
      ↓ 
MCP Servers 
      ↓ 
Tools, APIs, databases and cloud services

Applications no longer need to understand the internal implementation of every system. They communicate through the MCP protocol.

3. MCP Architecture

MCP follows a host-client-server architecture.

MCP Host

The MCP host is the AI application with which the user interacts.

Examples can include:

• An AI agent

• An IDE

• A desktop assistant

• A custom enterprise application

The host manages the LLM and one or more MCP clients.

MCP Client

The MCP client is the protocol component inside the host.

The client:

• Connects to an MCP server

• Negotiates protocol capabilities

• Discovers tools, resources, and prompts

• Sends requests

• Receives results

• Passes results back to the AI application

Each client normally maintains a dedicated connection with one MCP server. A host can create multiple clients when it needs to connect to multiple servers.

MCP Server

The MCP server exposes controlled capabilities from an external system.

A server might expose:

• Database queries

• Cloud-management operations

• File access

• Cost and usage information

• GitHub operations

• Monitoring data

• Enterprise workflows

Complete Flow

User 
  ↓ 
AI Application or Agent 
  ↓ 
LLM 
  ↓ 
MCP Client 
  ↓ 
MCP Server 
  ↓ 
Tool, API, database or cloud service

4. MCP Core Primitives

MCP servers primarily expose three primitives.

Tools: Do Something

Model-controlled

Tools allow the model to request an action.

Examples:

• Add two numbers

• Query a database

• Create an issue

• Retrieve cloud usage

• Send a message

• Run a test

The model reviews the available tool names, descriptions, and input schemas before selecting a tool.

Resources: Read Something

Application-controlled

Resources provide information that the application can load into the model’s context.

Examples:

• A project file

• Database schema

• Configuration setting

• API response

• Documentation page

Prompts: Structure Something

User-controlled

Prompts are reusable templates that help users initiate structured interactions.

Examples:

• Bug-report template

• Code-review prompt

• Troubleshooting template

• Document-summary prompt

Easy Way to Remember 

Primitive	Meaning	Controlled by
Tools	Do something	Model
Resources	Read something	Application
Prompts	Structure something	User

5. MCP Connection Lifecycle

An MCP connection can be understood through four stages.

1. Initialize

The client connects to the server and exchanges protocol versions and supported capabilities.

2. Discover

The client asks the server what capabilities are available.

For example:

tools/list 
resources/list 
prompts/list

3. Operate

The AI model selects an appropriate capability. The client sends the request, the server performs the operation, and the result is returned.

For a tool, the main method is:

tools/call

4. Shutdown

The client closes the transport and ends the MCP session.

Lifecycle Summary

Initialize → Discover → Operate → Shutdown

6. MCP and JSON-RPC 2.0

MCP uses JSON-RPC 2.0 for structured communication.

A JSON-RPC request generally contains:

• jsonrpc: Protocol version

• id: Identifier used to match the response

• method: Operation being requested

• params: Input arguments

A response contains either:

• result: Successful output

• error: Failure information

Simplified Tool Request

{ 
  "jsonrpc": "2.0", 
  "id": 2, 
  "method": "tools/call", 
  "params": { 
    "name": "multiply", 
    "arguments": { 
      "a": 15, 
      "b": 8 
    } 
  } 
}

Simplified Response

{ 
  "jsonrpc": "2.0", 
  "id": 2, 
  "result": { 
    "content": [ 
      { 
        "type": "text", 
        "text": "120" 
      } 
    ] 
  } 
}

MCP SDKs and frameworks normally handle these messages, so application developers do not have to construct every JSON-RPC message manually.

 

7. MCP Transport Mechanisms

STDIO Transport

STDIO is commonly used when the MCP server runs locally.

MCP Client ← stdin/stdout → MCP Server

Typical characteristics:

• The host starts the server as a child process.

• Communication happens through standard input and output.

• The server usually runs on the same machine.

• It is useful for local tools, files, Git, shell commands, and development demonstrations.

Streamable HTTP Transport

Streamable HTTP is designed for remote MCP services.

MCP Client ← HTTPS → Remote MCP Server

Typical characteristics:

• The server runs as an HTTP service.

• Multiple clients can connect to the service.

• The server can be hosted remotely.

• Standard authentication and authorization mechanisms can be applied.

Scenario	Suitable transport
Local server started by the application	STDIO
Remote or cloud-hosted MCP service	Streamable HTTP

 

8. Demonstration 1: Agent Without MCP

In the first demonstration, the tools are written directly inside the agent application.

Architecture

User 
  ↓ 
Agent application 
  ↓ 
LLM 
  ↓ 
Local Python functions

A single file contains:

• The LLM configuration

• Agent logic

• Tool definitions

• Tool execution

• Error handling

Example: first_agent.py

from langchain.agents import create_agent 
from langchain.tools import tool 
 
 
@tool 
def add(a: float, b: float) -> float: 
    """Add two numbers.""" 
    return a + b 
 
 
@tool 
def subtract(a: float, b: float) -> float: 
    """Subtract the second number from the first.""" 
    return a - b 
 
 
@tool 
def multiply(a: float, b: float) -> float: 
    """Multiply two numbers.""" 
    return a * b 
 
 
@tool 
def divide(a: float, b: float) -> float: 
    """Divide the first number by the second.""" 
    if b == 0: 
        raise ValueError("Division by zero is not allowed.") 
    return a / b 
 
 
tools = [add, subtract, multiply, divide] 
 
agent = create_agent( 
    model="your-configured-model", 
    tools=tools 
) 
 
result = agent.invoke( 
    { 
        "messages": [ 
            { 
                "role": "user", 
                "content": "Multiply 15 by 8 and then divide the result by 3." 
            } 
        ] 
    } 
) 
 
print(result)

What Happens?

1. The user asks a mathematical question.

2. The LLM sees the locally defined tool descriptions.

3. The LLM selects multiply.

4. The application runs the local multiply() function.

5. The LLM then selects divide.

6. The application runs the local divide() function.

7. The results are returned to the LLM.

8. The LLM prepares the final response.

Limitations

The program works, but the tools are tightly coupled to the agent.

• Only this application can use these tool definitions directly.

• Another agent may need another copy of the same functions.

• A tool change must be repeated across applications.

• Tool registration and execution belong to the agent application.

• Reuse across different AI clients becomes difficult.

For a very small application, this approach may still be simpler than introducing MCP.

9. Demonstration 2: The Same Agent Using MCP

With MCP, the application and tool implementation are separated.

Agent application                 MCP server 
-----------------                 ---------- 
LLM                               add() 
MCP client      ← JSON-RPC →       subtract() 
                                  multiply() 
                                  divide()

The demonstration now contains two independent programs:

1. MCP server: Provides the mathematical tools.

2. MCP client: Connects the agent to the server.

9.1 MCP Math Server

File: mcp_math_server.py

from mcp.server.fastmcp import FastMCP 
 
mcp = FastMCP("Math") 
 
 
@mcp.tool() 
def add(a: float, b: float) -> float: 
    """Add two numbers.""" 
    return a + b 
 
 
@mcp.tool() 
def subtract(a: float, b: float) -> float: 
    """Subtract the second number from the first.""" 
    return a - b 
 
 
@mcp.tool() 
def multiply(a: float, b: float) -> float: 
    """Multiply two numbers.""" 
    return a * b 
 
 
@mcp.tool() 
def divide(a: float, b: float) -> float: 
    """Divide the first number by the second.""" 
    if b == 0: 
        raise ValueError("Division by zero is not allowed.") 
    return a / b 
 
 
if __name__ == "__main__": 
    mcp.run(transport="stdio")

What the Server Does

1. FastMCP("Math") creates an MCP server.

2. @mcp.tool() exposes each Python function as an MCP tool.

3. Function docstrings become useful tool descriptions.

4. Function parameters define the tool input schema.

5. STDIO allows the client to launch and communicate with the local server.

The tool implementation is no longer defined inside the agent.

9.2 MCP Client and Agent

File: first_agent_with_mcp.py

import asyncio 
import os 
import sys 
 
from langchain.agents import create_agent 
from langchain_mcp_adapters.client import MultiServerMCPClient 
 
 
async def main(): 
    current_directory = os.path.dirname(os.path.abspath(__file__)) 
    server_path = os.path.join( 
        current_directory, 
        "mcp_math_server.py" 
    ) 
 
    client = MultiServerMCPClient( 
        { 
            "math": { 
                "command": sys.executable, 
                "args": [server_path], 
                "transport": "stdio" 
            } 
        } 
    ) 
 
    tools = await client.get_tools() 
 
    print("Discovered MCP tools:") 
    for discovered_tool in tools: 
        print(f"- {discovered_tool.name}") 
 
    agent = create_agent( 
        model="your-configured-model", 
        tools=tools 
    ) 
 
    result = await agent.ainvoke( 
        { 
            "messages": [ 
                { 
                    "role": "user", 
                    "content": ( 
                        "Multiply 15 by 8 and then divide " 
                        "the result by 3." 
                    ) 
                } 
            ] 
        } 
    ) 
 
    print(result) 
 
 
if __name__ == "__main__": 
    asyncio.run(main())

The exact model configuration depends on the LLM provider and the version of the agent framework being used.

9.3 What Happens Internally?

Discovery

When the client connects, the client requests the available tools:

Client → tools/list → Server

The server returns:

• Tool names

• Tool descriptions

• Input schemas

For example:

add 
subtract 
multiply 
divide

Tool Selection

The LLM reviews the user’s question and the discovered tool descriptions.

The LLM decides that multiply is required first.

Tool Execution

LLM 
↓ 
Agent 
↓ 
MCP Client 
↓ tools/call 
MCP Server 
↓ 
multiply(15, 8) 
↓ 
120

The result travels back through the same layers.

Final Answer

The LLM receives the tool result and continues its reasoning. The LLM does not need to know whether the result came from:

• A local Python function

• A local MCP server

• A remote MCP server

• A cloud API wrapped by an MCP server

The LLM primarily sees tool descriptions, arguments, and results.

10. Without MCP vs With MCP

Area	Without MCP	With MCP
Tool location	Inside the agent	Inside an MCP server
Discovery	Tools registered manually	Tools discovered from the server
Invocation	Local function call	Standardized MCP tool call
Reuse	Usually application-specific	Reusable by compatible clients
Maintenance	Update every application	Update the server
Coupling	Tightly coupled	Loosely coupled
External systems	Custom integration per application	Server provides a standard interface
Responsibility	Application owns integration	Server owns capability implementation

Core Difference

Without MCP

LLM asks for a tool 
        ↓ 
Application calls local function 
        ↓ 
Application receives result 
        ↓ 
Result returns to LLM

With MCP

LLM asks for a tool 
        ↓ 
Application uses MCP client 
        ↓ 
MCP client calls MCP server 
        ↓ 
MCP server executes the tool 
        ↓ 
MCP server returns the result 
        ↓ 
Result returns to LLM

11. Why Start with a Math MCP Server?

A Math MCP server is useful for learning because:

• The functions are easy to understand.

• Inputs and outputs are predictable.

• No cloud credentials are required.

• Client-server communication is easier to debug.

• Tool discovery and invocation are visible.

However, using MCP only to calculate 15 × 8 is normally excessive. A local Python function is simpler for one small application.

The Math MCP server is a protocol-learning demonstration, not the strongest business justification for MCP.

MCP becomes more valuable when the server:

• Wraps an external API

• Provides enterprise data

• Is reused by several applications

• Requires centralized security or maintenance

• Is published and maintained by the system owner

12. From Math MCP to Oracle Usage MCP

The additional slides compare two MCP implementations with different ownership boundaries.

Math MCP Server

Our MCP client 
      ↓ STDIO and JSON-RPC 
Our Math MCP server 
      ↓ Python calls 
Our local mathematical functions

In this demonstration, the development team owns everything:

• MCP client code

• MCP server code

• Mathematical functions

• Tool descriptions

• Error handling

• Maintenance

Oracle Usage MCP Server

Our MCP client 
      ↓ MCP connection 
Oracle OCI Usage MCP server 
      ↓ OCI service integration 
OCI Usage service

In this design:

• The application team writes or configures the client.

• Oracle publishes and maintains the OCI Usage MCP server.

• The MCP server exposes OCI usage capabilities.

• The server connects to the underlying OCI Usage service.

The official Oracle MCP repository includes an OCI Usage MCP Server for interaction with the OCI Usage service and documents STDIO and HTTP streaming execution modes.

13. What Stays the Same and What Changes?

What Stays the Same

From the client’s point of view, both scenarios follow a similar pattern:

• Establish an MCP connection

• Discover available tools

• Read tool descriptions and schemas

• Select a tool

• Pass arguments

• Receive structured results

What Changes

The ownership and implementation boundary change.

Area	Math MCP	OCI Usage MCP
Client	Written by us	Written or configured by us
Server	Written by us	Published by Oracle
Underlying capability	Local Python functions	OCI Usage service
Main purpose	Learn MCP mechanics	Retrieve cloud-usage information
Maintenance	Our responsibility	Server publisher maintains server implementation
External dependency	None	OCI environment and authorization

14. OCI Usage MCP Server Details

According to Oracle’s reference repository, the OCI Usage MCP Server provides tools for interacting with the OCI Usage service. Oracle’s repository contains MCP reference implementations for managing and interacting with Oracle products.

Publisher

The server is provided in Oracle’s MCP repository.

Capability Wrapped

The server wraps OCI usage functionality rather than performing a simple local calculation.

Example Tool

The screenshots show a summarized-usage capability that accepts usage-related inputs such as:

• Tenant identifier

• Start time

• End time

• Grouping

• Granularity

• Query type

The actual available tool names and schemas should always be confirmed through server discovery and the server’s current documentation.

Transport

The Oracle repository documents execution through STDIO and an HTTP streaming mode for the OCI Usage MCP Server.

15. Conceptual OCI Usage Client Configuration

The following is a simplified learning example based on the architecture shown in the slides. Environment names and authentication requirements should be validated against the current Oracle server documentation before use.

import os 
 
from mcp import StdioServerParameters 
 
 
server_parameters = StdioServerParameters( 
    command="uvx", 
    args=["oracle.oci-usage-mcp-server"], 
    env={ 
        **os.environ, 
        "OCI_CONFIG_PROFILE": "DEFAULT" 
    } 
)

The configuration tells the MCP client:

1. Which command starts the server

2. Which package or executable should run

3. Which environment and OCI profile should be used

4. Which transport connects the client and server

The current Oracle repository is the appropriate source for installation, package, authentication, configuration, and supported-tool details.

16. Suggested OCI Usage Demo

Demo Objective

Demonstrate that the agent can retrieve OCI usage information without embedding OCI SDK calls directly inside the agent.

Demo Flow

User asks an OCI usage question 
             ↓ 
LLM identifies the usage tool 
             ↓ 
Agent sends the request through the MCP client 
             ↓ 
Oracle Usage MCP server validates the request 
             ↓ 
Server communicates with the OCI Usage service 
             ↓ 
Structured usage data is returned 
             ↓ 
LLM explains the result

Example User Prompts

Subject to the tools and permissions exposed by the configured server:

• “Summarize OCI usage for the selected period.”

• “Group OCI usage by service.”

• “Show usage at daily granularity.”

• “Compare usage categories returned for the requested period.”

• “Explain the main components in the usage response.”

These are suggested demonstration prompts. Available parameters and operations must be validated through the server’s discovered tool schemas.

17. Demo Presentation Plan

Demo A: Without MCP

Show the audience:

1. A single Python agent file

2. Four locally defined mathematical tools

3. Manual tool registration

4. A calculation performed by the agent

5. The coupling between the agent and functions

Message for the Audience

The agent can use tools, but the application owns and maintains every integration.

Demo B: With a Local Math MCP Server

Show the audience:

1. mcp_math_server.py

2. Tools exposed with @mcp.tool()

3. first_agent_with_mcp.py

4. MCP client configuration

5. Dynamic tool discovery

6. Tool execution through the server

7. The same final result

Message for the Audience

The calculation has not changed. The integration boundary has changed.

Demo C: With Oracle Usage MCP Server

Show the audience:

1. The application-side MCP configuration

2. Server startup or remote connection

3. Discovered OCI usage tools

4. The discovered tool schema

5. A natural-language usage request

6. The structured result returned by the server

7. The explanation generated by the LLM

Message for the Audience

The application consumes a reusable capability published around an external system instead of implementing the underlying service integration directly.

18. Why MCP Makes an Agent Better

Write or Integrate Once

A capability exposed by an MCP server can be consumed by different compatible applications, subject to configuration and authorization.

Dynamic Discovery

The client can learn which tools are available from the server rather than maintaining a hardcoded list.

Centralized Maintenance

The server implementation can be updated independently from each agent application.

Multi-Server Composition

A host can connect to multiple MCP servers.

For example:

AI Agent 
├── OCI Usage MCP server 
├── Database MCP server 
├── GitHub MCP server 
├── File-system MCP server 
└── Documentation MCP server

The host coordinates these connections and gives the LLM the relevant capabilities.

Clear Responsibility Boundaries

LLM 
Chooses the capability 
 
MCP Client 
Manages the protocol connection 
 
MCP Server 
Exposes and executes controlled capabilities 
 
External System 
Provides the underlying data or operation

19. Security Considerations

MCP standardizes communication, but MCP does not automatically make every integration secure. 

Before connecting an MCP server:

• Use trusted server implementations.

• Review tool descriptions and source documentation.

• Apply least-privilege access.

• Protect credentials and tokens.

• Avoid placing secrets in prompts.

• Validate tool arguments.

• Add appropriate authorization.

• Log important operations.

• Confirm what data leaves the local environment.

• Require user approval for sensitive or destructive actions.

• Prefer read-only access for introductory demonstrations.

Internal MCP learning guidance also emphasizes reviewing server documentation, using least privilege, protecting credentials, and understanding what a server can access before enabling it.

20. When MCP Helps Most

MCP is valuable when:

• The tool communicates with an external service.

• Several agents need the same capability.

• A vendor publishes a supported server.

• Tool implementations must be maintained centrally.

• Applications need dynamic discovery.

• Multiple servers need to be combined.

• Security and authorization boundaries must be explicit.

MCP may not be necessary when:

• There is only one small local function.

• The capability is used by one application only.

• No reuse or external integration is expected.

• Direct code is simpler and easier to maintain.

Use MCP because the integration is reusable or external, not simply because MCP is available.

21. Final Takeaway

MCP does not replace the LLM or the agent.

MCP provides a standard connection layer between the agent and external capabilities.

Agent = LLM + Tools + Execution Loop 
 
MCP = Standard connection between the agent and external capabilities

Remember the complete picture:

• Tools: Do something

• Resources: Read something

• Prompts: Structure something

• Lifecycle: Initialize, discover, operate, and shut down

• Protocol: JSON-RPC 2.0

• Transports: STDIO and Streamable HTTP

• Architecture: Host, client, and server

• Beginner demo: Local Math MCP server

• Real-world demo: Oracle OCI Usage MCP server

• Main value: Build or integrate capabilities once and reuse them across compatible AI applications

One-Sentence Summary

Without MCP, every agent owns its integrations; with MCP, agents discover and consume reusable capabilities through a standard protocol.