discord-server-mcp

preview_blueprint

Read-only

Preview a Discord server layout before building it: channel sidebar, roles, permissions, and who can see or write in each channel, with new/existing/moved markers for approval.

Instructions

Show a visual preview of a server layout before building it: the channel sidebar as members will see it (categories, channel types, topics, forum tags, private areas), the roles with colours and key permissions, and a grid of who can see and write in each channel. With a server, also marks what is new, already there or moved. Use it to let the user approve or ask for changes; then apply_blueprint.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "preview_blueprint"
  }
}

Input Schema

Name	Required	Description
`bot`	No	Use this bot (name or id) instead of choosing automatically
`file`	No
`server`	No	Compare with this server (what is new / existing)
`template`	No
`blueprint`	No
`update_existing`	No
`copy_from_server`	No	Copy the structure of another server a configured bot is in
`discord_template`	No	A Discord server template link (discord.new/… or discord.com/template/…) or its code, e.g. from a template website

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 12, 2026

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description reinforces this by framing the tool as a pre-build inspection whose output drives user approval. It adds real behavioral context by describing the three views produced and the diff markers available in server-comparison mode. It does not say what happens when no source is supplied or when multiple sources conflict, which is the remaining behavioral gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core action and the approval workflow before the parenthetical detail. The long parenthetical enumeration of preview contents is dense but each item is informative; a slightly tighter phrasing would cost nothing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is complex: eight parameters, deeply nested blueprint/category/channel objects, no output schema, and no annotations covering input rules. The description compensates for the missing output schema by describing what the preview displays, but leaves the source-selection model (blueprint vs file vs template vs copy_from_server vs discord_template) unexplained, which is the main thing an agent could get wrong.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 50% and eight parameters exist, several of them (file, template, update_existing) undocumented in the schema. The description adds meaning only for the `server` parameter, explaining that it enables the new/existing/moved marking; the alternative input sources (file, template, discord_template, copy_from_server) and update_existing get no explanation of precedence or mutual exclusivity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Show a visual preview of a server layout') and then enumerates exactly what the preview contains: channel sidebar, roles with colours and permissions, and a visibility/write grid. It also distinguishes itself from the mutating sibling by name ('then apply_blueprint'), so an agent can tell the two apart without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit timing ('before building it'), an explicit purpose ('let the user approve or ask for changes'), and an explicit next step ('then apply_blueprint'). The clause 'With a server, also marks what is new, already there or moved' further tells the agent when the comparison mode applies.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.