Skip to main content
Glama
rbilleci

bsh-mcp

by rbilleci

combat_attack

Resolve a player attack against an NPC, applying threat level, rolling damage, handling weapon effects, updating hit points, and advancing the turn when the action is spent.

Instructions

Resolve one player attack against one NPC.

Melee tests STR and needs close range. Ranged tests DEX. The tool applies Threat Level, rolls damage on a success, applies a critical as maximum base damage plus one extra die, updates hit points, and marks a dead NPC.

Repeating the attack action in the same turn rolls Doom automatically.

Spending the last action advances the turn itself, and dropping the last enemy ends the fight itself: read turn_advanced, next_actor, combat_over, and next_step from the result rather than calling combat_end_turn. Only the active actor may attack; an attack out of turn is refused with the actor whose turn it actually is.

weapon_effect accepts none, brutal, disarm, pin_down, shove, entangle, cleave, or impale. Disarm, pin_down, and entangle deal no damage and instead flag the target (reduced damage output, or blocked from changing range band until it spends an action to break free). Shove deals no damage and pushes the target one band away. Cleave and impale both strike beyond the named target on the same swing: cleave also hits every other enemy sharing the target's range band, and impale, only when the blow fells the target, carries through for the same damage to one more enemy in that band, chosen at random. Any other value is rejected before dice are rolled: adjudicate it in fiction and record durable results with scene_commit.

Set runic true to strike with a granted runic weapon: damage equals the attribute the weapon's personality fixes, and a kill rolls the on-kill effect. A runic strike takes no weapon_effect and is not unarmed.

Set one_handed_blade true when the weapon in hand is a one-handed blade; a Sword master then tests DEX instead of STR on a melee attack. A Hunter's first ranged attack of a fight hits automatically without a test and adds their level to damage.

Set target_unaware true when the fiction holds the target unaware of the attacker; an Assassin's strike then deals damage equal to their DEX score in place of the rolled weapon damage. The engine only honours this while the target has not itself reacted this fight (its own turn opened, or it attacked someone) and this character has not already spent their own unaware strike this fight; being struck does not itself count as reacting, so a second Assassin can still find the same target unaware. Outside that window the flag is ignored and normal damage applies.

Set poisoned true to coat the strike with one prepared Herbalist poison dose. Refused before any dice roll if no dose is in stock, or alongside runic, unarmed, or a non-damaging weapon_effect (disarm, pin_down, shove, entangle). The dose is spent on the swing whether it hits or misses, and a damaging hit adds d6 poison damage.

A positioning declaration -- circling behind, backing off, working for an angle -- is not an attack; resolve it with attribute_test on the actor's own turn instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
runicNo
unarmedNo
poisonedNo
advantageNo
target_idYes
two_handedNo
attack_typeNomelee
attacker_idYes
disadvantageNo
weapon_effectNonone
target_unawareNo
one_handed_bladeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A5/5.0
Behavior5/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, and it does so thoroughly. It details critical rules (maximum base damage plus one die), doom roll mechanics, hit point updates, death marking, turn advancement, out-of-turn refusal, and the exact effects of optional flags like runic, poisoned, and target_unaware. It even explains edge-case behaviors such as the Assassin's unaware strike window and the interactions of weapon_effect types. This is exceptionally 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/5

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

While lengthy, the description is structured logically: core mechanics first, then optional flags, then explicit exclusions. Every sentence delivers essential information without redundancy. It is front-loaded with the basic resolution flow, then progressively adds detail on special cases. For a tool with this complexity, the length is appropriate and no sentence wastes the reader's time.

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

Completeness5/5

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

Given the absence of an output schema and annotations, the description must provide complete operational context. It does: it tells the agent to read turn_advanced, next_actor, combat_over, and next_step from the result, warns about turn advancement, and explains the positioning rule. All functional aspects—including error conditions (refusals), state changes, and return values—are covered. The description leaves no gap the agent needs to guess about.

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

Parameters5/5

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

Schema description coverage is 0%, yet the description compensates completely. It explains attack_type (melee vs ranged, which attribute to test), weapon_effect (all seven options and their consequences), runic (damage source and on-kill effects), one_handed_blade (Sword master DEX substitution), target_unaware (Assassin's damage replacement and conditions), and poisoned (requirements and damage addition). It even clarifies nuanced parameter interactions, such as poisoned being refused with runic or non-damaging effects. The description effectively documents nearly every parameter and its gameplay impact.

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

Purpose5/5

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

The description opens with a precise statement of the tool's purpose: 'Resolve one player attack against one NPC.' It clearly distinguishes from sibling tools like combat_move, combat_defend, and attribute_test by specifying exactly what game action this covers. The resource (attack) and verb (resolve) are concrete and unambiguous.

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?

The description provides explicit usage guidance, including when not to use it: positioning movements are not attacks and should use attribute_test instead. It also explains the interaction with turn mechanics (spending last action advances turn, dropping last enemy ends fight) and cautions against calling combat_end_turn. It names alternatives (attribute_test, combat_end_turn) and clearly states the conditions that trigger them.

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