Skip to main content
Glama

Who’s behind it

studio
Read-onlyIdempotent

A developer (a Roblox group or one person) and the games they make, by one of their games or by name: who owns it, members, verified, their place among developers, players in all their games now, and each game with players now, visits and likes. With studio instead: the studio’s whole page, as RoBot reads it: who runs it, its website, X and Discord, its people and what kind each is, its Roblox groups, how its players are doing, its games (as a dataset too), the games it worked on and its latest updates.

Input Schema

NameRequiredDescriptionDefault
gameNoThe game: its name (like "grow a garden"), its universe id, its Roblox link or place id, or its roterminal.co/g/ link
nameNoThe developer’s name, when no game is known
studioNoThe studio’s whole page: its name (like "kuzu"), its key from find (p2012478972, g16209082, u950371), or its roterminal.co or Roblox community link (optional)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / studio
      Added value: +{
      +  "description": "The studio’s whole page: its name (like \"kuzu\"), its key from find (p2012478972, g16209082, u950371), or its roterminal.co or Roblox community link (optional)",
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / game / description
      Previous value: -"The game: its name (like \"grow a garden\"), its universe id, or its roterminal.co/g/ link"New value: +"The game: its name (like \"grow a garden\"), its universe id, its Roblox link or place id, or its roterminal.co/g/ link"
  3. First observed

TDQS

C2.4/5.0
Behavior3/5

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

Annotations already declare read-only, idempotent, non-destructive behavior, so safety is covered. The description adds that results are 'as RoBot reads it,' implying a cached/derived snapshot, and enumerates what data is surfaced, but says nothing about what happens with conflicting or zero parameters, or about error behavior. Adequate but thin against the reduced bar set by annotations.

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

Conciseness2/5

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

Two long run-on sentences heavy with comma-separated field lists, and the front-loaded sentence describes the developer mode rather than the tool's own studio behavior. The structure buries the actual distinguishing information behind 'With studio instead.'

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?

Three optional parameters with no output schema and no required inputs make this inherently ambiguous, and the description does enumerate the data returned for both modes, which helps. However, it omits the mode-selection rules and mutual exclusivity that an agent needs to invoke a zero-required-parameter tool correctly.

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 coverage is 100%, so each parameter's format is already documented, establishing a baseline of 3. The description adds marginal meaning by implying game/name select the developer view while studio selects the page view, but it never states this mode-selection logic explicitly, leaving the key semantic relationship to inference.

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

Purpose2/5

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

The opening sentence describes a developer lookup by game or name, then switches to 'With studio instead' describing a studio page, so the agent cannot tell which behavior the tool itself performs without parsing parameters. The verb is absent entirely; the description is a list of returnable fields rather than a statement of purpose, and it does not differentiate itself from siblings like person, game, or find.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this versus person, find, or game — the closest thing is the schema note 'when no game is known' for name. 'With studio instead' implies a mode switch but never says under what conditions an agent should choose studio mode over developer mode, or that parameters are mutually alternative.

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.