Loading ToolBench
MCP server for Heroic Labs Nakama — wraps the client (:7350) and console (:7351) APIs via a search+execute pattern plus high-value convenience tools.
Strong foundation with 14 well-named tools, comprehensive schemas using Zod, and tool annotations (readOnlyHint/destructiveHint). Descriptions are detailed and action-oriented. However, several tools lack output schema documentation, error messages could be more recovery-focused, and some parameter descriptions are verbose rather than concise. Naming follows verb_noun convention consistently. Most tools are single-responsibility, though nakama_execute_action is a generic gateway that could benefit from more specific convenience wrappers.
Establish a player session for the client API (:7350). Required before calling other client/player endpoints. Supports device, custom, or email auth. The session token is held in memory for subsequent calls.
Ban a player account via the console API.
Invoke a registered runtime RPC function by id over the client API. Pass payload as a JSON object or string; it is encoded as the gateway expects. Provide http_key to call an RPC without a player session; otherwise authenticate first with nakama_authenticate.
Delete a player account via the console API (irreversible).
Fetch a single player account (profile, wallet, devices, linked logins) by user ID via the console API.
Get Nakama server status (version, uptime, node info, runtime stats) via the console API.
Output schemas not documented. Tools return structured JSON but LLMs cannot plan downstream calls without knowing field names and types. E.g., nakama_search_actions returns {count, matches} but match structure is not formally specified.
Error messages lack recovery guidance. fail() returns raw HTTP status and body without actionable next steps. E.g., 'Request failed (HTTP 404)' should suggest 'User not found. Try nakama_console_list_accounts() to find the correct user_id.'
Destructive tools (ban_account, delete_account) lack confirmation/dry-run support. Agents can irreversibly delete accounts without a safety gate. No pattern:confirmation-request implementation.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | <=2025-11-25 | v2 |
List/search player accounts via the console API. Optional filter by user ID or username.
Execute any Nakama operation by its action_id (from nakama_search_actions). Provide path_params, query_params, and/or body as needed. Auth is handled automatically: console actions auto-login with configured admin credentials; client actions use the player session from nakama_authenticate; authenticate endpoints use the server key. For calling server RPCs prefer nakama_call_rpc (it encodes the payload correctly).
Probe connectivity and authentication status for both client and console API surfaces. Reports reachability, auth status, and configuration.
Search the Nakama API catalog (${counts.total} operations: ${counts.client} client, ${counts.console} console) by natural-language intent and get matching action IDs, HTTP method/path, summaries, and parameter schemas. Use this to discover the action_id you then pass to nakama_execute_action. Results include resolved request-body field schemas when available. Examples: 'list players', 'write storage object', 'leaderboard records', 'ban account', 'active matches'.
Send a notification to a player via the console API.
Unban a player account via the console API.
Write a leaderboard record for the authenticated player.
Write a storage object for the authenticated player (convenience wrapper around nakama_execute_action Nakama_WriteStorageObjects).
nakama_execute_action is a generic gateway tool that accepts any action_id. While powerful, it violates single-responsibility principle and forces LLMs to discover action IDs via search before executing. Consider pre-built convenience wrappers for common operations.
Parameter descriptions for nakama_call_rpc 'payload' are vague ('RPC payload (object or string)'). Should specify encoding format, size limits, and examples of valid payloads for common RPCs.