DEV Community: Kyle Czajkowski

Introducing My Hiking Trip Planner: Motivation and Overview

Kyle Czajkowski — Tue, 23 Sep 2025 18:28:21 +0000

Motivation and Overview

Have you ever struggled to plan the perfect outdoor adventure? Juggling routes, deciphering weather forecasts, and wondering if you've remembered everything? I've been there. To make life easier for other adventurers, I've started developing a hiking trip planner that simplifies the process and eases any pre-trip doubts.

My Motivation

After experiencing burnout in my software engineering career, I revisited an idea I'd been sitting on for years. In doing so, I reignited my passion for coding, development, and exploring new technologies. This project gives me a way to channel my skills into something meaningful, with the potential to genuinely help others.

Project Overview

Right now, my project is an item inventory, checklist, and trip planning app. It's a work in progress, with several features either still in development or open to improvement.

The user interface is primarily designed a central dashboard that highlights the next upcoming trip, and includes a current weekly weather widget, localized to the upcoming trip destination. Past trips are also archived here. I've added a widget that displays the user's allocated AI recommendation usage in an easily digestible way. While I don't have monetization plans for the app yet, I found this was a fun and simple feature to include.

The dashboard also features placeholders for sustainable packing tips, weather updates, and safety alerts customized for upcoming trips. I intend to leverage Claude integrations to implement these functionalities, and I'm particularly interested in exploring the development of function calls (tools) for these features.

I'm especially proud of the personalized AI trip recommendations feature I developed. Users can choose to incorporate these into their checklists, making the process even more tailored to their needs.

Technologies Used

I've chosen a mix of familiar tools and new technologies to challenge myself.

Familiar Ground

Next.js: As an experienced React developer, I can move quickly with this performance-focused framework. Its built-in features, such as API endpoints, middleware, and server-side rendering (SSR), streamline the process of building full-stack apps while ensuring optimized performance and scalability. The framework's focus on developer experience, with features like automatic code splitting and fast refresh, helps me stay productive and efficient.

TypeScript: This has become a favorite of mine for its ability to keep code maintainable. The language also saves time by making old code easy to revisit and understand. Plus, having your code editor nudge you about available properties is always a win.

Exploring New Terrain

Supabase: This is an incredible open-source solution for database management. It offers a feature-rich free tier that includes authentication, user management, and plenty of room to grow as your project scales. While they market themselves as a "Firebase Alternative," I find their documentation much easier to follow than Google's. Being open-source also fosters an active and supportive community, and I've had an easier time finding solutions to problems quickly by leveraging those community replies. Moving forward, Supabase will definitely be at the top of my list for database solutions.

Anthropic API: My earliest experience working with AI was with machine learning about six years ago, using tools like TensorFlow.js for object detection, image classification, and other small, fun projects. Those experiments taught me valuable lessons about how neural networks work their magic (maybe a topic for the future?).

That said, I've had reservations about more recent AI tooling. The ethics of how these companies collect data to train their Large Language Models (LLMs) are murky at best. While LLMs are, at their core, sentence-completion networks, I've questioned the depth of their real-world utility beyond specific use cases like chatbots. However, with the rapid pace of development and the addition of new functionality and architectural complexities, these tools are beginning to prove their worth—though it's debatable how many truly useful ones have surfaced.

For this project, I stepped out of my comfort zone to challenge my biases against LLMs and chose to integrate Anthropic's API. I evaluated offerings from OpenAI, Google, Microsoft, IBM, and Meta before deciding on Anthropic for several reasons:

Cost-effective: One of the most budget-friendly options available
Model variety: The ability to choose between different models—like Haiku, Sonnet, and Opus—based on budget and functionality needs
Developer-focused documentation: Outstanding docs clearly designed with developers in mind, not just large corporations
Transparent tooling: Intuitive dashboard with clear billing, token cost tracking, and spending limits
Customization: Allows you to fine-tune how your "AI assistant" behaves

It's evident that Anthropic deeply cares about the product they're bringing into the world and the impact it will have.

One feature that particularly excites me is their recently open-sourced Model Context Protocol (MCP), which I am looking forward to exploring further and plan to write more about it as I dig in. I'm confident we'll be seeing and using more of this kind of innovation in the near future. With MCP, I could also experiment with introducing tools that directly modify the database, opening up possibilities for seamless data management and dynamic interactions within applications.

The Model Context Protocol is an open standard that enables developers to build secure, two-way connections between their data sources and AI-powered tools. The architecture is straightforward: developers can either expose their data through MCP servers or build AI applications (MCP clients) that connect to these servers.

Challenges and Learnings

As a seasoned software engineer, I'm well-versed in writing code, fixing bugs, and troubleshooting, but managing my own projects and balancing the research and development of each feature has proven to be a unique challenge. This is by far the most ambitious solo project I've undertaken, and my initial tendency to dive straight into coding wasn't going to work here. I realized I needed to approach each feature individually, compartmentalizing my work to ensure every detail was carefully planned and accounted for.

For example, I didn't set up a local Supabase database initially and relied solely on the deployed version. It worked, but when I started thinking about collaboration or offline development, I realized why developing against production wasn't going to be sustainable long-term. That's when I finally went back to the docs and saw that, of course 🤦, there's an entire section about how to develop locally and use Supabase's CLI.

While it felt like a setback at the time, it turned into a great learning opportunity. I've since explored features like generating types from the database and managing migrations locally before deploying them. This experience was a reminder of the value of understanding new tools thoroughly before diving in.

Future Plans

I'm embracing my inner project manager and taking a more deliberate approach to development. Here's what's on the horizon:

Styling Improvements: I want to incorporate sweeping landscape photos that my wife and I have taken, bringing a personal touch to the app's design.
Personalized AI Responses: Enhancing the AI assistant to provide even more tailored recommendations for users. This will help give better recommendations and give the user genuinely good (for them) information.
Sharing Features: Allowing users to share checklists and trips with others. As well as adding more collaboration features.
Food Planning: A tool to help users pack the right amount of food for their trips. No more overpacking or running out of snacks!
Machine Vision Tool: I have an exciting idea in mind, but I'll keep the details under wraps for now. Stay tuned!

Wrapping Up

This project has been an incredible journey, and I'm excited to keep refining it. If you're a backpacker, I hope this app makes your adventures easier and more enjoyable. Check out the code over on GitHub, and let me know what you think—I'd love your feedback!

Originally published on my blog where I write about tech, outdoor adventures, and the intersection of both. For more content like this, visit kyle.czajkowski.tech.

Troubleshooting Claude’s Remote Connection to MCP Servers

Kyle Czajkowski — Mon, 15 Sep 2025 15:20:09 +0000

I was very excited to hear about Anthropic’s announcement in May, that we now have the ability to add integrations to Claude. Connecting to remote MCP (Model Context Protocol) servers and not just local ones is a major step forward. AI systems like Claude are no longer limited by the age of their training data. They can pull in up-to-date context and use tools provided by these integrations (MCP servers).

Diagnosing the Initial Connection Failure

Adding MCP servers to Claude desktop is relatively straightforward, so I jumped right in. I already have a remote MCP server running and a few examples from other companies I wanted to try. Since I’ve been exploring Cloudflare’s offerings lately, I decided to start with their documentation server. After restarting Claude, I saw error messages saying that it couldn’t connect to the Cloudflare server. I double checked my config, everything looked correct, so I went to the troubleshooting documentation.

"cloudflare-docs": {
    "command": "npx",
    "args": [
        "mcp-remote",
        "https://docs.mcp.cloudflare.com/sse"
    ]
}

Inspecting Claude Desktop Logs

I walked through the debugging checklist in the MCP docs. The MCP inspector confirmed the Cloudflare server was up and running. Next I checked Claude’s logs:

tail -n 20 -F ~/Library/Logs/Claude/mcp*.log

I was able to quickly see that I was running into an issue importing something from node:fs/promises.

file:///Users/kyle/.npm/_npx/705d23756ff7dacc/node_modules/open/index.js:7
import fs, {constants as fsConstants} from 'node:fs/promises';
                ^^^^^^^^^
SyntaxError: The requested module 'node:fs/promises' does not provide an export named 'constants'

I noticed that this was coming from my .npm/_npx directory, so I wondered about my Node version. I was already on the latest Node (22.15.0) and npm was up to date too, but I ran an upgrade anyway:

npm install -g npm@latest

Then cleaned the cache

npm cache clean --force

After reinstalling and cleaning, I restarted Claude Desktop and the server connected! Amazing! I could ask Claude about workers, durable objects, whatever I needed, and I would get the most up to date information.

Encountering the TransformStream Error

When I tried to add another server, the connection failed again. The logs showed a different error in the mcp-remote package:

file:///Users/kyle/.npm/_npx/705d23756ff7dacc/node_modules/mcp-remote/dist/chunk-YJSTSVFG.js:6264
var EventSourceParserStream = class extends TransformStream {
                              ^

ReferenceError: TransformStream is not defined

This was odd because the mcp-remote package doesn’t using the TransformStream functionality. It’s a browser standard not implemented in Node.js. I double checked, and saw that my node and npm versions were still up to date. So this made me think that Claude was somehow invoking a version of node that I hadn’t used in a while.

Ensuring Claude Uses the Right Node Binary

Checking around the internet I found a GitHub Issue thread that confirmed my suspicions. Apparently nvm does not always play nicely with host apps like Claude Desktop. The thread offered several workarounds.

One reliable fix was to point directly to the Node binary instead of using npx:

{  
  "mcpServers": {
    "YOUR SERVER NAME": {
      "command": "/Users/username/.nvm/versions/node/v22.15.0/bin/node",
      "args": [
        "mcp-remote",
        "PATH TO THE MCP SERVER YOUR'E USING"
      ]
    }
  }
}

You can also keep npx as the command and set the PATH explicitly:

{  
  "mcpServers": {
    "YOUR SERVER NAME": {
      "command": "npx"
      "args": [
        "mcp-remote",
        "PATH TO THE MCP SERVER YOUR'E USING"
      ],
      "env": {
      "PATH": "/Users/username/.nvm/versions/node/v20.15.0/bin:/bin"
    }
    }
  }
}

Another option is to remove older Node versions below 18.20.4 from your system. That may not suit everyone but it ensures Claude Desktop always uses a compatible Node version.

I hope this post offers a bit more insight into debugging remote MCP servers with Claude Desktop. My issues were resolved by ensuring Claude always runs the correct Node binary. These tips should help you avoid version mismatches and get your integrations up and running more smoothly. If you’d like to explore more MCP server examples, check out Cloudflare’s Demo Day write-up and 13 servers you can use today.

Cross-posted from my blog. Have you run into similar MCP server issues? I'd love to hear about your experiences in the comments!

For more content like this, visit kyle.czajkowski.tech.