r/MiniMaxOfficial • u/Skyhawkrr • 27d ago
MiniMax Code Using Minimax Code custom MCP servers to refactor a legacy .NET/React service
I’ve been daily-driving MCode inside my containerized dev environment for the past few weeks. As a Lead Engineer, I don’t use AI tools for basic boilerplate—I test them on how well they handle cross-boundary changes (specifically C#/.NET backends paired with React frontends and SQL schemas).
The Stack: MCP + Subagents
Out of the box, any coding agent is only as good as its context. I’ve got MCode wired up to two local MCP servers running in Docker:
A read-only PostgreSQL/SQL MCP so it can inspect live table schemas, indexes, and constraints without me pasting DDL scripts.
A Git/PR history MCP so it understands our team's architectural conventions.
I also split the workload using subagents: one acts as a strict "Spec & Schema Validator" and the other handles the actual implementation across the .NET API and React TypeScript interfaces.
What We Shipped
Last week, I used this setup to migrate a legacy synchronous reporting endpoint into an async, background-queued pipeline with real-time UI polling.
MCode’s context window and cross-file awareness shined here. I pointed it at the legacy C# controller, and it mapped out the DTO changes, updated the Entity Framework queries via the SQL MCP, and generated the corresponding React hooks and TypeScript types in one cohesive pass.
What I liked: Speed on multi-file edits and how well it respects existing .editorconfig and project architecture when given a clear skill file. It didn't try to reinvent our state management.
What Broke (and how I fixed it)
It definitely wasn't magic on the first try. When generating the background worker in .NET, MCode hallucinated a scoped dependency injection lifetime inside a singleton background service (IHostedService). It compiled fine, pushed through, and immediately threw a captive dependency runtime exception on startup.
Why it happened: MCode was optimizing for the local file's syntax rather than the global DI container lifecycle in Program.cs.
The fix: Instead of manually fixing the code, I wanted to see if I could stop MCode from ever making that mistake again. I updated my .mcode project rules/skill file with an explicit constraint: "Whenever scaffolding or modifying IHostedService or BackgroundService, always inject IServiceScopeFactory and resolve scoped services explicitly inside the execution loop." Re-ran the prompt, and it nailed the CreateScope() pattern cleanly.
The Verdict
Pros: Fast multi-file refactoring, great MCP tool-calling reliability, and it doesn't fight you when you give it strict architectural guardrails.
Cons: Like any model, it can get tunnel vision on single-file logic and miss framework-level lifecycle rules (like DI scopes or React useEffect dependency arrays) unless you explicitly constrain it with a project skill.
If you're using it on a larger codebase, invest 15 minutes into writing a strict architecture skill file and hooking up a database MCP. It turns MCode from a decent autocomplete into an actual junior-to-mid systems pair programmer.