FiveM MCP

by 999luan

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation3/5
The fs.* tools are clearly distinct, but fivem.resource_inspect and fivem.resource_audit both analyze resources, and fivem.ui_add and fivem.ui_scaffold both deal with UI scaffolding, creating potential confusion.
Naming Consistency3/5
All tools use snake_case, but the word order is inconsistent: fs.* tools use verb_noun (read_text, write_text), while fivem.* tools use noun_verb (resource_create, ui_add). The prefix grouping helps, but the mixed conventions are noticeable.
Tool Count5/5
11 tools is well within the ideal 3-15 range. Each tool serves a distinct purpose in the FiveM resource development workflow, from file operations to resource creation and analysis.
Completeness4/5
The set provides good lifecycle coverage: file operations, resource creation, inspection, UI management, framework detection, and auditing. Minor gaps like file deletion or resource removal are not critical for the core workflow.
Average 3.2/5 across 11 of 11 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden for behavioral disclosure. It mentions 'garante' and 'pode criar' but does not disclose that it writes to the fxmanifest, creates directories, or that createFiles defaults to true, meaning files will be created unless otherwise specified. This lack of side-effect transparency is risky for a multi-parameter tool with potential file mutations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no obvious fluff, but it is under-specified rather than concise. The structure is acceptable, but it says almost nothing, so it does not earn its place as a useful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, and no annotations, this description is critically incomplete. It explains none of the parameters, does not mention return values or side effects, and gives no indication of behavior beyond the most basic action. For a tool that modifies files and scaffolds a UI, this is severely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 7 parameters, and the description references none of them by name or meaning. With schema description coverage at 0%, the description completely fails to explain what resourceDir, uiPage, htmlDir, uiTheme, uiVariant, createFiles, or title represent. It adds zero value beyond the raw schema.
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 it ensures ui_page and files in fxmanifest and can create the html folder with functional scaffold. This clearly indicates the tool adds NUI support to a resource, and the mention of 'fxmanifest' helps distinguish it from sibling fivem.ui_scaffold. However, it doesn't fully elaborate on the tool's scope or explicitly differentiate itself from other similar tools.
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 provided on when to use this tool versus siblings like fivem.ui_scaffold. It implies a general use case for adding NUI to a resource, but there are no prerequisites, exclusions, or alternative recommendations, making it hard for an agent to know when this is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns data, implying a read-only operation, but it does not disclose what happens if fxmanifest.lua is missing, whether the path must be absolute, or if any other side effects occur. The description is minimal and lacks detail about failure modes or constraints.
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?
The description is a single, concise sentence that is front-loaded with the primary action. It is efficient and does not waste words. While very short, it earns a 4 for being appropriately sized for the tool's simplicity, though it could benefit from a bit more detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given its simplicity (one parameter, no output schema, no annotations), the description is incomplete. It fails to explain the parameter semantics, usage context, or edge cases. The lack of parameter documentation and any behavioral detail makes it inadequate for an agent to reliably invoke the tool, especially with sibling tools present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no explanation of the resourceDir parameter. It is unclear whether resourceDir expects an absolute path, a relative path, or a resource name. The description does not compensate for the missing schema documentation, leaving the parameter meaning ambiguous.
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 clearly states what the tool does: analyzes fxmanifest.lua and returns client scripts, server scripts, and ui_page. It is specific about the verb and resource, and it distinguishes itself from sibling tools like fs.list or fivem.resource_audit by specifying the output types. However, it doesn't explicitly contrast with fivem.resource_audit, which may have overlapping capabilities.
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 usage is implied: use this tool when you need to inspect a FiveM resource's scripts and UI page by analyzing its fxmanifest.lua. There is no explicit guidance on when not to use it or alternatives, but for a simple inspection tool the context is fairly clear. No prerequisites or error conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It mentions 'sobrescreve' (overwrites) but gives no detail on what gets overwritten, side effects, or safety. It also omits the 'dashboard' variant that appears in the schema, which could mislead.
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?
The description is a single, efficient sentence with no fluff, front-loading the main action. However, it is so brief that it sacrifices essential information, making it minimally adequate in structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, no output schema, and no annotations, the description is too sparse. It fails to explain the variants, overwrite behavior, or use cases, leaving the agent without enough context to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It only vaguely refers to 'variantes' without connecting to uiVariant, and ignores resourceDir, overwrite, uiPage, htmlDir, uiTheme, and title. No added meaning beyond the schema.
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 uses a specific verb 'Gera ou sobrescreve' (generates or overwrites) and identifies the resource 'bundle de UI' with variants, clearly stating the tool's function. It distinguishes from siblings like fivem.ui_add by focusing on whole-bundle generation/overwrite rather than adding a single page.
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 explicit guidance on when to use this tool versus alternatives like fivem.ui_add or fivem.resource_create. The description implies usage for scaffolding UI bundles but does not state when this is preferred over other tools or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits, but it only states the basic operation. It doesn't mention important details such as the behavior on invalid line ranges, whether the file must exist, or how expectedSha256 prevents conflicts. This is a significant gap for a mutation tool.
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?
The description is two short sentences, efficiently front-loaded with the core action. It is concise and readable, though the second sentence's 'resources' reference is somewhat vague. Still, it is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has multiple parameters, a dryRun flag, and an integrity check, yet the description provides no context about usage patterns, expected return behavior, or failure modes. Sibling tools are not referenced, and no annotations or output schema exist, making this description insufficient for an agent to use the tool safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description only partially compensates by mentioning 'por intervalo de linhas,' which relates to startLine/endLine. It does not explain the edits array structure, newText semantics, or optional dryRun/expectedSha256 parameters, so it fails to add meaningful parameter understanding.
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 it applies changes by line range, which clearly indicates a targeted file-editing operation. It distinguishes itself from siblings like fs.write_text through the 'intervalo de linhas' (line range) focus, though it could be more explicit about editing a file's content.
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 phrase 'ideal para alterações mais assertivas em resources' implies this is preferred for precise, targeted changes, but it does not give explicit when-to-use or exclusions relative to siblings like fs.write_text or fs.read_text. The guidance is contextual but not actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 basic read operation and return values, but omits critical behaviors such as error handling for missing files, truncation semantics of maxBytes, encoding handling, and whether it rejects binary files.
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 sentence, front-loaded with the verb, and contains no filler. It efficiently communicates the core function in one line.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic return values but lacks essential context for a tool with maxBytes: what happens when the file exceeds maxBytes, error behavior, file encoding, and return value structure. Since there is no output schema, the description needs to fill these gaps but does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters. filePath is self-explanatory from context, but maxBytes has no meaning in the description—its default, maximum, and purpose are undocumented beyond the bare schema.
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 a specific verb ('Lê' = reads), resource ('arquivo de texto' = text file), and return values (content, size, SHA256 hash). This distinguishes it from sibling tools like fs.write_text and fs.list.
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 provided on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or compare with sibling tools like fs.edit_lines or fs.write_text.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose side effects. It mentions creating files but omits key behaviors like overwrite semantics, directory requirements, and whether existing files are modified. This is insufficient for a mutation tool.
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?
The description is a single concise sentence that front-loads the action ('Cria') and lists key components without fluff. Every word is useful, though it is brief for a tool with 8 parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no output schema, and no annotations, this description is far from complete. It omits return values, side effects, parameter semantics, and any practical usage context, leaving the agent with significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description only vaguely hints at optional NUI scaffolding. It does not explain parameters like framework, uiTheme, uiVariant, overwrite, resourcesDir, or title. The description adds minimal value beyond the raw schema.
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 it creates a base FiveM resource in Lua with fxmanifest, client/server files, and optional NUI scaffold. This distinguishes it from sibling inspection tools like fivem.resource_inspect and scaffolding tools like fivem.ui_scaffold.
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 verb 'Cria' (creates) implies this tool is for new resource generation, but there is no explicit when-to-use guidance or comparison to alternatives such as fivem.ui_scaffold for NUI-only work. Usage context is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of disclosing behavior. It indicates the tool inspects and returns problems/suggestions, but it does not explicitly state whether the tool is read-only, what side effects occur, or what the exact output format is. This leaves notable gaps.
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, focused sentence that front-loads the verb and conveys the core purpose without unnecessary elaboration. It is appropriately concise for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, and low schema description coverage. The description provides only a high-level overview and does not explain return values, side effects, or parameter specifics. For an audit tool that inspects multiple resource elements, this is insufficient for an agent to fully understand invocation consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only one parameter (resourceDir) with no description coverage (0%). The description does not mention or elaborate on this parameter, leaving the agent to infer its meaning from the name alone. Since schema coverage is low, the description should compensate, but it does not.
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 uses a specific verb ('Inspeciona') and clearly scopes the action to manifest, NUI files, and client-side callbacks with an explicit outcome ('apontar problemas e sugestões'). This distinguishes it from sibling tools like fivem.resource_inspect by focusing on auditing rather than generic inspection.
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 usage when an audit of a FiveM resource is needed but provides no explicit when-to-use or alternative guidance. It does not mention when to prefer this over fivem.resource_inspect or other siblings, so it falls short of explicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses a key constraint (only allowed roots), but does not mention what happens when a path outside the allowed roots is provided, whether the listing is recursive, or what output format is returned. For a read-only listing operation, the absence of safety annotations makes this somewhat thin, though the verb 'listing' implies no mutation.
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?
The description is a single sentence that is directly front-loaded with the action and resource. There is zero filler or redundancy, which makes it concise. However, it is so brief that it arguably under-specifies for a tool with no annotations or parameter documentation.
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?
For a simple list operation, the description covers the core purpose and the critical allowed-roots constraint. Yet it omits any mention of return format, recursion behavior, hidden files, or error handling, which the agent would need to know since there is no output schema. It is minimally viable but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only one parameter, dirPath, but schema description coverage is 0%. The tool description does not specify what dirPath should look like (absolute vs relative, trailing slash, path format). The parameter name 'dirPath' is self-explanatory, and the description implies it is a directory path, but it does not compensate for the complete lack of schema documentation.
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 verb 'Lista' (lists) and the resource 'arquivos e pastas' (files and folders), and adds the scope of allowed roots via FIVEM_MCP_ALLOWED_DIRS. This distinguishes it from sibling tools like fs.read_text or fs.write_text, which handle file content, not directory listings. It is specific and unambiguous.
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 mentions that listing is restricted to roots allowed by FIVEM_MCP_ALLOWED_DIRS, which gives some context about where it can be used. However, it does not explicitly state when to prefer this tool over alternatives, nor does it provide exclusions or conditions. The usage guidance is implied rather than explicit, so it's adequate but not exemplary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior on its own. It does mention optional hash validation, which is a behavioral trait beyond the basic write operation. However, it does not clarify whether the tool overwrites existing files, how createDirs behaves, what happens on hash mismatch, or the return value.
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, front-loaded sentence with no filler. It conveys the core purpose and a key distinguishing feature without wasting words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 params, no annotations, no output schema), the description is too sparse. It omits critical contextual details such as overwrite behavior, directory creation, error handling on hash mismatch, and any return value. The agent would need to rely on assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter documentation. It only indirectly references expectedSha256 via 'validação opcional de hash'. It fails to explain filePath, content, or createDirs, leaving the agent without essential parameter semantics beyond the schema names.
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 it writes a text file, using the specific verb 'escreve' and identifying the resource (arquivo de texto). It also mentions the distinguishing feature of optional hash validation, which sets it apart from sibling tools like fs.read_text and fs.edit_lines.
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 phrase 'para edição assertiva' implies a use case for safe, intentional file writes, but the description does not explicitly state when to use this tool versus alternatives like fs.edit_lines or fs.mkdirp. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the heuristic nature of the detection, which is useful, but it does not explicitly state that the operation is read-only, what the return value is, or any limitations of the heuristic. Some behavioral context is added, but gaps remain.
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 sentence, front-loaded with the verb and purpose. It is concise and directly to the point, with no unnecessary information.
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?
Given the tool's simplicity, the description covers the core purpose but omits details about the parameter and the return value. Since there is no output schema, the description should state what the tool returns, but it does not. It is adequate but leaves gaps for an agent to deduce.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, resourceDir, with no description, and the description itself does not explain what the parameter should contain. With 0% schema coverage, the description should compensate, but it only refers to 'the resource' implicitly. The agent must infer that resourceDir is the path to the resource directory.
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 performs heuristic detection to identify whether a resource uses qb-core, esx, or standalone. This is a specific verb and outcome, distinguishing it from sibling tools like resource_inspect or resource_audit, which have different purposes.
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 purpose implies when to use the tool (when you need to know a resource's framework), but there is no explicit guidance on when not to use it or comparisons with alternatives. The description provides a clear use case but no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses recursion and root restrictions, which are useful behavioral traits, but omits idempotency, error behavior, and permission requirements. Adequate but not rich.
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, front-loaded with the action and directly stating the key behaviors. No filler or redundant information.
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 tool with one parameter and no output schema, the description covers the core purpose and constraints. It lacks edge-case behavior details like handling of existing directories, but given the simple operation, it is reasonably complete.
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 single parameter dirPath is self-explanatory from its name, and the description adds context that creation must occur within allowed roots. With 0% schema description coverage, this added constraint is valuable and partially compensates for the lack of schema documentation.
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 creates directories recursively within allowed roots, using the specific verb 'Cria' and resource 'diretórios'. This distinguishes it from sibling file operations like fs.read_text and fs.write_text.
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 implies usage for creating directory structures, and the allowed roots constraint provides context. It does not explicitly name alternative tools or exclusions, but the distinct operation makes confusion unlikely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![FivemMcp MCP server](https://glama.ai/mcp/servers/999luan/FivemMcp/badges/card.svg)](https://glama.ai/mcp/servers/999luan/FivemMcp)

Score Badge

Copy to your README.md:

[![FivemMcp MCP server](https://glama.ai/mcp/servers/999luan/FivemMcp/badges/score.svg)](https://glama.ai/mcp/servers/999luan/FivemMcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/999luan/FivemMcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server