holonovel
Server Quality Checklist
Latest release: v1.0.1
- Disambiguation5/5
Every tool maps to a distinct resource or workflow—character vs npc, lore vs story vs note, countdown vs vow, combat vs condition—and descriptions explicitly disambiguate with 'Use when' and 'Do NOT use when' guidance. There is little risk of misselection despite overlapping vocabulary.
Naming Consistency4/5Most domain tools follow a predictable single-noun resource pattern (npc, lore, faction, story), which is clean and searchable. The utility verbs (respond, undo, redo, help) and snake_case set_badge break that pattern, making it mostly but not perfectly consistent.
Tool Count4/525 tools is at the upper edge of the heavy band, but the server covers a complete narrative-game stack: campaign files, characters, world, combat, factions, vows, journals, rulesets, codex, and synthesis. Each tool has a coherent subdomain, so the count feels justified rather than padded.
Completeness5/5The surface covers full lifecycle management for the domain: Novel saves/checkpoints/export, entity CRUD with roster/import, world modeling, combat/condition state, narrative journaling, lore, factions, relationships, vows, countdowns, sessions, adventures, rulesets, codex, and synthesis. There are no obvious critical dead ends; the main risk is complexity, not missing functionality.
Average 4.2/5 across 25 of 25 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 416 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
Tools from this server were used 2 times in the last 30 days.
This repository includes a glama.json configuration file.
This server has been verified by its author.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention that install/remove/bind mutate state, what happens with a ruleset-free novel beyond not using this tool, or any failure/return behavior. The description only provides usage context, not operational transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tightly structured sentences with purpose front-loaded and a clear Use/Do NOT use parallel. Every sentence earns its place and there is no filler, though the noun 'lookup' is slightly awkward.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six actions, twelve parameters, no annotations, and no output schema, this description is too thin. It entirely omits the 'roll' action and gives no indication of return values, state-changing behavior, or per-action semantics. The schema helps with parameters but cannot compensate for missing action coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all 12 parameters with descriptions, so the baseline is 3. The description adds minimal context about searching a bound ruleset's index, but it does not provide meaningful parameter-level meaning beyond what the schema already supplies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool manages ruleset packages and explicitly lists search, install, remove, list, and bind as use cases, while also distinguishing it from command and session in the negative case. However, it omits the 'roll' action from the action enum and uses the slightly vague phrase 'lookup', so it is not fully precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear 'Use when' and 'Do NOT use when' guidance, including specific alternatives (command action: suggest, session action: health). It is explicit for the listed cases, but incomplete because 'roll' is not mentioned as an eligible use, leaving a gap in routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only says 'manage' and gives usage conditions. It does not state whether combat state is persisted, what 'advance' changes, whether 'end' is destructive, or what side effects participants changes have.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the first states purpose, the second provides actionable selection guidance. The front-loaded structure makes the tool's role immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers general usage and parameter schemas are complete, but the multiple action enums—especially 'status'—are not explained, and the tool has no output schema or annotations to compensate. An agent can call it reasonably but may not understand action-specific behavior or results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all six parameters. The description adds no parameter-level meaning beyond mapping actions to high-level use cases, which matches the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb and resource ('Manage combat encounters in the active Novel') and goes beyond the title by listing concrete use cases (starting, advancing, ending, changing participants). It also differentiates from sibling 'condition' by explicitly routing status-effect application elsewhere, though it leaves the schema's 'status' action undefined, which creates mild ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit 'Use when' list and a 'Do NOT use when' rule with a named alternative tool (condition). However, it omits guidance for the schema's 'status' action, so an agent does not know when to invoke that action vs. the condition tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It refers only to high-level 'Manage Novel save files' and lists actions without explaining consequences of state-changing operations like end, archive, import replace, or checkpoint_remove. The description does not disclose what happens to save data, whether operations are reversible, or what mutations occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the tool's purpose and action list, followed by crisp routing guidance in the second sentence. The enumerated action list is somewhat redundant with the schema enum, but it helps the agent quickly grasp scope without opening the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 24-parameter dispatcher with no output schema, the description provides enough context for tool selection and sibling disambiguation. However, it does not explain per-action effects or return behavior, which would be valuable given the breadth of actions and absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 24 parameters already have meaningful descriptions in the input schema. The tool description adds no parameter-level detail, but per the calibration baseline this is acceptable since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages Novel save files and enumerates its actions, from lifecycle operations to checkpoints. It distinguishes the tool from sibling entity tools by explicitly saying not to use it for content inside the Novel. Minor wording inconsistency ('describe' vs schema's 'description') does not undermine the overall clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit 'Use when' condition—handling a campaign's lifecycle, interchange, or return points—and an explicit 'Do NOT use when' condition with named alternatives (npc, lore, faction, vow, story, note). This leaves little ambiguity about when to select this tool versus its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure, but it only says 'manage' without explaining side effects, mutability, prerequisites, or what happens when a countdown fires. Given the nested world_effect and on_scene_transition parameters in the schema, the description should disclose that setting a countdown can trigger world-model effects or advance on scene transitions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the core purpose, then provides usage conditions and exclusions in an efficient, scannable format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with nine parameters, a nested object, and no output schema or annotations, the description is somewhat minimal. It clearly supports tool selection and basic invocation, but it lacks context about countdown behavior, side effects, and prerequisites that would help an agent correctly invoke advanced options like world_effect or on_scene_transition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all nine parameters. The description adds minor value by mapping 'starting, advancing, removing, listing' to the action enum values, but it does not provide deeper meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool manages countdown timers in the active Novel and names the specific operations: starting, advancing, removing, or listing clocks. It also explicitly distinguishes itself from the sibling vow tool, so an agent can quickly identify the correct resource and action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance for countdown operations and an explicit when-not-to-use exclusion for vow progress tracking, including the specific alternative tool and action: vow (action: milestone). This leaves no ambiguity about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains the scope and general purpose of lore, but does not disclose side effects, reversibility, permission requirements, output behavior, or the behavior of destructive actions like 'remove' or 'import'. It also omits several actions present in the schema, such as reveal, knowledge, and secret operations, leaving those behaviors unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, with the core definition front-loaded and no filler. The use-when and do-not-use guidance is compact and immediately actionable. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 13 parameters and no output schema or annotations, more context would be valuable. The description clearly defines lore and provides a use-case boundary against 'story', but it does not explain the behaviors of lesser-known actions like reveal, knowledge, secret operations, or what import modes imply. It is adequate for selection but not fully complete for confident invocation of every action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 13 parameters have descriptions in the input schema, so the description does not need to repeat param-level meaning. The tool description adds little beyond what the schema already says, but with 100% schema coverage the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Manage'), a specific resource ('the active Novel's lore entries'), and clarifies what lore is ('world facts the narrator recalls'). It also distinguishes itself from a close sibling by saying the story-beat case should use 'story (action: record)', which helps an agent understand exactly what this tool is for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists when to use the tool: 'creating, revising, removing, toggling, grouping, suggesting, listing, exporting, or importing lore.' It also provides a clear exclusion: 'Do NOT use when: recording a story beat — use story (action: record).' This gives an agent direct routing guidance rather than leaving the decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Manage' and does not disclose that remove_room, remove_thing, and remove_exit are destructive, whether changes persist, or what convert does to the existing world model. This is a significant transparency gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, stating scope first, then usage conditions, then an exclusion with a concrete alternative. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives solid selection guidance and the schema handles per-parameter semantics, but with no annotations and no output schema, the tool-level behavior is incomplete. An agent still lacks information about return values, error conditions, persistence, and the semantics of the convert action beyond a vague 'bulk-converting' reference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents every parameter and its applicable action(s). The description adds no param-level meaning beyond grouping parameters conceptually by rooms, things, and exits, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear resource (the world model) and explicit actions (creating, updating, removing, or bulk-converting rooms, things, and exits). It distinguishes itself from the navigation-focused sibling command tool by explicitly naming what it is not for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'Use when' and 'Do NOT use when' guidance. It names the alternative tool and sub-actions (command action: execute / resolve), so an agent knows exactly when to route elsewhere.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It does disclose the behavioral repertoire, including a nuance like 'create (quick or step-by-step)' and 'send player signals'. However, it does not state consequences or side effects: whether 'remove' is permanent, what 'stage to roster' persists, or whether 'set_active' changes global state. For a tool with several mutating actions and zero annotations, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: one dense enumerative sentence listing the operations, followed by two one-line usage rules. Every sentence earns its place and the guidance is front-loaded. The long comma-separated action list is slightly unwieldy but appropriate for an 11-action dispatch tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity — 25 parameters, 11 actions, nested objects, no annotations, and no output schema — the description covers selection and routing well but omits several things an agent needs: the roster lifecycle (what 'stage to roster' vs 'roster_remove' vs 'remove' mean), the distinction between entity_id and roster_id, and any sense of return values since no output schema exists. The 100% schema coverage mitigates this, but the description alone does not fully equip an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. Every parameter already carries an action-context hint in the schema (e.g., 'Entity identifier (stage/sheet/set_active/personality/voice/remove)'). The description itself adds no parameter-level detail, but the schema fully compensates, so no penalty is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Manage') and resource ('player characters'), then enumerates the full operation surface: create (quick or step-by-step), stage, import, sheet, set_active, personality/voice, signal, remove, and roster listing. It explicitly differentiates from the npc sibling tool, so an agent can tell exactly what this tool is for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit routing guidance: 'Use when: working with player characters. Do NOT use when: managing NPCs — use npc.' This gives both a positive trigger condition and a named alternative with an exclusion, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/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. It communicates the core operations (apply/remove/list) and notes the domain (mechanical or narrative), but does not explain side effects, persistence, return values, or permissions. The action names imply mutation, but transparency about what changes and what list returns is absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each serving a distinct purpose: defining the resource, listing when to use, and specifying when not to use with an alternative. No wasted words, and the core purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 4-param tool with 100% schema coverage and one required param, the description covers the main use cases and exclusions. However, there is no output schema and the description doesn't clarify what 'list' returns or whether entity_id is required for list vs apply/remove, leaving minor ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents each parameter. The description adds minimal parameter-level meaning beyond mapping the action enum to apply/remove/list, which is already present in the schema. A baseline of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear resource ('conditions on entities') and a verb ('Manage'), and further narrows scope to applying, removing, or listing conditions. It explicitly contrasts with the combat tool, which helps differentiate it from the most relevant sibling, though 'Manage' is somewhat generic and doesn't distinguish from all other sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Use when' conditions (applying, removing, listing conditions) and an explicit 'Do NOT use when' (recording damage/combat state) with a named alternative tool and action (combat action: init/advance). This gives an agent clear decision criteria for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether 'remove' is destructive or reversible, whether updates require an existing faction, what side effects occur, or what the response contains. The territory-room exclusion is useful but does not compensate for the missing mutation/removal semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The first sentence establishes the tool's domain, and the second packs both when-to-use and when-not-to-use into a compact, scannable form. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with a fully described schema and explicit sibling routing, the description is largely complete: an agent knows the domain, the supported actions, and the key exclusion. However, with no annotations and no output schema, it would benefit from stating whether remove is permanent or whether list returns all factions; the unexplained 'progress clocks' also creates a small gap against the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with every one of the 7 parameters already documented inline. The description adds no param-specific detail beyond what the schema provides, so it meets the baseline but does not exceed it. The mention of 'progress clocks' is not tied to any actual parameter, so it adds semantic ambiguity rather than parameter clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Manage') and resource ('organizations in the active Novel'), then enumerates concrete actions: creating, revising, removing, or listing factions and their progress clocks. It also explicitly distinguishes itself from the sibling tool world by carving out territory-room tracking, making the tool's scope clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit 'Use when' conditions covering the supported actions, and an explicit 'Do NOT use when' with a named alternative tool and action (world, action: create_room). This is ideal routing guidance for an agent deciding between siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of disclosing side effects. It names the operations but does not explain what update/remove permanently change, what 'promote' does to an entry, or whether operations are reversible. 'Manage' only implies mutation rather than describing consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two purposeful sentences: the first defines the resource and content types, the second gives explicit use and non-use guidance. No filler and no repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a multi-action CRUD tool with no annotations or output schema, the description plus the fully documented schema covers selection and basic invocation well. The only real gap is operational semantics of promote/remove, which the description leaves to inference, so it is not a perfect 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter already has a description noting the action it applies to (e.g., 'Story entry text (record/update)', 'Optional page size (list)'). The description adds domain framing but no parameter-level detail beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair ('Manage the story journal'), enumerates the allowed entry types, and lists the five operations. It also differentiates itself from the lore tool by stating the domain boundary, so an agent can distinguish story from siblings like lore and note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'Use when' conditions cover all five supported actions, and the 'Do NOT use when' clause names the exact alternative (lore, action: set) for durable world facts. This is textbook when-to-use routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of disclosing side effects. It only says 'manage' and lists action names; it does not state whether run mutates persistent state, whether revert is safe or idempotent, or what player_add/player_emove actually change.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences front-load the purpose and then give use/non-use routing. There is no filler, repetition, or irrelevant context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 9-parameter, 10-action tool, the description plus the fully documented schema provides enough to select and invoke the tool. It lacks explicit output-shape and side-effect notes, but those are partly covered by the schema's 'detail' and action descriptions, making this a minor gap rather than a blocking omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline applies. The description adds no parameter-level meaning, but each of the nine properties is already documented in the input schema, so this is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific resource ('synthesis content'), a management verb, and the content subtypes it covers ('voice examples, lore templates, action patterns, and other enrichment'). It also explicitly excludes the codex sibling, so an agent can distinguish this tool from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Use when' and 'Do NOT use when' conditions, listing the relevant actions and naming the alternative for codex browsing. This gives the agent direct, actionable selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses that the tool generates, loads, and lists content and that it is not for recording story beats, but it does not state side effects such as whether generation persists content, whether loading changes the current session/module state, or what the tool returns. These omissions are noticeable but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: one sentence states the core capability, followed by conditional use and non-use guidance. Every sentence earns its place, and there is no repetition of schema details or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the multi-action nature of the tool and the 100% schema coverage, the description plus schema are largely sufficient for an agent to select and invoke the tool. The use/when-not guidance names the relevant sibling, and the schema maps parameters to actions. The only gap is the lack of return/output behavior, which is somewhat inferable for a content-generation tool. No output schema exists to fill this gap, but the omission is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds use-case framing around the actions (scaffold, encounter, module) but does not explain parameter semantics beyond what the schema already provides. The schema already associates parameters with actions, so the description adds marginal but non-essential value here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Generate, load, or list adventure content.' It also explicitly distinguishes itself from the sibling 'story' tool by saying it should not be used for recording a story beat. This gives an agent clear differentiation without needing to inspect the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit 'Use when' conditions for each of the main actions (new scaffold, single encounter, prepared module) and an explicit 'Do NOT use when' condition, naming the correct alternative tool, story (action: record). This is exactly the kind of routing guidance an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does convey that codex operates cross-Novels, that content is reusable, and that actions include storing, enumerating/reading, and deleting. However, it does not disclose side effects such as whether delete is irreversible, whether set overwrites existing entries, how capture behaves, or any permissions required. This is a meaningful gap for a tool with multiple mutating actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, with the core purpose front-loaded, followed by a concise 'Use when' and 'Do NOT use when' with alternatives. Every sentence earns its place and there is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 10 parameters, 6 actions, and no output schema, the description covers the essential when/why and explicitly rules out the main alternative use case. It does not describe return formats or the precise runtime effects of individual actions like import or capture, which would be helpful given the absence of an output schema, but the input schema compensates with detailed parameter descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 10 parameters with descriptions, so the baseline is 3. The description adds some contextual meaning by listing content types like 'voice profiles' which maps to the capture action, but it does not provide additional param-level detail beyond the schema. Since schema coverage is 100%, the description does not need to compensate, but it also doesn't enrich param understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Manage the cross-Novels codex library of reusable content' and lists concrete content types (NPCs, factions, rooms, spells, adventures, voice profiles). It explicitly distinguishes itself from siblings by stating 'Do NOT use when: storing Novel-scoped content — use lore (action: set) or note (action: set).' This gives an agent a precise understanding of the tool's scope and boundaries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Use when' and 'Do NOT use when' conditions. It names the alternative tools (lore and note) and the specific scenario (Novel-scoped content) that should route the agent away from codex. This is the highest level of usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral detail. It discloses the operational scope (active Novel) and the five operation kinds, including a destructive 'remove'. However, it does not state that remove is irreversible, whether updates merge or replace fields, or any side effects or authorization requirements, so it only partially meets the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose and scoped to the active Novel, followed by a precise exclusion. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core context: what it manages, when to use it, and the key sibling alternative, and the schema covers all parameter semantics. Without an output schema or annotations it could additionally explain response/return behavior, but for a CRUD tool the provided context is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all eight parameters. The description adds no parameter-specific detail beyond naming use cases, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Manage non-player characters in the active Novel' with a specific resource and scope, and directly contrasts with the character tool for player characters. The listed use cases (introducing, revising, removing, listing, reading) map cleanly to the five actions, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'Use when' and 'Do NOT use when' guidance names the exact alternative (character with action create/import/sheet) and the distinguishing condition (player characters vs NPCs). This is exemplary routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It does communicate the core distinction between 'set' and 'get' and the directed nature of the relationship. However, it does not mention overwrite semantics, return behavior for get, or any side effects beyond the implied mutation from 'set'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one sentence for the core function, one for when to use, and one for when not to use. It front-loads the essential purpose and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 7 parameters and no output schema, the description is adequate for selecting and invoking the tool: it defines the domain, the actions, and the exclusion case. It does not describe what a 'get' returns, but the schema's entity_id parameter partially covers that, and the tool is relatively simple.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already has 100% parameter descriptions, so the baseline is 3. The description adds useful domain context ('directed', 'entities, NPCs, or factions') but does not meaningfully elaborate on parameter meaning beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Manage') and resource ('directed relationships between entities, NPCs, or factions'), and it distinguishes itself from the similarly named faction tool by explicitly stating what it is not for. An agent can clearly tell this tool handles pairwise relationship queries/updates rather than faction progress.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: use when 'setting or reading how two parties relate' and do not use when 'tracking faction progress', directing to faction (action: update). This clearly states the intended conditions and provides an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does state that the tool manages the active scene and can perform mutations (set, directive, presence, autonomy, choices, oracle). However, it does not disclose side effects, whether existing scene data gets overwritten, or what the agent can expect back from oracle resolution. The mutation is implied but not explicitly characterized.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, followed by scoped use cases and a clear exclusion. Every sentence earns its place, there is no fluff, and the structure makes scanning easy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (23 parameters, 7 enums, nested objects, no output schema), and the description provides a strong high-level orientation: what it does, when to use it, and when not to. It does not explain behaviors like fast_forward or autonomy levels, but those are documented in the schema. The only notable omission is that it doesn't explicitly state that the 'action' field selects one of these operations, though the 'or' phrasing implies it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and every parameter already has a description with the action category in parentheses (e.g., '(set)', '(oracle)'). The description groups these categories into use cases like 'setting scene state (description, location, type)', but adds no new syntax, value constraints, or behavioral meaning beyond what the schema already documents. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Manage') and resource ('the active scene and its narrative framing'), then enumerates the concrete actions it supports: setting scene state, narrative directive, party presence, AI autonomy, choices, and oracle rolls. It explicitly differentiates from the sibling 'story' tool by stating when NOT to use it ('recording a story beat — use story (action: record)').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states 'Use when' with specific scenarios mapped to the tool's action types, and 'Do NOT use when' with the exact alternative tool and call ('story (action: record)'). This gives an agent clear routing criteria both for and against this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It does add useful traits such as 'without mutating state' for resolve and 'intent mapped to tool calls' for suggest, but it does not disclose whether execute mutates state, what errors or outcomes occur, or what the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler. The first sentence front-loads the mode semantics, the second gives conditional usage, and the third provides an exclusion with alternatives. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers when to use each mode but leaves gaps for a polymorphic tool with no output schema and no annotations: it does not state that execute requires a command, that resolve/suggest require intent, or what the tool returns. These are material omissions for an agent deciding how to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, so the baseline is 3, but the description adds mode-to-parameter relationships: command is tied to execute, intent to resolve/suggest, and entity_id to suggest. This helps agents know which parameters are relevant per action beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names three specific operations (execute, resolve, suggest) and ties each to a concrete resource or outcome: parser command, spatial intent outcome, and intent-to-tool-call mapping. It also explicitly distinguishes the tool from world/lore inspection with a do-not-use note, so an agent can tell it apart from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit conditions for each mode: physical player/narrator action for execute, non-mutating movement outcome for resolve, and intent-to-tool-call mapping for suggest. It also states when NOT to use the tool and names the alternatives (world or lore), which is strong routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It does identify the high-level behaviors (recap, verbosity, briefing_order, compress, health) and even implies that compress affects the audit log. However, it does not disclose side effects, reversibility, permissions, or output behavior, particularly for 'compress' which likely mutates or truncates data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the core purpose, uses a compact 'Use when' list, and closes with a clear negative routing rule. Every sentence contributes information and there is no redundant or filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficiently complete for selecting and invoking the tool: it covers all actions, the use-case context, and the main alternative tool. Schema descriptions cover all parameters. The main gap is that conditional parameter requirements per action (e.g., mode needed for verbosity, sections for briefing_order) are not explicitly stated, though they can be inferred from the description and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 meaningful context by mapping each action to its purpose: 'setting output verbosity (verbosity)', 'reordering briefing sections (briefing_order)', 'compressing the audit log (compress)'. This clarifies how the action parameter relates to mode, sections, and max_entries beyond the schema's terse descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Manage') with a clear resource ('session-level surfaces and diagnostics') and enumerates all five actions with their purposes. It explicitly distinguishes itself from the story tool via the 'Do NOT use when... use story (action: record)' directive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit 'Use when' list tying each action to its intended scenario, and an explicit 'Do NOT use when' exclusion with the correct alternative tool. This leaves little ambiguity about when to select this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does describe the lifecycle actions (set/milestone/resolve/forsake/list) and clarifies that it is not for clocks, which is useful. However, it does not disclose side effects such as whether forsake is destructive, whether changes persist, or what the list action returns, so it is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with no wasted words. Core purpose is front-loaded, followed by use-when and the explicit exclusion. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters and no annotations/output schema, the description gives a solid operational overview and redirection, and the schema covers parameter details. The main missing piece is output/effect behavior — no description of what resolve/forsake returns or how a list is presented — so it is quite complete but not fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents every parameter. The description still adds semantic value by framing 'milestone' as advancing, 'forsake' as abandoning, and by enumerating the action categories in plain language, which helps map parameters to operations. It does not add format-level details, but the baseline is already high due full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a specific verb and resource: 'Track narrative vows, quests, and obligations with milestones.' It enumerates the exact operations (setting, advancing, resolving, forsaking, listing), so an agent can understand both the purpose and scope. It also distinguishes itself from countdown, making it identifiable among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Contains explicit use-when guidance: 'Use when: setting, advancing, resolving, forsaking, or listing vows.' It also gives a direct negative rule: 'Do NOT use when: starting a clock timer — use countdown (action: set).' This clearly routes to the correct sibling and specifies the alternative action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses that listing is badge-filtered and that category reassignment is for a session, adding useful context beyond the schema. It doesn't detail all side effects, but the session-scoped wording covers the main mutation concern.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is compact: a one-sentence purpose statement followed by explicit use/when-not conditions. Every sentence earns its place, and the core behavior is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a help/discovery tool with no required parameters and no output schema, the description plus 100% schema coverage is complete: it covers both actions, keyword search behavior, session-scoped category reassignment, and the boundary with badge_briefing. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter is already documented. The description's 'find by keyword' and 'override a tool's category' map loosely to the query and action/category/tool_name parameters but add no new details; the baseline of 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Show the available tools grouped by category (badge-filtered) or reassign a tool's category.' It names two distinct actions and distinguishes itself from the badge_briefing prompt, so an agent knows what this tool does and is not.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit 'Use when' conditions (discover tools, find by keyword, override category) and a 'Do NOT use when' exclusion with a named alternative (badge_briefing prompt). No inference is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing side effects. It does so by stating the operation 'atomically drain[s]' the pending decision and 'persist[s] the outcome to the Novel.' This meaningfully describes the mutation behavior beyond the plain meaning of 'answer.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the core action, the exact when-to-use condition, and the explicit when-not-to-use with alternative. It is front-loaded with the primary purpose and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description provides everything an agent needs: the triggering condition, the behavior, the atomic side effect, the persistence target, and a clear disambiguation from alternatives. No critical context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-level detail beyond the schema; the schema already explains 'decision' as canonical waiting text and 'option' as the choice or 'cancel' to abort and restore the snapshot.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Answer a pending workflow decision', and adds unique behavioral details ('atomically draining it and persisting the outcome to the Novel'). It is clearly distinguishable from sibling tools like set_badge or state manipulation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides the trigger condition: 'the server emitted a [NEED_INPUT] prompt and the caller must choose.' It also gives a direct exclusion with an alternative: 'Do NOT use when: no decision is pending — use set_badge or a state tool instead.' This fully guides tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses that the tool is 'always callable' and that it gates tool access server-side for the session, revealing its mechanism and scope. It doesn't discuss side effects or reversibility, but for a simple session badge switch this is sufficient context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: the core action and enum are front-loaded in the first sentence, followed by concise use/do-not-use guidance. Every sentence adds value, and there is no redundant repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter enum tool with no output schema, the description fully covers the purpose, the value set, when to use it, when not to use it, and a key behavioral caveat ('always callable'). Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents the single parameter with the same enum values and prose. The tool description merely repeats the enum list ('player, game_master, observer, or none (Editor)') without adding new parameter-level meaning, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Switch') and resource ('active badge'), enumerates all four possible values, and adds the functional outcome ('gating tool access server-side for the session'). This clearly differentiates it from sibling tools like respond or set_active_entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases ('entering the story, spectating, or stepping away to edit') and explicitly names a when-not-to-use scenario with the correct alternative ('answering a pending workflow decision — use respond'). This gives an agent unambiguous routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses that notes are ephemeral 'scratch state' scoped per badge with a default, and warns against storing durable facts. It does not fully explain the server-scoped variants or operation side effects, keeping it just shy of complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: the first front-loads scope and default, the second gives usage rules and the alternative. There is no filler, repetition, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six actions and two scoping models, the description covers purpose, scope, default, and the key alternative. The only notable gap is that 'server' actions and narrative_tag are left entirely to the schema, but the schema descriptors are explicit enough to fill that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% parameter coverage, so the description only needs to add value. It adds the default for badge_scope (game_master) and clarifies the scratch/badge-scoped semantics, which goes beyond the enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource ('Novel-scoped scratch notes') plus scoping behavior ('badge-scoped to game_master (default), player, or shared'), and explicitly contrasts it with lore for durable facts. This clearly differentiates the tool from its siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'Use when' and 'Do NOT use when' conditions, and names the exact alternative ('use lore (action: set)'). An agent can decide immediately whether this is the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses non-obvious statefulness: the operation only applies to the most recently undone mutation and restores a per-badge snapshot, which is the inverse of undo's behavior. It could mention the empty-redo failure case, but for a zero-parameter utility the disclosure is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the operative statement, the when-to-use condition, and the explicit exclusion with its alternative. The core verb and object are front-loaded with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (zero parameters, no output schema, no nested objects), the description covers purpose, stateful scoping, and sibling routing completely. The only omission is an explicit failure-mode statement for when there is nothing to redo, which is minor against the simple surface area.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters with 100% schema coverage (empty schema), so the baseline is 4 and there is nothing the description must document. The phrase 'per-badge snapshot' usefully clarifies the implicit scope of the operation even though no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Re-apply the most recently undone mutation.' Adding 'restoring the per-badge snapshot that undo removed' pins down the exact semantics, and the explicit contrast with the sibling tool `undo` makes it unambiguous which operation is which.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when/when-not guidance: 'Use when: an undo was issued by mistake... Do NOT use when: reverting a new change — use undo.' This directly names the alternative tool and the condition that selects it, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the core behavior: restoring a prior per-badge snapshot and affecting only the most recent state mutation. It does not describe edge cases like attempting undo when there is nothing to undo, but the essential behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with clear front-loading of the action and effect, followed by compact usage rules. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description fully covers what the tool does, when to use it, and when to choose an alternative. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description needs no parameter-specific detail and does not attempt to invent any.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('undo') and the specific resource ('most recent state mutation', 'prior per-badge snapshot'). It also explicitly distinguishes the tool from its sibling 'redo' by stating what it is not for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance ('reverting a mistaken or unwanted change') and explicit when-not-to-use guidance ('re-applying an undone change — use redo'). It names the alternative tool, leaving no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/flukeatzerocool/holonovel'
If you have feedback or need assistance with the MCP directory API, please join our Discord server