Forem: Daniel Marin

MCP Servers Explained: The One Protocol That Makes AI Tool Integrations Stop Sucking

Daniel Marin — Thu, 16 Apr 2026 18:54:35 +0000

What the Model Context Protocol actually is, why it matters, and how to build your first server in under a hundred lines.

If you've spent any time with AI agents in the last year, you've run into a frustrating pattern: every new tool integration means re-implementing the same plumbing. Auth for Gmail here, auth for Slack there, a custom Postgres adapter for one project, a different Postgres adapter for the next. It eats your afternoon and produces nothing durable.

The Model Context Protocol (MCP for short) is the fix. It's an open standard for exposing tools, data, and prompts to AI agents, the same way HTTP is an open standard for exposing content to browsers. Write the integration once, and any MCP-compatible agent can use it.

This guide walks through exactly what MCP is, why it matters, and how to build your first MCP server end to end.

What Is MCP, Really?

MCP is a protocol. That's it. It's not a framework you have to adopt, a cloud service you have to pay for, or a library you have to import. It's a specification for how an AI agent (the client) talks to an external capability provider (the server) over JSON-RPC.

The easiest mental model: MCP is to AI agents what USB-C is to hardware. Before USB-C, every device had its own cable. Now one shape fits everything. MCP plays the same role for AI tooling. One protocol, any agent, any integration.

An MCP server can expose three kinds of things to an agent:

Tools. Functions the agent can call: "send_email", "query_database", "create_jira_ticket". Each tool has a name, a JSON Schema describing its inputs, and a return type.

Resources. Read-only data the agent can pull into its context: a file, a database table, a page from Notion. Resources are addressed by URI so the agent can reference them by name.

Prompts. Reusable prompt templates the server offers to the client. Useful for standardizing common workflows ("summarize this ticket", "draft a release note") across agents and teams.

Why MCP Matters More Than It Looks Like at First

On the surface, MCP sounds like "another API standard." The reason it's a big deal is more subtle: it breaks the tight coupling between a model and its tools. Three downstream effects follow from that.

Your integrations become portable. Build an MCP server for your internal ticketing system once, and it works with Claude, any Claude Code project, and any other MCP-compatible client, now and in the future. When a better model comes out, you don't rebuild your tooling.

You can compose capabilities. An agent can connect to multiple MCP servers at once (your GitHub server, your Postgres server, your Slack server) and reason across all of them. You stop thinking in integrations and start thinking in capabilities.

The ecosystem compounds. Because MCP is open, the number of off-the-shelf servers grows every week. Filesystems, browsers, Git, databases, search engines: most of what an agent needs already exists as an MCP server someone else maintains.

How an MCP Conversation Actually Works

Under the hood, MCP is a JSON-RPC conversation between a client and a server over either stdio (for local servers) or HTTP with Server-Sent Events (for remote ones). The handshake has three phases:

Initialize. The client says hello, declares which protocol version it speaks, and asks what capabilities the server supports.
Discovery. The client calls tools/list, resources/list, and prompts/list to find out what the server offers. Each returned entry includes a JSON Schema so the model knows how to call it.
Invocation. When the agent decides to use a tool, the client sends tools/call with the tool name and arguments. The server executes and returns the result.

Here's what a tool invocation looks like on the wire:

// client → server
{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "create_issue",
    "arguments": {
      "repo": "acme/backend",
      "title": "Payments webhook retry logic is flaky",
      "body": "Fails on third retry..."
    }
  }
}

// server → client
{
  "jsonrpc": "2.0",
  "id": 7,
  "result": {
    "content": [
      { "type": "text", "text": "Created issue #4821" }
    ]
  }
}

That's the whole protocol in miniature. The SDKs hide the JSON-RPC boilerplate, so in practice you're writing Python or TypeScript functions and decorating them as tools.

Building Your First MCP Server (Step by Step)

Let's build a minimal server from scratch. The example: a server that exposes one tool, get_weather, which takes a city name and returns a temperature. The same shape generalizes to any integration you'll ever build.

Step 1: Install the SDK

The official SDKs are published for Python and TypeScript. Pick whichever your team is more comfortable with. The protocol is identical.

# Python
pip install mcp

# TypeScript
npm install @modelcontextprotocol/sdk

Step 2: Write the Server

Here's a complete Python MCP server in twenty lines:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("weather-server")

@mcp.tool()
def get_weather(city: str) -> str:
    """Return the current temperature for a given city."""
    # Replace with a real API call
    return f"It is 18°C in {city} right now."

if __name__ == "__main__":
    mcp.run()

Three things are happening: FastMCP creates a server, the @mcp.tool() decorator registers the function (using the type hints and docstring to auto-generate the JSON Schema), and mcp.run() starts the JSON-RPC loop. That's a complete, valid MCP server.

Step 3: Register It with Claude Code

Add the server to your Claude Code config:

{
  "mcpServers": {
    "weather": {
      "command": "python",
      "args": ["/absolute/path/to/server.py"]
    }
  }
}

Restart Claude Code. The get_weather tool is now available to any agent in that project, with the schema auto-derived from your type hints. Ask "what's the weather in Lisbon?" and watch the agent call your tool.

Step 4: Add Resources and Prompts

Tools are usually where the interesting behavior lives, but resources and prompts round out a useful server:

@mcp.resource("weather://history/{city}")
def weather_history(city: str) -> str:
    """Return a 7-day weather history for a city."""
    return load_history(city)

@mcp.prompt()
def weather_report(city: str) -> str:
    """Generate a weather report for a given city."""
    return f"Write a short weather report for {city} using the current data and the last 7 days."

Resources give the agent read-only data it can pull into context. Prompts give users a ready-made starting point they can invoke from the client UI. Neither is required. Start with tools, add the others when they earn their keep.

Design Principles for Good MCP Servers

You can get a server running in twenty lines. You can't get a good server in twenty lines. The servers that hold up in production tend to share a few traits:

Name tools like verbs the agent would say. search_issues, not issuesSearchV2. The model chooses tools based on their names and descriptions. Write them for the model, not for your internal API taxonomy.

Keep tool surface area small. A server with eight focused tools outperforms one with forty overlapping ones. The agent has to pick the right tool on every turn. Fewer choices means fewer mistakes.

Return structured, summarizable results. Don't return a 50KB JSON blob when a five-line summary plus an ID to fetch more detail would do. Context is the agent's most expensive resource.

Fail loudly and usefully. Error messages are prompts. The agent reads them and decides what to do next. "Invalid date: expected YYYY-MM-DD, got 'last Friday'" is a good error. "400" is not.

Gate destructive actions. Require an explicit confirm=true parameter for anything that sends, spends, or deletes. Agents confidently miswield new tools. Guard rails catch most of those mistakes.

Local vs. Remote: Which Should You Build?

MCP servers come in two flavors. Local servers run as subprocesses on your machine and talk over stdio. Remote servers run over HTTP + Server-Sent Events, letting you host shared tooling for a team or expose a public capability.

Default to local. You'll only want a remote server if multiple people need to use the same tooling without setting it up themselves, the server needs access to secrets that shouldn't live on laptops, or you're exposing the capability to third parties. Each of those cases adds deployment, auth, and observability concerns that a local subprocess simply doesn't have.

Where This Is All Going

A year from now, "does it have an MCP server?" will be the first question teams ask when evaluating a new tool, the same way "does it have an API?" is asked today. The tools that don't expose themselves via MCP will still work, but they'll be invisible to the agents that increasingly do the work.

The good news is how little effort it takes to be on the right side of that shift. A useful MCP server can be under a hundred lines of code. The protocol is stable, the SDKs are solid, and the ecosystem is growing fast enough that most of what you need already exists.

Pick one integration you're tired of rebuilding, wrap it in MCP, and never think about it again.

Getting Started

I maintain a curated collection of free playbooks and MCP resources at claudecodehq.com, including a catalog of production-ready MCP servers you can drop into any project, and a builder that scaffolds a working server from a plain-English description. If you want to skip the boilerplate, it's a good place to start.

Originally published on claudecodehq.com

I Built My First AI Agent in an Afternoon. Here's the Playbook I Wish I Had on Day One.

Daniel Marin — Wed, 15 Apr 2026 19:06:56 +0000

A step-by-step guide to going from a blank folder to a working agent, without the hype.

"AI agent" has become one of the most overloaded words in tech. Depending on who you ask, it's either a ChatGPT wrapper, a multi-step workflow, or a fully autonomous system that replaces an employee.

Here's the definition I actually use when I sit down to build one: an AI agent is an LLM in a loop that can use tools, read from and write to memory, and make decisions about what to do next.

That definition is small enough to build in an afternoon, and powerful enough to automate real work. This is the guide I wish someone had handed me before I started.

Step 1: Define the Agent's Job (Narrowly)

The single biggest predictor of whether your agent will work is how clearly you can describe its job. Vague goals produce vague agents.

The rule of thumb: if you can't describe the success criteria in one sentence, the scope is too broad.

Too broad: "An agent that helps me manage my business."

Good: "An agent that reads incoming invoice emails, extracts vendor, amount, and due date, then appends a row to a Google Sheet."

Before writing any code, write down three things: the input the agent receives, the output it produces, and the boundary, meaning what it is explicitly not allowed to do (send email, spend money, delete files). That boundary is what keeps an autonomous loop safe.

Step 2: Pick the Model and the Loop

Every agent has two core pieces: a model that makes decisions, and a loop that feeds those decisions back into the next step.

For most projects in 2026, the default model choice is Claude Sonnet 4.6. It's fast, cheap enough to run in a loop, and strong at tool use. Reach for Opus when the task requires deep reasoning over long context.

The loop itself is deceptively simple:

while not done:
    response = model.run(messages, tools=available_tools)
    if response.has_tool_call:
        result = execute_tool(response.tool_call)
        messages.append(result)
    else:
        done = True
        return response.text

That's it. Everything else (memory, planning, multi-agent orchestration) is a variation on this pattern. If you're using Claude Code as your runtime, the loop is already implemented for you. You just supply the tools and the instructions.

Step 3: Give the Agent Tools (This Is Where It Gets Real)

An LLM without tools can only produce text. An LLM with tools can read files, call APIs, query databases, and trigger side effects in the world. Tools are what turn a chatbot into an agent.

There are roughly three ways to give your agent tools, in increasing order of power:

1. Built-in tools. Filesystem, bash, web fetch. Claude Code ships with these out of the box. If your agent's job involves reading code, running tests, or pulling data from URLs, you already have everything you need.

2. Custom functions. Write a function, describe its inputs and outputs in JSON schema, and hand it to the model. Good for private APIs, internal databases, and anything specific to your project.

3. MCP servers. The Model Context Protocol is the standard for exposing tools to AI agents. Instead of re-implementing Gmail, Slack, or Postgres integrations for every project, you run (or build) an MCP server once and plug it into any agent. This is the path that scales.

Step 4: Write the System Prompt (aka CLAUDE.md)

The system prompt is the agent's job description. It tells the model who it is, what tools it has, what the success criteria are, and critically, what it should refuse to do.

A good system prompt has four sections:

Role: "You are an agent that..."
Inputs and outputs: what you'll receive and what you should produce
How to use your tools: when to reach for each one, in what order
Guardrails: explicit limits, things to escalate, never-do actions

In Claude Code, this prompt lives in a file called CLAUDE.md at the root of your project. The agent reads it on every invocation. If you find yourself re-explaining the same thing across runs, that's a signal the information belongs in CLAUDE.md instead.

Step 5: Add Memory (When the Agent Needs to Remember)

A single-shot agent is stateless. Each run starts fresh. That's fine for "parse this invoice" but useless for "keep track of which customers have been contacted."

You give agents memory the same way you give yourself memory: by writing things down.

Two patterns cover most use cases:

Scratchpad memory. A single Markdown file the agent reads at the start of each run and appends to at the end. Simple, inspectable, easy to debug. Good for personal agents and small teams.

Structured memory. A database or vector store the agent queries through tools. Necessary when memory grows past what fits comfortably in context, or when multiple agents share state.

Start with scratchpad memory. Upgrade only when you hit a concrete limit. Most agents never do.

Step 6: Run Agents in Parallel (When One Isn't Enough)

Once a single agent is working, the natural next step is to run several at once. Parallel agents are how you scale from "automate one task" to "process a queue of tasks," or "explore several solutions simultaneously and pick the best."

The common patterns:

Fan-out / fan-in: split a big task into independent subtasks, run them in parallel, merge the results. Great for research, code review, and batch processing.
Specialist agents: a planner delegates to specialists (tester, writer, reviewer), each with its own system prompt and tools.
Critic loops: one agent proposes, another critiques, the first revises. Useful when quality matters more than speed.

Step 7: Test, Observe, Iterate

Agents fail in ways that deterministic programs don't. They hallucinate tool arguments, loop on the same action, or misread the system prompt. The cure is observability.

Three things to put in place before you trust an agent with anything real:

Log every tool call. Inputs, outputs, and the model's stated reasoning. When something goes wrong, this is your black box recorder.

Run on a fixed eval set. A folder of sample inputs and expected outputs. Every prompt change gets re-run against it. You'd be surprised how often a "small tweak" regresses an edge case.

Put irreversible actions behind confirmations. Sending email, deleting data, spending money. These should either require human approval or be locked behind a hard-coded allowlist until the agent has earned trust.

The Lesson I Keep Relearning

The agents that end up valuable aren't usually the most ambitious ones. They're the ones with a narrow job, clear boundaries, and a prompt that's been refined through a hundred real runs.

Treat the CLAUDE.md like a living document. Every bug you hit is a line you should add so the agent doesn't hit it again. Start small, ship it, and let the scope grow from there.

Getting Started

You can absolutely build all of this from first principles, and you should, at least once, to understand the moving parts. But for real projects, starting from a battle-tested template is faster and less error-prone.

I publish a collection of free, copy-paste Claude Code playbooks at claudecodehq.com, including an AI Agent Builder that scaffolds a custom agent from a plain-English description, an MCP Server Builder for exposing your own tools, and a Parallel Task Agents template for running multiple sub-agents concurrently. Worth a look if you want to skip the boilerplate and get to the interesting parts.

Originally published on claudecodehq.com

How to Build an AI Agent from Scratch: A Step-by-Step Guide

Daniel Marin — Tue, 14 Apr 2026 19:42:09 +0000

A step-by-step guide to going from a blank folder to a working agent, without the hype.

"AI agent" has become one of the most overloaded words in tech. Depending on who you ask, it's either a ChatGPT wrapper, a multi-step workflow, or a fully autonomous system that replaces an employee.

Here's the definition I actually use when I sit down to build one: an AI agent is an LLM in a loop that can use tools, read from and write to memory, and make decisions about what to do next.

That definition is small enough to build in an afternoon, and powerful enough to automate real work. This is the guide I wish someone had handed me before I started.

Step 1: Define the Agent's Job (Narrowly)

The single biggest predictor of whether your agent will work is how clearly you can describe its job. Vague goals produce vague agents.

The rule of thumb: if you can't describe the success criteria in one sentence, the scope is too broad.

Too broad: "An agent that helps me manage my business."

Good: "An agent that reads incoming invoice emails, extracts vendor, amount, and due date, then appends a row to a Google Sheet."

Step 2: Pick the Model and the Loop

Every agent has two core pieces: a model that makes decisions, and a loop that feeds those decisions back into the next step.

The loop itself is deceptively simple:

while not done:
    response = model.run(messages, tools=available_tools)
    if response.has_tool_call:
        result = execute_tool(response.tool_call)
        messages.append(result)
    else:
        done = True
        return response.text

Step 3: Give the Agent Tools (This Is Where It Gets Real)

An LLM without tools can only produce text. An LLM with tools can read files, call APIs, query databases, and trigger side effects in the world. Tools are what turn a chatbot into an agent.

There are roughly three ways to give your agent tools, in increasing order of power:

2. Custom functions. Write a function, describe its inputs and outputs in JSON schema, and hand it to the model. Good for private APIs, internal databases, and anything specific to your project.

Step 4: Write the System Prompt (aka CLAUDE.md)

The system prompt is the agent's job description. It tells the model who it is, what tools it has, what the success criteria are, and critically, what it should refuse to do.

A good system prompt has four sections:

Role: "You are an agent that..."
Inputs and outputs: what you'll receive and what you should produce
How to use your tools: when to reach for each one, in what order
Guardrails: explicit limits, things to escalate, never-do actions

Step 5: Add Memory (When the Agent Needs to Remember)

A single-shot agent is stateless. Each run starts fresh. That's fine for "parse this invoice" but useless for "keep track of which customers have been contacted."

You give agents memory the same way you give yourself memory: by writing things down.

Two patterns cover most use cases:

Scratchpad memory. A single Markdown file the agent reads at the start of each run and appends to at the end. Simple, inspectable, easy to debug. Good for personal agents and small teams.

Structured memory. A database or vector store the agent queries through tools. Necessary when memory grows past what fits comfortably in context, or when multiple agents share state.

Start with scratchpad memory. Upgrade only when you hit a concrete limit. Most agents never do.

Step 6: Run Agents in Parallel (When One Isn't Enough)

The common patterns:

Fan-out / fan-in: split a big task into independent subtasks, run them in parallel, merge the results. Great for research, code review, and batch processing.
Specialist agents: a planner delegates to specialists (tester, writer, reviewer), each with its own system prompt and tools.
Critic loops: one agent proposes, another critiques, the first revises. Useful when quality matters more than speed.

Step 7: Test, Observe, Iterate

Agents fail in ways that deterministic programs don't. They hallucinate tool arguments, loop on the same action, or misread the system prompt. The cure is observability.

Three things to put in place before you trust an agent with anything real:

Log every tool call. Inputs, outputs, and the model's stated reasoning. When something goes wrong, this is your black box recorder.

Run on a fixed eval set. A folder of sample inputs and expected outputs. Every prompt change gets re-run against it. You'd be surprised how often a "small tweak" regresses an edge case.

The Lesson I Keep Relearning

The agents that end up valuable aren't usually the most ambitious ones. They're the ones with a narrow job, clear boundaries, and a prompt that's been refined through a hundred real runs.

Treat the CLAUDE.md like a living document. Every bug you hit is a line you should add so the agent doesn't hit it again. Start small, ship it, and let the scope grow from there.

Getting Started

Originally published on claudecodehq.com

Claude Code vs ChatGPT vs Gemini: an honest breakdown for developers who want to stop guessing and start shipping.

Daniel Marin — Sun, 12 Apr 2026 19:32:15 +0000

I Tested All 3 AI Coding Tools: Here's What Each One Is Actually Good At

If you write code for a living, you've probably tried at least one AI coding assistant by now. The real question isn't whether to use one. It's which one fits the way you actually work.

I've spent serious time with all three (Claude Code, ChatGPT with GPT-4o and Canvas, and Gemini with 2.5 Pro and Jules) across real projects. Not toy demos. Real production code, real deadlines, real frustration when things break.

Here's what I found.

The 30-Second Version

Before we go deep, here's the short answer:

Claude Code: the one that actually does the work autonomously
ChatGPT: the best teacher and fastest autocomplete (via Copilot)
Gemini: the one that can swallow your entire codebase in one gulp

Now let's unpack each one.

Code Quality: Who Writes Code You'd Actually Ship?

This is what matters most, so let's start here.

Claude Code consistently produces production-ready code with fewer hallucinations. It respects your project conventions. If your codebase uses Zod for validation, it won't randomly switch to Joi. It's particularly strong with TypeScript, Python, and Rust. The code reads like a senior engineer wrote it, not a tutorial author.

ChatGPT (GPT-4o) excels at explaining code and generating snippets for common patterns. It's the best at answering "how do I do X?" with clear, step-by-step explanations. But for large-scale generation, it tends to produce more boilerplate and sometimes invents APIs that don't exist, especially for newer libraries.

Gemini 2.5 Pro benefits from its massive context window to understand large projects holistically. Code generation is solid but occasionally verbose, and it can struggle with less common frameworks.

My take: Claude Code for writing production code. ChatGPT for learning and explanations. Gemini for architectural understanding of large codebases.

Agentic Capabilities: This Is Where the Gap Gets Wide

An AI coding assistant answers questions. An AI coding agent reads your codebase, writes code, runs tests, fixes errors, and commits autonomously.

This is where Claude Code separates itself from the pack.

Claude Code operates as a true agent in your terminal. It reads and navigates your project directory. It creates, edits, and deletes files. It runs shell commands like build, test, lint, and deploy. It connects to external tools via MCP (GitHub, databases, browsers, Slack). You can hand it a GitHub issue and walk away while it creates a working solution.

The key difference: Claude Code doesn't just suggest code. It implements features end-to-end.

ChatGPT operates in a conversational loop. Canvas lets you edit code in a side panel, and Code Interpreter runs Python in a sandbox. But there's no filesystem access, no terminal integration, no multi-step workflow chaining. You're always the one copying code from chat into your editor.

Gemini's Jules agent can handle multi-step tasks in a sandboxed environment, and Gemini CLI brings terminal-based workflows. It's improving fast, but the agentic capabilities are still maturing compared to Claude Code's battle-tested agent loop.

Context and Codebase Understanding

How much of your project can the AI "see," and how well does it use that information?

Gemini wins on raw numbers. Its 1M+ token context window is genuinely impressive. You can feed it an entire codebase in a single prompt. For tasks like "explain how authentication works across this 50-file project," Gemini is hard to beat.

Claude Code wins on practical context management. Its 200K token window is smaller on paper, but it compensates with smart strategies: persistent CLAUDE.md project files, automatic context compression, and strategic file reading. In practice, it handles large codebases effectively because it reads files on demand rather than dumping everything into context at once.

ChatGPT starts from scratch every time. 128K tokens with GPT-4o, no persistent project context between sessions, no way to point it at your local codebase.

IDE Integration: Where Does Each Tool Live?

Each tool meets developers differently:

ChatGPT (via GitHub Copilot) still has the smoothest inline autocomplete, the fastest "tab-tab-tab" experience
Gemini integrates deeply with Google's ecosystem: Firebase, Android Studio, Google Cloud
Claude Code is terminal-first, which means it fits into any workflow where you already use a command line, plus IDE extensions for VS Code and JetBrains

The Right Tool Depends on Your Workflow

Choose Claude Code if you want an AI that does the work, not just suggests it. If you build full-stack applications, need multi-file edits, want to automate workflows end-to-end, or need to connect AI to external tools via MCP, this is your tool.

Choose ChatGPT if you primarily need code explanations, want the best inline autocomplete, work mostly in short one-off tasks, or are learning to code and want tutorial-style guidance.

Choose Gemini if you need to analyze massive codebases, work in the Google ecosystem, or need long-context analysis of large PRs, audit trails, or legacy systems.

Pricing: All Three Start at $20/Month

At the entry level, all three offer strong value at $20/month. The differences emerge at scale:

Claude offers a Max tier ($100 to $200/month) built for developers who use AI as their primary coding partner all day
ChatGPT Pro costs $200/month for unlimited GPT-4o access
Gemini has the most competitive API pricing for high-volume inference

The Truth Most Comparison Articles Won't Tell You

Most professional developers use two or even all three of these tools, each for different tasks.

A common stack:

Claude Code for day-to-day development: writing features, fixing bugs, refactoring, running tests
GitHub Copilot (ChatGPT) for inline autocomplete while typing
Gemini for analyzing unfamiliar codebases or processing massive files

The tools are complementary, not mutually exclusive. But if you need to pick one as your primary AI coding partner, the one that handles the broadest range of real development work, Claude Code's agentic capabilities give it a decisive edge for anyone who's past the "asking questions about code" stage.

Getting Started

If you're curious about going deeper with any of these tools, I publish practical playbooks and guides at claudecodehq.com, covering everything from agentic workflows and MCP integrations to building your own AI agents. Worth a look if you want to get productive fast.

Originally published on claudecodehq.com

How to Automate Your Entire Workflow with Claude Code in 2026

Daniel Marin — Tue, 07 Apr 2026 18:21:05 +0000

Most knowledge workers lose between one and two hours a day to tasks that could be fully automated: copying data from web dashboards, sorting emails into folders, rearranging calendar blocks, pasting standup updates into Slack. Individually, each task feels minor. Collectively, they add up to roughly 300+ hours a year of busywork.

Claude Code changes the equation. Instead of writing brittle scripts or stitching together five different SaaS tools, you describe what you want in plain English and let an AI agent build, test, and maintain the automation for you. This guide walks you through four high-impact areas where Claude Code playbooks can eliminate repetitive work entirely.

1. Browser Automation: Stop Copy-Pasting from Dashboards

If your morning starts with opening three browser tabs, logging into dashboards, and manually pulling numbers into a spreadsheet, you're doing the computer's job for it.

The Browser Automation Assistant (https://www.claudecodehq.com/playbooks/browser-automation) playbook generates production-ready Puppeteer or Playwright scripts from a plain-English description of what you need. Tell Claude Code something like:

"Scrape daily sales figures from our Shopify admin dashboard and export them to a Google Sheet. Run every morning at 7 AM."

Claude Code generates the full script, handles authentication cookies, pagination, and error retries. You get a working automation instead of a half-finished Stack Overflow snippet.

What you can automate
Competitor price monitoring across multiple websites
Daily screenshot reports from analytics dashboards
Automated form submissions (expense reports, compliance filings)
Web scraping pipelines that handle login walls and CAPTCHAs
End-to-end browser tests for your own product

Email Automation: Reclaim Your Inbox Email is the original productivity black hole. The average professional spends 28% of their workday on email, much of it on tasks that follow predictable patterns: saving attachments, forwarding invoices, labeling messages by client.

The Gmail Workflow Automation playbook (https://www.claudecodehq.com/playbooks/gmail-workflows) builds n8n workflows that monitor your inbox and act automatically. Some real examples:

Attachment Management

Invoices from vendors are automatically extracted from emails, saved to the right Google Drive folder by month, and the original email is labeled and archived.

Smart Triage

Emails from clients are auto-labeled by project. Internal newsletters skip the inbox entirely and go straight to a "Read Later" folder. Urgent emails from your boss trigger a Slack DM.

Follow-up Tracking

Emails you sent that haven't received a reply in 3 days automatically surface in a "Needs Follow-up" label so nothing falls through the cracks.

The playbook handles Google API authentication, webhook setup, and error handling. You describe the rules; Claude Code builds the plumbing.

Calendar Automation: Protect Your Focus Time Your calendar should work for you, not against you. But most people's calendars are a reactive mess — anyone can book over your focus blocks, meetings pile up back-to-back with no prep time, and you spend 15 minutes every morning manually rearranging things.

The Calendar & Scheduling Automation playbook (https://www.claudecodehq.com/playbooks/calendar-automation) sets up intelligent calendar workflows that run on autopilot:

Auto-protected focus blocks — deep work time that can't be overwritten by meeting invites
Meeting prep automation — relevant docs and context are sent to you 10 minutes before each meeting
Daily agenda posts — your schedule for the day is automatically posted to Slack at 8 AM
Cross-platform sync — Google Calendar and Outlook stay in sync without manual export/import
Smart time blocking — tasks from your project management tool automatically get calendar blocks assigned
If you manage other people's calendars — as an EA or team lead — the compound time savings are even larger. What takes 30 minutes of manual shuffling per person per day becomes a single setup that runs forever.

Slack Automation: Eliminate Repetitive Messaging Slack is where coordination happens, but it's also where people spend the most time on repetitive messaging patterns: daily standups, approval requests, status check-ins, and the dreaded "can someone review my PR?" message.

The Slack Workflow Automation playbook (https://www.claudecodehq.com/playbooks/slack-workflows) builds bots and workflows that handle the repetitive parts:

Async Standup Bot

Collects standup updates from each team member at their preferred time, compiles them into a formatted summary, and posts it to the team channel. No more 15-minute meetings that could have been a message.

PR Approval Workflow

GitHub PRs automatically post to a review channel with approve/reject buttons. If a PR hasn't been reviewed in 24 hours, it escalates with a mention to the team lead.

Smart Notifications

Route monitoring alerts to the right channel based on severity. Critical alerts page on-call via DM. Low-severity alerts batch into a daily digest.

Putting It All Together: The Fully Automated Workday
Here's what a typical morning looks like when all four automation layers are running:

7:00 AM
Browser automation scrapes overnight metrics and drops them in your Google Sheet.

7:05 AM
Gmail workflows have already sorted your inbox — invoices filed, client emails labeled, newsletters deferred.

8:00 AM
Your daily agenda posts to Slack. Focus blocks are locked in. Prep docs for your 10 AM are ready.

9:00 AM
Standup bot has collected everyone's updates. You read a 30-second summary instead of sitting through a meeting.

9:05 AM
You start actual work. No email sorting, no calendar rearranging, no Slack catch-up.

That's roughly 90 minutes saved every single day, compounding to over 350 hours per year. More importantly, you start each day in a proactive state instead of a reactive one.

How to Get Started
You don't need to automate everything at once. Pick the area where you lose the most time and start there:

Browser Automation

Scraping, form fills, dashboard monitoring

Gmail Workflows

Attachment management, triage, auto-archiving

Calendar Automation

Focus blocks, meeting prep, daily agendas

Slack Workflows

Standup bots, approval flows, smart alerts

Each playbook gives you a ready-to-use CLAUDE.md template. Download it, drop it in a project folder, open Claude Code, and describe what you want to automate. The AI handles the implementation details — API integrations, error handling, scheduling — so you can focus on defining the "what" instead of wrestling with the "how."

The best part: once one automation is running and saving you time, you'll immediately see where the next one should go. Automation compounds.