Skip to main content
Glama
Sign In
mcgl-mcp

mcgl-mcp

by exi66
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Forum sections

forum_list_sections
Read-only

Lists Minecraft Galaxy forum sections by category with ids, descriptions, topic and reply counts, and last post data, so you can pick a section id for forum_list_topics.

Instructions

Sections of the Minecraft Galaxy general forum (ids 1-11) grouped by category, with description, topic/reply counts and last post. Use the id with forum_list_topics. Content is in Russian.

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

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.0.0-dev

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true. Beyond that, the description adds useful behavior context: the section ids are fixed at 1-11, results are grouped by category, counts and last-post data are included, and content is in Russian.

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

Conciseness5/5

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

The description is two compact sentences, front-loaded with the resource and scope. Every phrase adds information: id range, grouping, fields, sibling usage, and language.

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

Completeness5/5

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

For a parameterless read-only list with no output schema, the description supplies scope, grouping, returned fields, and the key downstream usage instruction. Nothing essential for correct invocation appears missing.

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?

There are zero input parameters, so the baseline is 4. The description correctly emphasizes that the returned section id is the value to reuse with forum_list_topics, which is helpful even without parameters.

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?

The description names the exact resource (Minecraft Galaxy general forum sections), the fixed id range (1-11), the grouping (by category), and the returned fields. An agent can distinguish it from topic-level siblings such as forum_list_topics and forum_get_topic.

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?

It explicitly tells the agent to use the returned id with forum_list_topics, which is clear next-step guidance. It does not state when not to use this tool or compare it against every sibling, so it falls short of full routing guidance.

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