Skip to main content
Glama

Who can join a battle

get_combat_roster
Read-onlyIdempotent

Every seat at the table (with their character's numbers where they have one) and every sheet nobody holds. GM only. Returns: seats (each with the character it plays and its others) and characters (sheets no seat holds).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "campaign": "<campaign>"
    },
    "name": "get_combat_roster"
  }
}

Input Schema

NameRequiredDescriptionDefault
campaignYesThe campaign, by its slug (what its link says) or its id.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already establish readOnly, idempotent, non-destructive behavior, so the bar is low; the description still adds the meaningful access constraint "GM only" and spells out the two top-level return collections. The one gap is that the nested `others` field inside each seat is referenced without explanation, so a consumer cannot predict its shape.

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 compact sentences with the payload described up front and the access constraint immediately after, no filler. Some phrasing is terse to the point of opacity — "every sheet nobody holds" and "its `others`" require a second read.

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?

With no output schema, the description carries the return-value burden and does name both top-level keys and their rough contents, which is enough to call the tool correctly. The only shortfall is that the nested `others` sub-field and the practical effect of the GM-only restriction (error vs. empty result) are left undefined.

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 100% and the single `campaign` parameter is already documented as accepting a slug or id in the schema. The description adds nothing about the parameter, which is acceptable given the schema handles it, so this stays at the baseline.

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 gives a concrete verb-and-resource picture: it returns every seat plus every unheld character sheet, i.e. the pool of who can be pulled into a battle. It is clear about what is returned but never names the closest siblings (list_seats, list_characters, get_party), so an agent must infer whether this is a filtered union of those or something distinct.

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

Usage Guidelines3/5

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

"GM only" and the title "Who can join a battle" imply the context of use (pre-battle roster lookup by a GM), but there is no explicit when-to-use or when-not-to-use statement. The description never says to prefer list_seats for all seats or list_characters for full sheets, leaving the agent to guess at the boundary.

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.