Loading ToolBench
A Tabletop RPG (TRPG) game server providing tools for character management, game mechanics (sanity checks, skill checks, attribute checks, damage calculations, dice rolling), scenario management, and Keeper (game master) assistance features.
This MCP server has significant quality gaps across naming, parameter documentation, and schema rigor. Tools have descriptions (good baseline compliance), but parameters lack type specifications in the visible schema, most descriptions are generic, and error handling is minimal. The codebase shows 20 tools with [McpServerTool] attributes and basic descriptions, but the underlying input schema definitions are not fully visible in the provided source. Parameter descriptions exist but are terse (1-3 words), and complex objects like 'PlayerCharacterRequest' lack documented structure. Output schemas are implicit (ResponseBase<T> wrappers) but not formally documented for downstream tool chaining. No evidence of enums for constrained inputs, pagination support, or recovery guidance in errors. The naming is mostly clear (verb-noun pattern: GetAllCharacters, CreateCharacter, etc.), but several tools expose low-level domain concepts without abstraction (e.g., 'UpdateCharacterAttributeAsync' with string attributeName and newValue, inviting type confusion). Error responses are basic (Success flag + Message) without classification (retryable vs. user-fixable). Security checks show service injection pattern (good), but no permission gates visible, no audit logging, and no rate-limiting evidence.
Perform an attribute check for a character.
Calculate damage for an attack.
Creates a new player character from a template ID.
Delete a player character by ID.
Generate NPC dialogue (KP assist)
Generate random event (KP assist)
Generate scene description (KP assist)
Retrieves a list of all player characters.
Parameter type information incomplete or missing. Tools like UpdateCharacterAttributeAsync accept 'attributeName' and 'newValue' as strings without enum constraints or validation hints. LLMs cannot determine valid values and risk passing arbitrary strings that fail at runtime.
Parameter descriptions are minimal (1-3 words: 'Character ID', 'Skill ID', 'Roll expression'). LLMs need context like 'The ID of the character performing the check' and whether ID is a username, integer ID, or UUID.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 40 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 39 | - | v1 |
Retrieves a list of all available TRPG scenarios for user selection.
Get available character templates for character creation.
Get a player character current status.
Get game progress suggestions (KP assist)
Fetches detailed information about a specific TRPG scenario based on the provided scenario ID.
Roll dice using standard notation.
Perform a sanity check on the system.
Perform a Saving Throw on the system.
Perform a skill check for a character.
Suggest checks and difficulties (KP assist)
Update a player character's information.
Update a player character's attribute.
No evidence of output schema documentation. ResponseBase<T> wrapper structure is implicit; LLMs cannot determine what fields to expect or how to chain outputs to downstream tool inputs. E.g., does GetCharacterByIdAsync return an ID that CreateCharacterFromTemplateIdAsync will accept?
Error responses are generic: 'Success' flag + 'Message'. No classification of error type (retryable, user-fixable, fatal), no recovery guidance (e.g., 'Character not found. Try GetAllCharactersAsync() to list valid IDs').
Destructive tools (DeleteCharacterAsync) lack confirmation or dry-run support. Agents can permanently delete characters without safeguards. No evidence of 'confirm_before_execute' pattern or audit logging.
Complex input types (PlayerCharacterRequest object in UpdateCharacterAsync) have no documented schema. LLMs cannot infer required fields, types, or constraints for nested objects. Object descriptions must state what fields are required.
No pagination support visible. List tools (GetAllCharactersAsync, GetAllScenariosAsync) may return unbounded results, risking context window exhaustion.
Tool names contain domain jargon without abstraction (SanityCheck, SavingThrowAsync, CalculateDamageAsync). Users don't say 'do a sanity check', they say 'is my character going insane?' Naming should align with user intent, not game mechanics terminology.
Tool descriptions for KP assistance tools (GenerateSceneDescriptionAsync, GenerateNpcDialogueAsync, etc.) are generic and under 50 chars. Missing context about when to use each, what triggers generation, and whether they require prior scene setup.
No permission gates or scope declarations visible. No evidence of 'read:character', 'write:character', 'delete:character' scopes. Tools accept any input without permission checks.