Forem: Daniel Shashko

🤖 Build Make.com Automation Scenarios with AI Using MCP

Daniel Shashko — Tue, 10 Feb 2026 17:57:51 +0000

Have you ever wanted to build complex Make.com automation scenarios using natural language? What if your AI assistant could understand Make.com's 200+ base modules and help you create, validate, and deploy scenarios in seconds?

Enter make-mcp-server - an unofficial Model Context Protocol (MCP) server that brings Make.com's powerful automation platform directly into your AI workflow.

🎯 What is MCP?

The Model Context Protocol is a standardized way for AI assistants (like Claude Desktop, Cursor, or any MCP-compatible client) to interact with external tools and services. Think of it as a universal adapter that lets your AI assistant "talk" to different platforms.

🚀 What Can You Do?

With make-mcp-server, you can:

✅ Search 200+ Make.com Modules

"Find modules for sending Slack notifications"

Returns comprehensive information about Slack modules with parameters, examples, and documentation.

🔍 Get Detailed Module Information

"Show me how to use the Google Sheets Add Row module"

Get parameter schemas, configuration examples, and best practices.

🧠 Validate Scenarios Before Deployment

"Check if this scenario is valid: [blueprint JSON]"

Auto-healing validation that catches errors, suggests fixes, and validates data flow.

🚢 Deploy Directly to Make.com

"Create this scenario in my Make.com account"

One command deploys your AI-generated scenario to production.

📦 Quick Setup

Prerequisites

Node.js 18+
Make.com account (sign up free)
Make.com API token

Installation

For Claude Desktop:

Get your Make.com credentials:
- Team ID: Found in your Make.com dashboard URL
- API Token: Settings → API → Generate Token
- Region: Check your Make.com URL (eu1, eu2, us1, us2)
Configure Claude Desktop:

Edit your claude_desktop_config.json:

{
  "mcpServers": {
    "make-mcp-server": {
      "command": "npx",
      "args": ["-y", "make-mcp-server@latest"],
      "env": {
        "MAKE_API_KEY": "your-api-token",
        "MAKE_TEAM_ID": "your-team-id",
        "MAKE_API_URL": "https://eu2.make.com/api/v2"
      }
    }
  }
}

Restart Claude Desktop - The MCP server icon should appear.

For Cursor IDE:

Add to your Cursor settings (Ctrl+Shift+P → "MCP: Edit Config"):

{
  "mcpServers": {
    "make-mcp-server": {
      "command": "npx",
      "args": ["-y", "make-mcp-server@latest"],
      "env": {
        "MAKE_API_KEY": "your-api-token",
        "MAKE_TEAM_ID": "your-team-id",
        "MAKE_API_URL": "https://eu2.make.com/api/v2"
      }
    }
  }
}

🎨 Real-World Examples

Example 1: Slack → Notion Integration

Prompt to Claude:

"Create a Make.com scenario that monitors a Slack channel for messages containing 'bug report', extracts the content, and creates a new page in Notion with the report details."

What happens:

Searches for Slack and Notion modules
Builds the scenario structure with proper routing
Validates the blueprint for errors
Deploys to your Make.com account

Example 2: GitHub → Discord Notifications

Prompt:

"Build a scenario that watches GitHub for new pull requests and posts them to Discord with formatting."

Result: A working scenario with GitHub webhook trigger, data mapping, and Discord message formatting.

Example 3: Complex Multi-Step Workflow

Prompt:

"Create a scenario that: 1) Triggers daily at 9 AM, 2) Fetches data from Airtable, 3) Uses a router to split records by status, 4) Sends different email templates via Gmail, 5) Logs results to Google Sheets"

Result: Complete scenario with scheduler, Airtable integration, router logic, conditional branching, and logging.

🔧 Available Tools

The MCP server exposes these tools:

Tool	Description
`search_modules`	Search 200+ Make modules by keyword/app
`get_module`	Get detailed info about a specific module
`list_apps`	Browse all available Make.com apps
`search_templates`	Find pre-built scenario templates
`validate_scenario`	Check blueprint validity with auto-healing
`create_scenario`	Deploy scenario to Make.com

⚡ Advanced Features

Auto-Healing Validation

The validator doesn't just find errors - it fixes them:

// Invalid: Missing required parameters
{
  "module": "google-sheets:addRow",
  "parameters": {
    "spreadsheet": "abc123"
    // Missing 'sheetName' parameter
  }
}

// Auto-healed:
{
  "module": "google-sheets:addRow",
  "parameters": {
    "spreadsheet": "abc123",
    "sheetName": "Sheet1"  // ✅ Added with default
  }
}

Router Support

Build complex conditional workflows:

{
  "modules": [
    {
      "id": 1,
      "module": "webhook:trigger"
    },
    {
      "id": 2,
      "module": "router",
      "routes": [
        {
          "filter": "{{status}} = 'urgent'",
          "modules": [/* urgent path */]
        },
        {
          "filter": "{{status}} = 'normal'",
          "modules": [/* normal path */]
        }
      ]
    }
  ]
}

Template Discovery

Browse 500+ pre-built templates:

"Show me templates for e-commerce automation"

Returns categorized templates with difficulty ratings and module lists.

🔐 Security & Disclaimer

⚠️ Important: This is an unofficial, community-built project. It is:

✅ NOT affiliated with Make.com
✅ NOT officially supported
✅ Open source and transparent
✅ Uses official Make.com APIs

Always review scenarios before deployment - AI can make mistakes!

🌟 Why Use This?

For Developers:

10x faster scenario creation
Natural language → working automation
Instant documentation lookup
No more clicking through UI menus

For AI Enthusiasts:

See MCP in action
Learn how AI agents interact with external tools
Build your own MCP servers

For Make.com Users:

Rapid prototyping
Complex scenario scaffolding
Template discovery
Validation before deployment

🛣️ Roadmap

[ ] Support for more Make.com features
[ ] Visual scenario builder integration
[ ] Scenario testing framework
[ ] Community template sharing
[ ] Improved error recovery

🤝 Contributing

This is an open-source project! Contributions welcome:

🐛 Report bugs: GitHub Issues
💡 Feature requests: GitHub Discussions
🔧 Pull requests: Contributing Guide

📚 Resources

GitHub Repository: danishashko/make-mcp
npm Package: make-mcp-server
MCP Registry: io.github.danishashko/make-mcp
Make.com Docs: make.com/en/help
MCP Documentation: modelcontextprotocol.io

🎓 Tutorial: Your First AI-Powered Scenario

Let's build a simple RSS → Email notification scenario with Claude:

Step 1: Set up the MCP server (see Installation above)

Step 2: Prompt Claude:

"Create a Make.com scenario that:
- Checks an RSS feed every hour
- Filters for items with 'AI' in the title
- Sends me an email with the article link"

Step 3: Claude will:

Search for RSS and Email modules
Configure the schedule trigger
Set up filtering logic
Build the email template
Ask if you want to deploy

Step 4: Review and deploy!

🔥 Hot Tips

Be specific: "Use Gmail" vs "Send email"
Provide context: Share your data structure
Iterate: Ask Claude to refine the scenario
Test first: Use Make.com's test mode
Review always: AI is powerful but not perfect

🎉 Get Started Now!

# Quick test (no installation)
npx make-mcp-server --help

# Install globally
npm install -g make-mcp-server

# Check version
make-mcp-server --version

Then configure your AI assistant and start building!

📈 Stats

⭐ 200+ Make.com modules supported
🎯 500+ templates searchable
🔧 6 powerful tools for AI agents
💪 Auto-healing validation with smart fixes
🚀 1-command deployment to production

⭐ Star the repo: github.com/danishashko/make-mcp

📦 Try it now: npx make-mcp-server

Built with 🧡 by the community. Not affiliated with Make.com.

Best AI Models for Agentic Vibe Coding in VS Code (March 2026)

Daniel Shashko — Sat, 20 Dec 2025 13:37:42 +0000

Hey everyone! In this short article, I’ll cover the AI models that worked best for me when doing agentic coding in VS Code.

Nothing here is backed by formal research. This is all based on hands-on, daily usage, real projects, and a lot of trial and error.

Let’s go!

1. Claude Opus 4.6

This one was probably expected.

I use Claude Opus 4.6 mainly for multi-step execution, combined with a custom “Beast Mode” agent written by Burke Holland from the Copilot team at Microsoft. If you haven’t tried it yet, I strongly recommend it. You can find it here or read my LinkedIn post about it.

In my experience, Opus 4.6 is the best model for working across multiple large files. It’s currently the only model I trust to run without constant manual code review. The code is clean, focused, and avoids unnecessary boilerplate.

The main downside is the quota cost, which is counted as x3.

Best use case

Large features
Multi-file refactors
End-to-end implementation with minimal supervision

Usage quota: x3

2. Claude Sonnet 4.6

Need a quick review? A small UI tweak? Minor backend logic improvements? This is the model I choose for those.

With only x1 quota usage, Sonnet 4.6 gives the best balance of speed, quality, and cost for smaller tasks.

I usually use it right after a long Opus 4.6 session to polish things. It performs best with strong context, so I always test my app using Simple Browser and then point Sonnet to the exact elements I want to change.

I also rely on it for changelog creation after long coding sessions and summarization.

Best use case

Small fixes after large coding sessions
UI tweaks
Code reviews
Changelog and summary generation

Usage quota: x1

3. GPT-5.2

I have mixed feelings about GPT-5.2, but it clearly is very good in one specific area.

I don’t enjoy using it for direct coding. Compared to Opus 4.6, I often see more boilerplate and more bugs. That said, where GPT-5.2 really stands out is planning and architecture.

It consistently produces excellent:

System architecture
Stack decisions
Data models
Step-by-step development plans

With a single, well-defined prompt, I often get a deeply structured plan with clear todos, many fetched relevant sources, and strong reasoning. Beast Mode helps a lot here. See this example:

Best use case

Architecture planning
System design
Data modeling
Breaking ideas into actionable steps

Usage quota: x1

4. Gemini 3 Pro

Gemini 3 Pro is a strong backend-focused model in my experience, but is much weaker for complex UI work.

I usually choose it for database logic and authentication because it requires very little back-and-forth to reach a solid result (at least for me). It tends to “get it” quickly when it comes to structured backend problems.

It’s also very good at writing documentation and general content.

Best use case

Database implementation
Auth flows
Backend logic
README and documentation generation

Usage quota: x1

5. GPT-5 Codex (Preview)

This is my go-to model for smaller coding tasks when I want precision and predictability.

GPT-5 Codex is much less 'opinionated' than GPT-5.2 and stays very focused on the code. It’s not great for planning, but it’s very good at implementing exactly what you ask for, especially for backend coding and when the scope is clear (less of a UI star for me).

I use it a lot for isolated features, functions, and clean implementations.

Best use case

Writing specific backend functions
Implementing clear specs
Code-first tasks with minimal discussion

Usage quota: x1

6. Claude Haiku 4.5

Claude Haiku 4.5 is my “fast response” model.

It’s not meant for heavy logic or large features, but it’s extremely useful when I want a quick answer without wasting quota on stronger models. It’s responsive, clear, and surprisingly accurate for small tasks.

I mostly use it as a helper during development, never as the execution model. I haven't even tried using it for execution, feel free to share your experience with it in the comments.

Best use case

Quick questions
Small helpers
Explaining existing code

Usage quota: x0.33

Final Thoughts

No single model does everything perfectly.

For me:

Opus 4.6 is the heavy lifter
Sonnet 4.6 is the finisher
GPT-5.2 is the architect
Gemini 3 Pro owns backend logic
GPT-5 Codex is the clean coder
Haiku 4.5 is the fast assistant

If you combine them instead of sticking to one model, the results are on a completely different level (and your quota too 🫠).

10 AI Coding Patterns That'll Make You Look Like a Wizard 🧙‍♂️

Daniel Shashko — Tue, 04 Nov 2025 21:58:37 +0000

Most developers or technical marketers I see are either copying garbage code without thinking, or avoiding AI entirely because "it doesn't understand my problem 🤥". Both approaches miss the point. AI won't write your app for you, but it can handle the parts of coding that make you want to quit and cry.

The ten techniques below work because they're based on how you actually build software and are tested by me and many others I learned from.

Make AI Explain Your Code Back to You

This one changed everything for me. Instead of asking AI to fix broken code, I started explaining my code to it first and asking it to tell me what it does.

It's rubber duck debugging, but the duck actually talks back 🤪

When you hit a bug, write out what you're trying to accomplish and what your code actually does. Then ask AI to explain your logic back to you in plain language. Nine times out of ten, when the AI restates your code, you'll spot the flaw immediately.

The Reverse Explanation Pattern:

I'm trying to calculate the total price with tax. Here's my function:

[paste your code]

Can you explain back to me, in plain English, what this function does step by step? Don't fix anything, just tell me what the code is actually doing.

When the AI says "this function multiplies price by 0.08 then adds it to itself," you'll realize you forgot to add the original price. The bug becomes obvious because someone (or something) else is reading your intent.

I use this for almost every bug now. It catches logic errors way faster than staring at the screen for an hour.

⏱️ Time Saved: 30 minutes to 2 hours per bug

Generate Database Schemas That Actually Work

Setting up databases is one of those things that's never creative but always takes forever (at least for me). You know what you need: tables, relationships, indexes, etc. It's just annoying to write it all out.

AI can generate complete database schemas if you give it the full picture upfront. Don't just say "make me a user table." Describe your entire data model, how pieces relate, what needs to be fast, and what needs to be secure.

Schema Generation Checklist:

📊 Entities: List every type of thing (users, posts, comments, etc.)
🔗 Relationships: One-to-many? Many-to-many? Be explicit
🔒 Constraints: Required fields, unique values, foreign keys
⚡ Performance: What queries will run most often?
🗂️ Indexing: Which columns need indexes for speed?
📝 Audit: Do you need created_at, updated_at, deleted_at?

For a blog platform side project, I asked for tables for users, posts, comments, and tags. Told it users write posts, posts have comments, and posts can have multiple tags. Needed it optimized for showing recent posts by author since that's the main query. Asked for PostgreSQL with proper relationships and timestamps on everything.

I got back complete table definitions with all the connections set up correctly. Ran it, worked immediately. Saved hours of looking up syntax (especially for a newbie like me).

⏱️ Time Saved: 2 to 4 hours

Ask AI to Break Down Your Approach First

This is the opposite of what most people do. Instead of asking AI to solve your problem, ask it to help you plan your solution.

Tell AI what you're building and ask it to question your approach. What edge cases might you be missing? What's a simpler way to do this? Where might this break at scale?

The Interrogation Pattern:

I'm building [feature description]. My plan is to [your approach].

Before I start coding or working on this project, what questions should I be asking myself? What edge cases am I probably not thinking about? Is there a simpler architecture I'm overlooking?

I was planning to build a simple feature for handling file uploads on a personal project (the blog platform from before). Asked AI what could go wrong with my approach. It caught that I wasn't checking file size limits or validating file types. Would have been a security nightmare in production.

Use this for any feature that feels like it might get complicated or if you always "forget" something. The AI won't always be right, but it'll force you to defend your choices, which often reveals flaws you didn't see.

⏱️ Time Saved: 4 to 8 hours (by avoiding wrong implementations)

Generate Migration Scripts Without the Headache

Database migrations are error-prone and boring. One typo in a migration and you're rolling back in production at 2am.

AI is perfect for generating migration scripts because it can be paranoid about edge cases in ways humans forget to be.

Give it your current schema and your target schema, and ask for migration scripts that handle existing data, add rollback commands, and preserve data integrity.

Migration Request Template:

Current schema: [paste current tables]
Target schema: [describe changes]

Generate migration scripts that:
- Add new columns with appropriate defaults
- Migrate existing data safely
- Create rollback scripts
- Add necessary indexes
- Handle foreign key constraints
- Work with [your DB engine]

Include warnings for any data loss scenarios.

Needed to split a users table into users and user_profiles to separate auth from profile data. Described the split and asked for both up and down migrations. AI generated scripts that created the new table, copied data over, set up foreign keys, added indexes, and included a rollback that would merge everything back. Even included warnings about potential data loss if email fields were longer than 255 characters. For best practices, see Database Rollback Strategies in DevOps.

Tested the migration on a copy of production data. Worked perfectly. Would have taken me all afternoon to write and test manually.

⏱️ Time Saved: 1 to 3 hours

Build Multi-Step Workflows in One Shot

Once you understand individual prompting patterns, you can chain them together to generate entire features.

The trick is structuring your prompt as a sequence: models first, then business logic, then API, then UI, then tests. Each piece builds on the previous one.

Feature Blueprint Format:

Build a [feature name] with the following stack: [technologies]

Step 1 - Data Model:
[describe your entities and relationships]

Step 2 - Business Logic:
[describe the core functionality]

Step 3 - API Endpoints:
[list endpoints with methods and requirements]

Step 4 - Frontend:
[describe the UI components needed]

Step 5 - Tests:
[what needs test coverage]

Generate code for each step that works together as a cohesive feature.

I needed a content translation system. Described the setup: Streamlit for the UI, Playwright to scrape web pages, AI models for translation, Bright Data's SERP API to find relevant links to add, and Pyppeteer for simple browser actions like screenshots.

AI generated the complete pipeline in about 30 minutes of back-and-forth. The scraping worked immediately, translation was solid, and the UI had all the controls I needed. Code wasn't perfect (had to fix some error handling and rate limiting), but it was ~90% done and properly structured.

This works best for self-contained tools that don't need to integrate deeply with existing systems. For modifying production apps, it's better to do it piece by piece.

My own example:

⏱️ Time Saved: 4 hours to 2 days

Let AI Write Your Documentation

Writing docs is important and nobody wants to do it. AI is actually pretty good at this if you give it the code and tell it who the audience is.

Don't ask for generic documentation. Specify the audience, the format, what needs examples, and what needs warnings.

Documentation Pattern:

Create documentation for [code/API/component] targeted at [audience].

Include:
- Brief overview of what it does
- Setup/installation steps
- Usage examples (at least 3 realistic scenarios)
- Common pitfalls and how to avoid them
- API reference (if applicable)
- Links to related docs

Format: [Markdown/Docstring/JSDoc/etc.]

Built a custom event tracking system that sends user behavior data to our analytics stack. Needed a documentation so other marketers could add new events without breaking anything. Gave AI the code and asked for docs with examples of tracking button clicks, form submissions, and page views.

Got back a documentation that actually made sense to non-developers. First time it's ever happened to me.

⏱️ Time Saved: 1 to 3 hours

Use AI for "What's Wrong With This" Reviews

When your code works but feels off, ask AI to review it like a senior engineer would. Not just for bugs, but for code smell, performance issues, security problems, and maintainability.

Code Review Prompts:

Review Type	Prompt
Security	"Review this code for security vulnerabilities. Look for SQL injection, XSS, insecure dependencies, and auth bypass issues."
Performance	"Analyze this code for performance problems. Identify N+1 queries, unnecessary loops, and expensive operations."
Maintainability	"Review this code for maintainability. Point out complex logic, poor naming, missing error handling, and tight coupling."
Best Practices	"Review this against [language/framework] best practices. What patterns am I violating? What's going to confuse the next dev?"

I had an API endpoint that worked fine in testing but felt slow. Asked AI to review it for performance and security. It caught that I was making 50 separate database calls inside a loop when I could do it in one query, spotted a missing rate limit, and found a security hole in how I was handling user input.

⏱️ Time Saved: 2 to 6 hours (by catching issues early)

Generate Environment-Specific Configs

Docker files, CI/CD configs, environment variable files, they're all important but boring. Each one has specific syntax that I often forget.

AI can generate complete config files for your stack if you tell it what you're deploying and where.

Config Generation Needs:

🚀 Stack: Framework, database, services you're using
🌍 Environments: Development, staging, production requirements
🔧 Build process: Dependencies, build steps, optimization
🧪 Testing: How tests should run in CI
📦 Artifacts: What gets deployed, where it goes
🔒 Secrets: How environment variables get managed

I saw a LinkedIn post about someone needing a complete Docker setup for a Next.js app with PostgreSQL. Asked for a Dockerfile with multi-stage builds for production, docker-compose for local dev with hot reloading, and a GitHub Actions workflow that runs tests, builds the image, and pushes to AWS ECR.

And guess what? He got back everything he needed with comments explaining each step. The Dockerfile was optimized for layer caching, docker-compose had correct volume mounts, and the GitHub workflow included parallel test runs.

Disclaimer: The above section is based on someone else's story.

⏱️ Time Saved: 2 to 4 hours

Ask AI to Generate Only The "Boring" Parts

One of the best uses of AI is admitting which parts of your job are genuinely choking your soul.

Form validation? Have AI write it. Type definitions? AI. Converting JSON to TypeScript interfaces? AI. Boilerplate CRUD endpoints? AI.

Keep the interesting problems for yourself. Let AI handle the stuff that makes you zone out.

High-Value Automation:

✓ Form validation with error messages
✓ TypeScript type definitions from JSON
✓ CRUD endpoints (basic create/read/update/delete)
✓ Data transformation utilities
✓ Mock data generators for testing
✓ Regex patterns for common validations
✓ Basic error handling wrappers
✓ Logging setup and configuration

This is where AI really shines. Not replacing you, just doing the things you'd do anyway but faster.

⏱️ Time Saved: 15 minutes to 2 hours per task

Create Reusable Code Patterns

If you find yourself writing the same kind of code repeatedly, have AI generate a template you can reuse.

This works great for things like API error handlers, database query wrappers, authentication middleware, logging, or anything else that follows the same pattern every time.

Pattern Template Request:

Create a reusable template for [pattern type] that:

Base requirements:
- [list core functionality]

Must handle:
- [list edge cases]

Should be customizable by:
- [parameters/options]

Generate TypeScript/Python/etc. with inline comments explaining how to customize it for different use cases.

I kept writing the same code to connect to a CRM API every time we built a new automation. Asked AI to create a reusable connector that takes care of authentication, retries failed requests, and formats the data correctly. Said that I wanted detailed error messages during testing but simple ones in production.

Got back a wrapper function I now use for all integrations. Changed a few field names to match our CRM structure, but the connection logic worked perfectly.

Now whenever I need to pull CRM data, I copy the template and customize it in 2 minutes instead of fighting with API documentation.

⏱️ Time Saved: 30 minutes to 2 hours (accumulated over multiple uses)

What This Actually Means

The pattern here is obvious: AI is best at structured, repetitive work with clear requirements. It's not good at creative problem-solving (yet).

That means your job changes, no matter if you are a dev or a marketer. Instead of writing every line of code, you're making architectural decisions, explaining requirements, reviewing generated code, and solving the interesting problems.

The boring parts (boilerplate, config files, CRUD, type definitions - you name it) happen faster. The creative parts (system design, user experience, performance optimization) get more of your time.

Start This Week

When	Do This
Today	Use the "explain back" technique on your current bug
Tomorrow	Generate a database schema or migration script
This Week	Try the multi-step workflow for a small feature
Next Week	Review what saved you the most time and do more of that

You don't need to use AI for everything. Use it for the parts that make sense for your workflow. If something works better the old way, keep doing it the old way. Thanks for reading!

Connect Claude Desktop to Local MCP Servers

Daniel Shashko — Mon, 03 Nov 2025 16:09:45 +0000

MCP servers give Claude Desktop superpowers. They're programs that run on your computer and let Claude interact with your files, databases, and other local resources. It's like giving Claude hands to actually do things on your machine instead of just talking about them.

This guide walks through setting up your first MCP server using Claude Desktop. We'll get Claude connected to your file system so it can read files, create documents, organize folders, and search through your directories. Every action requires your approval, so you stay in control.

What You'll Need

Before we start, make sure you have these installed.

Claude Desktop - Download it from the official Claude website. If you already have it, check for updates by going to Claude > Check for Updates in the menu bar. You need the latest version for MCP support to work properly.

Node.js - Most MCP servers (including the filesystem one we're using) run on Node. Check if you have it by opening your terminal and running node --version. If you don't see a version number, grab the LTS version from nodejs.org. The LTS version is more stable than the cutting edge releases.

How MCP Servers Actually Work

Think of MCP servers as specialized assistants that run in the background. Each one provides specific tools that Claude can use. The filesystem server we're setting up gives Claude tools for reading files, creating directories, moving stuff around, and searching for files by name or content.

The key thing is that Claude can't just go wild with these tools. Every single action needs your explicit approval. When Claude wants to create a file or move something, you'll see a prompt asking if it's okay. If something looks sketchy, just decline it.

Setting Up the Filesystem Server

Here's how to get Claude Desktop talking to your file system. The configuration happens through a JSON file that tells Claude which servers to start and what they can access.

Open the Configuration File

First, open Claude Desktop's settings. Not the settings inside a chat window, the actual app settings. On Mac, click Claude in the menu bar and select Settings. On Windows, you'll find it in the system tray menu.

Once you're in settings, go to the Developer tab on the left sidebar.

You'll see an "Edit Config" button. Click it. This either opens your existing config file or creates a new one. The file lives at ~/Library/Application Support/Claude/claude_desktop_config.json on Mac or %APPDATA%\Claude\claude_desktop_config.json on Windows.

Add the Filesystem Server Config

Copy this configuration into your file. Make sure to replace username with your actual computer username:

macOS:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/username/Desktop",
        "/Users/username/Downloads"
      ]
    }
  }
}

Windows:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "C:\\Users\\username\\Desktop",
        "C:\\Users\\username\\Downloads"
      ]
    }
  }
}

Here's an example of my config file (Bright Data is the only remote MCP server I am using):

The paths in the args array are the directories Claude can access. This example gives it Desktop and Downloads, but you can change these to whatever makes sense for you. Just be thoughtful about it. Only give access to folders you're genuinely comfortable with Claude reading and modifying.

Here's what each piece of the config does. The "filesystem" name is just a label that shows up in Claude Desktop. The command tells it to use npx, which comes with Node.js. The -y flag auto-confirms installing the server package. And @modelcontextprotocol/server-filesystem is the actual package name. Everything after that is directories the server can touch.

One thing to watch out for: the server runs with your user permissions. If you can delete or modify something, the server can too. So be selective about which directories you expose.

Restart Claude Desktop

Save your config file and completely quit Claude Desktop. You need to fully restart it, not just close the window. Once it starts back up, look for a small hammer icon in the bottom-right corner of the chat input box. That's your MCP server indicator.

Click the hammer icon to see what tools the filesystem server provides. You should see options for reading files, creating directories, moving files, and searching. If you don't see the hammer icon at all, something went wrong. Check the troubleshooting section below.

Actually Using It

Now the fun part. Try asking Claude to do something with your files. Here are some examples that show off what's possible:

"Can you write a short story and save it to my desktop?" Claude will write the story and create a new file for it. Before saving, you'll see an approval prompt showing exactly what file it wants to create and where.

"What PDFs are in my downloads folder?" Claude will scan downloads and list any PDFs it finds. It can even summarize what they're about if you want.

"Organize all the images on my desktop into a folder called 'Images'" Claude will create the folder and move image files into it. You'll approve each step.

Every time Claude wants to do something with your files, it asks first. You'll see exactly what operation it wants to perform and on which files. Take a second to read these prompts. If something looks weird, deny it and ask Claude why it wanted to do that.

Here's an example of how I use the Yahoo Finance MCP Server:

And here's the final result:

When Things Don't Work

If the filesystem server isn't showing up or tools are failing, here's how to fix it.

Server not connecting - First, completely restart Claude Desktop. Not just closing the window, actually quit the app. Then check your claude_desktop_config.json syntax. JSON is picky about commas and brackets. Make sure all your file paths are absolute, not relative. So /Users/username/Desktop, not just Desktop. Also verify the paths actually exist on your system.

If it's still not working, check the logs. On Mac they're in ~/Library/Logs/Claude, on Windows in %APPDATA%\Claude\logs. The mcp.log file shows general connection info. Files named mcp-server-filesystem.log show errors from the filesystem server specifically.

You can tail the logs on Mac with:

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

On Windows:

type "%APPDATA%\Claude\logs\mcp*.log"

Try running the server manually to see if it throws any errors:

npx -y @modelcontextprotocol/server-filesystem /Users/username/Desktop /Users/username/Downloads

Tools failing silently - If Claude tries to use tools but they fail without clear error messages, check the logs first. Then verify the server runs correctly when you start it manually. Sometimes restarting Claude Desktop fixes weird state issues.

Windows path issues - If you're on Windows and seeing errors about ${APPDATA} in paths, you might need to add the expanded value to your config's env section:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "C:\\Users\\username\\Desktop"],
      "env": {
        "APPDATA": "C:\\Users\\username\\AppData\\Roaming\\"
      }
    }
  }
}

Also make sure npm is installed globally. You should have a %APPDATA%\npm directory. If not, run npm install -g npm to install it globally.

What's Next

You've got Claude connected to your file system now. That's a solid start, but there's a lot more you can do with MCP.

Check out the official MCP servers repository on GitHub to see what else is available. There are servers for databases, APIs, web scraping, and all sorts of other tools. The community has built some really interesting ones too.

If you've got specific needs, you can build your own MCP server. It's not as hard as it sounds. The MCP documentation has guides for creating custom servers in Python or TypeScript.

You can also connect Claude to remote servers, not just local ones. This opens up possibilities for cloud-based tools and services. Same concept, different connection method.

And if you want to really understand what's happening under the hood, read through the MCP architecture docs. They explain the protocol design and how clients and servers communicate. It's genuinely interesting if you're into that kind of thing.

MCP Server Architecture: A Developer's Guide

Daniel Shashko — Mon, 03 Nov 2025 15:56:11 +0000

The Model Context Protocol lets AI applications like Claude Desktop pull in context from different data sources. Think of it as a way to connect your AI to databases, APIs, file systems, and other tools without writing custom integrations for each one.

This guide focuses on how MCP actually works. If you want to start building, check out the language-specific SDK docs instead.

What's Actually in MCP

MCP is really four things:

First, there's the specification that defines how clients and servers should talk to each other. Then you've got SDKs in different languages that handle the protocol details for you. The MCP Inspector helps you test and debug your servers during development. And finally, there are reference server implementations you can learn from or use directly.

One thing to understand upfront: MCP only handles context exchange. It doesn't care how your AI application uses that context or which language model you're running. That's your problem to solve.

How MCP Components Fit Together

MCP uses a straightforward client-server setup. An AI application (the MCP host) creates separate client connections to each server it wants to talk to. Every connection is one-to-one, so if you connect to three servers, you're managing three separate client instances.

The main players are:

MCP Host - This is your AI application. It could be Claude Desktop, VS Code, or anything else that needs context from external sources. The host coordinates multiple client connections.

MCP Client - Each client maintains one connection to one server. It's basically a messenger that fetches context and passes it back to the host.

MCP Server - A program that serves up context. Could be running locally on your machine or hosted remotely somewhere.

Here's a real example: VS Code is the host. When you connect it to the Sentry MCP server, VS Code spins up a client object just for that connection. Connect to the filesystem server too, and you get a second client object. Two servers, two clients, clean separation.

graph TB
    subgraph "MCP Host (AI Application)"
        Client1["MCP Client 1"]
        Client2["MCP Client 2"]
        Client3["MCP Client 3"]
    end

    Server1["MCP Server 1<br/>(e.g., Sentry)"]
    Server2["MCP Server 2<br/>(e.g., Filesystem)"]
    Server3["MCP Server 3<br/>(e.g., Database)"]

    Client1 ---|"One-to-one<br/>connection"| Server1
    Client2 ---|"One-to-one<br/>connection"| Server2
    Client3 ---|"One-to-one<br/>connection"| Server3

Quick terminology note: we call them MCP servers regardless of where they run. A server running on your laptop using standard input/output? That's a local server. A server running on Sentry's infrastructure using HTTP? That's a remote server. Both are just MCP servers.

The Two Layers

MCP splits responsibilities between two layers:

Data Layer - This is the protocol itself, built on JSON-RPC 2.0. It defines the message formats for everything: initializing connections, discovering tools, reading resources, handling prompts, and pushing notifications.

Transport Layer - This is how messages actually move between client and server. Could be stdio (standard input/output) for local processes or HTTP for remote servers. The transport handles connection setup, message framing, and authentication.

Think of the data layer as what you're saying, and the transport layer as how you're saying it. The same JSON-RPC messages work across both transport types.

Transport Options

You've got two ways to move data around:

Stdio Transport - Uses standard input and output streams. Perfect for local servers because there's no network overhead. When Claude Desktop launches the filesystem server, it uses stdio. Fast, simple, stays on your machine.

Streamable HTTP Transport - Uses regular HTTP POST requests for client-to-server messages. Optionally adds Server-Sent Events for streaming updates from server to client. This is how remote servers work. Supports standard HTTP auth: bearer tokens, API keys, custom headers. MCP recommends OAuth for getting those tokens.

The nice thing about having two transport options is you can use the same server code locally during development (stdio) and deploy it remotely in production (HTTP) without changing the core logic.

What You Actually Share: The Data Layer

This is the interesting part. The data layer defines how servers share context with AI applications. It uses JSON-RPC 2.0 for all communication. Clients send requests, servers respond. If no response is needed, you send a notification instead.

MCP is stateful (mostly - you can make parts of it stateless with HTTP). That means you need to manage the connection lifecycle. Both sides negotiate what features they support during initialization. We'll walk through a real example in a minute.

MCP Primitives: The Core Concepts

Primitives are the heart of MCP. They define what clients and servers can offer each other. Three main types that servers expose:

Tools - Functions the AI can call to do things. Query a database, hit an API, write a file. Tools are actions.

Resources - Data the AI can read for context. File contents, database schemas, API responses. Resources are information.

Prompts - Templates that structure how the AI interacts with everything. System prompts, few-shot examples, conversation starters. Prompts are guidance.

Each primitive type has methods for listing (*/list), getting details (*/get), and sometimes executing (tools/call). Clients use */list to discover what's available, and those lists can change dynamically. That's important - a database server might expose different tools depending on which database is connected.

Here's a concrete example: you build an MCP server for Postgres. It exposes tools for running queries, resources containing your table schemas, and prompts with examples of good queries for your specific schema. The AI application can discover all of this through the list methods, then use it as needed.

Servers can also use primitives that clients expose:

Sampling - Ask the client's AI to generate completions. Useful when you need language model access but don't want to bundle an LLM SDK in your server. Call sampling/complete and let the client handle it.

Elicitation - Request more information from users. Need confirmation before deleting something? Want clarification on a query? Use elicitation/request to ask.

Logging - Send debug and monitoring messages back to the client. Helps you understand what's happening without cluttering the main data flow.

Real-Time Updates

MCP supports push notifications so servers can tell clients when things change. Your available tools change? Send a notification. A monitored resource updates? Push it to the client. Notifications use JSON-RPC 2.0's notification format (no response expected) and keep everything synchronized without constant polling.

Walking Through a Real Interaction

Let's see how this actually works with a step-by-step example. We'll show the JSON-RPC messages going back and forth.

Step 1: Initializing the Connection

First, the client and server need to agree on what they can do. The client sends an initialize request:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-06-18",
    "capabilities": {
      "elicitation": {}
    },
    "clientInfo": {
      "name": "example-client",
      "version": "1.0.0"
    }
  }
}

The server responds with its own capabilities:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2025-06-18",
    "capabilities": {
      "tools": {
        "listChanged": true
      },
      "resources": {}
    },
    "serverInfo": {
      "name": "example-server",
      "version": "1.0.0"
    }
  }
}

What's happening here? The protocol version ensures compatibility. If they can't agree on a version, they should disconnect. The capabilities object is crucial - it's how each side declares what features it supports.

In this exchange, the client says "I can handle elicitation requests" (meaning it can prompt users for input). The server says "I've got tools and they might change, plus I can serve resources." That listChanged: true flag means the server will send notifications when its tool list updates.

The info objects are mainly for debugging and logging. After this succeeds, the client sends a quick notification saying it's ready:

{
  "jsonrpc": "2.0",
  "method": "notifications/initialized"
}

Behind the scenes in your AI application, this initialization happens for each server you connect to. The app stores those capabilities and uses them to route requests correctly.

Step 2: Discovering Tools

Now the client wants to know what tools are available. It sends a simple list request:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/list"
}

The server responds with detailed information about each tool:

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "tools": [
      {
        "name": "calculator_arithmetic",
        "title": "Calculator",
        "description": "Perform mathematical calculations including basic arithmetic, trigonometric functions, and algebraic operations",
        "inputSchema": {
          "type": "object",
          "properties": {
            "expression": {
              "type": "string",
              "description": "Mathematical expression to evaluate (e.g., '2 + 3 * 4', 'sin(30)', 'sqrt(16)')"
            }
          },
          "required": ["expression"]
        }
      },
      {
        "name": "weather_current",
        "title": "Weather Information",
        "description": "Get current weather information for any location worldwide",
        "inputSchema": {
          "type": "object",
          "properties": {
            "location": {
              "type": "string",
              "description": "City name, address, or coordinates (latitude,longitude)"
            },
            "units": {
              "type": "string",
              "enum": ["metric", "imperial", "kelvin"],
              "description": "Temperature units to use in response",
              "default": "metric"
            }
          },
          "required": ["location"]
        }
      }
    ]
  }
}

Each tool includes everything the client needs to use it. The name is a unique identifier. The description explains what it does. The inputSchema uses JSON Schema to define exactly what parameters it expects, which ones are required, and what types they should be. This lets clients validate inputs before sending them and helps language models understand how to call the tools correctly.

Your AI application fetches these tool lists from all connected servers and builds a unified registry. When the language model needs to do something, it can see all available tools and pick the right one.

Step 3: Calling a Tool

Let's actually use one of those tools. The client sends a call request with the tool name and arguments:

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "weather_current",
    "arguments": {
      "location": "San Francisco",
      "units": "imperial"
    }
  }
}

The name has to match exactly what was in the discovery response. The arguments need to conform to that inputSchema we saw earlier. Here we're providing both the required location and the optional units parameter.

The server executes the tool and returns results:

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Current weather in San Francisco: 68°F, partly cloudy with light winds from the west at 8 mph. Humidity: 65%"
      }
    ]
  }
}

The response uses a content array. This gives you flexibility - you could return text, images, or references to other resources. Each content object has a type field to identify what kind of data it contains. Here it's just text, but MCP supports richer response formats.

When your language model decides to use a tool during a conversation, your AI app intercepts that call, routes it to the right MCP server, executes it, and feeds the results back to the LLM. This is how the AI can access real-time data and take actions in the real world.

Step 4: Handling Real-Time Updates

Remember how the server said listChanged: true during initialization? That means it can send notifications when its tools change. Here's what that looks like:

{
  "jsonrpc": "2.0",
  "method": "notifications/tools/list_changed"
}

Notice there's no id field. That's because this is a notification - no response expected. The server is just saying "hey, my tools changed, you should check again."

When the client gets this, it typically responds by requesting an updated tool list:

{
  "jsonrpc": "2.0",
  "id": 4,
  "method": "tools/list"
}

This notification pattern is really useful. Tools might appear or disappear based on server state, user permissions, or external dependencies. Instead of constantly polling for changes, clients get notified exactly when updates happen. Keeps everything in sync efficiently.

This works for other primitives too, not just tools. You can get notifications about changed resources, updated prompts, anything that makes sense for your use case.

Your AI application handles these notifications by refreshing its internal registry and updating what the language model can access. If a conversation is active, the LLM can immediately start using new tools as they become available.

Wrapping Up

That's the core flow: initialize, discover, execute, stay synchronized. The actual protocol has more features (resources, prompts, sampling, elicitation), but this example covers the fundamental patterns you'll use most often.

Getting Started with Claude Code (Super Easy!)

Daniel Shashko — Mon, 03 Nov 2025 15:37:15 +0000

Let's get you up and running with Claude Code in a few minutes. This AI-powered coding assistant will feel like having a smart colleague right in your terminal.

What you'll need

Before we start, make sure you've got:

A terminal or command prompt open
A code project to work with (any project is fine)
A Claude.ai or Claude Console account

Claude.ai is probably your best bet if you're just getting started since it has subscription plans that are easier to manage.

Installing Claude Code

Pick the method that works for your system:

macOS or Linux with Homebrew:

brew install --cask claude-code

macOS, Linux, or WSL:

curl -fsSL https://claude.ai/install.sh | bash

Windows PowerShell:

irm https://claude.ai/install.ps1 | iex

Windows Command Prompt:

curl -fsSL https://claude.ai/install.cmd -o install.cmd && install.cmd && del install.cmd

Logging in

Once Claude Code is installed, you'll need to sign in. Start an interactive session and it'll walk you through the login process:

claude
# You'll get prompted to log in on first use

If you need to log in manually or switch accounts later, just use:

/login

You can use either a Claude.ai account (the subscription one) or a Claude Console account (pay-per-use with API credits). Both work fine, and you can even have both under the same email if needed.

When you first connect a Claude Console account, Claude automatically creates a workspace called "Claude Code" for tracking your usage and costs. Pretty handy for keeping tabs on what you're spending.

Once you're logged in, your credentials get saved locally so you won't have to do this dance every time.

Your first session

Navigate to any project directory and fire up Claude Code:

cd /path/to/your/project
claude

You'll see a welcome screen with your session info, recent conversations, and any updates. Type /help to see what commands are available, or /resume to pick up where you left off in a previous conversation.

Understanding your codebase

Let's start by having Claude take a look at your project. Try asking:

> what does this project do?

Claude will scan through your files and give you a summary. You can get more specific too:

> what technologies does this project use?
> where is the main entry point?
> explain the folder structure

You can also ask Claude about itself:

> what can Claude Code do?
> how do I use slash commands in Claude Code?
> can Claude Code work with Docker?

The cool thing is that Claude reads your files automatically as it needs them. You don't have to manually feed it context like you would with some other AI tools. It also knows about its own documentation, so it can answer questions about its features.

Making your first code change

Time for the fun part. Let's have Claude actually write some code:

> add a hello world function to the main file

Here's what happens next:

Claude finds the right file to modify
Shows you exactly what it wants to change
Asks for your permission
Makes the edit once you approve

Claude always asks before touching your files. You can approve changes one by one, or if you're feeling confident, enable "Accept all" mode for the session.

Working with Git

Claude makes Git operations feel natural. Instead of remembering commands, just describe what you want:

> what files have I changed?
> commit my changes with a descriptive message
> create a new branch called feature/quickstart
> show me the last 5 commits
> help me resolve merge conflicts

It's like having a Git expert sitting next to you who actually pays attention to what you're working on.

Fixing bugs and adding features

This is where Claude really shines. Describe what you want in plain English:

> add input validation to the user registration form
> there's a bug where users can submit empty forms - fix it
> refactor the authentication module to use async/await instead of callbacks
> write unit tests for the calculator functions

Claude will figure out where the relevant code lives, understand the context, implement a solution, and even run tests if you have them set up.

Other useful workflows

Here are some other things you can try:

Code review:

> review my changes and suggest improvements

Documentation:

> update the README with installation instructions

Testing:

> write integration tests for the API endpoints

The key is to talk to Claude like you would a helpful colleague. Be conversational and describe what you're trying to achieve.

Essential commands you'll use daily

Command	What it does
`claude`	Start interactive mode
`claude "task"`	Run a one-time task and exit
`claude -p "query"`	Ask a quick question and exit
`claude -c`	Continue your most recent conversation
`claude commit`	Create a Git commit
`/help`	Show available commands
`exit` or Ctrl+C	Exit Claude Code

Tips that'll save you time

Be specific with your requests. Instead of "fix the bug," try "fix the login bug where users see a blank screen after entering wrong credentials." The more context you give Claude, the better it can help.

Break complex tasks into steps. Don't try to do everything at once:

> 1. create a new database table for user profiles
> 2. create an API endpoint to get and update user profiles  
> 3. build a webpage that allows users to see and edit their information

Let Claude explore before making changes. Have it understand your codebase first:

> analyze the database schema
> build a dashboard showing products that are most frequently returned by our UK customers

Learn the shortcuts. Press ? to see keyboard shortcuts, use Tab for command completion, press ↑ for command history, and type / to see all slash commands.

What's next?

Now that you've got the basics down, you can explore more advanced features in the documentation. The CLI reference has all the commands, the configuration guide shows you how to customize things, and the common workflows section walks through more complex tasks.

If you get stuck, just type /help in Claude Code or ask "how do I..." Claude's pretty good at explaining its own features. You can also check out the community Discord for tips and support from other developers.

The main thing to remember is that Claude Code is designed to be conversational. Don't overthink it - just describe what you want to accomplish and let it help you get there.

Claude Code for Growth Marketing (Hell Yeah!)

Daniel Shashko — Sun, 02 Nov 2025 20:31:14 +0000

Below I’ll explain what they built, why it matters, and how you can copy the patterns without a big team (with only Claude Code). Who is they you are asking? Well, Anthrophic! Read their full document here.

What they built and why it matters

They focused on four practical automations: automatic Google Ads creative generation, a Figma plugin for mass creative production, a Meta Ads MCP (Model Context Protocol) server for campaign pull, and a simple memory system - I personally recommend basic-memory for such use cases. Each automation handles a specific pain point.

For Google Ads, the heavy lift is generating many compliant variations, then testing them. Ads have strict character limits, and manual creation is slow and error prone. The Claude Code workflow reads a CSV of past ads and metrics, flags underperformers, and spins up hundreds of new headline and description variations. Instead of a human spending hours or days, the system churns out candidates in minutes.

For creative output on social, they automated what designers do manually. A Figma plugin finds frames and swaps text layers to produce batches of variations. That reduced a job that used to take hours of copy-pasting down to less than a second per batch.

For measurement, they built a small MCP server that talks to the Meta Ads API and serves campaign performance directly into Claude Desktop. No more tab switching between platforms to pull numbers and form hypotheses.

Finally, they added a lightweight memory system. It logs hypotheses, experiment parameters, and results so each new round of creative generation can reference past learnings. That makes the testing pipeline self-improving rather than starting from scratch every time.

These are small, repeatable automations that buy hours per week and let a tiny team operate like a larger one.

How the Google Ads automation works (practical details)

They start with a CSV export that includes ad text and performance columns. Think columns like ad_id, headline, description, impressions, clicks, ctr, conversions, cost_per_conversion. The workflow first filters for ads that meet a "needs iteration" rule, for example CTR below a threshold with reasonable impressions. That keeps the system focused on ads that matter.

Claude Code runs two focused sub-agents. One handles headlines and enforces the 30 character limit. The other handles descriptions and enforces the 90 character limit. Splitting the task makes each agent simpler to prompt and easier to debug. Each sub-agent is asked to produce N variants and to return both the copy and metadata like estimated tone and targeted audience hints. The workflow then writes the new variations back to a CSV, tags them for a staged rollout, and hands them off to the ad platform or human QA.

Why split agents? Prompting one model to manage all constraints tends to create edge-case failures. Two small, single-responsibility agents give predictable outputs and make it simple to add more constraints later, like legal checks or localization.

The Figma plugin for mass creative production

Designers hate repetitive resizing and swapping. The plugin they wrote scans a Figma page for frames that match an ad template. It finds the text layers that contain headline and description, then programmatically replaces those with the generated copy. It can output up to 100 variations in one go. The plugin also exports image assets ready for upload to ad platforms.

This approach does two useful things. First, it preserves layout and image composition, so designers don't lose control of the visual. Second, it scales testing by letting you attach many copy variants to a small set of visual templates. You end up testing more combinations without hiring more designers.

A few practical tips here: keep text layers named consistently across templates, and bake in a fallback font size so long headlines truncate predictably. Also add a quick visual QA step. Even automated swaps can create weird line breaks or overlap.

Meta Ads MCP server and measurement flow

The MCP server is small and focused. It pulls campaign-level metrics, spend data, and ad creative performance from the Meta Ads API. The server normalizes the data and serves endpoints Claude Desktop can query. That means the marketing workflow can ask for the latest stats, form hypotheses, and generate new creatives without switching tools.

Rate limits and data freshness matter. They implemented simple caching and incremental pulls so the server doesn't hammer the API. They also added a lightweight schema that ties creative variants to experiment IDs so test results are easy to attribute back to individual variations.

Why bother? Pulling data into the same environment where you generate copy closes the loop fast. You look at a bad ad, ask Claude to rewrite it using the last two months of learnings, and get candidate copy within the same session. That sort of tight loop speeds up meaningful iterations.

The memory system: keep experiments from getting lost

Tracking hypotheses used to be a spreadsheet nightmare for them. They built a small memory layer that logs experiments, the hypothesis, the variants used, rollout dates, and results. When generating new creative, Claude can pull past experiment summaries and avoid repeating failed approaches. It can also suggest promising directions based on winning motifs from similar audiences.

This is not a full-featured experiment platform. It’s a simple registry that prevents reinventing the wheel. Even a few structured fields and a consistent naming convention for experiments can save hours of duplicated effort and make A/B test attribution sane.

Real-world impact and trade-offs

The concrete results were simple. Ad copy creation time dropped from roughly two hours to about 15 minutes for a campaign refresh. Creative output increased by about 10x, meaning many more variants get tested. The single-person team started running workflows that used to need engineering support.

But there are trade-offs. Automated copy still needs human QA for brand voice and legal compliance. Models can hallucinate metrics or fabricate claims, so you need checks that prevent false statements from going live. API rate limits and costs are practical constraints. And automated variants are only useful if your experiment and attribution setup is solid, otherwise you’ll collect noise instead of signal.

Practical how-to and a short starter checklist

If you want to try this in your team, start small and focus on one bottleneck. For most teams that will be either creative generation or measurement.

Quick starter checklist:

Pick one ad platform and export a CSV with ad text and at least three performance columns.
Build two simple Claude Code prompts: one for headlines, one for descriptions, each enforcing the exact character limits. Keep prompts short and strict.
Add a human QA step before anything goes live. Automate everything else once you trust the outputs.

After that, add a Figma export/import step if you want batch creative rendering. Then bring in a tiny MCP server for the platform you care about and connect it to the same workflow.

Common pitfalls and how to avoid them

People tend to ask Claude for one-shot, complicated magic prompts. That fails. Break the job into small tasks. Validate outputs at each step. Log every experiment with IDs so you can map results back to variants. Beware overfitting to short-term metrics, and make sure you track the right goals, not just CTR.

Also watch out for rate limits and edge-case text behavior. Long headlines that barely fit may break layouts on mobile. Automated QA should check character counts, line breaks, and legal tokens before upload.

Final thoughts

The pattern here is simple: automate the repetitive, make the outputs predictable, and keep humans in the loop for judgment. Claude Code isn't a all magic, but it lowers the engineering bar so small marketing teams can move fast.

If you keep prompts focused, split responsibilities across small agents, and make sure you can tie experiments back to results, you'll get a lot of mileage from this approach.

P.S. I suggest always starting with this prompt: "Do not waste tokens on generating implementation guides and illustrations, focus on the producing quality codes, I am satisfied with only minimal explanation."

How to Create and Publish Your First NPM Package

Daniel Shashko — Sun, 02 Nov 2025 19:43:16 +0000

Publishing your first NPM package feels like a rite of passage for JavaScript developers. Whether you've built a utility function you keep copying between projects or solved a problem that others might face, sharing it on NPM makes your code accessible to millions of developers worldwide.

I'll walk you through the entire process, from choosing a name to seeing your package live on the registry. We'll build a simple example together so you can follow along.

Picking the Perfect Package Name

Before you write a single line of code, you need a name. This is trickier than it sounds because NPM has over a million packages, and yours needs to be unique.

Head over to npmjs.com and search for your desired name. If you find something similar, NPM will likely reject your submission. For example, if there's already a package called hellonpmpackage, you can't publish hello-npm-package because they're too similar.

Don't panic if your name is taken. You have two options: pick a different name or publish a scoped package (which I'll explain later). Scoped packages let you use @yourusername/package-name, so you can still get the name you want.

Setting Up Your Package

Let's create a simple package together. I'll build one called first-hello-npm that returns a greeting.

Getting Node.js Ready

You'll need Node.js installed, which comes with NPM built-in. Grab it from nodejs.org if you don't have it yet.

Initialize Your Project

Create a new folder for your package and set up version control:

mkdir my-npm-package
cd my-npm-package
git init

Now initialize NPM:

npm init

This creates your package.json file. You'll get prompted for details like package name, version, description, and entry point. Here's what each field means:

Package name: Must be unique and lowercase. Hyphens are fine, underscores aren't recommended.

Version: Starts at 1.0.0. Follow semantic versioning when you update later.

Description: Tell people what your package does. Be clear and concise.

Entry point: Usually index.js. This is the file that loads when someone requires your package.

Keywords: Help people find your package when searching NPM.

The rest is pretty self-explanatory. Don't worry about getting everything perfect - you can always edit package.json later.

Writing Your Package Code

Create your main file (probably index.js) and add your functionality:

// index.js
function helloNpm() {
  return "Hello NPM!";
}

module.exports = helloNpm;

That's it! The module.exports line is crucial because it makes your function available when someone installs and requires your package.

Testing Before Publishing

Always test your package before publishing. There's nothing worse than releasing broken code to the world. Here's a simple way to test locally.

In your package directory, run:

npm link

This makes your package available globally on your machine. Now create a test folder somewhere else:

mkdir test-my-package
cd test-my-package
npm link first-hello-npm  # replace with your package name

Create a test.js file and try out your package:

// test.js
const helloNpm = require('first-hello-npm');

console.log(helloNpm()); // Should print "Hello NPM!"

Run it with node test.js. If everything works, you're ready to publish.

Publishing to NPM

First, you need an NPM account. Sign up at npmjs.com/signup if you haven't already.

Back in your package directory, log in through the terminal:

npm login

Enter your credentials. You should see a confirmation message.

Now for the moment of truth:

npm publish

If successful, you'll see output confirming your package is live. Congratulations! You can search for it on npmjs.com to see it in action.

Working with Scoped Packages

Sometimes you want to publish under your username, either because your preferred name is taken or you want to organize your packages. Scoped packages use the format @username/package-name.

Initialize a scoped package like this:

npm init --scope=@yourusername

When prompted for the package name, use the full scoped format: @yourusername/package-name.

Publishing scoped packages requires an extra flag:

npm publish --access public

Without --access public, NPM assumes you want a private package, which requires a paid account for scoped packages.

What Happens After Publishing

Once your package is live, anyone can install it:

npm install your-package-name
# or for scoped packages
npm install @yourusername/package-name

They can then use it in their code just like any other NPM package. Pretty cool, right?

Your package page on NPM will show download statistics, and if you've linked a GitHub repository, it'll display your README file automatically.

A Few Final Tips

Keep your package focused on solving one problem well. The most successful NPM packages do one thing excellently rather than many things poorly.

Write a good README file. This becomes your package's homepage on NPM, so explain what it does, how to install it, and provide usage examples.

Version your updates properly. Use semantic versioning: patch versions for bug fixes (1.0.1), minor versions for new features (1.1.0), and major versions for breaking changes (2.0.0).

Consider setting up automated testing and continuous integration. As your package grows, you'll want confidence that updates don't break existing functionality.

Publishing your first NPM package is exciting. It's your contribution to the massive ecosystem that powers modern JavaScript development. Whether it's a simple utility function or something more complex, you're helping other developers build better software faster.

Now go build something useful and share it with the world. The JavaScript community is waiting for what you'll create next.