Skip to main content
Glama
rbilleci

bsh-mcp

by rbilleci

combat_defend

Resolve a player's defense against an incoming attack. Uses parry or dodge to block, spending the attacker's turn without consuming the defender's action.

Instructions

Resolve one player defence against an incoming attack.

Enemy attacks resolve through this tool, so the player always rolls. Defending never consumes the defender's own actions, but it spends the attacking enemy's one action for its turn -- and when that exhausts the enemy's actions the turn advances itself: read next_actor and next_step from the result. An enemy whose turn is closed cannot attack again until the order reaches it in the next round; do not narrate an enemy attack outside its own turn.

Parry tests STR and needs a held object. Dodge tests DEX and is the only option against a ranged attack. A shield grants Advantage when parrying and breaks on a critical failure. A critical failure ignores armour.

Omit incoming_damage to use the named NPC's recorded damage.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
methodNododge
rangedNo
shieldNo
advantageNo
attacker_idNo
defender_idYes
disadvantageNo
incoming_damageNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/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 and delivers richly. It discloses action-economy effects (defender loses no action, enemy spends its action), automatic turn advancement, next_actor/next_step reading, shield-breaking on critical failure, critical-failure armour bypass, and the optional incoming_damage behavior. These are exactly the non-obvious behavioral traits an agent needs.

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 dense but every sentence earns its place: purpose, action economy, turn-advancement, defensive options, shield mechanics, and damage fallback. It is front-loaded with the core purpose and then structured into rules that directly affect how the agent should invoke and interpret the call.

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?

For a combat-resolution tool with no output schema and no annotations, the description covers side effects, turn state, defensive rules, and parameter fallback behavior. It even tells the agent to read next_actor and next_step from the result. This is sufficient for a competent agent to call the tool correctly without inventing assumptions.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must compensate. It does for method (parry vs dodge), ranged (dodge only), shield (advantage and break on critical failure), advantage, and incoming_damage (omit to use NPC recorded damage). However, it does not explicitly explain the disadvantage parameter or clarify how attacker_id relates to the recorded-damage fallback.

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 opening sentence states the exact operation: 'Resolve one player defence against an incoming attack.' This clearly distinguishes it from attack, movement, and turn-management siblings. It also adds a key scoping detail: enemy attacks resolve through this tool, so the player always rolls.

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

Usage Guidelines4/5

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

The description gives concrete when-to-use guidance: use it for incoming enemy attacks, with dodge mandatory against ranged and parry requiring a held object. It also warns against narrating enemy attacks outside their own turn ticks. It stops short of explicitly naming alternative sibling tools, so it misses the top bar for this dimension.

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