What can you do with this server?

This server lets you operate a FiveM game server through an MCP interface by connecting to the txAdmin live console and public FXServer endpoints. * Execute any console command — run commands like status, refresh, ensure/restart/stop , say, kick, set/setr, svgm, etc., and capture the console output. * Read recent console lines — inspect the last captured console output, optionally filtered by a regex. * Check server status — see if the server is online, hostname, player count/slots, game build, and resource count. * List connected players — get online players with id, name, ping, and identifiers. * Control the server process — start, stop, or restart the entire FXServer via txAdmin (drops all players). * Additional modes — run via MCP stdio, streamable HTTP, or direct --exec commands; includes setup, doctor, and registration tools for MCP clients.

Which integrations are available for this server?

Provides tools to operate a FiveM server by executing console commands, reading console output, checking server status, listing online players, and controlling the server process (start/stop/restart).

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@yafmcp restart resource esx_ambulancejob" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

yafmcp

by ggfto

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

yafmcp

Servidor MCP para operar um servidor FiveM: o agente manda um comando, o comando entra no console do FXServer e a saída do console volta como resposta.

Funciona com qualquer cliente MCP — Claude Code, Hermes, Codex, OpenCode, ou o que vier depois — porque é MCP por stdio puro (e HTTP streamable quando você quiser).

Como ele fala com o servidor

Pelo live console do txAdmin (v7/v8): login por senha em /auth/password, sessão guardada em cookie, e o comando vai pelo socket.io na sala liveconsole, exatamente como a aba Live Console do painel faz. A saída é capturada do stream consoleData, limpa de ANSI e devolvida.

Não precisa de rcon_password, não precisa reiniciar o servidor, não precisa de acesso ao container.

O socket.io do txAdmin só responde por long-polling: o servidor HTTP que escuta na porta do painel roteia /socket.io para engine.handleRequest, e não trata upgrade de websocket. O cliente aqui já vem fixado em polling por causa disso.

Related MCP server: factorio-mcp

Instalação

Pelo npm, sem clonar nada:

npx -y yafmcp --setup     # grava as credenciais do txAdmin
npx -y yafmcp --doctor    # confere a conexão

Ou do repositório, para mexer no código:

git clone https://github.com/ggfto/yafmcp.git
cd yafmcp
npm install
npm run setup     # pergunta URL do txAdmin, usuário e senha; grava 600 em ~/.config/yafmcp/config.json
npm run doctor    # loga, conecta no console e roda um "version"

Requer Node 18+ (testado no 22) e um admin do txAdmin com permissão de console (console.view + console.write; o master já tem).

Configuração

~/.config/yafmcp/config.json (ou variáveis de ambiente, que têm precedência):

Campo	Env	Padrão
`txadminUrl`	`FIVEM_TXADMIN_URL`	`http://127.0.0.1:40120`
`serverUrl`	`FIVEM_SERVER_URL`	`http://127.0.0.1:30120`
`username`	`FIVEM_TXADMIN_USER`	—
`password`	`FIVEM_TXADMIN_PASS`	—
`quietMs`	`FIVEM_QUIET_MS`	`900` — silêncio no console que fecha a captura
`timeoutMs`	`FIVEM_TIMEOUT_MS`	`10000` — teto da captura
`scrollback`	—	`2000` linhas guardadas em memória

Registrando nos agentes

node src/register.js          # registra em todos os clientes presentes na máquina
node src/register.js --print  # só imprime os trechos, você cola onde quiser

Ou na mão:

Em todos os exemplos abaixo, npx -y yafmcp e node /caminho/yafmcp/src/index.js são intercambiáveis — o primeiro dispensa clone, o segundo usa a sua cópia local.

# Claude Code
claude mcp add --scope user fivem -- npx -y yafmcp

# Codex — ~/.codex/config.toml
[mcp_servers.fivem]
command = "node"
args = ["/caminho/yafmcp/src/index.js"]

// OpenCode — ~/.config/opencode/opencode.json
{ "mcp": { "fivem": { "type": "local", "command": ["node", "/caminho/yafmcp/src/index.js"], "enabled": true } } }

# Hermes — ~/.hermes/config.yaml
mcp_servers:
  fivem:
    command: node
    args:
      - /caminho/yafmcp/src/index.js
    enabled: true

Ferramentas

Ferramenta	O que faz
`fivem_command`	Executa qualquer comando no console e devolve a saída. Para resource, `ensure <resource>` é o padrão (inicia ou reinicia); `refresh` antes se o resource é novo no disco. `timeoutMs`, `quietMs` e `timestamps` são opcionais.
`fivem_console`	Últimas linhas do console capturadas pela sessão, com `filter` por regex.
`fivem_status`	No ar?, hostname, jogadores, game build, nº de resources.
`fivem_players`	Jogadores online com id, ping e identificadores.
`fivem_server_control`	`start` / `stop` / `restart` do processo do servidor (derruba quem estiver online).

> recarrega o resource mri_Qadmin
  fivem_command("ensure mri_Qadmin")
  $ ensure mri_Qadmin
  [           resources] Stopping resource mri_Qadmin
  [    c-scripting-core] Creating script environments for mri_Qadmin
  [           resources] Started resource mri_Qadmin

Outros modos

node src/index.js                   # MCP stdio (o normal)
node src/index.js --http --port 8765  # MCP streamable HTTP em /mcp, para clientes que falam por URL
node src/index.js --exec "refresh"  # um comando direto pelo terminal, sem agente no meio
node src/index.js --doctor          # diagnóstico da conexão

Agente dedicado no Clink (opcional)

Quem usa o Clink pode criar um tipo de agente FiveM Ops — mission + rule sheet — que nasce sabendo operar o servidor:

node tools/clink-agent.js
clink new "FiveM Ops" "FiveM"

FIVEM_DEFAULT_PATH escolhe a pasta em que esse agente abre (padrão ~/fx-panel).

Segurança

Nenhum comando é bloqueado: quem tem o MCP tem o console do servidor inteiro. A senha fica só no arquivo de config (modo 600) ou no ambiente — nunca no repositório, nunca no prompt do agente. Se isso for demais para o seu caso, dê ao MCP um admin do txAdmin com permissões reduzidas: a checagem de permissão é feita pelo próprio txAdmin.

Publicando o pacote

.github/workflows/publish.yml roda ao publicar uma release no GitHub (ou pela aba Actions) e manda o mesmo código para os dois registries:

npmjs.com como yafmcp, público — precisa do segredo NPM_TOKEN (token de automação da sua conta npm) em Settings → Secrets → Actions.
GitHub Packages como @<owner>/yafmcp — usa o GITHUB_TOKEN do próprio job, sem segredo nenhum.

Antes de publicar, suba a versão (npm version patch|minor|major), empurre a tag e crie a release. .github/workflows/ci.yml roda os testes em cada push, no Node 20 e 22.

Licença

MIT.

Available Tools

5 tools

fivem_commandExecutar comando no console do FiveMB

Executa um comando no console do FXServer e devolve o que o console imprimiu. Aceita qualquer comando do servidor (status, refresh, ensure/restart/stop , say, kick, set/setr , svgm, etc.). A captura fecha quando o console fica quieto; comandos que demoram para responder pedem timeoutMs maior.

ParametersJSON Schema

Name	Required	Description
`command`	Yes	Comando exatamente como se digitasse no console
`quietMs`	No	Silêncio no console que encerra a captura (padrão 900)
`timeoutMs`	No	Tempo máximo de captura da saída (padrão 10000)
`timestamps`	No	Prefixar cada bloco com o horário

TDQS

B3.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses the return behavior (console output), the capture ending condition (quiet console), and the timeout relationship. However, it does not warn about side effects or hazards of destructive commands (stop, kick, restart) despite accepting any server command.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose and behavior. The list of command examples is somewhat long, but it earns its place by clarifying the scope of accepted commands. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without annotations or output schema, the description explains return behavior, capture timing, and parameter tuning. It omits error handling, side-effect warnings, and output format details, which are relevant for arbitrary command execution. Adequate but not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds the relationship between slow commands and timeoutMs, but otherwise the schema already defines all parameters; the description adds minimal extra meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clear verb+resource: 'Executa um comando no console do FXServer e devolve o que o console imprimiu', with examples of accepted commands. The purpose is specific, but it does not explicitly differentiate from sibling tools like fivem_status or fivem_players; distinction is only implicit in 'any server command'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs. alternatives. It provides parameter tuning advice (timeoutMs for slow commands) but does not mention sibling tools, when to prefer one over another, or when not to use this tool.

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

fivem_consoleLer o console do FiveMA

Últimas linhas do console do servidor capturadas por esta sessão, com filtro opcional por regex. Use depois de um comando que continua imprimindo, ou para investigar erros.

ParametersJSON Schema

Name	Required	Description	Default
`lines`	No	Quantas linhas (padrão 80)
`filter`	No	Regex case-insensitive para filtrar as linhas

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral disclosure burden. It adds relevant context by saying the lines are 'capturadas por esta sessão' and that the tool is for post-command output or error investigation, but it does not disclose whether reading consumes or clears the buffer, nor how far back the captured lines go.

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?

Two sentences deliver purpose, optional filter, and usage guidance with no filler. It is front-loaded with the core behavior ('Últimas linhas do console...') before the usage note.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a low-complexity read-only tool, the description adequately covers what it returns, the optional filter, and the intended usage scenarios. It lacks an explicit note about output formatting or persistence, but the schema and session qualifier make the tool actionable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and both parameters are already documented with descriptions. The tool description adds only that the regex filter is optional, which is marginal value beyond what the schema already provides.

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 description clearly states that the tool returns the latest server console lines captured in the current session, with an optional regex filter. The resource ('console do servidor') and the session-scope qualifier distinguish it from sibling tools like fivem_status and fivem_players. The title adds the explicit verb 'Ler'.

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 provides explicit usage guidance: use it after a command that keeps printing, or to investigate errors. It does not, however, name alternatives or state when not to use the tool, so it stops short of full routing guidance.

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

fivem_playersJogadores conectadosA

Lista os jogadores online com id, nome, ping e identificadores.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the behavioral burden. It does communicate a read-only listing behavior and the output fields, but it does not mention details such as ordering, identifier format, error behavior, or whether the result is a flat list or nested structure.

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 a single concise sentence with no filler. The key verb, resource, and output fields are all front-loaded and every word contributes value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read-only listing tool, the description provides the essential information: what it lists and which fields are included. It is adequate, though the absence of an output schema and any detail on identifiers or edge cases leaves minor room for ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and the schema is complete with an empty properties object. There is no parameter information for the description to add, so the baseline of 4 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Lista') and a clear resource ('jogadores online'), and enumerates the returned fields (id, nome, ping, identificadores). It is clear and unambiguous, though it does not explicitly differentiate itself from sibling tools like fivem_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given about when to use this tool versus siblings such as fivem_status or fivem_command. There are no exclusions, alternative suggestions, or contextual conditions provided.

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

fivem_server_controlControlar o processo do servidorA

start, stop ou restart do FXServer pelo txAdmin. Derruba todo mundo que estiver online — para recarregar um resource use fivem_command com "restart ".

ParametersJSON Schema

Name	Required	Description	Default
`action`	Yes	Ação no processo do servidor

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Since no annotations are provided, the description carries the full burden. It explicitly warns that the action drops all online players, which is crucial for a destructive operation. It implies restart involves stopping and starting, which is understood. It doesn't mention permission requirements, but the explicit warning and the action types are sufficient for basic transparency.

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 a single, well-structured sentence with no wasted words. The core action is front-loaded, and the critical warning and alternative routing are provided efficiently. Every sentence earns its place.

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 simple tool with one enum parameter and no output schema, the description is complete: it covers the purpose, usage, and behavioral impact. The warning about disconnecting players is essential context, and the routing to fivem_command addresses the most common alternative. Nothing critical is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already fully documents the 'action' parameter with an enum and a description, so baseline is 3. The description adds context by implying the effects of each action (e.g., restart drops players), which adds value. Since there is only one parameter and the schema is clear, the description's extra context justifies a 4.

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 description clearly states the tool controls the FXServer process (start, stop, restart) and explicitly distinguishes it from fivem_command for resource reloads. The verb and resource are specific, and the warning about disconnecting players adds clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states when to use this tool (for process control) and when not to (for resource reloads, use fivem_command with 'restart <resource>'). This clearly routes the agent to the correct sibling tool, leaving no ambiguity.

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

fivem_statusStatus do servidor FiveMA

Estado do servidor: se está no ar, hostname, jogadores online, slots, game build e quantidade de resources. Lê os endpoints públicos do próprio FXServer.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations present, the description carries the behavioral burden. It explicitly says the tool only reads public endpoints of the FXServer, which conveys a read-only, unauthenticated operation and differentiates it from control/command siblings. It does not discuss error behavior when the server is offline, but for a zero-parameter status check this is a minor gap.

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?

Two short sentences, front-loaded with the returned fields and ending with the data source. Every word contributes; no fluff or repetition.

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 parameterless status endpoint, the description lists all relevant output categories and the data source. There is no output schema, but the enumerated fields effectively tell the agent what to expect. No additional context seems necessary for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters and schema coverage is trivially 100%, so there is no parameter documentation burden. The baseline of 4 applies because the description is not required to explain any inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool returns server status (up/down), hostname, players, slots, game build, and resource count, using the verb 'Lê' reading public FXServer endpoints. It is clear about the resource, though it does not explicitly contrast itself with sibling tools such as fivem_players or fivem_server_control.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this is the tool to call for a read-only health overview of the FiveM server, and the listed fields suggest it covers player counts too. However, it never says when to prefer it over fivem_players or fivem_server_control, or when not to use it.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv1.0.0Sep 15, 2026
- First observedfivem_command
- First observedfivem_console
- First observedfivem_players
- First observedfivem_server_control
- First observedfivem_status

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.8/5.0

Scored 2026-09-15 04:20 across 5 tools

Disambiguation4/5

Each tool targets a distinct concern: command execution, console inspection, server status, player listing, and server lifecycle control. The only slight overlap is between fivem_command and fivem_server_control, but the description explicitly clarifies when to use each.

Naming Consistency4/5

All tools share the fivem_ prefix and use a noun-based naming pattern (command, console, status, players, server_control). The pattern is consistent, though fivem_server_control is a compound noun while the others are single nouns.

Tool Count5/5

Five tools is a well-scoped set for a FiveM server management MCP. Each tool covers a distinct operational need without redundancy or bloat.

Completeness4/5

The set covers the core server management workflows: executing commands, reading console output, checking status, listing players, and controlling the server process. Minor gaps exist (e.g., no direct resource listing or player kick tool), but these can be accomplished via fivem_command.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

mcp A
com.fadehost
Manage FadeHost game servers, Discord bots and VPS: console, stats, backups, logs, lifecycle.
Games & Gamification Virtualization
251
termalin-web A
in.termal
Run commands and read/write files on your servers over Termalin's keyless tunnels (hosted MCP).
Shell Access File Systems
81
sachicali-discordmcp-suiteOAuth
ai.smithery
Control your Discord community: send/read messages, manage channels and forums, and handle webhook…
Communication Social Media
2
Tacyon MCOAuth
io.tacyon
Create, configure, manage Minecraft servers — plugins, files, console, modpacks, backups, metrics.
Games & Gamification Shell Access File Systems
2

Related MCP Servers

mc-rcon-mcp
Games & Gamification Command Line
pedxyuyuko
A
license
A
quality
D
maintenance
Enables Minecraft server management via RCON: execute commands, list players, get server info, manage whitelist and operators.
Updated 7 months ago (2026-02-21 22:34 UTC)
9
1
MIT
factorio-mcp
Games & Gamification Command Line
phiresky
F
license
A
quality
D
maintenance
Enables control and inspection of a Factorio 2.0 server via RCON, with tools for administration, player management, game state queries, and Lua execution.
Updated 3 months ago (2026-06-30 15:08 UTC)
19
-
pebblehost-mcp
bop-del
A
license
Not graded
quality
D
maintenance
Enables natural language management of Pebblehost Minecraft servers, including server status, control, console commands, file management, and backups.
Updated 7 months ago (2026-02-15 16:27 UTC)
MIT
txadmin-mcp
Games & Gamification
SaxxSaxx
A
license
Not graded
quality
A
maintenance
Enables AI assistants to read and administer FiveM/RedM game servers via txAdmin, supporting queries about server status, players, bans, and actions like announcements, resource control, and bans.
Updated 2 months ago (2026-07-30 21:10 UTC)
6 npm
MIT