AI agents' integration with Integrated Development Environments (IDEs) is already part of the usual workflow. Most software engineers use AI auto-completion tools like GitHub Copilot, and many use "vibe coding."

AI agent instructions are commonly seen in many projects. We often find files like AGENT.md, AGENTS.md, CLAUDE.md, and others. These files usually contain instructions for AI agents on how to interact with the project, what tools to use, and any specific guidelines. For example, they might define how to use the codebase, which libraries are utilized, what the project goals are, and so on.

Ideal instructions should allow an AI agent to complete complex tasks autonomously, such as: "I need a new feature that lets users add commands to text pages on the website." Ideally, the AI agent should have all the necessary information, such as "how to add new API endpoints," "how to add new database models," "how to support a database migration," and "how to link the UI to the backend."

However, I haven't seen truly effective working instructions. Usually, all this information is too vast for a single instruction file. If we describe every detail, this information will overload the AI agent's context.

We must remember that an AI agent's instructions are sent to the Large Language Model (LLM) along with every user prompt. Instructions that are too long distract the model's attention because they always contain everything, not just what's relevant at the moment.

Solution: A Custom MCP Server for Every Code Project

And here's the idea: why not create a custom Model Context Protocol (MCP) server for every project? This can replace AI agent instruction files and offer much greater flexibility.

Before going further, if you're not familiar with the MCP protocol, I recommend reading the official documentation: https://modelcontextprotocol.io/docs/getting-started/intro.

There are several advantages to using an MCP server for every project:

• Dynamic Instructions: An MCP server can provide dynamic instructions upon request from the LLM. It could support a tree of knowledge and provide only the relevant information for the current task. The LLM will decide which "article" to read, and the MCP server will provide only that specific content.
• Access to Framework Tools: Many software frameworks have their own tools for working with the codebase. For example, Django has management commands to create models, run migrations, start a development server, and so on. The MCP server can expose these tools to the LLM, allowing it to use them directly.
• Project-Specific Logic: The MCP server can implement project-specific logic, such as understanding the architecture, coding conventions, and best practices. This helps the LLM generate consistent code. For instance, the MCP server can have an add_new_feature tool. If we know that a new feature in our project means adding an "API router with a default endpoint," a "database model," "unit tests," and so forth, the MCP server can implement all this logic, so the LLM simply calls this single tool.
• Additional Tools: Many projects have their own tools, such as linters, formatters, test runners, package builders, and "GUI builders." The MCP server can expose these tools to the LLM, allowing it to use them directly. We can prompt the LLM with commands like "run tests," "build package," or "format code," and the MCP will execute the project's specific tools.
• Integration with Services: Many projects are integrated with external services, like CI/CD pipelines, cloud providers, monitoring tools, and project management tools. The MCP server can implement tools to interact with these services, enabling the LLM to manage deployments, monitor performance, and handle incidents directly from the codebase. Note: often these services have their own MCP servers, so having a custom tool in a project's MCP might seem redundant. However, I see benefits in having a unified interface for all project-related tools and services, which I'll explain below.
• Connection to Cooperative Repositories: Many projects have related repositories, such as documentation sites, design systems, shared libraries, and microservices. The MCP server can implement tools to interact with these repositories, allowing the LLM to access and update related resources seamlessly.

A couple of months ago, I published the blog post Implementing Authentication in a Remote MCP Server with SSE Transport. That article demonstrated how to add authentication for remote MCP servers written in Go.

At the time, I also wanted to include Python examples. Unfortunately, things weren’t straightforward. The official Python MCP SDK didn’t provide a clean way to implement what I needed. There were some workarounds using Starlette middleware, but in my experience, those solutions were brittle and ultimately unsuccessful.

Later, I managed to create a working Python MCP server supporting SSE (or streaming HTTP) transport. But my solution relied on thread-level hacks to make the data thread-safe. It worked, but it felt like a fragile and inelegant design—something I wasn’t comfortable recommending or maintaining long-term.

Now, after revisiting the problem, I’ve found a much cleaner solution in Python. This time it’s not with the official Python MCP SDK, but with an alternative implementation called FastMCP. FastMCP is written in the spirit of the official SDK, offering a very similar syntax, but with additional features, clearer abstractions, and—importantly—excellent documentation.

Over the past couple of months, I’ve been experimenting with the Model Context Protocol (MCP) — building AI agents and tools around it. While the experience has been promising, I’ve noticed a few areas where MCP could be expanded or improved.

These aren’t critical issues, but adding them would make MCP more complete and developer-friendly.

Here’s my current wishlist:

1. A Standard MCP Server Interface
2. Bidirectional Notifications
3. Built-in or Native Transport Layer

Let’s walk through each of these in more detail.

Good news! I've extended my lightweight AI orchestrator, CleverChatty, to support Retrieval-Augmented Generation (RAG) by integrating it using the Model Context Protocol (MCP).

Quick Recap

• RAG (Retrieval-Augmented Generation) is an AI technique that enhances language models by retrieving relevant external documents (e.g., from databases or vector stores) based on a user’s query. These documents are then used as additional context during response generation, enabling more accurate, up-to-date, and grounded outputs.

• MCP (Model Context Protocol) is a standard for how external systems—such as tools, memory, or document retrievers—communicate with language models. It enables structured, portable, and extensible context exchange, making it ideal for building complex AI systems like assistants, copilots, or agents.

• CleverChatty is a simple AI orchestrator that connects LLMs with tools over MCP and supports external memory. My goal is to expand it to work with modern AI infrastructure—RAG, memory, tools, agent-to-agent (A2A) interaction, and beyond. It’s provided as a library, and you can explore it via the CLI interface: CleverChatty CLI.