Skip to main content
Glama

Hit the boss

smack_boss

Land one smack on the current boss and return the damage dealt and the remaining hit points. One swing per call — call it repeatedly to keep hitting.

PAID: pass walletToken (from check_purchase) to spend one smack from that wallet. Paid hits are the real thing — they can crit, they take the momentum multiplier, and only a paid hit can land the killing blow and put a name on the grave forever.

FREE: pass visitorId instead and it costs nothing. Three per visitorId — the count is held for about thirty days — then FREE_EXHAUSTED, which is the limit working and not a fault. It is NOT an hourly allowance: waiting does not give them back. A free smack can never land the killing blow and free damage is capped per boss, so the engraving stays with somebody who paid for it.

Pass one or the other. If both arrive, the wallet is spent.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoOptional display name for the public hit feed, the leaderboard, and — on a killing blow — the grave. Visible to everyone, and permanent once engraved.
visitorIdNoFor a free smack. A stable identifier you generate once and reuse so the free allowance is tracked. Any opaque string; a UUID is ideal. Nothing personal in it.
walletTokenNoA walletToken from check_purchase. Spends one paid smack. Takes precedence over visitorId.

TDQS

A4.8/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 it delivers: it discloses crits, momentum multiplier, paid-only killing blows, free-hit limits, the ~30-day window, FREE_EXHAUSTED semantics, per-boss free damage cap, and the wallet-spending tie-breaker. This is exceptionally transparent about side effects and constraints.

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 contributes: the core action is front-loaded, followed by clearly labeled PAID and FREE sections. The formatting makes the two modes scannable, and no sentence is redundant or filler.

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 tool with no output schema and no annotations, the description covers the essential call semantics, return values, error condition (FREE_EXHAUSTED), parameter relationships, and edge cases like both parameters being supplied. A caller has enough information to invoke it correctly in either free or paid mode.

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?

Even though schema description coverage is 100%, the tool description adds meaning beyond the schema: walletToken is tied to check_purchase and takes precedence, visitorId is a stable reusable identifier tracked for free allowance, and name is public and permanent when engraved. This substantially enriches the raw parameter definitions.

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 a specific verb ('Land one smack'), the resource ('current boss'), and the return values ('damage dealt' and 'remaining hit points'). It also clarifies that each call is exactly one swing, distinguishing it from any batch or multi-hit behavior and from read-only sibling tools like get_boss.

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 clearly separates paid vs. free usage, explains the implications of each mode, and defines the precedence rule when both parameters are passed. It does not explicitly contrast this tool against sibling alternatives like get_boss or check_purchase, but it does tell the caller how to obtain and spend walletToken.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool addresses a distinct resource or action: checkout flow tools, boss state tools, leaderboard/graveyard views, wallet balance, and the pixel. No two tools could plausibly be confused, and smack_boss's paid/free modes are clearly documented within a single tool.

Naming Consistency5/5

All tool names are snake_case and follow a clear verb_noun pattern: get_* for state queries, create_checkout/check_purchase for the payment flow, list_packs for catalog, and smack_boss for the action. The naming is uniform and predictable.

Tool Count5/5

Nine tools cover the full surface of this server: commerce (list/create/check/wallet), combat (smack/get boss), and meta views (leaderboard/graveyard/pixel). Nothing feels redundant, and the count is appropriate for a focused game/payment server.

Completeness5/5

The domain is fully covered: users can discover packs, pay, verify payment, spend smacks, observe boss state, and view historical results. The intentional omission of a pixel purchase tool is documented as a design decision, and all core workflows have no dead ends.