Skip to main content
Glama

create_journal

Add a new journal to a Kanka campaign by supplying the campaign ID and journal details. Use this to document worldbuilding lore and notes.

Instructions

Create a new journal

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYes
campaignIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.1.1

TDQS

C2.1/5.0
Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only states the mutation ('create a new journal') and says nothing about side effects, required ownership (campaignId), or what the response will be. This is minimally transparent and leaves the agent to infer the behavior of a create operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loaded with the verb, with no wasted words. However, it is under-specified even for a simple tool, so the brevity is not a fully appropriate size and does more to obscure than to clarify.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given two required parameters (one an undocumented nested object), no output schema, and no annotations, the tool needs a much richer description to be callable by an agent. The single sentence is nowhere near complete for deciding how to construct a correct request.

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

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema exposes campaignId and data with zero description coverage, and the description mentions neither parameter. The agent cannot tell what campaignId refers to, what shape data should take, or why both are required; the description adds no meaning beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Create a new journal' states a clear verb and resource, so an agent can identify the basic operation. However, it essentially paraphrases the tool name and gives no detail about what a journal is or what differentiates this create operation from the many other create_* siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives such as create_character, create_note, or update_journal, and no prerequisites or context for journal creation are given. The only usage signal is the bare infinitive 'Create,' which provides no strategic direction.

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