Last week, I needed a PlantUML MCP server for my team. Instead of spending days learning TypeScript, wrestling with npm configurations, and debugging dependency issues, I treated Claude like my personal implementation partner. I focused on the what and why—Claude handled the how.

In this post, I’ll walk you through my exact process for building the PlantUML MCP server, sharing the specific prompts, workflows, and mindset shifts that made it possible. By the end, you’ll have a repeatable framework for building software at the speed of thought, regardless of your programming background.

Let’s dive into the nitty-gritty details!

The Setup: You Drive, Claude Codes 

I think of Claude as a junior developer who types extremely fast and never seems to get tired. I’m the architect, the reviewer, and the decision-maker; meanwhile, Claude handles the implementation. 
For me, this isn’t about replacing developers—it’s about focusing on what matters: solving problems, not syntax. 

Here’s my personal cookbook recipe for building software with Claude, using a real project I shipped last week. 

The Project: PlantUML MCP Server

PlantUML is a tool for creating diagrams I often use for my projects. The problem I was having with it was that every time I wanted a PlantUML diagram, I had to: 

• Ask Claude to generate PlantUML code and copy it manually 

• Paste the code piece by piece to the repository I was working in. 

• Generate the diagram image myself and copy its URL back to my documentation. 

Solution:  

• Build an MCP server so Claude can automate all this manual work. 

Phase 1: Brainstorm First, Code Later (10-15 minutes)

Start in Claude.ai web interface. Don’t jump to code—design your solution first. The more well-thought-out the scenario is, the greater the chance you have for a good working solution. 

As for the model, I used Sonnet 4 because it’s typically faster than Opus and yields good enough results. I usually only switch to a ‘better yet slower’ model in case I am not satisfied with the answer/discussion and want to see if a stronger model would render better results. 

Me: “Let’s brainstorm. I want to create a PlantUML MCP server so that Claude Code can use our internal PlantUML server directly for SVG generation…” 

And from there, Claude and I went back and forth: 

• What tools do we need? 

• What’s the minimal viable version? 

• What can we skip for now? 

The core concept I was after was to start simple. Just wrap the internal server I was working in and skip complex features. 

Phase 2: Get Something Working (20-30 minutes) 

Once I was satisfied with the design phase, I asked Claude (still through the web interface version) for the minimal working code. 

Me: “I would start simple to make it functional. Just use our internal  
server for diagramming.” 

As a result, Claude generated ~100 lines of TypeScript, which I attempted to copy to my terminal to test. Which failed after just a few lines. 

$ npm install 
$ node index.js 
# Error: module not found

I went back to Claude with the error to troubleshoot. Two iterations later, with the help of AI and its ability to troubleshoot, the code runs as expected. 

Phase 3: Switch to Claude Code (5 minutes) 

Now the fun begins! In my terminal, I created a git repository and committed the initial working version I’d gotten from Claude’s web interface. 

$ cd plantuml-mcp-server
$ claude
> /init
> Create a git repository and commit this initial working version

Claude now understands the entire codebase. We’re ready to iterate fast. 

Phase 4: Iterate with Plan-Review-Execute (30-45 minutes)

This is where the magic happens. Look at this actual conversation. 

Me: “The encoding doesn’t work correctly. Here’s the official PlantUML  
encoding documentation [paste link]. We have two options: custom  
implementation or use the plantuml-encoder library” 

Claude: “I’ll use the plantuml-encoder library. Here’s my plan: 
1. Add plantuml-encoder dependency 
2. Replace the custom encoding function 
3. Update the generate_diagram tool 
4. Add error handling.” 

Me: “Looks good, proceed.” 

While Claude codes, I watch the changes it IntelliJ’s diff view. It’s like pair programming where I review in real-time.

During one of the iterations, I asked Claude to create a Makefile for easy build and command run. As a response, Claude generated a complete Makefile with targets for install, build, test, and clean.  

I tested each command as it was created. 

Phase 5: Ship It (15 minutes)

There’s no reason why you shouldn’t use Claude for the finishing yet mundane tasks, such as creating documentation, preparing the repository for public consumption, and adding compliance details. 

This is my prompt to help prepare an open-source repository: 

Me: “I created a GitHub repository and selected MIT license. Here’s  
the repo: github.com/mzagar/plantuml-mcp-server. Prepare the code  
for publishing there with proper README, examples, and npm setup.” 

Claude updates everything for the existing repo: 

• Comprehensive README with installation instructions 

• Package.json configured for npm publishing 

• GitHub Actions workflow 

• Example usage documentation 

• Architecture explanation 

Quick End Result Summary 

Time invested: ~2 hours 

Lines of code written by me: 0 

Lines of code generated: ~500 

Current status: Published on npm, used by my team daily 

The Unexpected Freedom: Language Agnostic Development 

Here’s something I didn’t expect to happen when working on a programming project: I’ve stopped caring about programming languages and frameworks. 

For Quick POCs 

Claude picked TypeScript for this project. I don’t know TypeScript—I mean, code is code, I can read and understand it—but I know nothing about the TypeScript ecosystem, npm dependencies, build lifecycles, or how to publish to npm. 

And it doesn’t matter. Claude handled all of that. 

What I had to focus on was “Does this solve my problem?”, rather than “How do I configure a webpack?” 

For Existing Projects 

I now use Claude habitually, and it becomes even more interesting for existing projects, such as our company’s React apps. When I need to contribute: 

• I jump into the terminal, run Claude, then /init 

• If there’s no technical documentation, I ask: “Generate ADR9 minimal technical docs and C4 diagrams for this codebase.” 

• Now I can ask questions and implement features 

My React knowledge? Same as my TypeScript knowledge—basically none. But when you look at my skills from a high-level perspective, I can: 

• Implement features 

• Test them 

• See if they solve my problem 

• Submit PRs for review 

And that’s all I need to create compelling and working projects. 

Instead of writing JIRA tickets to explain to our already busy frontend devs what I need from them, I implement it myself and ask them to review. They focus on code quality, patterns, and security, rather than implementing from scratch. 

My Cookbook Rules (What Works for Me)

• I always start with Claude.ai for design – I find it faster for brainstorming 

• Get minimal code working first – I’ve learned not to build features on broken foundations 

• I switch to Claude Code only with working code – /init needs something to understand 

• Review every change in your IDE – I stay responsible for the code 

• Provide external docs – Claude doesn’t know your internal APIs 

• I commit after each successful feature – Git is my safety net 

• Test continuously – I run the code after every change 

What This Means for My Workflow 

I spent two hours being an architect and reviewer instead of eight hours typing code. I focused on: 

• What the tool should do 

• How it should work 

• Quality and correctness 

• User experience 

Claude handled: 

• Syntax and boilerplate 

• Package management 

• Error handling patterns 

• Documentation formatting 

This isn’t about AI replacing programmers. For me, it’s about focusing on what’s important: problems instead of syntax, architecture instead of boilerplate, user value instead of configuration files.