MCP server for FiveM/RedM server administration through txAdmin
Strong tool definitions with excellent naming, comprehensive descriptions, and well-structured schemas. All 15 tools follow verb_noun convention (txadmin_*). Descriptions are detailed (100-250 chars typical), explaining WHAT, WHEN, and WHY. Input schemas use proper JSON Schema with types, enums, and constraints. Parameters have descriptions. Risk annotations (READ_ONLY, WRITE, DESTRUCTIVE, REVERSIBLE) are present and valuable. Key gaps: output schemas are not documented in the source code (only inferred from descriptions), error handling guidance is minimal, and some parameter relationships (e.g., license vs netid+mutex in txadmin_player_info) could be clearer.
Broadcast an announcement to every player currently on the server. Note this reaches beyond the game: if the panel has a Discord bot configured, txAdmin also posts the announcement to the configured Discord channel.
Execute an arbitrary command in the FXServer console and return its output. This is unrestricted server console access — equivalent to root on the game server — and can stop resources, change convars, or run anything a server owner could type. Prefer a specific tool when one exists.
Search the txAdmin player database by name, admin notes, or identifier (license, discord, steam). Covers offline players too. For the currently-connected list use txadmin_online_players.
Search the moderation log — every ban and warning issued on this server, newest first. Filter by type, by the admin who issued it, or by free text over the reason. Use this for questions like "who banned whom last night" or "how many bans did X issue".
List the players connected to the server right now, with their server IDs (netid) and licenses. This is the only source of the live playerlist — txadmin_find_player searches the historical player database instead, which includes people who are offline.
Output schemas not documented. Tool descriptions infer return structure (e.g., 'List the players...', 'Full profile for one player...') but no explicit schema definitions visible in source. LLMs cannot reliably extract fields or plan downstream tool chains without documented output types.
Parameter mutual exclusivity not documented. txadmin_player_info accepts 'license' OR ('netid' + 'mutex'), but descriptions do not state this constraint. LLMs may pass all three or omit required pairs, causing silent failures.
Error handling guidance absent. Tools return errors but descriptions do not explain recovery steps (e.g., 'If player not found, try txadmin_find_player'). Agents cannot self-correct without explicit guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
Reversible moderation actions on one player: send them a direct message, issue a warning, save an admin note, or set their whitelist state. Kicking and banning are deliberately not here — they live in txadmin_player_punish, which requires admin mode.
List recent player disconnections: who dropped, when, and why (timeout, crash, ragequit, etc.). Useful for diagnosing server stability or player experience issues.
Full profile for one player: identifiers, playtime, whitelist state, admin notes, and their complete ban and warning history. Identify the player by license (works offline) or by netid plus mutex (online only — get both from txadmin_online_players).
Kick or ban a player. Banning requires an explicit duration — there is no default, so a permanent ban is never issued by omission. Durations use txAdmin syntax: "2 hours", "7 days", "permanent". Bans are recorded in txAdmin history and can be undone with txadmin_revoke_action.
Read the FXServer console output: the last lines logged by the server and resources. Useful for debugging resource crashes, checking command output, or seeing what happened during a restart.
Reload a server resource: ensure (start if stopped), restart, or refresh (rescan the resources folder so newly added ones are discovered). These are the safe iteration verbs for developing a resource. Stopping or starting a resource outright is in txadmin_server_control, because stopping a framework core takes the server down.
Revoke a ban or warning by its action ID (the ID column from txadmin_history_search or txadmin_player_info, e.g. "BAN-1A2B"). Revoking a ban lets the player rejoin immediately.
Start, stop or restart the FXServer process, stop or start an individual resource, or kick every player at once. Every action here disconnects players: restarting or stopping the server drops everyone, and stopping a framework resource can break the server without stopping it. For reloading a resource during development prefer txadmin_resource_control, which is recoverable.
Current FiveM/RedM server status: whether FXServer is running, the scheduled restart, plus txAdmin and FXServer versions and host CPU/memory load. Start here when asked whether the server is up or how it is holding up.
Report which txAdmin account this MCP server is authenticated as, what permissions it holds, and which txadmin_* tools are active as a result. Use this first when another tool fails unexpectedly or seems to be missing — it turns a permission problem into a one-call diagnosis.
Destructive operations lack confirmation step. txadmin_player_punish (ban/kick), txadmin_server_control (stop/restart), and txadmin_console_command are irreversible but have no dry-run or confirmation mechanism. Agents can cause outages without safeguards.
Permission model not exposed to LLM. txadmin_whoami reports permissions, but tool descriptions do not state which permissions each tool requires. Agents cannot predict permission failures or explain why a tool is unavailable.