Skip to main content
Glama

Read the game categories

get_game_categories
Read-onlyIdempotent

The values update_application_form takes for category, in priority order, and how to choose one. Read it before setting or changing a game’s category. howToChoose is the rule; each of categories has slug (what the form takes), title, description, like (the kinds of games it holds), examples (names of Playgama games of it) and notLike: games it does not hold, each with the categories they belong to. groups is how the console groups them. The same list the console shows the developer.

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

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/no-destructive, and the description adds what the annotations cannot: the returned structure (`howToChoose`, `categories` fields, `notLike`, `groups`) and its provenance as the same list the console shows. With no output schema, this disclosure carries the return-value burden well.

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?

Front-loaded with the purpose and the trigger, then a compact field inventory. It borders on dense, backtick-heavy enumeration, but every sentence contributes and nothing is repeated.

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?

Given zero parameters, no output schema and a read-only annotation set, the description supplies exactly the missing piece – the shape and meaning of each returned field. An agent has everything needed to call and interpret it.

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 the baseline is 4; there is nothing further for the description to disambiguate. It correctly spends no words on parameter guidance.

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 first sentence names the exact resource (the values `update_application_form` takes for `category`) and the scope (priority order plus how to choose). An agent can distinguish it from `update_application_form` and from other read tools without opening the 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?

Explicitly states 'Read it before setting or changing a game's category', naming the sibling that consumes this data and the moment to call it. That is a concrete when-to-use rule rather than an implied one.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources