selfmcp: The MCP Server That Lets an AI Write Its Own Tools
A tiny Python kernel, a versioned skill registry, and a subprocess executor turn a model into a system that can extend itself in real time.
The current BabyAGI is a self-building framework—an agent that can write its own functions.
- selfmcp is interesting because it turns MCP from a connector layer into a tool-making system.
- Its core trick is a minimal kernel of fixed tools that can grow a larger skill library on demand.
- The registry matters as much as the executor because discovery, versioning, and search keep the expanding toolset usable.
- The trade-off is deliberate: the same openness that makes the system flexible also makes it harder to sandbox.
The AI Is Not Just Using Tools. It Is Making Them
Most MCP servers expose a fixed menu of actions. selfmcp flips that script. It gives the model a small kernel of tools, then lets it write new Python skills, save them, search them later, and execute them inside the same session.
Eight Tools, Not Eighty
| Project type | Tool source | How new capability appears | Search/discovery model | Risk profile |
|---|---|---|---|---|
| Standard MCP server | Fixed external integrations | A new server or connector must be added by a human | List and call predefined endpoints | Lower flexibility, lower code execution risk |
| Conventional agent framework | Predefined tools plus orchestration | Capability is usually scripted ahead of time | Planner picks from a known tool list | Moderate flexibility, higher orchestration complexity |
| selfmcp | Dynamic skill registry | The model writes, stores, and reuses its own Python skills | Lightweight summary first, full code on demand | Highest flexibility, highest safety burden |
Skills as Data
The elegant idea in skills.py and db.py is that a skill is not a magical runtime object. It is a row in a registry with a name, description, and code body. The server first shows a narrow table of contents, then reveals full code only when a specific skill is worth opening.
| Pattern | What the LLM sees first | What happens next | Why it matters |
|---|---|---|---|
| Materialized TOC | A short skill summary list | Fetch detail only for the chosen skill | Keeps context lean |
| Full dump | Everything at once | The model sorts through too much text | Wastes context and attention |
| Append-only history | Current skill plus prior versions | Older bodies stay recoverable | Supports rollback and auditability |
How a Skill Becomes an Executable
The runtime is deliberately simple. `executor.py` writes generated code to a tempfile, passes parameters through `SELFMCP_PARAMS`, and launches a subprocess. That makes a skill easy to inspect, portable across environments, and close to the way a human would actually ship a small script.
def execute_skill(code: str, params: dict[str, object]) -> str:
with tempfile.NamedTemporaryFile(mode="w", suffix=".py", delete=False) as f:
f.write(extract_code_block(code))
path = f.name
env = os.environ.copy()
env["SELFMCP_PARAMS"] = json.dumps(params)
result = subprocess.run(
[sys.executable, path],
capture_output=True,
text=True,
env=env,
check=False,
)
return result.stdoutThe important part is not that code runs. It is that the generated code stays human-readable, can be archived as Markdown, and can be re-opened as a versioned artifact instead of a throwaway string.
Search Keeps the Growing Library Usable
Once the library starts to grow, retrieval stops being optional. `embeddings.py` adds hybrid search so the model can find likely matches without scanning the entire registry, and the deterministic local fallback means the system still works when an embedding API is unavailable.
| Search mode | Strength | Weakness | Best use |
|---|---|---|---|
| Semantic search | Finds related skills by meaning | Depends on embeddings quality | Growing libraries with fuzzy queries |
| Local fallback | Always available and deterministic | Less semantically rich | Offline or API-free environments |
| Naive list scan | Simple and transparent | Does not scale well | Tiny skill sets only |
The Trade-Off Is the Point
This project does not pretend to be a hardened sandbox. Skills inherit the server environment, deleted names can be reactivated, and subprocess execution keeps the system flexible at the cost of stronger isolation. That is the central tension: self-extension is useful precisely because it is permissive.
Tools like`FastAPI-MCP` are gaining traction because they simplify turning existing services into MCP-compatible ones with zero configuration.
| Question | selfmcp answer | Safer alternative |
|---|---|---|
| Who owns tool creation? | The model does | A human developer does |
| Are tools fixed? | No, they grow during the session | Yes, the API surface is static |
| Is history preserved? | Yes, through versioning | Often only the latest state exists |
| Is the runtime tightly sandboxed? | Not by design | Usually yes |
Why This Matters in the MCP Era
The larger landscape makes the contrast sharper. Standard MCP servers connect models to existing tools. Agent frameworks orchestrate those tools. selfmcp does something else entirely. It treats the model as a producer of tools, not just a consumer of them, which turns MCP into a self-extension layer instead of a mere connector standard.
What selfmcp Suggests About Agents
This repo is less a polished product than a design sketch for recursive software. Its real argument is that agent progress may come not only from bigger context windows or better prompts, but from systems that let models grow their own working set over time.
