Skip to main content
Glama
flukeatzerocool

holonovel

by flukeatzerocool
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Combat

combat

Start, advance, or end battle encounters and manage participants. Keeps fight flow consistent with the active Novel scene.

Instructions

Manage combat encounters in the active Novel. Use when: starting, advancing, ending a fight, or changing its participants. Do NOT use when: applying a status effect — use condition (action: apply).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
seedNoOptional deterministic seed (init).
actionYesinit, advance, end, add_participant, remove_participant, or status.
dangersNoOptional non-entity combatants (init).
outcomeNoOptional text describing how combat ended (end).
participantsNoEntity identifiers participating (init).
participant_idNoEntity identifier (add_participant/remove_participant).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior4/5

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

The description implies state changes (manage, start, advance, end) and matches the readOnlyHint=false annotation. However, it does not detail exactly what happens with each action (e.g., what 'advance' does to the combat state), leaving some behavioral details implicit.

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

Conciseness5/5

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

The description is compact and to the point, using a single sentence plus explicit use-case guidance. It avoids redundancy and focuses on the essential information an agent needs.

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

Completeness4/5

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

The description provides enough context for the tool's role and action types, but it does not mention return values or output format, which could be useful for an agent to fully understand the tool's behavior. However, given the action-oriented nature, the missing output info is a minor gap.

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?

All parameters are covered by schema descriptions that clearly explain their purpose and which action they apply to (e.g., participants for init, outcome for end, participant_id for add/remove). The descriptions add value beyond the raw schema by tying each parameter to its action context.

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?

Clearly states the tool manages combat encounters in the active Novel, with explicit use cases (starting, advancing, ending, changing participants) and a clear distinction from the sibling 'condition' tool for status effects.

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

Usage Guidelines5/5

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

Explicitly specifies when to use (starting, advancing, ending, changing participants) and when not to (status effects, with a pointer to the condition tool), leaving no ambiguity about its scope.

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