Skip to main content
Glama
Niclasp1501

ninjos-foundry-mcp

by Niclasp1501
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Request a roll from a player

request-player-rolls

Send a private roll request to a specific player in Foundry VTT, placing a button in chat that only they and the Gamemaster can press. Ask the user to confirm public or private visibility before creating the request.

Instructions

Put a roll button into the chat so a player rolls on their own device. Only that player and a Gamemaster can press it, and it rolls once. Whether the roll is PUBLIC (visible to all players) or PRIVATE (visible to the target player and the Gamemaster only) is a game decision: if the user did not say it, ask "Do you want this to be a PUBLIC roll or a PRIVATE roll?" and wait for the answer, then set isPublic and userConfirmedVisibility. targetPlayer is a player name or a character name. The formula comes from the adapter of the game system; without one, only rollType "custom" with a formula in rollTarget works. A player who is offline gets no request.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
flavorNoThe occasion, shown as context in the chat
isPublicYestrue: everyone sees the roll; false: only the target player and the Gamemaster
rollTypeYesability, skill, save, attack, initiative or custom, as far as the game system offers them; custom takes a formula in rollTarget
rollTargetYesWhat is rolled: an ability like "dex", a skill like "perception", or the formula for custom like "1d100"
rollModifierNoAdded to the formula, e.g. "+2", "-1" or "+1d4"
targetPlayerYesName of the player or of their character
userConfirmedVisibilityYesMust be true: the user chose public or private, or was asked

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv14.2609.4

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the sparse annotations, the description reveals important behavior: the button is interactive, only the target player and GM can press it, it rolls once, offline players get no request, and the visibility setting requires user confirmation. It also explains adapter limitations for formula-based rolls.

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?

Every sentence earns its place: main action is front-loaded, the visibility decision process is clearly specified, and the adapter/offline constraints are all relevant. The description is dense but not padded.

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?

Despite having no output schema, the description covers all required parameters, the forced visibility clarification, permission restrictions, adapter limitations, one-shot behavior, and offline handling. This is sufficient for an agent to select and invoke the tool correctly.

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, but the description adds essential semantics: targetPlayer can be a player or character name, userConfirmedVisibility must be set only after asking and waiting for an answer, and formula support depends on the game system adapter. This goes beyond the JSON schema's field descriptions.

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?

The description uses specific verb-resource language: it puts a roll button into chat so a player rolls on their own device. It distinguishes itself from sibling dice/roll tools by emphasizing the per-player device interaction and target/GM-only press permissions.

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?

The description clearly indicates when to use this tool: when a player should roll on their own device and when a visibility decision must be resolved. It gives behavioral constraints such as offline players receiving no request weekends, but it does not explicitly name alternative sibling tools or state when not to use it.

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

Deploy Server

Other Tools