The End of Front-End

Delivering Software via LLMs and the Model Context Protocol

pip install rse-vibe-coding

Just to check… you’re all here for the ‘Advanced Vibe Coding’ session, right?

Ah, sorry, that was cancelled. Apparently, pip install vibes kept failing with a ResolutionImpossible error. Couldn’t find a version of ‘good-vibes’ that was compatible with ‘reality>=20.2.5’.

But we are here to talk about the future of interfaces. A future that feels like magic but is built on solid, almost reliable engineering.

👋 Cristian Dinu, UCL

The RSE Friction

RSE as Tool Builders…

• Endless UIs
• Endless docs
• Endless support

RSE as Tool Users…

• Endless wrappers
• Endless glue code
• Endless boilerplate

My name is Cristian Dinu, and I’m a Senior Research Software Engineer at UCL. My job is to bridge the gap between complex energy data and the researchers who need it. Essentially, I spend my days trying to eliminate friction.

And as RSEs, we live in a world of friction, don’t we? We build these powerful tools and APIs…

…When we’re building for others, we then spend months building bespoke GUIs, writing documentation, and answering the same support questions over and over.

…And when we’re building for ourselves, we spend hours writing boilerplate code and wrapper scripts just to glue our own tools together.

This isn’t just theory for me; we’re actively exploring these concepts with a heat pump manufacturer to help make their complex products genuinely accessible to everyday users.

What if your software just… understood you?

So, this brings us to the central question for this talk. What if we could eliminate some of that friction? What if, instead of clicking buttons or learning command-line flags, your users—or you—could just write / say what you want?

The Chasm

Right now, there’s a chasm between a user’s intent and our software’s action.

Our users think in terms of goals, like ‘find the greenest time’. But our software speaks in rigid API calls and endpoints.

We spend most of our front-end effort building bridges over this chasm by hand—with GUIs, CLIs, and documentation.

Image source: Nano-Banana, prompt

A simple diagram, white background, showing a process with a chasm in the middle Left side: An EV icon with a question mark and text “What is the cleanest time to charge my car?”. Right side: A code icon with text /api/v1/forecast?region=04 A big, messy, chasm is in between.

There is something that can:

• understand natural language
• understand intent
• could generate a list of commands… if it only had the tools

We all now it, we all already use it. The Large Language Model.

This is how I imagine a model. It is like a brain in a jar. It has knowledge, it has reasoning, it has memory. But it has no body. It has no tools. It cannot find new things, it cannot act in the world.

This is how we all met the LLM. In a chat interface. You type something, it responds. It is a great interface for exploration, for brainstorming, for learning. It relies on its static training data, and onn you, the user, to provide context, and do the actions.

It is not a great interface for action. It cannot do anything in the world. It cannot access new information. It cannot run code. It cannot control devices.

So the next step was to give the LLM some tools. We saw this with web search in Perplexity, plugins in ChatGPT.

But this approach has limitations. Each integration is bespoke, requiring custom engineering for each tool and each LLM. It’s not scalable. It’s not reliable. And it’s not interoperable.

So what if we had a standard way for LLMs to discover and use tools? A universal contract that any LLM could understand, and any tool could implement.

This is where the Model Context Protocol, or MCP, comes in. MCP is an open standard that defines how LLMs can discover and use tools in a consistent way.

When the MCP client starts, it discovers all available MCP servers. It fetches their tool definitions, which are written in a standard schema.

Then, when the user makes a request, the LLM parses it, decides which tools to use, and calls them via MCP.

MCP is a Contract

A simple schema defines your tool’s capabilities.

{
  name: fetch,
  description: `Fetches a URL from the internet...`
  inputSchema:{
      url: {
        description: URL to fetch,
        format: uri,
        type: string
      },
      max_length: {
        default: 5000,
        description: Maximum number of characters to return.,
        type: integer
      },
      ...
  }
} 

So how does it work? It’s surprisingly simple. As the developer, you define your tool’s capabilities in a standard schema.

You give it a name the LLM can call.

You write a clear description in plain English, which is crucial for the LLM to understand when to use your tool.

And you define the parameters it accepts.

That’s it. This simple, machine-readable contract is all the LLM needs to start using your tool intelligently.

Live Demo: The Setup

• Client: Any LLM chat interface (VSCode, Claude, Cursor, etc.)
• Server: A Python app exposing our tools via MCP.

Okay, enough talk. Let’s build one.

First, the setup. We have a client, which is just a standard LLM chat interface. The user just talks to it.

And we have the server. This is what we’re about to build in Python. It’s a simple web server that exposes our tools via MCP.

Creating our own MCP Server

• Carbon Intensity API – api.carbonintensity.org.uk
• Prerequisites:
  • uv - python project manager
  • nodejs - JavaScript interpreter (optional, for inspector tool)
• We need to think about semantic intent

Initialize the project

uv init intensity_mcp
cd intensity_mcp

uv add fastmcp requests

(code at: github.com/cdinu/uk-carbon-intensity-mcp-py)

Write the code – main.py

import requests

def intensity_current():
    """Fetches the current carbon intensity of the UK electricity grid.
    Returns a JSON with the current carbon intensity in gCO2eq/kWh."""
    response = requests.get("https://api.carbonintensity.org.uk/intensity")
    response.raise_for_status()
    data = response.json()
    return data["data"]

import requests
from fastmcp import FastMCP

def intensity_current():
    """Fetches the current carbon intensity of the UK electricity grid.
    Returns a JSON with the current carbon intensity in gCO2eq/kWh."""
    response = requests.get("https://api.carbonintensity.org.uk/intensity")
    response.raise_for_status()
    data = response.json()
    return data["data"]

import requests
from fastmcp import FastMCP

mcp = FastMCP("CarbonIntensityMCP")

def intensity_current():
    """Fetches the current carbon intensity of the UK electricity grid.
    Returns a JSON with the current carbon intensity in gCO2eq/kWh."""
    response = requests.get("https://api.carbonintensity.org.uk/intensity")
    response.raise_for_status()
    data = response.json()
    return data["data"]

import requests
from fastmcp import FastMCP

mcp = FastMCP("CarbonIntensityMCP")

@mcp.tool(name="Get Current Intensity")
def intensity_current():
    """Fetches the current carbon intensity of the UK electricity grid.
    Returns a JSON with the current carbon intensity in gCO2eq/kWh."""
    response = requests.get("https://api.carbonintensity.org.uk/intensity")
    response.raise_for_status()
    data = response.json()
    return data["data"]

if __name__ == "__main__":
    mcp.run()

Add parameters, too:

@mcp.tool(name="Read Carbon Intensity for Dates and Postcode")
def intensity_for_dates_and_postcode(from_datetime: str, to_datetime: str,
    postcode: str,
):
    """Fetches electricity grid carbon intensity data for a specific UK postcode and time range.
    The `from_datetime` and `to_datetime` should be in ISO 8601 format (e.g. 2018-05-15T12:00Z).
    The `postcode` needs only the first part e.g. RG10 (without the last three characters or space)
    Returns a summary including average forecast and generation mix. Dates returned are UTC. Units are gCO2eq/kWh.
    """
    url = f"https://api.carbonintensity.org.uk/regional/intensity/{from_datetime}/{to_datetime}/postcode/{postcode}"
    try:
        response = requests.get(url)
        response.raise_for_status()
        return response.json()["data"]

    except Exception as e:
        return f"Failed to retrieve carbon intensity data: {str(e)}"

Configure your MCP client

View available tools

Call a tool

Call another tool

The Real Magic: Orchestration

prompt:

I am currently near Coventry. I want to charge my EV tomorrow or on Friday when the electricity grid is the cleanest. Find a good 3 hr spot, add it to my iCloud Calendar and send an e-mail to [email protected] with the information.

What Just Happened?

1. We provided capabilities
2. User stated intent
3. The LLM built the workflow on the fly

So what just happened? The LLM performed three key actions: Decomposition, Tool Chaining, and Synthesis.

We didn’t build a ‘carbon-to-calendar’ app. We provided two separate capabilities, and the LLM built the workflow on the fly.

RSE Superpowers Unlocked 🚀

For Tool Builders…	For Tool Users…
✅ Escape the UI Treadmill	✅ Query by Intent
✅ Slash Support Load	✅ Zero Boilerplate
✅ Instant “Feature” Rollout	✅ Your Personal Orchestrator

So what does this mean for us as RSEs? It unlocks superpowers.

For tool builders: We can escape the UI treadmill. Your schema is the interface. You can slash your support load because the system is self-documenting. And feature rollout is instant.

And for tool users: We can query by intent. We can skip the boilerplate. And the LLM becomes your personal orchestrator, chaining tools together.

The Future is a Conversation

• Natural Language is the universal flexible front-end “programming language”.
• APIs are the stable, reliable backend.
• MCP is the contract that connects them.

We are moving from a world where we adapt to computers to a world where computers adapt to us.

In this new paradigm, APIs remain the stable, reliable backend. Natural Language becomes the universal, flexible front-end.

And MCP is the crucial contract that connects them reliably.

What will you build?

• The front-end isn’t disappearing.
• It’s becoming invisible, adaptive, and conversational.

The front-end isn’t going away. It’s becoming invisible, adaptive, and conversational. It’s becoming intelligent.

The opportunity for us as RSEs is immense. We can deliver more value, faster, by focusing on what we do best—building powerful tools—and letting the conversation handle the rest.

So I’ll leave you with this question: What will you build when the UI is no longer a barrier?

Thank You!

Cristian Dinu

https://cdi.nu

Thank you very much. I’m happy to take any questions.

Thank you!

https://cdi.nu/talks/2025-09-RSECon