Skip to main content
Glama
Sign In
Discord MCP - Discord server management MCP for AI agents

Discord MCP - Discord server management MCP for AI agents

by OrygnsCode
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

List reference layouts

list_reference_layouts
Read-only

Lists curated Discord server blueprints for common server types, helping AI agents choose a starter structure before adapting channels and staging a build.

Instructions

Curated server blueprints to start from: vetted structures for common server kinds. Fetch one with get_reference_layout, adapt names and channels to the user's theme, then stage it with plan_server_build.

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": "list_reference_layouts"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.4.2
    • addedInput schema / $schema
      Added value: +"https://json-schema.org/draft/2020-12/schema"
  2. First observedv1.0.2

TDQS

A4/5.0
Behavior4/5

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

readOnlyHint=true already covers the safety profile, and the description adds genuinely useful behavioral context beyond that: the items are curated/vetted (not user-generated arbitrary data) and are intended as a starting point that must be adapted and then staged via plan_server_build. It does not mention result volume, ordering, or pagination, which is the main remaining gap for a list tool.

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 short sentences, front-loaded with what the tool returns and followed by the action sequence. 'Curated' and 'vetted' are mildly redundant, but nothing else is wasted and the workflow order mirrors the actual usage order.

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

Completeness4/5

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

For a no-argument, no-output-schema list tool, the description covers what the items are and what to do with them next, which is the information an agent needs. The only omission is any hint about how many layouts come back or their shape before fetching one.

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

Parameters4/5

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

The tool takes zero parameters, so there is no parameter semantics to add and the baseline of 4 applies. The description correctly avoids inventing any filtering or argument behavior.

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

Purpose4/5

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

The description names the resource concretely — 'curated server blueprints' / 'vetted structures for common server kinds' — which tells an agent exactly what the list contains, beyond the bare title 'List reference layouts'. It does not explicitly disambiguate from similarly named siblings like list_blueprints or list_server_templates, but the phrasing 'reference layouts' plus the workflow sentence keeps the scope reasonably distinct.

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

Usage Guidelines4/5

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

The second sentence gives an explicit next-step chain: fetch one with get_reference_layout, adapt names/channels to the user's theme, then stage with plan_server_build. That is clear positive guidance on how to act on results. It stops short of stating when NOT to use this tool or naming an alternative listing source, so it falls short of a 5.

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

Deploy Server

Other Tools