(This is an English translation of my original Japanese article: 日本語版はこちら)
The MCP server that provides compressed MySQL schema information I introduced previously was largely built using Vibe Coding. While researching Vibe Coding techniques, I found many tips but couldn't find detailed examples of actual AI conversations and workflows, which was frustrating.
So in this article, I'll share the specific Vibe Coding process I used when implementing this tool. I hope this helps others who are struggling to understand the concrete approaches like I was.
When building this MCP server, my overall Vibe Coding approach was:
- Built the core functionality almost entirely through Vibe Coding with minimal code review, just runtime verification
- Since Vibe Coding didn't work well for initial test structure setup, I manually created this part
- From there until this point, I made changes like test creation, refactoring, and text/template implementation. I used Vibe Coding as the main approach while manually adjusting parts that didn't work well.
I'd like to share some implementation examples from this process. In this repository, up to this commit tree, I actively committed files in .cursor/ and docs/ directories, so looking at those alongside will be helpful.
Basic Workflow
- Before starting implementation, chat with AI to brainstorm requirements and create a requirements.md file
- When implementing something: first ask AI to design it in chat => write out the design including TODO lists in docs => reload those docs and have AI code based on them
- However, if it's not complex design and won't exceed context length limits, you can implement directly without writing to docs
- When making spec or design changes during development, document them in docs
I primarily used Cursor's Agent with Gemini 2.5 Pro model. Occasionally used o4-mini or Claude 3.5 Sonnet. I didn't use memory bank or MCP servers.
Examples
Requirements.md Brainstorming
Let me start with an example of brainstorming requirements. I began with questions like this and had AI help define requirements:
I continued chatting quite casually:
What I want to do is configure which database to connect to via environment variables, then have two tool calls:
- Output table list
- Output table details
What would be good tool names?
After continuing the conversation, when I felt we had something reasonable, I said "Please reflect our conversation so far into requirements.md" and had it written out.
What was created then is here. As you can see, at this point the AI didn't understand the MCP server concept.
So I continued to help AI understand MCP server concepts while updating requirements.md. Since I thought the reference material https://modelcontextprotocol.io/quickstart/server would be useful for implementing MCP servers, I first asked ChatGPT to create summary material:
I want to prepare reference material for AI when implementing MCP Server.
Please read the material at https://modelcontextprotocol.io/quickstart/server and create markdown information for AI to read
After placing the created material in docs/, I loaded it and created requirements.md again. The commit is here. This produced a requirements.md that seemed to understand MCP server tool concepts.
Please also refer to the diff up to this point.
Implementing list_tables
Next, let me introduce an example of implementing list_tables, a tool function that outputs summary information for table lists in a specific database. The overall picture is here.
Since I had a TODO list for list_tables implementation in my head, I implemented it step by step with Vibe Coding.
First, I created the part that outputs only table names and table comments. When creating this, I used Cursor's @ reference to load docs/ and asked to start with design rather than writing code. The chat flow was roughly:
@main.go I want to create list_tables. First, please think about what kind of design to use without writing code @docs
How about we start by listing table names and table comments?
Please read @https://github.com/mark3labs/mcp-go/blob/main/README.md and examine the content that listTablesHandler should return more carefully
After repeating chat like this and feeling the design was reasonable, I generated code all at once:
Looks good. Please reflect this implementation in main.go
Similarly, I also created the PK, UK, FK output parts using this flow.
Refactoring to Use text/template
After creating all functional requirements with the approach explained above, let me also introduce an example of refactoring to use text/template.
The code initially created with Vibe Coding used string concatenation for text assembly. To improve readability, I considered using text/template and implemented it through Vibe Coding. The overall picture is this.
The approach was the same as previously introduced: first have AI design in chat => write out the design including TODO lists in docs => reload those docs and have AI code. I started with questions like this:
I continued chatting, asking questions like:
Should template-related processing go in view.go? Are there other good file names?
When I felt the design was roughly complete, I had it written to docs. What was created then is this (though this doc wasn't committed and includes describe_tables text/template work too).
Let's go in that direction. Could you write out the design so far to docs/onetime/20250427-use-template.md?
Then I moved to the implementation phase. After loading the document and having AI create a TODO list:
Let's go step by step. What should we do first?
After that, I repeated the flow of generating code one step at a time, staging it in git, then implementing the next step. I committed when list_tables text/template conversion was complete.
I then created the describe_tables side using the same flow to complete the refactoring.
Thoughts After Trying Vibe Coding
- Among various models I tried, Gemini 2.5 Pro was quite good. Not sure if it's because of the long context length or other reasons
- However, Gemini has a tendency to write excessive code comments, which was very annoying
- Setting up .cursor/rules/ is essential
- For example, without rules like 000-global.mdc, code generation became quite chaotic and difficult. Reference: https://qiita.com/masachaco/items/c56bd601576ed9612f6c
- I also prepared 100-go-test.mdc to inform about Go test execution methods
- For newer technology specs or library usage, prepare separate docs and load them when needed
- I prepared a summary of MCP server implementation documentation and a summary of mcp-go usage
- Having many such references on hand seems important
- While I used agent delegation as a constraint to understand Vibe Coding this time, for anything other than throwaway code or tools maintained only by myself, it seems better to use Vibe Coding for PoC then adjust or rewrite code yourself
Summary
In this article, I introduced the specific workflow for creating an MCP server that returns MySQL schema information using Vibe Coding. Since there are many articles about Vibe Coding but few concrete examples, I hope this helps people with similar concerns.
Top comments (0)