DEV Community: Dineshsuriya D

Python Code Obfuscation: A Practical Guide to Protecting Your IP

Dineshsuriya D — Mon, 01 Jun 2026 20:15:26 +0000

You've built something valuable in Python. Maybe it's a proprietary algorithm, a business logic engine, or an AI application with carefully crafted prompts. Now you need to distribute it — but here's the problem: Python source code is essentially an open book.

Unlike compiled languages where you ship binaries, Python's interpreted nature means your .py files go wherever your application goes. Anyone can open them in a text editor and see exactly how your code works.

So, how do you protect your intellectual property while still distributing Python applications?

In this guide, I'll walk you through the landscape of Python obfuscation tools, explain why I chose Nuitka for my projects, and share a practical solution for protecting data files that Nuitka can't handle on its own.

Your Options for Python Obfuscation

Let's look at the main contenders:

PyArmor

PyArmor encrypts your Python scripts and decrypts them at runtime. It's straightforward to use and offers multiple obfuscation modes.

The catch? It requires a commercial license for enterprise use. The trial version has limitations, and if you're building a product for commercial distribution, you'll need to pay up. For some teams, that's fine. For others (especially startups or open-source-adjacent projects), it's a dealbreaker.

Also worth noting: your protected code still needs a Python interpreter to run, and there's runtime overhead from the decryption process.

PyInstaller

I see this mentioned in obfuscation discussions a lot, but let me be clear: PyInstaller is a packaging tool, not an obfuscation tool.

Yes, it bundles your code into a standalone executable. But here's what many people miss — those .pyc bytecode files inside the bundle? They can be extracted and decompiled using tools like uncompyle6 or pycdc. It's not even that hard.

PyInstaller is great for distribution (no Python installation required on the target machine), but don't rely on it for IP protection.

Nuitka

This is where things get interesting. Nuitka takes a fundamentally different approach — it actually compiles your Python into C code, which then gets compiled into native machine code.

No bytecode. No Python source. Just machine code that's extremely difficult to reverse-engineer.

Bonus: you often get a 2-4x performance improvement because you're running native code instead of interpreted Python.

Why I Chose Nuitka (Hint: It's the License)

When you're building commercial products, licensing matters. A lot.

Tool	License	Commercial Use
PyArmor	Proprietary	Requires paid license
PyInstaller	GPL (with exception)	Free, but not true obfuscation
Nuitka	Apache-2.0	Free for any use

Nuitka's Apache-2.0 license means you can use it in commercial products, modify it, and distribute compiled binaries — all without licensing fees or restrictions.

For me, this was the deciding factor.

How Nuitka Actually Works (The Fun Part)

Let's geek out for a minute. Understanding what Nuitka does under the hood helps you appreciate why it's so effective.

Step 1: Python → C Translation

Nuitka doesn't just wrap or encrypt your code. It translates your Python into C code.

But here's the clever part — it's not arbitrary C code. It's C code that uses CPython's C API, the same API used to write Python itself and native C extensions.

Step 2: Preserving Python Semantics

The generated C code follows Python semantics exactly. Your code behaves identically because:

Dynamic typing works through PyObject* pointers
Reference counting and garbage collection function correctly
All built-ins and standard library remain available
Exception handling follows Python's model

Take this simple function:

def add(a, b):
    return a + b

Nuitka translates this to C code that:

Receives PyObject* arguments
Calls PyNumber_Add (the C API function for Python's + operator)
Returns a PyObject* result

The behavior is identical to interpreted Python — just compiled.

Step 3: Compilation to Machine Code

Finally, a standard C compiler (GCC, Clang, or MSVC) compiles the C code into:

.so files on Linux/macOS
.pyd files on Windows
Standalone executables if you want them

Why This Makes Reverse-Engineering Hard

No bytecode — There's no .pyc file to decompile
Native machine code — Requires assembly-level reverse engineering skills
Compiler optimizations — Inlining, dead code elimination, and other optimizations further obscure the logic
No clear mapping — The relationship between your original Python and the final machine code is complex

Could someone with serious skills and time still figure out what your code does? Probably. But the barrier is significantly higher than just opening a .py file.

Practical Guide: Using Nuitka

Enough theory — let's get practical.

Installation

pip install nuitka

# Or with uv (my preference)
uv add nuitka

You'll also need a C compiler:

Linux: apt install gcc or yum install gcc
macOS: xcode-select --install
Windows: Visual Studio Build Tools or MinGW

Compiling a Single Module

To compile a Python file as an importable module:

python -m nuitka --module your_module.py

This creates your_module.cpython-3XX-*.so (or .pyd on Windows).

Recommended Options for IP Protection

For maximum protection and optimized output:

python -m nuitka \
    --module \
    --output-dir=build \
    --remove-output \
    --no-pyi-file \
    --lto=yes \
    --python-flag=no_docstrings \
    --enable-plugin=anti-bloat \
    your_module.py

Option Breakdown:

Option	Purpose
`--module`	Build as importable module (not standalone executable)
`--output-dir=build`	Place compiled output in a specific directory
`--remove-output`	Clean up intermediate build artifacts
`--no-pyi-file`	Don't generate `.pyi` stub files (which expose API)
`--lto=yes`	Link-time optimization for smaller, faster binaries
`--python-flag=no_docstrings`	Remove docstrings from the compiled code
`--enable-plugin=anti-bloat`	Reduce binary size by removing unnecessary dependencies

Compiling an Entire Package

For a package with multiple modules:

# Compile all .py files in a directory
for file in src/mypackage/*.py; do
    if [ "$(basename $file)" != "__init__.py" ]; then
        python -m nuitka --module \
            --output-dir=src/mypackage \
            --remove-output \
            --no-pyi-file \
            --lto=yes \
            --python-flag=no_docstrings \
            "$file"
    fi
done

Important: Keep __init__.py files as-is — they're needed for Python package discovery.

Creating a Standalone Executable

For distribution without requiring Python:

python -m nuitka \
    --standalone \
    --onefile \
    --output-dir=dist \
    --python-flag=no_docstrings \
    --enable-plugin=anti-bloat \
    main.py

Parallel Compilation

For large projects, use parallel compilation:

python -m nuitka --module --jobs=$(nproc) your_module.py

The Data File Problem

Here's the catch — and it's a big one.

Nuitka's community version only compiles Python code. It doesn't touch:

YAML configuration files
JSON data files
Text templates
Any other non-Python resources

If you've got sensitive data in these formats (think: API prompts, business logic configs, proprietary algorithms stored as data), they ship as plain text. Anyone can read them.

What About Nuitka Commercial?

Yes, Nuitka Commercial has data file embedding features. But that requires a commercial license. If you want to stay with the free Apache-2.0 version, you need a workaround.

Here's what I came up with.

Custom Obfuscation for Data Files

I've found two approaches that work well:

Approach 1: XOR Obfuscation with Embedded Key

XOR encryption is symmetric — the same operation encrypts and decrypts. The trick is embedding the key in your Python code, which then gets compiled by Nuitka into machine code.

Here's the module I use:

"""Simple XOR-based obfuscation for data files."""

import base64
from pathlib import Path

# Key embedded in compiled code — difficult to extract after Nuitka compilation
_OBFUSCATION_KEY = b"your_32_byte_secret_key_here_!!"  # 32 bytes recommended

OBFUSCATED_EXTENSION = ".enc"


def _xor_transform(data: bytes) -> bytes:
    """Apply XOR transformation with the embedded key."""
    return bytes(
        b ^ _OBFUSCATION_KEY[i % len(_OBFUSCATION_KEY)]
        for i, b in enumerate(data)
    )


def obfuscate_content(content: str) -> bytes:
    """Obfuscate string content.

    Args:
        content: Plain text content to obfuscate.

    Returns:
        Base64-encoded obfuscated bytes.
    """
    data = content.encode("utf-8")
    xored = _xor_transform(data)
    return base64.b64encode(xored)


def deobfuscate_content(obfuscated: bytes) -> str:
    """Deobfuscate content back to string.

    Args:
        obfuscated: Base64-encoded obfuscated bytes.

    Returns:
        Original plain text content.
    """
    decoded = base64.b64decode(obfuscated)
    original = _xor_transform(decoded)  # XOR is symmetric
    return original.decode("utf-8")


def obfuscate_file(file_path: Path, delete_original: bool = False) -> Path:
    """Obfuscate a file and save with .enc extension.

    Args:
        file_path: Path to the file to obfuscate.
        delete_original: Whether to delete the original after obfuscation.

    Returns:
        Path to the obfuscated file.
    """
    content = file_path.read_text(encoding="utf-8")
    obfuscated = obfuscate_content(content)

    output_path = file_path.with_suffix(OBFUSCATED_EXTENSION)
    output_path.write_bytes(obfuscated)

    if delete_original:
        file_path.unlink()

    return output_path


def deobfuscate_file(file_path: Path) -> str | None:
    """Read and deobfuscate a .enc file.

    Args:
        file_path: Path to the .enc file.

    Returns:
        Deobfuscated content as string, or None if file doesn't exist.
    """
    if not file_path.exists():
        return None

    obfuscated_data = file_path.read_bytes()
    return deobfuscate_content(obfuscated_data)

Build-Time: Obfuscate Your Data Files

Before distribution, obfuscate all sensitive data files:

from pathlib import Path
from obfuscation import obfuscate_file

# Obfuscate all YAML files in a directory
data_dir = Path("config")
for yaml_file in data_dir.rglob("*.yaml"):
    obfuscate_file(yaml_file, delete_original=True)
    print(f"Obfuscated: {yaml_file.name}")

Runtime: Load Obfuscated Files

Modify your application to load .enc files:

import yaml
from pathlib import Path
from obfuscation import deobfuscate_file, OBFUSCATED_EXTENSION

def load_config(config_name: str) -> dict:
    """Load configuration, supporting both plain and obfuscated files."""
    config_dir = Path("config")

    # Try obfuscated version first
    enc_path = config_dir / f"{config_name}{OBFUSCATED_EXTENSION}"
    if enc_path.exists():
        content = deobfuscate_file(enc_path)
        return yaml.safe_load(content)

    # Fall back to plain YAML (development mode)
    yaml_path = config_dir / f"{config_name}.yaml"
    if yaml_path.exists():
        return yaml.safe_load(yaml_path.read_text())

    raise FileNotFoundError(f"Config not found: {config_name}")

Why This Works

Key gets compiled — After Nuitka compilation, _OBFUSCATION_KEY is buried in machine code, not visible as a plain string
Base64 makes it filesystem-safe — No weird bytes that could cause issues
Good enough — Casual inspection reveals nothing. Yes, someone determined could still reverse-engineer it, but that's true of any protection

Approach 2: Convert Data to Python Structures

Here's an alternative: convert your data files into Python code at build time, then let Nuitka compile them.

# build_time_converter.py
import json
from pathlib import Path

def convert_json_to_python(json_path: Path, output_path: Path):
    """Convert JSON file to a Python module with the data as a dict."""
    data = json.loads(json_path.read_text())

    python_code = f'''"""Auto-generated data module. Do not edit."""

DATA = {repr(data)}
'''
    output_path.write_text(python_code)

# Usage
convert_json_to_python(
    Path("config/settings.json"),
    Path("src/mypackage/_settings_data.py")
)

The data literally becomes part of the compiled binary.

Pros: No runtime decryption, everything in one binary
Cons: More build complexity, changes require rebuild

Putting It All Together: Build Script

Here's a complete build script that combines Nuitka compilation with data obfuscation:

#!/usr/bin/env python3
"""Build script for protected distribution."""

import subprocess
import sys
from pathlib import Path

PACKAGE_DIR = Path("src/mypackage")
DIST_DIR = Path("dist_build")


def obfuscate_data_files():
    """Obfuscate all YAML and JSON files."""
    from obfuscation import obfuscate_file

    for pattern in ["*.yaml", "*.json"]:
        for data_file in PACKAGE_DIR.rglob(pattern):
            if data_file.name != "schema.yaml":  # Skip non-sensitive files
                obfuscate_file(data_file, delete_original=True)
                print(f"Obfuscated: {data_file.name}")


def compile_python_files():
    """Compile all Python files with Nuitka."""
    py_files = [
        f for f in PACKAGE_DIR.rglob("*.py")
        if f.name != "__init__.py"
    ]

    for py_file in py_files:
        cmd = [
            sys.executable, "-m", "nuitka",
            "--module",
            f"--output-dir={py_file.parent}",
            "--remove-output",
            "--no-pyi-file",
            "--lto=yes",
            "--python-flag=no_docstrings",
            "--enable-plugin=anti-bloat",
            str(py_file),
        ]

        result = subprocess.run(cmd, capture_output=True, text=True)
        if result.returncode == 0:
            py_file.unlink()  # Remove source file
            print(f"Compiled: {py_file.name}")
        else:
            print(f"Failed: {py_file.name}")
            print(result.stderr)
            sys.exit(1)


def main():
    print("Step 1: Obfuscating data files...")
    obfuscate_data_files()

    print("\nStep 2: Compiling Python files...")
    compile_python_files()

    print("\nBuild complete!")


if __name__ == "__main__":
    main()

A Reality Check on Security

Before you ship, let's be honest about what this does and doesn't do:

No protection is absolute — Determined attackers with enough time and skill can potentially reverse-engineer anything
Defense in depth — This is one layer. Consider combining with licensing checks, server-side validation, legal protections, etc.
Key management — Use a strong, unique key for XOR obfuscation. Consider rotating it between versions
Legal backup — Technical measures complement but don't replace patents, licenses, and contracts

The goal isn't to make your code impossible to crack. It's to make it not worth the effort for the vast majority of cases.

Wrapping Up

Here's the TL;DR:

Use Nuitka — Apache-2.0 license, true compilation to native code
Compile everything except __init__.py files
Obfuscate data files with XOR + embedded key (or convert to Python structures)
Automate your build so protection is consistent

This combination has worked well for me. My Python code ships as machine code, my sensitive configs are obfuscated, and I sleep a little better knowing my IP isn't sitting in plain text on customer machines.

Got questions or a different approach? Drop a comment below — I'd love to hear what's worked for you.

Resources

PEP 703 Explained: How Python Finally Removes the GIL

Dineshsuriya D — Mon, 08 Dec 2025 16:21:56 +0000

PEP 703 is one of the most transformative changes in CPython’s history. This proposal—now accepted—re-architects memory management, garbage collection, and container safety to safely enable true parallelism.

For years, Python has had a massive "elephant in the room": the Global Interpreter Lock (GIL). If you have ever written a Python script that tries to do two CPU-heavy tasks at once, you have likely run into it. You spawn two threads, expecting your code to run twice as fast, but instead, it runs at the same speed—or sometimes even slower.

The GIL allows only one thread to execute Python bytecode at a time, effectively turning your powerful multi-core CPU into a single-core machine. In this deep dive, we will explore exactly how the Python core team solved the "impossible" problem: removing the GIL while keeping Python safe.

Why This Matters Now

Before looking at the "how," we must address the "why." For decades, single-threaded Python got faster automatically as CPUs improved (Moore’s Law). That era is over. Today, performance gains come from adding more cores, not faster ones.

At the same time, Python has become the standard for AI and Machine Learning—workloads that are inherently parallel. Sticking to a single-threaded runtime in a multi-core, AI-driven world is no longer sustainable. PEP 703 bridges this gap, allowing Python to finally utilize modern hardware to its full potential.

The Core Problem: Concurrency vs. Parallelism

Imagine a ticket counter with 10 open windows (your CPU cores), but there is only one employee (the GIL) who runs back and forth between the windows. Even if you have 10 customers (threads) ready to do business, only one gets served at a time. The others just wait.

Concurrency: The employee switches between windows rapidly. Progress happens on all tasks, but not at the exact same instant.
Parallelism: You hire 10 employees. All 10 windows serve customers at the exact same second.

Standard Python does concurrency well, but limits parallelism

PEP 703 removes the "one employee" limit, allowing every core on your machine to run Python code simultaneously. But doing this safely requires redesigning Python internals from the ground up.

How Python Fixed Reference Counting Without the GIL

Python manages memory automatically using Reference Counting. Every time you create a variable, Python attaches a counter to that object. In a free-threaded world, two threads updating the same counter simultaneously would cause race conditions.

Using atomic operations for every reference count update would be safe but unacceptably slow. PEP 703 solves this with three innovations:

1. Biased Reference Counting (BRC)

The developers realized that most objects are only ever used by the thread that created them.

BRC "biases" the reference count accordingly:

Owner thread: Fast non-atomic increments
Other threads: Slower atomic increments for safety

2. Immortal Objects

Objects like None, True, False, and small integers (0, 1) are accessed constantly. Locking them would create a hotspot of contention.

PEP 703 marks these objects as Immortal. Their reference counts never change—updates are simply ignored.

3. Deferred Reference Counting

Functions and modules are touched millions of times by many threads. Updating their refcounts constantly would drown performance.

PEP 703 defers these updates and allows the Garbage Collector to reconcile them later, avoiding countless atomic operations.

How Memory Allocation Works in the Free-Threaded Build

Standard Python uses pymalloc, which assumes the GIL is present. Without the GIL, it becomes unsafe for multithreaded use.

The free-threaded build introduces optional support for mimalloc, a high-performance allocator designed for parallel workloads.

mimalloc provides:

Thread-safe allocation without global locks
Paging of similar-sized objects, making GC scans much more efficient

If mimalloc is unavailable, CPython automatically falls back to a thread-safe variant of pymalloc, ensuring correct behavior even without the external allocator.

This significantly reduces contention when multiple threads request memory simultaneously.

How the New GC Avoids Race Conditions

Python’s Garbage Collector finds cyclic references. Under the GIL, the GC could run safely because no other thread could mutate structures mid-scan.

Without the GIL, Python adds new protection:

1. Stop-the-World Scanning

Pause all threads executing Python code
Scan safely
Resume execution ### 2. Removal of Generational GC

Standard Python scans young objects frequently. In a multi-threaded world, frequent pauses would crush performance.
The free-threaded build adopts a non-generational GC, running less frequently and merging deferred reference count updates during each cycle.

Because the GC now runs less frequently in the free-threaded build, these stop-the-world pauses are shorter and happen significantly less often in practice.

How Lists and Dicts Stay Safe Across Threads

Each list and dictionary now has a very lightweight lock. But locking to read would destroy performance.

Python uses Optimistic Locking with version numbers instead.

A writer acquires the lock and increments the version number.
A reader:

Reads version
Reads data without locking
Re-reads version
If unchanged → success
If changed → retries with lock

Lists and dicts no longer depend on the GIL for thread safety — their lock-and-version design ensures safe concurrent access even when many threads operate on the same container.

Because reads far outnumber writes, this design keeps containers extremely fast.

The Reality Check: Performance & Trade-offs

Removing the GIL comes with overhead. Free-threaded Python must maintain per-object locks, deferred refcounting logic, and more.

Single-threaded programs: ~10–15% slower
Multi-threaded CPU-bound programs: scale almost linearly with core count

Python Build	CPU-Heavy Threads on 8 Cores
Standard CPython	~1× speed (no scaling)
Free-Threaded CPython	~6–8× speed depending on workload

For AI, scientific computing, and high-throughput web servers, this trade-off is overwhelmingly worthwhile.

Real-World Scenarios: Why Developers Should Care

ML Pipelines: Run data loading, preprocessing, and model evaluation in parallel without multiprocessing overhead.
Web Frameworks: Background CPU tasks (e.g., PDF generation, hashing) no longer block the main request thread.
Scientific Computing: Complex simulations can use multiple cores on a shared in-memory dataset instead of slow inter-process communication.

Compatibility & Migration

Will this break your code?
Short answer: No, but you might now see race conditions that were previously hidden by the GIL.

Pure Python: Runs unchanged, but you must protect shared mutable state yourself when using threads.
C-extensions: Must be rebuilt with free-threading support. Many major libraries (NumPy, Pandas, PyTorch) already provide experimental builds.
Async: Unaffected—async is I/O-bound, not CPU-bound.
Ecosystem: Support is accelerating as the Python 3.14 timeline approaches.

Summary

PEP 703 represents years of engineering effort. Key takeaways:

True Parallelism: Python can now execute multiple threads at the same time on different CPU cores.
Redesigned Internals: Reference counting, memory allocation, container safety, and GC were upgraded for multi-threading.
Performance Reality: ~10% slower for purely single-threaded workloads, but massive multi-core acceleration for CPU-heavy tasks.
Status: Free-threaded Python is available in Python 3.13 (as an experimental build) and continues as an optional GIL-less build in Python 3.14.

Disclaimer: The views and opinions expressed in this blog are solely those of the author and do not represent the views of any organization or any individual with whom the author may be associated, professionally or personally.

Model Context Protocol : A New Standard for Defining APIs

Dineshsuriya D — Mon, 14 Apr 2025 11:54:07 +0000

Why APIs Need a New Standard for LLMs:

Large Language Models (LLMs) are like compressed versions of the internet — great at generating text based on context, but passive by default. They can’t take meaningful actions like sending an email or querying a database on their own.

To address this, developers began connecting LLMs to external tools via APIs. While powerful, this approach quickly becomes messy: APIs change, glue code piles up, and maintaining M×N integrations (M apps × N tools) becomes a nightmare.
That’s where the Model Context Protocol (MCP) comes in.
MCP provides a standardized interface for connecting LLMs to tools, data sources, and services. Instead of custom integrations for every app-tool pair, MCP introduces a shared protocol that simplifies and scales integrations.

Think of MCP like USB for AI.

Before USB, every device needed a custom connector. Similarly, before MCP, each AI app needed its own integration with every tool. MCP reduces M×N complexity to M+N:

Tool developers implement N MCP servers
AI app developers implement M MCP clients With this client-server model, each side only builds once — and everything just works.

Understanding MCP’s Core Architecture:

Hosts: These are applications like Claude Desktop, IDEs, or AI-powered tools that want to access external data or capabilities using MCP.
Clients: Embedded within the host applications, clients maintain a one-to-one connection with MCP servers. They act as the bridge between the host and the server.
Servers: Servers provide access to various resources, tools, and prompts. They expose these capabilities to clients, enabling seamless interaction through the MCP layer.

Inside MCP Servers: Resources, Tools & Prompts

MCP servers expose three key components — Resources, Tools, and Prompts — each serving a unique role in enabling LLMs to interact with external systems effectively.

Resources

Resources are data objects made available by the server to the client. They can be text-based (like source code, log files) or binary (like images, PDFs).
These resources are application-controlled, meaning the client decides when and how to use them.
Importantly, resources are read-only context providers. They should not perform computations or trigger side effects. If actions or side effects are needed, they should be handled through tools.

Tools

Tools are functions that LLMs can control to perform specific actions — for example, executing a web search or interacting with an external API.
They enable LLMs to move beyond passive context and take real-world actions, perform computations, or fetch live data.
Though tools are exposed by the server, they are model-driven — meaning the LLM can invoke them (usually with user approval in the loop).

Prompts

Prompts are reusable prompt templates that servers can define and offer to clients.
These help guide LLMs and users to interact with tools and resources more effectively and consistently.
Prompts are user-controlled — clients can present them to users for selection and usage, making interaction smoother and more intentional.

MCP Servers: The Bridge to External Systems

MCP servers act as the bridge between the MCP ecosystem and external tools, systems, or data sources. They can be developed in any programming language and communicate with clients using two transport methods:

Stdio Transport: Uses standard input/output for communication — ideal for local or lightweight processes.
HTTP with SSE (Server-Sent Events) Transport: Uses HTTP connections for more scalable, web-based communication between clients and servers.

How MCP Works: The Full Workflow

The Model Context Protocol follows a structured communication flow between hosts, clients, and servers. Here's how the full lifecycle plays out:

1. Initialization

The host creates a client, which then sends an Initialize request to the server. This request includes the client’s protocol version and its capabilities.
The server responds with its own protocol version and a list of supported capabilities, completing the handshake.

2. Message Exchange

Once initialized, the host gains access to the server’s resources, prompts, and tools.
Here’s how interaction typically works:
- Request: If the LLM determines that it needs to perform an action (e.g., for the user query “What’s the weather in Bangalore?”), the host instructs the client to send a request to the server — in this case, to invoke the fetch_weather tool.
- Response: The server processes the request by executing the appropriate tool. It then sends the result back to the client, which forwards it to the host. The host can then pass this enriched context back into the LLM, enabling it to generate a more accurate and complete response.

3. Termination

Either the host or the server can gracefully close the connection by issuing a close() command.

Hands-On: Building an MCP Server & Client in Python:

MCP Server:

from mcp.server.fastmcp import FastMCP

# Create an MCP server
mcp = FastMCP("LLMs")

# The @mcp.resource() decorator is meant to map a URI pattern to a function that provides the resource content
@mcp.resource("docs://list/llms")
def get_all_llms_docs() -> str:
    """
    Reads and returns the content of the LLMs documentation file.
    Returns:
        str: the contents of the LLMs documentation if successful,
             otherwise an error message.
    """
    # Local path to the LLMs documentation
    doc_path = r"C:\Users\dineshsuriya_d\Documents\MCP Server\llms_full.txt"
    try:
        # Open the documentation file in read mode and return its content
        with open(doc_path, 'r') as file:
            return file.read()
    except Exception as e:
        # Return an error message if unable to read the file
        return f"error reading file : {str(e)}"
# Note : Resources are how you expose data to LLMs. They're similar to GET endpoints in a REST API - they provide data
# but shouldn't perform significant computation or have side effects

# Add a tool, will be converted into JSON spec for function calling
@mcp.tool()
def add_llm(path: str, new_llm: str) -> str:
    """
    Appends a new language model (LLM) entry to the specified file.
    Parameters:
        path (str): The file path where the LLM is recorded.
        new_llm (str): The new language model to be added.
    Returns:
        str: A success message if the LLM was added, otherwise an error message.
    """
    try:
        # Open the file in append mode and add the new LLM entry with a newline at the end
        with open(path, 'a') as file:
            file.write(new_llm + "\n")
        return f"Added new LLM to {path}"
    except Exception as e:
        # If an error occurs, return an error message detailing the exception
        return f"error writing file : {str(e)}"
# Note: Unlike resources, tools are expected to perform computation and have side effects


@mcp.prompt()
def review_code(code: str) -> str:
    return f"Please review this code:\n\n{code}"

if __name__ == "__main__":
    # Initialize and run the server
    mcp.run(transport='stdio')

MCP Clients:

MCP Clients are part of host like Claude Desktop, Cursor.

from mcp import ClientSession, StdioServerParameters, types
from mcp.client.stdio import stdio_client

# Commands for running/connecting to MCP Server
server_params = StdioServerParameters(
    command="python",  # Executable
    args=["example_server.py"],  # Optional command line arguments
    env=None,  # Optional environment variables
)

async with stdio_client(server_params) as (read, write):
    async with ClientSession(
        read, write, sampling_callback=handle_sampling_message
    ) as session:
        # Initialize the connection
        await session.initialize()

        # List available prompts
        prompts = await session.list_prompts()

        # Get a prompt
        prompt = await session.get_prompt(
            "example-prompt", arguments={"arg1": "value"}
        )

        # List available resources
        resources = await session.list_resources()

        # List available tools
        tools = await session.list_tools()

        # Read a resource
        content, mime_type = await session.read_resource("file://some/path")

        # Call a tool
        result = await session.call_tool("tool-name", arguments={"arg1": "value"})

Why Use MCP? Key Advantages & Benefits

MCP brings a number of practical benefits that make it easier to build and scale LLM-based applications:

No Need to Manage API Changes: MCP servers are typically maintained by the service providers themselves. So if an API changes or a tool gets updated, developers don’t need to worry — those changes are handled within the MCP server. This makes LLM integrations more reliable and future-proof.
Automatic Server Spin-Up: MCP servers automatically start when a host creates a client and connects to it. There’s no need for developers to manually launch or manage the server process — just provide the necessary configuration to the MCP-compatible host (like Claude), and it takes care of the rest.
Plug-and-Play Model Switching: With MCP in place, switching between different models becomes much easier. Since all tool and resource integrations are standardized and maintained by their providers, any compatible model can use them without extra setup.
Rich Ecosystem of Integrations: A growing number of integrations are already available in the MCP ecosystem — offering access to powerful tools and high-quality resources. These can be effortlessly accessed through clients by any host application

Explore: Community & Pre-Built MCP Servers

Looking to dive deeper or get started fast? Check out these great community-driven resources and ready-to-use MCP servers:

🌟 Awesome MCP Servers – A curated list of high-quality MCP server implementations, tools, and resources.
🛠️ Official MCP Server Repository – The official collection of MCP server examples and standards maintained by the protocol community.

Happy vibe coding! 😊

Disclaimer:
This is a personal blog. The views and opinions expressed here are only those of the author and do not represent those of any organization or any individual with whom the author may be associated, professionally or personally.