fivem-mcp-server

Overview Schema Source Related Servers Discussions Admin

Close the FiveM client

quit_game

Destructive

Closes the FiveM game gracefully by sending 'quit' to the client console, or force-kills the process tree when the game is frozen.

Instructions

Graceful path: prints 'quit' to the client console over devcon and waits for the game to close (nothing is typed into the window). force: true kills the FiveM process tree instead — use it only when the game is wedged.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "quit_game"
  }
}

Input Schema

Name	Required	Description	Default
`force`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.6.0Oct 17, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only say destructiveHint=true; the description adds how each path works — the graceful path prints 'quit' over devcon and waits for closure without typing into the window, while force kills the process tree. This mechanism-level detail goes well beyond the structured hints.

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 dense sentences, graceful path front-loaded before the force branch. Every clause earns its place with no redundancy.

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 one-param, no-output-schema tool, the description covers the critical decision (graceful vs. force) and the mechanics. It omits edge cases such as what happens if the graceful path times out or fails, which would matter for an agent deciding whether to escalate to force.

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?

Schema coverage is 0% and the single 'force' parameter has no schema description, so the description carries the burden — and it does, explaining that force:true kills the process tree and that the default is a graceful quit. Full parameter meaning is conveyed, though without naming acceptable values beyond boolean semantics.

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?

States a specific verb+resource ('quits the FiveM client') and immediately distinguishes the two shutdown paths (graceful console quit vs. force kill). No sibling tool does this, and the description makes that clear without opening the schema.

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?

Explicitly states when to use the force path ('only when the game is wedged') and implies the default graceful path otherwise. This is actionable when/when-not guidance rather than mere context.

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