Skip to main content
Glama
Niclasp1501

ninjos-foundry-mcp

by Niclasp1501
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Create a campaign dashboard

create-campaign-dashboard

Create a Foundry VTT campaign journal that tracks progress, parts, locations, quest givers, and status toggles. Parts stay locked until the previous is completed or skipped.

Instructions

Create a journal that gives an overview of a campaign in several parts: progress, current part, location and quest giver, and for each part its levels, description and a status toggle. Clicking a toggle in Foundry cycles not started, in progress, completed, skipped and saves it on the journal; figures, current part and lock markers follow the saved status whenever the page is shown. A part is locked until the one before it is completed or skipped. The journal is visible to Gamemasters only, named after the campaign and placed in a journal folder with the campaign title (created when missing). Texts are written in the language of the Gamemaster's client.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
templateYesStructure of the campaign. "custom" requires customParts; the other templates bring fixed parts and refuse customParts.
customPartsNoThe parts of a campaign with template "custom", in order. At least one.
campaignTitleYesTitle of the campaign, e.g. "The Whisperstone Conspiracy".
defaultLocationNoMain location or setting of the campaign, shown in the overview (optional).
defaultQuestGiverNoName of the figure who gives the party its quests, shown in the overview (optional).
campaignDescriptionYesShort description of the theme and scope of the campaign.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv14.2609.4

TDQS

A4.4/5.0
Behavior5/5

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

The description goes well beyond the sparse annotations by disclosing many behavioral traits: status toggles cycle through four states and persist, figures/current part/lock markers react to saved status, parts lock until predecessors are completed/skipped, journal is GM-only, folder is auto-created if missing, and text follows the GM's client language. These details add substantial context beyond readOnlyHint and destructiveHint.

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?

The description is information-dense and front-loaded with the core purpose. Each of its five sentences contributes distinct value: contents, toggle behavior, locking rules, folder/visibility, and localization. There is no filler or repetition of schema details.

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?

Given the tool's complexity and the absence of an output schema, the description is largely complete: it explains the journal's contents, dynamic status behavior, locking, permissions, folder creation, and localization. A minor gap is that it never states what the function returns (e.g., journal ID), but for calling and creating the dashboard, the essential context is present.

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?

The input schema has 100% description coverage for all six parameters, so the baseline is 3. The tool description adds narrative context about how the journal uses campaign data (e.g., location, quest giver, parts), but it does not add parameter-specific meaning or constraints beyond what the schema already states. It does not need to repeat 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?

The description opens with a specific verb and resource: 'Create a journal that gives an overview of a campaign.' It then enumerates the journal's contents (progress, current part, location, quest giver, per-part levels/description/status toggles), which clearly distinguishes it from sibling tools like create-quest-journal. The resource and behavior are unambiguous.

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 makes the tool's context clear: it is for creating a campaign-wide overview journal with status tracking, lock progression, and GM-only visibility. It does not explicitly name alternatives or state when not to use it, but the campaign focus and journal structure implicitly separate it from quest journal and combat tools.

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