Skip to main content
Glama
Niclasp1501

ninjos-foundry-mcp

by Niclasp1501
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Create a quest journal

create-quest-journal

Create a Gamemaster-only quest journal in Foundry VTT with structured pages for overview, objectives, rewards, secret notes, and progress. Add optional pages for handouts or extra notes.

Instructions

Create a quest journal visible to Gamemasters only. Its first page holds the title and description, a background from location, quest giver and key figure, an overview with the given details, rewards and "Status: Active", an adventure hook as read-aloud text, a secret note for the Gamemaster, objectives from the quest type and the given facts, and a section for progress notes. All given values are escaped, so they appear as text. Write richer content yourself into additionalPages, which are stored as sent. Without folderName the journal is created outside any folder. The answer lists the pages with their ids and lengths, not the HTML.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
npcNameNoName of the key figure of the quest: opponent, ally or target (optional).
rewardsNoThe rewards (optional).
locationNoWhere the quest takes place (optional).
questTypeNoKind of quest (optional). fetch, escort, kill and mystery bring fixed objectives.
difficultyNoDifficulty (optional).
folderNameNoJournal folder at the top level to put the journal in, by exact name; created when missing. Omit for no folder.
questGiverNoName of the figure who gives the quest to the party (optional).
questTitleYesTitle of the quest, also the name of the journal.
additionalPagesNoFurther pages after the quest page, such as a player handout or Gamemaster notes. Their HTML is stored as sent.
questDescriptionYesWhat the quest is about and what it should achieve.

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?

The annotations only carry negative hints (readOnlyHint=false, etc.), so the description carries the full behavioral load. It does well: it discloses GM-only visibility, HTML escaping of given values, that additionalPages are stored as sent, and that the response lists page ids and lengths, not HTML, which is essential because there is no output schema.

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?

The description is dense and every sentence conveys a meaningful behavior, with no padding. It is, however, long and sentence-like; a structured list or clearer breaks would improve scannability, but not at the cost of necessity.

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 and 10 parameters, the description provides a complete mental model: what the journal contains, how optional params affect it, folder behavior, and the response format. This is enough for an agent to call the tool correctly without hunting for additional guidance.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/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 goes well beyond the schema. It explains how parameters are used: values are escaped, the questType drives fixed objectives, folderName governs folder placement, and additionalPages content is stored as sent—all crucial for correct invocation or interpretation.

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 states a specific verb ('Create'), a specific resource ('a quest journal'), and a distinguishing scope ('visible to Gamemasters only'). It also enumerates the journal's internal content, which differentiates it from generic siblings like journal-create and update-quest-journal.

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 it clear when this tool is appropriate: when you need to create a quest journal with the canonical first page, optional folder handling, and additional pages. It does not explicitly call out alternatives or say when not to use this tool versus update-quest-journal or journal-create, but the context is clear enough.

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