How to Describe a Server So an AI Builds the Right One

The single biggest factor in whether an AI-built Discord server is usable is the description you gave it. Not the model, not the tool. A vague prompt produces a generic server because a vague prompt contains no information the tool could have used.

This guide is written against PeakBot's Onyx, but the principles apply to any AI server builder.

What makes a good prompt for an AI server builder?

Include six things: who the community is for, what people will actually do there, who is allowed to post where, which features you want running, roughly how many members you expect, and anything that already exists.

Everything else is decoration. Those six are the ones that change the output.

1. Who it is for. "A Valorant clan" produces a different server from "a Valorant news community". One needs scrims and rosters; the other needs an announcements channel and a chat.

2. What people do there. The activity determines the channels. Voice-heavy communities need join-to-create rooms. Text communities do not.

3. Who posts where. This is the one people leave out and then regret. "Only staff post in announcements", "only verified members can see the LFG channels", "everyone can read the rules, nobody can reply". Permission overrides are the hardest part of Discord to get right by hand and the easiest thing to specify in a sentence.

4. Which features you want. Naming them is faster than discovering them. Tickets, XP, welcome messages, reaction roles, anti-raid, invite tracking.

5. Rough size. A twelve-person friend server and a 10,000-member community want opposite things. The small one wants fewer channels than feels right; the large one wants more separation than feels necessary.

6. What already exists. If your server has channels, say so. Onyx reads the existing structure, and telling it what you want kept saves a round trip.

What should you leave out?

Channel-by-channel lists. If you already know every channel you want, you do not need an AI server builder; you need ten minutes. Describe the outcome and let the plan propose the structure — then correct it.

Cosmetics. Emoji in channel names, exact colour codes, precise ordering. These are trivial to adjust afterwards and they crowd out the information that actually shapes the build.

Anything you are not sure about. A guess stated confidently in a prompt gets built confidently. "Maybe a shop channel?" is better left for a follow-up.

Worked examples

Weak prompt

Make me a gaming server.

That is one fact. Expect a generic gaming server, because nothing else was supplied.

Strong prompt

A Valorant clan server for about 40 members. We scrim three nights a week, so we need LFG and scrim scheduling, plus voice rooms that spawn when a stack queues up. Ranked chat separate from casual. Only officers post in announcements and only officers see the mod log. Set up welcome messages, tickets for join requests, and anti-raid.

That contains all six: who, what, who-posts-where, features, size, and structure. Every clause maps to something the plan can act on.

Strong prompt for an existing server

We already have a 3,000-member art community with a #showcase and #general. Keep those. Add a WIP channel, a critique channel that people opt into with a role, and separate NSFW channels only verified members can see. Turn on logging and tickets for commission requests.

Naming what to keep is what stops a builder from proposing a restructure you did not want.

How do you fix a build that came out wrong?

Correct it in a follow-up message rather than starting over. With Onyx the follow-up works on the plan it just produced, so "make the LFG channels voice instead" changes those channels and leaves the rest alone. Rewriting the original prompt and re-running throws away everything that was already right.

Three corrections that come up constantly:

• "Lock the mod log to staff only." Permission fixes are the most common follow-up and the most important to check.
• "Fewer channels." Almost every first pass proposes more than a small server needs. Ask for the cut.
• "Merge these two." Near-duplicate channels are easier to spot in a plan than to predict in a prompt.

Does the prompt need to be long?

No. The strong examples above are four sentences. Length is not the point; specificity about who posts where is. A two-sentence prompt that names the permission rules beats a paragraph of atmosphere.

Where to go next

• What is Onyx? — what PeakBot's builder is and is not.
• How Onyx builds a Discord server — what happens after you press send.
• The permission mistakes an AI build prevents — the failure this whole thing exists to avoid.