Loading ToolBench
MCP server providing tools to interact with RimWorld game through a bridge interface, offering diagnostics, profiling, scripting, and game state management capabilities
RimBridgeServer demonstrates moderate definition quality with consistent naming conventions and complete input schemas. All 12 tools follow verb_noun naming patterns (get_, list_, wait_for_). However, several critical gaps reduce the score: (1) Most parameter descriptions are present but brief (typically 15-50 chars), below the 72-char baseline for A+ tools. (2) No output schemas are documented, callers cannot predict return structure. (3) Descriptions vary widely in quality; several read like API docs rather than LLM-optimized guidance. (4) No error handling guidance visible in descriptions; agents given no recovery paths. (5) Tool definitions are inferred from method signatures via reflection (LegacyToolExecution.cs), not explicitly registered with full schemas, this violates the requirement that schemas be directly visible and caps inferred tools at 50. The tools are functionally complete and well-named, but lack the documentation rigor expected for production agent integration.
Get the current bridge and RimWorld state snapshot without mutating game state
Get one registered bridge capability descriptor by capability id or alias
Get the latest retained journal snapshot for a specific operation id, including any bounded retained result payload
List registered bridge capabilities so an agent can discover the live bridge surface instead of relying on hardcoded tool knowledge
List recent captured RimWorld and bridge log entries from the in-memory log journal, including operation correlation when available
List recent bridge operation lifecycle events from the in-memory event journal
No output schemas documented for any tool. Agents cannot predict return structures, forcing them to make assumptions about field names and types. This breaks tool chaining and forces discovery detours.
Parameters with constrained value sets lack enum constraints in schemas. Examples: 'minimumLevel' (info|warning|error|fatal), 'eventType' (operation.failed, etc.), 'readiness' (gameData|mapData|currentMap|playable|visual). Agents must infer valid values from description text, inviting hallucinated inputs.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
List recent bridge operations from the in-memory operation journal, optionally expanding retained result payloads
Connectivity test. Returns 'pong'.
Wait until RimWorld reaches the requested loaded-game readiness level
Wait until RimWorld reports no long events in progress
Wait for an operation in the journal to reach a terminal status
Get basic information about the current RimWorld game
Tool definitions are inferred via reflection in LegacyToolExecution.cs rather than explicitly registered with full, directly-visible schemas. The code uses ToolAttribute metadata and method signatures to construct tool definitions at runtime. This affects all 12 tools.
No error handling guidance in tool descriptions. Agents are not told what errors can occur, whether they are retryable, or what recovery steps to take. E.g., 'wait_for_operation' does not explain what happens if the operation never reaches terminal status.
Parameter descriptions are too brief (15-50 chars on average vs. 72-char baseline). Many read like minimal API docs rather than LLM-optimized guidance. Example: 'Operation id returned in tool metadata' (41 chars) does not explain how to obtain an operationId or where to find one initially.
Redundant/aliased parameters create ambiguity. 'wait_for_game_loaded' accepts both 'readiness' and 'targetReadiness', and both 'waitForVisualReady' (boolean) which overrides readiness. This forces agents to reason about which parameter to use and risks misconfiguration.