Random Tables

Roll Table

roll_table

Read-onlyIdempotent

Pipeworx original random tables: roll one or more entries from a built-in table — encounters_fantasy, encounters_scifi, encounters_modern, loot, weather, complication, npc_personality, npc_secret, npc_occupation, plot_hook, tavern, rumour, settlement_quirk, npc_full. Entries may contain {{table:}} references to OTHER built-in tables, resolved recursively (up to 6 levels deep) — the response gives both the raw entry text and the fully resolved text. Optional seed makes the roll reproducible (same seed + arguments = same result; the seed used is always returned). Optional session_id draws without replacement across repeated calls (hosted only, via the gateway's shared KV) — pass none to get an ordinary independent weighted roll every time, or pass any string to start tracking a no-repeat session (the response returns the real session_id to reuse). No text from any commercial RPG product — every table and entry is written for Pipeworx.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "seed": "pw-smoke-1",
      "count": 2,
      "table": "npc_full"
    },
    "name": "roll_table"
  }
}

Input Schema

Name	Required	Description
`seed`	No	Optional seed for a reproducible roll. Omit for fresh randomness; the seed actually used is always returned.
`count`	No	How many entries to roll, 1-20 (default 1).
`table`	Yes	Built-in table id, e.g. "loot", "npc_full", "encounters_fantasy". Call list_random_tables to see every id.
`session_id`	No	Optional. Omit for an ordinary independent weighted roll. Pass a session_id (your own first time, or one returned by a previous call) to draw without replacement across calls — hosted only.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Adds substantial behavior the annotations cannot convey: recursive {{table:<id>}} resolution capped at 6 levels, that responses include both raw and resolved entry text, that the actual seed is always returned, and that session tracking uses the gateway's shared KV and is hosted-only. Note there is mild tension with idempotentHint (session_id rolls deliberately differ across repeated identical calls), but the description discloses that statefulness rather than hiding it.

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 core verb and resource, then the mechanics; nearly every clause carries operational information. It is still a single dense em-dash run-on mixing table ids, recursion, seeds, sessions, and a licensing note, which is harder to scan than a short structured list.

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?

With no output schema, the description carries the return-value burden and does it: raw entry text plus resolved text, the seed used, and the real session_id to reuse. Combined with the annotations covering the safety profile and the schema covering every parameter, an agent has what it needs to call this correctly on the first try.

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 already 100%, so baseline is 3; the description goes slightly further by explaining how seed and session_id interact behaviorally (reproducibility vs. no-repeat draw) and that 'pass none' is the default independent roll. It does not add syntax, bounds, or format detail beyond the schema text.

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?

States a specific verb and resource — 'roll one or more entries from a built-in table' — and enumerates the exact built-in table ids, so the scope is concrete. The 'built-in' qualifier implicitly separates it from roll_custom_table/get_random_table, but no sibling is named explicitly, so the differentiation is left to inference.

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 conditional guidance for the two optional mechanics: 'pass none to get an ordinary independent weighted roll every time' versus 'pass any string to start tracking a no-repeat session', plus when to supply a seed for reproducibility. It never names an alternative tool to use instead (e.g. roll_custom_table for homebrew tables), so it stays short of explicit when-not guidance.

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

All Random Tables 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.