Tavern

Put somebody in a battle

add_participant

Add a character at this table (player or companion, by slug, with live health), a seat with no sheet (seat), or anybody you name on the spot (custom, or creature with a stat block you supply). GM only. Returns: The whole battle, the new participant last in participants with the id the other participant tools take.

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>",
      "battle": "<battle>",
      "kind": "<kind>"
    },
    "name": "add_participant"
  }
}

Input Schema

Name	Required	Description
`kind`	Yes	Who they are.
`name`	No	Their name in the order.
`role`	No	A short line under the name.
`side`	No	Which way they point.
`state`	No	Health and the GM's notes. For a character at this table, health is written to their own sheet.
`stats`	No	A stat block you supply, for somebody nobody has a sheet for. Invent it or take it from your own notes.
`battle`	Yes	The battle's id.
`control`	No	Who runs them.
`campaign`	Yes	The campaign, by its slug (what its link says) or its id.
`memberId`	No	For seat: the seat's id.
`avatarUrl`	No	A picture's web address.
`initiative`	No	Their initiative total, with the bonus already in. Stored exactly as given.
`companionId`	No	For companion: the companion's id.
`characterSlug`	No	For player and companion: the character's slug.
`initiativeRoll`	No	Or the number on the die alone: their bonus is added for you (a character's live one off their sheet). Wins over `initiative`.
`initiativeBonus`	No	Their bonus, which breaks ties. Never added to `initiative`.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 3, 2026

changedInput schema / properties / initiative / description

Previous value: -"What they rolled."New value: +"Their initiative total, with the bonus already in. Stored exactly as given."

changedInput schema / properties / initiativeBonus / description

Previous value: -"Their bonus, which breaks ties."New value: +"Their bonus, which breaks ties. Never added to `initiative`."

addedInput schema / properties / initiativeRoll

Added value: +{
+  "description": "Or the number on the die alone: their bonus is added for you (a character's live one off their sheet). Wins over `initiative`.",
+  "type": "integer"
+}

First observedNov 3, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations declare this as a non-readonly, non-destructive, non-idempotent write; the description adds the authorization requirement (GM only) and an explicit return shape ('the whole battle, the new participant last in participants with the id'). It stops short of warning that a second call creates a duplicate participant or stating that a battle must already exist.

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?

Three sentences: what it adds (with the kind routing inline), who may call it, and what comes back. Front-loaded with zero filler despite covering 16 parameters.

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 16-parameter write tool with nested objects and no output schema, the description covers purpose, permission, kind routing, and return value. The main omission is interaction with the closely named sibling tools and any precondition on battle state.

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?

Schema coverage is 100%, so the baseline is 3; the description still adds value by mapping `kind` values to required companion parameters (slug, companion/seat id, stat block), which the enum alone does not convey. Remaining parameters (initiative, side, control, state) are left entirely to the schema.

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?

States a specific verb (add) and resource (a participant in a battle), then enumerates the five `kind` values and what each one means, so an agent knows exactly what it creates. The 'GM only' clause further pins down scope.

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?

Gives clear routing guidance among the `kind` variants (character with a sheet vs. empty seat vs. ad-hoc name vs. supplied stat block) and a prerequisite (GM only). It does not, however, address when to use this versus the sibling `add_seat`, `add_companion`, or `add_character_from_beyond`, which an agent would plausibly confuse with it.

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

All Tavern tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.