Arma Reforger MCP Server

by maxionice

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
Disambiguation5/5
Each tool targets a distinct aspect of ArmA Reforger development: project discovery, inspection, file I/O, validation, script analysis, generation, log analysis, documentation search, and workbench execution. No two tools have overlapping purposes; even the three search tools are scoped to workspace files, official docs, and local API respectively.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case (e.g., list_projects, inspect_project, search_workspace, validate_resources). The verbs are descriptive and uniform, making the toolset easy to navigate.
Tool Count5/5
With 13 tools, the set is well-scoped for a modding assistant. It covers discovery, inspection, file operations, validation, analysis, generation, and documentation without being overwhelming or too sparse.
Completeness4/5
The toolset supports the core modding workflow: discover projects, inspect and modify files, validate resources, analyze scripts, generate templates, search documentation, and examine logs. Minor gaps like project creation or dependency management are absent but do not severely hinder core functionality.
Average 3.3/5 across 13 of 13 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 7 of 7 community issues answered or closed in the last 6 months
- 6 commits in the last 12 weeks
- Last stable release on July 30, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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?
Annotations exist but are neutral (no readOnly, destructive hints). The description adds 'launch without a shell' but doesn't clarify side effects, permissions, or execution behavior. For a tool that can launch executables, more behavioral context is needed.
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?
Two sentences (one English, one German) are brief, but the repetition of the same information in two languages is wasteful. It is structured but lacks useful content that earns its place.
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 6 parameters, a nested object, no output schema, and no parameter descriptions, the description is severely incomplete. It does not cover return values, error cases, or parameter relationships, leaving the agent with little to act on.
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 coverage is 0% and the description provides no explanation of any of the 6 parameters. The agent must guess from names like 'pluginArguments' or 'autoClose'. No example values or context for the nested object or enum values.
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 builds a Workbench command and optionally launches it, using clear verbs and resource. The title adds 'Prepare or Run Arma Reforger Workbench', making the purpose specific. It distinguishes from sibling tools like list_projects or server_status, which are about listing or inspecting, not building commands.
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. No mention of prerequisites, exclusions, or context. The description only states what it does, not when or why.
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?
The annotations already declare readOnlyHint=true, so the description adds little beyond that. It does not explain what the output looks like, any side effects, or limitations. The tool is said to run checks, but without an output schema, the agent cannot anticipate the return value. No additional behavioral traits are disclosed.
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 extremely concise: a single sentence in English and its German translation. It is front-loaded with the core purpose and contains no unnecessary words. Every sentence earns its place by stating what the tool does.
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 complexity of the tool (4 parameters, no output schema, no parameter descriptions), the description is incomplete. It does not explain how to specify code vs file vs addon, what the output contains, or how to interpret the results. The agent would lack essential 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 4 parameters with 0% description coverage, and the description does not explain any of them. It mentions 'code, one file, or all scripts' but does not map these to the parameters (code, path, project, creatorTag). The agent cannot understand how to use each parameter effectively, making the description insufficient for parameter selection.
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 that the tool runs heuristic Enfusion convention and performance checks on code, files, or all scripts in an addon. The verb 'Run' and the specific resource ('checks') are well-defined, and it is easily distinguishable from siblings like 'validate_resources' or 'inspect_project' which have different purposes. However, it could be more specific about the exact nature of the checks.
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 such as 'validate_resources' or 'inspect_logs'. There is no mention of prerequisites, context, or when not to use it. The description leaves the agent to infer usage from the tool name and title alone.
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?
The annotations already declare readOnlyHint=true, so the description adds no significant behavioral context. It does not mention search mechanics (e.g., case-sensitivity, indexing scope) or any side effects beyond what is implied by read-only.
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 English sentence (plus German translation), which is concise. However, the bilingual content is unnecessary for an agent, and the structure does not front-load key details beyond the basic action.
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 no output schema and no parameter description coverage, the description should at least hint at what the search returns (e.g., Doxygen page links, snippets). It does not, leaving the agent uncertain about the tool's output and usage expectations.
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 provides no additional meaning for 'query' or 'limit' beyond their names and schema constraints. The agent gains no insight into query format, matching behavior, or how limit affects results.
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 it searches 'the official Doxygen HTML installed with Arma Reforger Tools', specifying the resource and action. The title reinforces 'Search Local'. However, it does not explicitly differentiate from the sibling 'search_official_docs', though the 'installed' phrase hints at local vs online.
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 versus alternatives like search_official_docs or search_workspace. No prerequisites or context are provided, leaving the agent without decision-support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description states 'generate ... without writing it' suggesting a read-like operation, but annotations declare readOnlyHint=true which contradicts the generative nature. No other behavioral details (auth, side effects) are disclosed.
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 concise with two sentences (EN and DE). However, the bilingual repetition adds minor redundancy; overall efficient.
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 moderate parameter count and no output schema, the description lacks details on return format, error handling, and prerequisites. It is too brief for a tool with 4 parameters and no schema descriptions.
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 description mentions 'creator-tagged' and lists kinds, giving partial meaning to creatorTag and kind parameters, but does not explain className or baseClass constraints. With 0% schema coverage, this is insufficient.
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 'generate' and the resource 'Enforce Script template' with specific kinds (class, component, modded class, Workbench plugin). It distinguishes this tool from siblings like write_project_file or analyze_enforce_script by focusing on template generation without writing.
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 for code generation but does not explicitly state when to use this tool versus alternatives. No 'when-not' or exclusion criteria are provided, so guidance is minimal.
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?
Annotations indicate readOnlyHint=true, so the tool is safe. The description adds value by explaining it groups errors and provides remediations, but does not disclose potential side effects or access requirements. No contradiction with annotations.
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?
Description is bilingual, adding length. The English part is one concise sentence covering main actions. Could be slightly more compact, but no unnecessary filler.
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 2 parameters, no output schema, and siblings, the description covers the core purpose but omits output format, prerequisites (e.g., log configuration), and error handling. Adequate but not fully comprehensive.
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 coverage is 0%, so description must compensate. The 'log' parameter is partially explained as a selected or newest configured log, but 'tailBytes' (integer with default and bounds) is not described at all. Schema provides type info but no context.
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 analyzes logs, groups actionable errors, and provides bilingual remediations. It uses specific verbs ('analyze', 'group') and distinguishes from siblings like inspect_project or read_project_file.
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 vs alternatives (e.g., inspect_project, read_project_file). The description mentions 'selected or the newest configured log' but lacks context for choosing this over sibling tools.
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?
Annotations already provide readOnlyHint=true and openWorldHint=false. The description adds context that the catalog is 'curated' and 'offline', which is useful but does not disclose additional behavioral traits such as authorization needs or result format. It adds some value beyond annotations.
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 short and front-loaded with the key purpose. However, including a bilingual version (German) adds redundancy for an agent likely operating in English. It could be more concise by omitting the German text, but it is still efficient.
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 lacks details about result format, limitations (e.g., only documentation, not code), and parameter usage. Given that there is no output schema and schema coverage is 0%, the description does not sufficiently compensate to make the tool's usage fully clear.
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 'query' or 'limit' parameters at all. It only describes the catalog being searched. For a search tool, parameters are critical, and the description fails to add meaning beyond the schema's basic definitions.
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?
Description clearly states the tool searches a specific curated, offline catalog of official documentation and samples. It distinguishes itself from siblings like search_workspace or search_local_api by specifying the source (Bohemia Interactive) and nature (curated, offline).
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 it should be used for official docs via 'primary Bohemia Interactive documentation and samples', but it does not provide explicit guidance on when to use this versus alternative search tools, nor does it mention 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and idempotent hints. The description adds atomicity and SHA-256 concurrency protection, but does not elaborate on approval requirements, error scenarios, or failure behavior. Adds some value beyond annotations but incomplete.
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 sentences (EN and DE), front-loading key functionality. While bilingual content may be redundant for an AI agent, it does not waste words and is efficiently structured.
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?
With 6 parameters, no output schema, and write operation with destructive hint, the description should cover success/failure indicators, preview behavior, and atomic write guarantees. It only partially addresses these, leaving gaps in completeness for a complex tool.
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 description must compensate. It mentions 'SHA-256' and 'approved text resource', partially explaining expectedSha256 and content, but does not describe dryRun, project, createDirectories, or path. Minimal addition beyond 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 'Preview or atomically write an approved text resource inside an addon', specifying the verb (preview/write) and resource (text resource). It distinguishes from sibling 'read_project_file' as a write operation.
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 for writing or previewing a file but does not explicitly state when to use versus alternatives like 'read_project_file' or when not to use. No explicit guidance on preview vs write choice.
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?
Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds context about the types of files searched (text, scripts, configs, etc.), but does not disclose other behaviors such as performance, result limits, or scanning scope. With annotations present, the description provides marginal added 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 concise, with a single English sentence and a German translation. It front-loads the purpose without extraneous information. Every word earns its place.
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 five parameters, no output schema, and 0% schema coverage, the description is highly incomplete. It fails to explain parameter behavior, return format, or effective querying strategies. For a search tool, more context is necessary.
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. However, it only lists file types and does not explain any of the five parameters (limit, query, project, extensions, caseSensitive). The description adds little meaning beyond what the schema 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 the tool's purpose: searching text, scripts, configs, metadata, prefabs, and world files using a safe literal query. The name 'search_workspace' aligns with the resources searched, and it distinguishes from siblings like search_official_docs and search_local_api.
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 for workspace search via 'safe literal query' but does not explicitly state when to use this tool over alternatives like search_official_docs or search_local_api. No exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the tool is known to be read-only and closed-world. The description adds transparency by detailing exactly what is validated (meta files, GUIDs, paths, etc.), going beyond the annotations without contradicting them.
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 sentences (EN and DE), front-loaded with the English version. It is concise and to the point, though the German repetition could be trimmed. Overall, it is efficient and readable.
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 a simple input (one parameter) and no output schema, the description lists what the tool checks but does not explain the return format (e.g., list of issues, success/failure). It covers the scope of validation adequately but lacks detail on expected output, making it mildly incomplete.
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 a single required parameter 'project' with no description. Schema description coverage is 0%, and the tool description does not explain what 'project' means (e.g., project name or path). The description adds no semantic meaning to the parameter.
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 specific verbs ('Check') and lists concrete resources (local .meta files, GUID uniqueness, resource paths, missing metadata, mismatches). This clearly distinguishes it from sibling tools like inspect_project or search_workspace, which serve 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 description states what the tool checks but provides no guidance on when to use it versus alternatives (e.g., inspect_project for project structure, search_workspace for broader search). No when-not or explicit context is given, so the usage is implied but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered. Description adds the important behavioral detail of 'bounded line range', clarifying that not the entire file is read. This is useful context beyond the annotation.
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?
Description is short (two sentences) and to the point. The bilingual format adds some redundancy but is acceptable for a multilingual tool. No filler.
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?
With 4 parameters, no output schema, and low parameter documentation, the description lacks return value info, error cases, and prerequisites. It is insufficient for a file reading tool that could have encoding or size limitations.
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 coverage is only 25% (only path has description). Description mentions 'bounded line range' but does not explain startLine, endLine defaults, or constraints (e.g., endLine max 5000). It fails to add meaning for 3 out of 4 parameters, which is needed given low coverage.
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?
Description clearly states 'read a bounded line range from a text file', specifying the action, scope (inside an addon), and the bounded nature of the read. This distinguishes it from sibling tools like write_project_file (write) and inspect_project (inspect).
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?
Description implies usage for reading specific file sections but gives no explicit guidance on when to choose this over siblings (e.g., search_workspace for search or inspect_project for metadata). No exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds context by detailing the specific read-only operations performed (parse, inventory, resolve, check). It does not mention potential performance or prerequisite details, but the annotation covers the safety profile.
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 concise with two bilingual lines, front-loaded with key actions. The slight redundancy due to dual language is acceptable and does not harm clarity.
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?
Missing output format description; for a tool with no output schema, the agent cannot know what data the tool returns. The actions listed give a hint, but explicit return value information is absent.
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 parameter 'project' is well-documented in the schema. The description does not add additional parameter-specific information 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 lists four specific actions: parse metadata, inventory assets, resolve dependencies, and check script-module placement. It clearly defines the tool's purpose and distinguishes it from siblings like list_projects (listing only) or read_project_file (reading a single file).
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?
No explicit usage guidelines are provided; the description implies the tool is for comprehensive project inspection, but does not state when to prefer it over alternatives like validate_resources or analyze_enforce_script. The usage context is implied by the actions listed.
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?
Annotations already indicate readOnlyHint=true, so the description adds value by specifying the scope ('under the configured roots'). However, it does not disclose other behavioral traits like performance implications or authentication needs beyond what annotations provide.
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 extremely concise: two short sentences (one in English, one in German) with no wasted words. It front-loads the English version and efficiently conveys the tool's purpose.
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 read-only tool with no parameters, the description covers what it does and its scope. However, it lacks any indication of the output format (e.g., list of paths or names), which is a gap given no output schema is provided. The bilingual duplication adds no contextual completeness.
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 input schema has no parameters, so the description has no burden to explain parameters. With 0 parameters and 100% schema coverage, a baseline of 4 applies, and the description adds no parameter-related meaning—which is acceptable.
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 the verb 'discover' and specifies the resource '.gproj addons under the configured roots', clearly indicating a listing action. This distinguishes it from siblings like 'inspect_project' or 'read_project_file', which focus on single items or file reading.
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?
The description provides no guidance on when to use this tool versus alternatives like 'search_workspace' or 'inspect_project'. There is no mention of prerequisites, use cases, or exclusions, leaving the agent without context for selection.
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?
Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds that it shows capabilities, safety gates, and path availability, which is useful but does not disclose further behavioral traits such as caching, server requirements, or output format. With annotations covering the safety profile, the description provides moderate additional context.
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 extremely concise with two short sentences (EN and DE), front-loading the English version. Every word contributes to the purpose without redundancy or filler.
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?
While the description is sufficient for a zero-parameter status tool, it could be more complete by hinting at the output format or structure (e.g., JSON, list). The description covers what it shows but not how the data is presented, which might require the agent to infer.
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 input schema has 100% coverage trivially. Per guidelines, a baseline score of 4 is appropriate since no parameter description is needed. The description does not repeat schema information.
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 explicitly states the tool shows 'configured capabilities, safety gates, and path availability.' The verb 'show' combined with specific resource types clearly defines the tool's purpose and distinguishes it from sibling tools like 'list_projects' or 'inspect_logs,' which address different concerns.
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 lacks explicit guidance on when to use this tool versus alternatives. While it implies its use for checking server configuration before other operations, no when-not-to-use or alternative recommendations are provided. The context is implied but not elaborated.
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:

[![arma-reforger-mcp MCP server](https://glama.ai/mcp/servers/maxionice/arma-reforger-mcp/badges/card.svg)](https://glama.ai/mcp/servers/maxionice/arma-reforger-mcp)

Score Badge

Copy to your README.md:

[![arma-reforger-mcp MCP server](https://glama.ai/mcp/servers/maxionice/arma-reforger-mcp/badges/score.svg)](https://glama.ai/mcp/servers/maxionice/arma-reforger-mcp)

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/maxionice/arma-reforger-mcp'

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