DEV Community: Gurinder Chauhan

I Connected My AI Agent to My Inbox with MCP - Here's How It Works

Gurinder Chauhan — Fri, 18 Sep 2026 21:47:20 +0000

Consider a concrete task: triaging a support inbox. An assistant with mailbox access can search the mailbox, summarize the threads, and leave drafts waiting for review. No integration code, no API glue. Just a server URL and a sign-in.

That server is the new LetMeSend.Email MCP server, and this post is the practical walkthrough: what it exposes, how auth works, how to connect it, and the workflows I've found genuinely useful.

What the server exposes

One Streamable HTTP endpoint - https://mcp.letmesend.email - serves 35 tools across four areas:

Mailboxes (mailboxes-list, mailbox-messages-search, mailbox-messages-thread, mailbox-messages-reply, mailbox-messages-action, mailbox-drafts-create, …) - read, search, thread, reply, forward, archive, and draft.
Transactional email (emails-send, emails-list, emails-get) - send through verified domains, inspect past sends.
Domains (domains-list, domains-verify, domain-health-check, domain-health-history, email-verification-check) - DNS verification, deliverability health and history, single-address validation.
Marketing (contacts-create, contacts-list, campaigns-create, campaigns-schedule, campaigns-send, campaigns-cancel) - contacts and full campaign lifecycle.

Every call runs under the same rules as the dashboard: the agent only sees mailboxes assigned to it, scoped to ability tiers (mailbox:read, mailbox:write, mailbox:send).

Authentication: OAuth first, API key for headless

The recommended path is OAuth - the client opens a browser sign-in where you log in with your LetMeSend.Email account and approve the mailbox abilities the agent gets. Nothing to copy into config files.

For headless setups (CI, servers, cron jobs), create a dashboard API key and send it as a Bearer token instead. Same tools, same guardrails, no browser involved.

Setup with OpenCode

This is the flow from the OpenCode setup guide:

opencode mcp add
# Choose remote, name it lmse, and enter https://mcp.letmesend.email
opencode mcp auth lmse

The auth command walks you through sign-in, including picking mailbox ability tiers. Then confirm the connection with a first prompt:

List my mailboxes using the LetMeSend.Email tools.

If it answers with your real mailboxes (that's mailboxes-list under the hood), you're connected. Prerequisites: a LetMeSend.Email account, and a verified domain before anything is allowed to send. The same pattern - remote URL plus OAuth or Bearer - applies to the other documented clients: Claude, Cursor, Copilot, Codex, Gemini, Warp, Zed, and more.

Workflow 1: Summarize threads, draft follow-ups

A useful bounded task for an agent:

Search the support mailbox for threads from the last two days, summarize each one, and draft a follow-up message for each - don't send anything.

The agent chains mailbox-messages-search → mailbox-messages-thread → mailbox-drafts-create. One permission note: searching and summarizing run fine on mailbox:read, but creating drafts requires write access - so this workflow needs the agent to hold both. Two things to know about that last step: mailbox-drafts-create saves a standalone draft (recipients, subject, body) - it takes no thread reference, so treat its output as a follow-up draft to review, not an in-thread reply. Actual in-thread replies go through mailbox-messages-reply, which sends immediately from the mailbox's primary address - only invoke that one with explicit approval. The boundary is structural: creating a draft and sending an email are different tools, so "don't send anything" means there's simply no send call in the chain.

Workflow 2: Check domain health in one question

Is example.com healthy? Check DNS, read the current deliverability score, and flag anything I should fix.

Behind that sentence: domains-verify for the DNS records, domain-health-get for the current score with findings and recommendations, domain-health-history for the trend. (domain-health-check triggers a fresh scan instead - it's rate-limited, so reach for it only when you need new data, not for routine reads.) What used to be several dashboard tabs and some DNS-tab archaeology becomes a single answer with a fix list.

Workflow 3: Prepare a campaign, review before it flies

Create a draft campaign for Friday's newsletter. Show me its audience and content for review. Don't schedule or send it.

campaigns-create stages the campaign and stops there. Note the deliberate omission: scheduling authorizes a future send, so it belongs after review, not before it. Once you've approved the draft, scheduling (campaigns-schedule) and sending (campaigns-send) are separate explicit steps. The pattern across all three workflows is the same: the agent does the assembly, you keep the trigger.

The draft/send boundary, stated plainly

Worth repeating because it's the whole safety model: draft creation does not send; sending tools deliver immediately, while scheduling authorizes a future send. Start new agents on mailbox:read - noting that read still permits organizing actions like archiving - and graduate to send access once you've seen the drafts it produces.

What's next, and where to start

On the roadmap (planned, not shipped): a short walkthrough video of the server end-to-end, and an n8n plugin for workflow automation. I'll update this post when they land.

Read announcement blog post to learn more about MCP server.

To try it now: create an account, verify a domain, point your agent at https://mcp.letmesend.email, and start with "list my mailboxes." Full reference lives at letmesend.email/docs/mcp/overview - and if you wire up a workflow I haven't thought of, I'd genuinely like to hear about it in the comments.

Laravel 13.20 Image Processing: A Production Guide

Gurinder Chauhan — Wed, 15 Jul 2026 22:26:19 +0000

Originally published on letmesend.email. I work on letmesend.email, and this is an adapted edition of that guide.

This article was prepared with AI-assisted editorial support. Its technical claims and examples were tested against Laravel Framework v13.20.0 in an isolated application.

Image handling rarely stays small. An avatar upload becomes a thumbnail, a WebP copy, a storage policy, a validation rule, and eventually a queue job.

Laravel 13.20, released on July 14, 2026, gives this work a first-party home through the new Illuminate\Image component and Image facade. It connects image processing to requests, filesystem disks, configuration, and Laravel's container while keeping transformation pipelines immutable.

This guide focuses on what actually shipped and the production boundaries that still belong in your application.

What first-party image processing means

Laravel applications have used Intervention Image, custom wrappers, and external image services for years. Laravel 13.20 does not make Intervention Image disappear. The built-in GD and Imagick drivers use intervention/image:^4.0 underneath.

The first-party part is the Laravel-facing API:

use Illuminate\Support\Facades\Image;
use RuntimeException;

$thumbnail = Image::fromPath(storage_path('app/source/photo.jpg'))
    ->orient()
    ->cover(640, 360)
    ->toWebp()
    ->quality(80);

$storedPath = $thumbnail->store('thumbnails', 'public');

if ($storedPath === false) {
    throw new RuntimeException('The thumbnail could not be stored.');
}

That chain describes four concerns:

Load the source lazily.
Record transformations in order.
Select an output format and quality.
Process and store the result through Laravel's filesystem.

The built-in drivers support GD and Imagick. GD is the default. The default processing quality is 70 unless the pipeline selects another value.

Install and configure a driver

Laravel 13.20 and the image component require PHP 8.3 or newer. Install the suggested processing dependency:

composer require intervention/image:^4.0

Your runtime also needs the extension for the chosen driver:

GD requires ext-gd.
Imagick requires ext-imagick and the ImageMagick system library.

The image configuration uses GD by default:

<?php

return [
    'default' => env('IMAGE_DRIVER', 'gd'),
];

To use Imagick as the application default:

IMAGE_DRIVER=imagick

An individual pipeline can choose a different driver without changing global configuration:

use Illuminate\Support\Facades\Image;

$source = Image::fromPath(storage_path('app/source/photo.jpg'));

$gdVariant = $source->usingGd()->cover(400, 400);
$imagickVariant = $source->usingImagick()->cover(400, 400);

Test both drivers with the same representative files in the container you deploy. Output size, memory use, and processing time depend on the source material and extension build.

Create images from supported sources

The component accepts request uploads, local paths, URLs, raw bytes, Base64 strings, and Laravel storage paths.

Request uploads

Validate an upload before asking the image driver to decode it:

use Illuminate\Http\Request;

public function store(Request $request)
{
    $request->validate([
        'avatar' => [
            'required',
            'image',
            'mimes:jpeg,png,webp',
            'max:5120',
            'dimensions:min_width=200,min_height=200,max_width=6000,max_height=6000',
        ],
    ]);

    $image = $request->image('avatar');

    abort_if($image === null, 422, 'A valid avatar image is required.');

    // Build the output pipeline from $image.
}

$request->image('avatar') returns an Illuminate\Image\Image when the input contains one uploaded file. It returns null when it does not.

Other entry points

use Illuminate\Support\Facades\Image;
use Illuminate\Support\Facades\Storage;
use RuntimeException;

$binaryContents = file_get_contents(storage_path('app/source/photo.jpg'));

if ($binaryContents === false) {
    throw new RuntimeException('The source image could not be read.');
}

$base64Contents = base64_encode($binaryContents);

$fromPath = Image::fromPath(storage_path('app/source/photo.jpg'));
$fromUrl = Image::fromUrl('https://assets.example.test/photo.jpg');
$fromBytes = Image::fromBytes($binaryContents);
$fromBase64 = Image::fromBase64($base64Contents);
$fromStorage = Image::fromStorage('originals/photo.jpg', 's3');
$fromDisk = Storage::disk('s3')->image('originals/photo.jpg');

Most sources are lazy. Laravel reads or downloads the actual contents when output or metadata is requested.

Do not pass an untrusted user URL directly to fromUrl(). A controlled downloader should limit redirects and response size, reject private network destinations, set a short timeout, and confirm the media type first.

Immutability changes how variants are built

Every transformation and output option clones the image. The source pipeline does not change.

use Illuminate\Support\Facades\Image;

$source = Image::fromPath(storage_path('app/source/product.jpg'))
    ->orient();

$thumbnail = $source
    ->cover(400, 400)
    ->toWebp()
    ->quality(78);

$detail = $source
    ->scale(width: 1600)
    ->toWebp()
    ->quality(84);

$openGraph = $source
    ->cover(1200, 630)
    ->toJpg()
    ->quality(85);

This makes branching predictable. Adding cover() to $thumbnail cannot accidentally resize $detail.

There is one related boundary: an Image object cannot be serialized. Do not put one on a queued job. Store the original first, then dispatch the storage path or your own asset identifier.

Choose the transformation that matches the layout

Laravel 13.20 exposes these transformations:

Method	Use it when
`cover()`	The output must fill exact dimensions and cropping is acceptable.
`contain()`	The complete image must fit inside a box without cropping.
`crop()`	You need a specific rectangular region.
`resize()`	You intentionally want exact dimensions, even if the aspect ratio changes.
`scale()`	You want proportional resizing from one target dimension.
`rotate()`	The application needs an explicit rotation.
`orient()`	Uploaded photos should respect orientation metadata.
`blur()`	You need a blur effect or low-resolution placeholder.
`sharpen()`	A resized output needs measured sharpening.
`grayscale()`	The output should be converted to grayscale.
`flipVertically()` or `flip()`	The image should be flipped vertically.
`flipHorizontally()` or `flop()`	The image should be flipped horizontally.

Prefer cover() for fixed cards and avatars, contain() when the whole product or logo must remain visible, and scale() for responsive width variants.

Convert and inspect output

Laravel 13.20 provides explicit WebP and JPEG output methods:

use Illuminate\Support\Facades\Image;

$source = Image::fromPath(storage_path('app/source/product.jpg'));

$webp = $source
    ->scale(width: 1200)
    ->toWebp()
    ->quality(82)
    ->optimize();

$jpeg = $source
    ->cover(1200, 630)
    ->toJpg()
    ->quality(85);

toJpeg() is also available as an alias for toJpg().

Using the $webp pipeline created above, you can inspect or export processed output with methods such as:

$width = $webp->width();
$height = $webp->height();
$dimensions = $webp->dimensions();
$mimeType = $webp->mimeType();
$extension = $webp->extension();
$bytes = $webp->toBytes();
$base64 = $webp->toBase64();
$dataUri = $webp->toDataUri();

Store paths and image metadata in the database, not the Image instance or a large Base64 value.

A production avatar workflow

A safe workflow preserves the previous asset until both the new file and database update succeed. The following shortened example shows the important boundary:

use Illuminate\Http\Request;
use Illuminate\Support\Facades\DB;
use Illuminate\Support\Facades\Storage;
use Illuminate\Support\Str;
use RuntimeException;
use Throwable;

public function updateAvatar(Request $request)
{
    $request->validate([
        'avatar' => [
            'required',
            'image',
            'mimes:jpeg,png,webp',
            'max:5120',
            'dimensions:min_width=200,min_height=200,max_width=6000,max_height=6000',
        ],
    ]);

    $source = $request->image('avatar');

    abort_if($source === null, 422, 'A valid avatar image is required.');

    $user = $request->user();

    abort_if($user === null, 401);

    $path = "avatars/{$user->getKey()}/".Str::uuid().'.webp';

    $stored = $source
        ->orient()
        ->cover(512, 512)
        ->toWebp()
        ->quality(82)
        ->storeAs($path, disk: 'public');

    if ($stored === false) {
        throw new RuntimeException('The avatar could not be stored.');
    }

    try {
        DB::transaction(function () use ($user, $path): void {
            $user->forceFill(['avatar_path' => $path])->save();
        });
    } catch (Throwable $exception) {
        Storage::disk('public')->delete($path);

        throw $exception;
    }

    return back()->with('status', 'Avatar updated.');
}

In a full replacement workflow, keep the old path before the transaction and delete it only after the new path is active. Versioned filenames prevent a failed write from destroying the last known good asset.

Move expensive work to a queue

Small avatars may be reasonable to process during a request. Large originals, many variants, and batch imports usually belong on a queue.

A reliable sequence is:

Validate and store the original upload.
Create an asset record with a pending state.
Dispatch a job with the asset identifier or storage path.
Load the source from storage in the job.
Generate every required variant.
Mark the asset ready only after all required writes succeed.
Record failures and allow controlled retries.

Keep retry operations idempotent. A job should produce the same variant paths or replace them through an explicit versioning policy.

Production checks worth keeping

The convenient facade does not remove the operational work around image processing:

Validate MIME type, compressed size, and pixel dimensions before decoding.
Decide whether animated input is allowed.
Set web server, PHP, worker memory, and worker timeout limits.
Cap the number of generated variants.
Re-encode accepted input instead of keeping an uploaded file as the public derivative.
Check every storage return value because storage methods return string|false.
Monitor processing time, failures, and worker memory.
Clean abandoned originals and partial variants.
Store final width, height, MIME type, and path with each asset variant.

A small compressed file can expand into a large in-memory bitmap. Test the limits with real source dimensions and formats in your production container.

Should an existing application migrate?

The new API does not require an immediate rewrite. Start with one contained workflow, such as avatars or product thumbnails, then compare the old and new output:

Crop and scale behavior
EXIF orientation
Output dimensions
MIME type and extension
File size at the selected quality
Transparency and background behavior
Animated input behavior, if supported by the product

If the application depends on Intervention operations that Laravel's smaller API does not expose, keep direct Intervention usage for that workflow. If an external image CDN handles dynamic delivery and caching, Laravel's local component does not automatically replace it.

Laravel 13.20 makes the common path more consistent. It does not eliminate the need for input policy, storage design, queues, observability, or realistic performance testing.

The complete Laravel 13.20 Image facade guide includes every released source, transformation, storage method, a multi-variant avatar controller, responsive image markup, migration guidance, tests, and the exact implementation details verified against the v13.20.0 tag.

Sources

🚀 How I Stopped Juggling 4 Terminal Tabs Every Morning

Gurinder Chauhan — Thu, 16 Oct 2025 19:56:12 +0000

When working locally on my Laravel + Bun + Stripe stack for AI Email Builder, I used to open 4 terminal tabs every time:

bun run dev for frontend
php artisan queue:work for jobs
php artisan schedule:work for cron
and Stripe listener for webhooks

It worked… but it was annoying.

So I wrote a tiny Bash script to spin everything up in one command 👇

#!/bin/bash

BASE=$PWD

DEV_CMD="(cd $BASE && bun run dev)"
QUEUE_CMD="(cd $BASE && php artisan queue:work)"
SCHEDULE_CMD="(cd $BASE && php artisan schedule:work)"
STRIPE_CMD="(cd $BASE && zsh listen-stripe.sh)"

npx concurrently \
    -n dev,queue,schedule,stripe \
    -c green,blue,magenta,yellow \
    "$DEV_CMD" \
    "$QUEUE_CMD" \
    "$SCHEDULE_CMD" \
    "$STRIPE_CMD"

Now I just run: ./dev.sh

And everything starts together — clean, color-coded, and fast 🙌

This little script made my daily development workflow for Email Builder so much smoother.

Feel free to tweak it to match your stack too.