DEV Community: Robert Wilde

Building My First MCP Server: Scratching That Obsidian Itch

Robert Wilde — Sat, 02 Aug 2025 12:51:29 +0000

Building My First MCP Server: Scratching That Obsidian Itch

Finally, an Idea Worth Building

After months of hearing about Model Context Protocol (MCP) servers and thinking "that's cool, but what would I actually build?", I finally had my moment. Like many developers, there's no better motivation to work on a project than scratching your own itch.

Mine was simple: I kept losing valuable Claude Code responses. Those perfectly crafted solutions, detailed explanations, and code snippets would disappear into the void of my terminal's scrollback buffer. Meanwhile, my Obsidian vault sat there, begging to become the permanent home for this knowledge.

That's when it clicked - I needed to build an MCP server that automatically saves Claude Code responses to Obsidian.

The Challenge

Working with Claude Code daily, I noticed a pattern: I'd get fantastic responses—detailed code explanations, debugging insights, architectural suggestions—and then they'd vanish. Copy-pasting to Obsidian manually was tedious and I'd inevitably forget to do it.

What I needed was automatic capture that preserved context, added proper metadata, and organized everything in my existing knowledge management system.

!!!info "The Itch"
Every time I scrolled back through my terminal looking for that perfect Claude response from yesterday, I knew I had to build something.
!!!

The Solution

The architecture turned out simpler than I initially thought:

MCP Server: Provides tools that Claude Code can use directly
Project Detection: Automatically detects current project context
Template Engine: Formats content using customizable templates
Direct Integration: Just ask Claude to "save to Obsidian" and it happens

No hooks required—the MCP server makes tools available that Claude Code can use naturally during conversations.

Building the Real Thing

Beyond My Initial Concept

What I actually built was far more polished than my initial hook-based approach. The final MCP server provides a clean, direct integration where you simply ask Claude Code to save content to Obsidian.

Key Features I Implemented

One-command installation: python3 install.py handles everything
Project-specific configuration: Each project can have custom folders and templates
Rich formatting: Automatic frontmatter, timestamps, and structured templates
Multiple content types: Reports, reviews, and notes with different formatting

The core insight was making it conversational—instead of automatic hooks, you explicitly ask Claude to save content:

The server provides four main tools:

save_to_obsidian: Primary tool for saving formatted content
save_claude_response: Direct response saving
list_vault_files: Browse existing vault files
get_vault_structure: View vault folder hierarchy

The Magic of Direct Integration

Instead of hooks, I made it conversational. You simply ask Claude Code:

"Create a security review of the authentication system and save to Obsidian"
"Generate API documentation and save it to Obsidian as a report"
"Document the database schema and save to Obsidian"

Claude Code automatically uses the save_to_obsidian tool to format and save content to your vault with proper structure and metadata.

Project-Specific Configuration

Each project can have custom settings in .claude/obsidian.json:

{
  "folder": "Projects/My Awesome Project",
  "templates": {
    "report": "# {title}\n\n**📋 Report Generated**\n- **Date:** {timestamp}\n- **Project:** {project}\n\n{content}",
    "review": "# Code Review: {title}\n\n**👀 Review Details**\n- **Date:** {timestamp}\n- **Project:** {project}\n\n{content}"
  }
}

Automatic Formatting

The server generates properly structured files with frontmatter:

---
created: 2025-01-27T14:30:22.123456
source: claude-code
tags: [claude-code, report, project-name]
---

# Security Review: Authentication System

**📋 Report Generated**
- **Date:** 2025-01-27 14:30:22
- **Project:** my-awesome-project
- **Type:** Technical Report

---

[Your content here, formatted according to the template]

---

*Generated by Claude Code*

Template Flexibility

One of the best features is the template system. Different content types get different formatting:

{
  "templates": {
    "security-review": "# 🔒 Security Review: {title}\n\n**Reviewed by:** Claude Code\n**Date:** {timestamp}\n\n## Executive Summary\n\n{content}",
    "api-docs": "# 📚 API Documentation: {title}\n\n**Generated:** {timestamp}\n**Version:** 1.0\n\n{content}"
  }
}

Getting It Running

Super Simple Installation

I built an interactive installer that handles everything:

git clone https://github.com/your-username/obsidian-mcp-server.git
cd obsidian-mcp-server
python3 install.py

The installer:

✅ Checks Python 3.8+ and installs MCP dependencies
✅ Prompts for your Obsidian vault path
✅ Installs the MCP server globally to ~/.claude/
✅ Configures Claude Code settings automatically
✅ Optionally creates project-specific configuration

For Existing Projects

Add project-specific configuration to any existing project:

python3 install.py --project-config

This creates a .claude/obsidian.json file in your current project with custom folder and template settings.

What I Learned

MCP is Simpler Than Expected

The Model Context Protocol documentation made it seem complex, but the reality is refreshingly simple. You define tools, handle requests, and return responses. The Python SDK abstracts away the protocol details.

Conversational Beats Automatic

My initial hook-based approach felt clever, but the conversational approach proved better. Being explicit about what to save gives you control over content and context.

Templates Transform Usability

The template system was a game-changer. Different content types (reports, reviews, notes) get appropriate formatting automatically. No more manually structuring every saved item.

!!!tip "Pro Tip"
Start with simple templates and evolve them. I began with basic frontmatter and gradually added project-specific formatting.
!!!

The Payoff

Now I can tell Claude Code "generate a security analysis and save it to Obsidian" and get a perfectly formatted document in my vault. The project-specific configuration means each project's documentation lands in the right folder with the right formatting.

More importantly, I scratched my itch. That nagging feeling of losing valuable information is gone. My knowledge management system finally captures the full context of my development workflow.

Common Pitfalls

A few things that initially tripped me up:

MCP server path: Ensure the Python path in settings.json is correct
Vault permissions: Make sure Claude Code can write to your Obsidian vault
Project detection: The .claude/obsidian.json file needs to be in your project root
Template syntax: Use double braces {timestamp} for variable substitution

Why This Approach Works

Sure, I could have manually copied responses or used existing clipboard managers. But there's something deeply satisfying about building a solution that perfectly fits your workflow.

The conversational approach feels natural—you're already talking to Claude, so asking it to save content is intuitive. The project-specific configuration means each codebase gets its own organization without any manual setup.

Real-World Usage

Now I regularly ask Claude Code to:

"Create a deployment guide and save to Obsidian as a report"
"Review this security vulnerability and save the analysis to Obsidian"
"Document this API endpoint and save it to Obsidian"

Each gets properly formatted, timestamped, and filed in the right project folder.

Conclusion

Building my first MCP server taught me that the best projects often start with the simplest problems. I wasn't trying to revolutionize AI tooling—I just wanted to stop losing Claude responses.

The final solution exceeded my expectations. What started as a basic "save responses" idea became a comprehensive documentation workflow that integrates seamlessly with how I already work.

Sometimes the most powerful solutions come from scratching your own itch.

Resources

Reducing Cognitive Load: My Approach to Team Collaboration

Robert Wilde — Tue, 01 Jul 2025 02:03:17 +0000

Today I completed an API endpoint that a colleague needed to integrate with their system. Rather than simply sending over the endpoint URL and waiting for the inevitable questions, I took a different approach.

I prepared a comprehensive package that included a POSTMAN collection with pre-configured diagnostics, a fully populated example request with actual data including signature and delivery images, and a sample of the generated PDF output.

The entire process took me perhaps ten additional minutes.
My colleague's response was telling: "Thanks! Can you embed a soundtrack and make the pdf 3D 😂👍 just kidding. Looks nice. Will run few tests in the morning."

The time I invested was minimal because I had just built the feature and had all the context fresh in my mind. However, the time saved for my colleague could be hours of trial and error, debugging, and back-and-forth communication.

When we thoughtfully reduce friction at the right points, we enable our teams to focus on innovation rather than interpretation.

This small example reflects a larger principle: the most impactful contributions often come not from what we build, but from how we enable others to build upon our work.

AI as a Development Tool: Enhancing, Not Replacing

Robert Wilde — Thu, 19 Jun 2025 05:12:27 +0000

The conversation around AI in software development continues to evolve, and I've recently experienced some breakthroughs that have fundamentally changed how I view these tools. The key insight? AI serves as a helper, not a replacement – and this distinction matters more than we might think.

Tools Define Our Trade

Throughout my career across different industries, including construction, I've learned that tools are everything. Yet developers often have strong, sometimes puzzling preferences. Why do some developers choose VS Code for PHP development when PHPStorm offers comprehensive, purpose-built functionality? The answer lies not in the tool itself, but in how we choose to leverage it.

Reducing Development Arrogance

One of the most unexpected benefits I've discovered in working with AI tools is how they've reduced my tendency toward development arrogance. As a contractor, I've encountered numerous approaches to writing code:

The general framework-specific best practices
Internet-wide accepted standards
Internal company style guides (often defended with "that's how we've always done it")
My own preferred methods

Previously, I might have stubbornly advocated for my approach. Now, AI helps me evaluate these different perspectives objectively. This shift is particularly valuable when working on greenfield projects or MVPs, where I've learned to view everything as potential technical debt until it reaches production.

The Power of Rapid Iteration

AI has transformed my development workflow by enabling rapid scenario testing. I can now:

Compare different approaches and their trade-offs
Analyze package documentation against framework requirements
Evaluate compatibility issues across different components
Consider multiple implementation strategies simultaneously

What previously took a week of research and experimentation can now be accomplished in hours. This isn't about cutting corners – it's about exploring more possibilities and making better-informed decisions.

Ownership and Responsibility

Here's a crucial point: when you use AI to help write code, it remains your code. You are responsible for it. Others will review it as if you wrote every line yourself – because ultimately, you did. AI is simply another tool in your toolkit, similar to linters, static analysis tools, or any other development aid.

This perspective drives home the importance of:

Implementing comprehensive testing
Ensuring proper test coverage
Verifying that tests actually validate functionality
Maintaining code quality standards

Beyond Copy-Paste Development

Using AI effectively isn't about laziness. Developers who use AI poorly are often the same ones who blindly copied from Stack Overflow without understanding the code. The tool may have changed, but the underlying methodology and thought process should remain rigorous and thoughtful.

Learning Through Application

Perhaps most surprisingly, I've learned more in recent months using AI tools than in years of traditional development. Working on unique, complex projects – including replicating legacy applications with their quirks intact – has pushed me to understand not just how to code, but why certain approaches work better than others.

The ability to quickly generate multiple test cases, explore edge conditions, and consider alternative implementations has made me a more thorough and thoughtful developer. When replicating legacy systems, AI helps identify potential bugs that might actually be features, allowing me to document and preserve intentional behaviors while building in flexibility for future corrections.

Conclusion

AI in development isn't about replacing human judgment or creativity. It's about amplifying our capabilities, reducing cognitive load, and enabling us to focus on what matters most: solving problems effectively. By embracing these tools while maintaining our professional standards and responsibility, we can create better software faster – without sacrificing quality or understanding.

The key is remembering that AI assists us in writing code; it doesn't write code for us. This distinction shapes how we approach development, how we maintain quality, and ultimately, how we grow as professionals in an evolving technological landscape.