DEV Community: Gautam Suthar

I didn't want a stranger's code holding my Discord bot token, so I wrote my own MCP server

Gautam Suthar — Sat, 31 Oct 2026 15:24:07 +0000

I wanted Claude Code to manage my Discord server. Create channels, sort out roles, clean up messages, check the audit log, the boring admin stuff.

Community Discord MCP servers already exist. Every one of them needs your bot token. My bot has admin-level permissions on a server with real people in it. Handing that token to code I hadn't read felt like a bad trade for saving a weekend.

So I wrote my own. It's small enough to read end to end, it runs locally in Docker, and it only does what I put in it.

It's called discord-mcp, it's MIT licensed, and it's on 1.3.

What it does

67 tools across the parts of Discord you'd actually manage:

channels and categories, including permission overwrites and cloning
roles: create, edit, reorder, assign
moderation: kick, ban, timeout, nicknames, audit log
messages: read, send with embeds, edit, delete, bulk delete, pins, reactions
threads and forum posts
invites, webhooks, emojis, stickers, scheduled events, server settings
a permission audit, and server templates you can export and apply

The direction matters: this isn't a way to talk to Claude from Discord. Claude manages the server.

Safety first, then write tools

The first release with write tools came after a release that was only safety rails. If something is going to delete channels on my server, the guard rails come first.

Three settings narrow down what the bot can do beyond its Discord permissions:

Variable	What it does
`READ_ONLY`	`true` exposes only read-only tools. Nothing can change.
`ALLOWED_GUILD_IDS`	Servers the bot may touch. Every other server is hidden.
`DISABLED_TOOLS`	Switch off single tools by name.

A typo in any of them stops the server at startup. An unknown tool name or a server ID the bot isn't in is an error, not something silently ignored.

Read-only mode can't drift

The usual way to build a read-only mode is a list of "write tools" to skip. That list goes stale the first time someone adds a tool and forgets it.

discord-mcp uses the MCP annotations instead. Every tool has to declare readOnlyHint, every write tool has to declare destructiveHint, and every destructive tool has to accept a reason that ends up in the Discord audit log. Startup refuses any tool that breaks those rules.

Read-only mode then just drops anything not marked read-only. The client and the filter read the same annotations, so they can't disagree.

The tools I actually use

The CRUD tools are the boring part. Two newer ones are why I keep it running.

audit_permissions reads the whole server and flags what's risky: dangerous permissions on @everyone, roles and bots with Administrator, staff channels everyone can see, verification level, content filter, moderator 2FA. It only reads, so it works in read-only mode too. The first time I ran it on my test server it flagged the bot's own Administrator role. Fair.

export_template and apply_template turn a server's roles, categories and channels into JSON and back. Apply only adds, never edits or deletes, and skips anything that already exists, so running it twice is safe. The whole template gets checked before the first change, with dry_run if you just want to see what would happen. There's also a setup_community_server prompt: describe the community you want, Claude drafts the layout, dry runs it, and applies it after you say yes.

Errors that tell you what to fix

Discord's answer to a missing permission is a bare 403. Write tools check permissions and role order before calling Discord, so you get this instead: which permission the bot is missing, or which role sits at or above the bot's highest role, and how to fix it.

Tested against a real server

Unit tests cover the logic. They can't tell you how Discord actually behaves.

So there are 35 integration tests that spawn the server over stdio and call tools through the MCP SDK client, the same path Claude uses, against a throwaway test server. The harness locks itself to that one server and refuses any server with more than 10 members, so a wrong ID can't hit a real community.

They found two bugs the unit tests never would have:

list_role_members fetched all members on every call. Discord rate limits that to about once per 30 seconds per server, so the second call failed. Now it loads members once and the cache stays current after that.
get_message kept showing reactions that had already been removed. Discord leaves out reactions when there are none, and discord.js only patches its cached copy with fields that are present. Dropping the cached message before fetching fixed it.

Try it

You need a Discord bot with the permissions you want it to have. The README walks through that.

docker pull ghcr.io/callmegautam/discord-mcp:1

Put your token in a .env and add it to Claude Code:

claude mcp add discord -s user -- docker run --rm -i --env-file /absolute/path/to/.env ghcr.io/callmegautam/discord-mcp:1

It works with any MCP client, same command. Start with READ_ONLY=true if you just want it to look around first.

Repo: https://github.com/callmegautam/discord-mcp
Tool reference: https://github.com/callmegautam/discord-mcp/blob/main/docs/tools.md

There's also an HTTP transport now (TRANSPORT=http with a bearer token) if you'd rather run one long-lived container than spawn one per session.

If something breaks on your server, open an issue. The things I couldn't test live yet are kick, ban and timeout on a real member, announcement and stage channels, and private threads.

I hang out with other devs in The Basement, my Discord server. Questions, side projects, and a contributor cup every month or so. https://discord.gg/BqAK3RNWeP

Templates don't scale, so I rebuilt my scaffolder around composable blueprints

Gautam Suthar — Tue, 20 Oct 2026 05:54:28 +0000

Every project scaffolder I've used works the same way. You pick a template, it copies a folder, and you start deleting what you didn't want.

Atarashi v0.6 worked that way too. It had five template folders. Then the obvious problem showed up: every new combination of framework, database and ORM meant another folder to write and maintain. Fastify with Postgres and Drizzle? New folder. Same thing with Prisma? Another one. The number of folders grows with every option you add, and none of them is ever quite what you wanted.

So for 1.0 I threw the template engine out and rebuilt it around composition.

The problem with templates

A template folder is a snapshot of one set of decisions. Two things go wrong with that.

First, you can't change one decision without hand-editing generated code. Want Hono instead of Express? You're now rewriting the template's output by hand.

Second, nothing records what you chose. Three weeks later you want structured logging, and the scaffolder can't help, because it has no idea what your project is made of.

Blueprints instead of folders

Atarashi 1.0 builds a project out of small units called blueprints. There are 36 of them: HTTP frameworks (express, fastify, hono), databases (postgres, mysql, mongodb, sqlite), ORMs (drizzle, prisma, mongoose), auth, testing, linting, docker, CI, and React, Angular and Next front ends.

The important part: blueprints never name each other. They declare capabilities.

{
  "id": "orm/drizzle",
  "provides": ["orm", "orm:drizzle"],
  "requires": ["database:sql"],
  "conflicts": ["orm"]
}

Drizzle doesn't know about Postgres. It says "I need a SQL database", and anything that provides database:sql satisfies it. That one indirection is what makes every combination work without a template for it.

It refuses things that can't work

Because every blueprint declares what it needs and what it conflicts with, Atarashi can check the whole plan before it writes a single file.

Ask for Drizzle with no database:

$ atarashi new my-api --add orm/drizzle
✖ orm/drizzle requires `database:sql`, and 3 blueprints provide it
    → Add `--add db/mysql` to choose it
    → Add `--add db/postgres` to choose it
    → Add `--add db/sqlite` to choose it

Ask for two databases:

$ atarashi new my-api --add db/postgres --add db/mongodb
✖ Cannot combine db/mongodb with db/postgres: both claim `database`, and only one is allowed
    → Remove one of them: `--remove db/postgres`

No half-generated directory to clean up. And when exactly one blueprint can satisfy a requirement, it gets added for you. Pick Fastify and it pulls in validation/zod, because the env config needs it:

$ atarashi new my-api --http fastify --db postgres --orm drizzle --auth jwt
✔ Created my-api

  14 files · 14 dependencies · npm
  + validation/zod (required by http/fastify → config:env)

It remembers what you chose

Every generated project gets an atarashi.json:

{
  "name": "my-api",
  "blueprints": [
    { "id": "core/node-ts", "version": "1.0.0" },
    { "id": "validation/zod", "version": "1.0.0" },
    { "id": "db/postgres", "version": "1.0.0" },
    { "id": "orm/drizzle", "version": "1.0.0" },
    { "id": "http/fastify", "version": "1.0.0" },
    { "id": "auth/jwt", "version": "1.0.0" }
  ],
  "answers": {
    "auth.expiry": "7d",
    "db.name": "my-api",
    "db.pool": true
  }
}

This is what templates are missing. Because the project knows what it's made of, you can keep adding to it later:

$ atarashi add obs/pino
Adding obs/pino to my-api
  · .env.example (update)
  · atarashi.json (update)
  · package.json (update)
  · src/config/env.ts (update)
  + src/lib/logger.ts (new)
✔ Added obs/pino

add re-renders only what the new blueprint contributes and splices it into your existing files. Files you've edited by hand are never silently overwritten.

The same file also makes generation reproducible: atarashi new --from atarashi.json gives you a byte-identical project (generated secrets in .env are the exception, on purpose).

The bar every project has to clear

A generated project has to install, build, lint, test, boot and answer GET /health with no edits from you. If a combination can't hit that, it's a bug.

A few other things I cared about:

--dry-run prints the plan and writes nothing
it works offline, the blueprints ship inside the package
nothing it generates depends on Atarashi, and atarashi eject cuts the last link
third-party blueprints use the same format and validator as the built-in ones. Publish one as atarashi-blueprint-* on npm and anyone can use it

Try it

The fastest way is a preset, a set of blueprints known to work together:

npx atarashi@latest new my-api --preset backend-ts --yes
cd my-api && pnpm dev

backend-ts is Express, Postgres, Drizzle, JWT and Docker with strict TypeScript. There are six presets in total, from backend-minimal to fullstack-react. Or pick pieces yourself:

npx atarashi@latest new my-api --http hono --db sqlite --orm drizzle --tests vitest --lint biome

Or run atarashi with no arguments for the wizard.

What I want to hear

It's 1.0 but brand new. The most useful thing you can tell me is which combinations break: a set of flags that should work but gets rejected, or a generated project that doesn't build. There's a pinned tracking issue for exactly that.

Repo: https://github.com/callmegautam/atarashi
Docs: https://atarashi.gautamsuthar.in
Tracking issue: https://github.com/callmegautam/atarashi/issues/4

Developer Matureness

Gautam Suthar — Fri, 14 Nov 2025 13:30:16 +0000

I seriously can’t stand these junior developers who treat every tiny error like a national emergency. The moment something breaks, they sprint to a senior or drop a screenshot in the group chat without even reading the first line of the stack trace. It’s wild. When I was at their stage, I used to sit with an error for hours, sometimes days, poking at it from every angle, searching, reading docs, trying things, breaking things, rebuilding the project twice because maybe the universe just needed a reset. That’s how you build intuition. That’s how you grow.

The funniest part? They act like the internet doesn’t exist. Docs? Never heard of them. Stack Overflow? Apparently a myth from ancient times. Even AI is right there, literally begging to help, but somehow the default response is: “bhaiya error aa gaya, dekhlo.” It’s not even about being a hero and solving everything yourself. it’s about respecting the craft. Respecting the people around you. Seniors aren’t Google. They’re not a walking Stack Overflow clone with free time to babysit your missing comma.

I don’t get why some people treat debugging like a personal insult. As if the moment something goes wrong, it’s proof that they suck and someone else needs to come pat their head and fix it. Debugging is half the job. Half of engineering is staring at error messages and slowly negotiating with your own sanity until the code finally behaves. If you avoid that part, you never develop the instincts that make you a real dev.

And the worst part is when they skip the basics. They don’t isolate the issue, don’t try to reproduce it, don’t check what they changed five minutes ago. They don’t even read the error. They just panic. They just want someone else to tell them the answer as fast as possible so they can paste it, pretend they understand it, and move on without learning anything.

Meanwhile seniors have their own fires to put out. They’re juggling deployments, code reviews, deadlines, and their own bugs. and junior devs casually drop in like, “bro, help.” Some juniors are even busy with their own tasks. Time is expensive. Attention is expensive. Running to AI is fine, that costs no one anything. But running to a human for every hiccup? That’s just straight-up disrespectful.

This isn’t about gatekeeping or flexing. It’s about maturity. Writing code is easy. Searching for answers is easy. What takes maturity is the willingness to sit with your mistakes, poke at them, dig into the logs, question your assumptions, and slowly unravel the mess you made. The uncomfortable truth is: if you keep running from the discomfort, you’ll always be stuck at the same level.

Growing as a developer is not some magical jump. It’s built from tiny moments where you choose to think instead of panic, read instead of whine, experiment instead of complain. Debugging is not punishment. Debugging is training. And if you always outsource that part, you’re basically outsourcing your future self.

So yeah, stop behaving childish. Stop treating every error like a dead end. Slow down, breathe, investigate, try things, break things intentionally, learn why things fail. Ask for help when it’s truly needed, not when you’re just feeling lazy or scared. Be a developer, not a notification.

This industry rewards people who can think. Errors are invitations to think. If you keep running from them, you’ll never cross the threshold from junior to actual engineer. Debug with some dignity. That's where the real growth lives.