Model Context Protocol and ‘Enveloping’ the world for AI

I’ve been thinking a lot about the idea of building an environment that empowers AI to work efficiently, rather than solely focusing on developing more powerful models. Particularly working on some day-builds recently which have been rapid development in Python or TypeScript, I’ve been thinking a lot about notion of ‘enveloping’ the world for artificial intelligence.

Luciano Floridi talks about this - I remember an analogy of his involving phones and GPS. Put simply (and horribly paraphrased)

You don’t just make a phone so smart it can navigate the world, you create a GPS network which a less smart phone can ping and triangulate from in order get around

- Luciano Floridi, in my head, but probably something similar and more eloquent

Agentic Development

I see a parallel in my recent work and the developments in agent enhanced development (MCP etc.). Just as a phone relies on an ecosystem to enhance its capabilities, LLMs thrive when integrated with effective frameworks and tools. This is particularly true in ‘yolo’ mode (as Cursor call it).

graph TD
    subgraph "Enveloping Approach"
        A2[AI Model] -- "Bring bounded intelligence" --> B2[Enabling Infrastructure]
        B2 -- "Combine intelligence with infrastructure" --> C2[Solve with high signal and many levers]
    end
    subgraph "Traditional Approach" 
        A1[AI Model] -- "Be as smart as possible" --> B1[Try to solve with low signal and few levers]
    end

Some Simple Examples

Developing in Python is much nicer with unit tests, and if you tell the agent to check whether tests pass as part of it’s task, you can get a nice satisfying loop where it runs ‘make test’, realises it broke something, attempts to fix, repeats. You still need to watch it closely, but it’s very impressive to watch.

In Python, using mypy in strict mode is awesome, because when (as you’ve instructed it to) the agent runs mypy ., it can tell before actually running anything if it’s messed up, and the code it’s editing is easier to reason about because types act as a kind of in-line documentation.

This is even more true for TypeScript vs JavaScript!

Yolo in plain JS would be a complete nightmare - I probably don’t need to elaborate

A More Complex and Abstract Example

It gets even deeper when you start setting abstract tasks like when I wanted to quickly add chunking to my audio generation pipeline and test out a more autonomous approach.

Take this folder in my currently ongoing bookworks project for example:

.
├── STATUS.yaml
├── clean-markdown-for-tts-chunked.py
├── clean-markdown-for-tts.py
├── epub-to-markdown-for-tts.py
├── experiment_plan.md
├── experiment_results.md
├── minimal_changes.md
└── output
    ├── clean-markdown-for-tts
    ├── tts-ready-chapters
    └── tts-ready-chapters-chunks

This is a particular ‘experiment’ in the experiments folder. Unlike the rest of the code in this repo, mypy and ruff aren’t enforced.

But why Rory?

Because - in this folder agent’s do quick spikes to figure out functionality, and I’d rather the agent focus on quick informative results.

file	function
STATUS.yaml	track the status of the experiment (I generated this)
clean-markdown-for-tts-chunked.py	clean markdown for TTS chunked (AI generated)
clean-markdown-for-tts.py	clean markdown for TTS (AI generated)
epub-to-markdown-for-tts.py	epub to markdown for TTS (AI generated)
experiment_plan.md	experiment plan (I generated this)
experiment_results.md	experiment results (AI generated)

STATUS.yaml

2025-03-15: 
    - Experiment complete, I'm satisfied with the results and the outputs 
      have been integrated to bookworks.

experiment_plan.md

# Chapter Chunking Experiment

## Aim
To modify the existing `clean-markdown-for-tts.py` script to add functionality for splitting long chapters into smaller, more manageable chunks for better TTS processing.

## Approach
1. Add a new function to split chapter content into smaller chunks based on:
   - Maximum character count per chunk
   - Natural paragraph boundaries to maintain readability
   - Proper sentence boundaries to avoid cutting mid-sentence

2. Modify the existing script workflow to apply this chunking after chapters have been identified and before they are written to files.

(file goes on to describe the approach in more detail)

experiment_results.md

# Chapter Chunking Experiment Results

## Summary

The experiment to add chunking functionality to the `clean-markdown-for-tts.py` script was successful. We added a new function to split long chapters into smaller chunks based on paragraph and sentence boundaries, while preserving the natural flow of the text.

## Testing Results

Using a sample book with three chapters:

1. **Chapter 1**: Long chapter (2991 characters) → Split into 2 chunks (1814 and 1175 characters)
2. **Chapter 2**: Short chapter (333 characters) → Kept as a single chunk
3. **Chapter 3**: Medium chapter (2285 characters) → Split into 2 chunks (1781 and 502 characters)

Total chapters: 3
Total chunks created: 5

## Implementation Details

The core of the implementation is the `chunk_chapter_content` function, which:

(file goes on to describe outcome of the results)

What Was the Result?

The initial result was two new scripts clean-markdown-for-tts-chunked.py and epub-to-markdown-for-tts.py which can be run from the command line.

I tested these out and they worked as expected, so I folded them into the existing pipeline and deleted the old scripts. The whole process took me maybe 30 minutes but what I got was:

1. Working code which does what I wanted
2. A much cleaner pipeline that handles chunking automatically
3. Better TTS output since the chunks are now properly sized
4. Improved performance on longer books that were previously causing issues
5. A reusable chunking function that I can apply to other text processing tasks

I’m thinking about extending this further to handle special cases like poetry or code blocks, but for now, it’s working great for my needs. The experiment was definitely worth the time investment.

flowchart TD
    A[Create Experiment Plan] -->|Human task| B[AI Implements Solution]
    B -->|AI generated code| C[AI Review & Test]
    C -->|Human oversight| D{Successful?}
    D -->|Yes| E[Integrate into Main Pipeline]
    D -->|No| F[Feedback to AI]
    F --> B

Model Context Protocol and the Future of AI Integration

Looking at the experiment I ran earlier, I think there’s a parallel to what’s happening with Model Context Protocol (MCP) right now. If you haven’t heard of it, MCP is an open-source protocol developed by Anthropic that’s getting a ton of attention lately.

What Is MCP?

In essence, MCP is a standardised way for AI models to interact with external tools and data sources. Instead of building custom integrations for every tool an AI needs to use, MCP provides a uniform interface.

graph TD
    AI["AI Model/Client"] --- MCP["Model Context Protocol"]
    
    MCP --- FS["File System"]
    MCP --- DB["Database"]
    MCP --- API["3rd Party APIs"]
    MCP --- Browser["Web Browser"]
    MCP --- Code["Code Repository"]

It’s exactly that “enveloping” concept I mentioned earlier - we’re not just making the AI smarter, we’re making the world more accessible to the AI through a standardised protocol.

I’m looking forward to delving in to this more. Next steps are to install some MCP servers from the registry in future projects. Neo4j was a favourite of mine back in my DFID days, perhaps I’ll start there.