Skip to main content
Glama
rbilleci

bsh-mcp

by rbilleci

attribute_test

Roll a d20 attribute test with declared stakes, applying advantage, disadvantage, threat, and doom to determine the outcome of a risky action in a Black Sword Hack campaign.

Instructions

Roll one d20 roll-under attribute test with declared stakes.

Call this whenever an action has a meaningful chance and consequence of failure. Do not call it for an ordinary active search that simply succeeds. Inside a fight, a declaration about the actor's own position or footing on their own turn -- circling behind, a trip, a climb -- rolls here.

Declare the stakes before rolling: stakes_success is what durably changes if the dice favour, stakes_failure what durably changes if they do not, in one sentence each. You already must know both to justify the roll. The server records your words verbatim, tags the branch the dice realize, and holds it as an unratified outcome until scene_commit. stakes_hidden is optional and never shown to players.

The tool applies Advantage, Disadvantage, conditions, Threat Level, and Doom. It decides dice and outcome. It does not decide the fictional cost.

attribute: STR, DEX, CON, INT, WIS, or CHA. opponent_level: the opposing creature's level, when one opposes the action. call_on_doom: true only when the player chooses to call on Doom. failure_mode: fail, success_at_cost, or gm_choice. Metadata for the narrator. category: optional structured tag for the kind of test — stealth, pickpocketing, eavesdropping, streetwise, or sorcery. Some backgrounds grant Advantage on a category; an unknown category is refused with the legal list. Pass sorcery (attribute INT) for a Forbidden-knowledge spell casting: a critical failure then rolls the Torn Veil table itself and applies its consequence, returned under torn_veil, exactly as a demonic invocation's Doom depletion rolls Demon's Revenge through use_ability. Do not roll Torn Veil yourself in fiction; it is not a separate tool call.

A test rolled by the active combatant on their own turn is that character's combat action and spends one action exactly as an attack would. The result's combat_action block reports the count, and the turn advances itself when the last action is spent. Stakes in combat may only promise what the failing character suffers or fails to do; never promise that an enemy attacks, because an enemy acts only on its own turn through combat_defend.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
reasonYes
categoryNo
advantageNo
attributeYes
call_on_doomNo
character_idYes
disadvantageNo
failure_modeNogm_choice
stakes_hiddenNo
opponent_levelNo
stakes_failureYes
stakes_successYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description carries the full disclosure burden, and it delivers: server verbatim recording, branch tagging, unratified outcomes until scene_commit, automatic application of Advantage/Disadvantage/conditions/Threat Level/Doom, Torn Veil behavior on sorcery critical failure, and combat action counting with turn advancement. It also states what the tool does not decide, the fictional cost, which is valuable boundary disclosure.

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 long but every sentence earns its place for a complex roll tool. It is front-loaded with the core purpose)Skip? Actually front-loaded: purpose, then usage, then stakes, then mechanics, then parameter notes, then combat caveats. The parameter list is easy to scan, and the prose paragraphs each cover one coherent behavioral topic. No filler or schema repetition.

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 annotations and output schema, this description is unusually complete: it explains when to roll, how to phrase stakes, how hidden stakes behave, what parameters mean, how special category handling works, the combat action economy, and what must never be promised in stakes. An agent has everything needed to select and invoke the tool correctly and to avoid forbidden patterns.

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, and it does for nearly every meaningful parameter: attribute values, stakes_success/stakes_failure semantics, stakes_hidden privacy, opponent_level meaning, call_on_doom condition, failure_mode options, and category behavior including the torn_veil_returned consequence. A few parameters like reason and character_id are not individually explained, but their purposes are largely self-evident from names and 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?

The first sentence names a specific operation: 'Roll one d20 roll-under attribute test with declared stakes.' It plainly identifies the resource (an attribute test) and the mechanic (d20 roll-under), and the surrounding text draws boundaries against siblings like group_test and combat_attack. An agent can tell this tool apart from the other roll-based siblings without opening their schemas.

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 gives an explicit trigger: 'Call this whenever an action has a meaningful chance and consequence of failure.' It also gives a concrete negative case ('Do not call it for an ordinary active search that simply succeeds'), a combat-use rule, and a direct routing instruction away from combat_defend for enemy actions. This is strong when-to-use and when-not-to-use guidance.

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