Tavern

Hand session notes to Lorekeeper

queue_session_for_lorekeeper

Destructive

Give Lorekeeper a session's notes as you wrote them. It logs the session, links every name, writes new wiki pages, updates the ones the session touched, pins the map and writes the recap. When the write-up is in, the other seats are emailed a link to it unless those letters are switched off. Needs Lorekeeper at the table. GM only. Returns: The job.

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>",
      "sessionDate": "<sessionDate>",
      "notes": "<notes>"
    },
    "name": "queue_session_for_lorekeeper"
  }
}

Input Schema

Name	Required	Description
`notes`	Yes	The session's notes, as you wrote them.
`title`	No	The session's title, if it has one.
`campaign`	Yes	The campaign, by its slug (what its link says) or its id.
`playedAt`	No	When it was played, in your own clock (ISO 8601).
`sessionDate`	Yes	The play date.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 3, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Adds substantial context beyond the annotations: it discloses the full set of side effects (wiki page creation and updates, map pinning, recap writing) and, crucially, an outbound notification to other seats unless disabled — a consequence an agent could not infer from destructiveHint alone. It does not restate the non-idempotent risk (double submission duplicating wiki work), which would have completed the picture.

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?

Four sentences, front-loaded with the action and its effects, then prerequisites and return value. Minimal waste, though "Returns: The job." is cryptic enough to read as filler rather than useful information.

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 five-parameter mutation with no output schema, the definition covers effects, permissions, side effects, and a rough return indication. The return value ("The job") is under-explained, but list_lorekeeper_jobs provides the follow-up path, keeping the gap small.

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%, so all five parameters are already documented in the schema. The description only echoes "as you wrote them" without adding format, slug resolution, or date-versus-timestamp guidance beyond what the schema states, so baseline 3 applies.

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?

Names a specific verb and resource ("Give Lorekeeper a session's notes") and then enumerates the concrete pipeline it triggers: logging the session, linking names, creating and updating wiki pages, pinning the map, writing the recap. This is clearly distinct from single-item siblings like add_session_note or create_session.

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?

Supplies real preconditions — "Needs Lorekeeper at the table. GM only." — and implies usage timing ("When the write-up is in"). It stops short of explicitly naming when to prefer this over add_session_note or create_session, so the agent must infer the boundary.

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.