The ark-asa-mcp server provides an MCP interface to manage Ark: Survival Ascended game servers via RCON, enabling configuration management, remote administration, and game interaction.
Server Configuration Management
List all configured RCON servers (passwords excluded)
Add or update named server entries in config.json (host, port, password, timeout, response cap)
Remove a named server entry from config.json
Set a default server used when serverName is not specified
RCON & Game Administration
Run any single-line raw RCON command (newlines rejected to prevent command batching)
List currently connected players, returning raw output and parsed player entries
Broadcast custom messages (up to 512 characters) to all connected players
Trigger a world save to persist current game state
Retrieve recent game log output from the server
Multi-Server Support
All RCON tools accept an optional serverName argument to target a specific server when multiple are configured
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ark-asa-mcp who is online on my ark server?"
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.
ark-asa-mcp is a Node.js Model Context Protocol server for Ark: Survival Ascended servers that expose RCON.
It lets an MCP client run common ASA administration commands through a small, typed tool surface while keeping one or more RCON server definitions in a local config.json file.
MCP stdio server built with @modelcontextprotocol/sdk.
RCON command execution against one or more named Ark: Survival Ascended servers.
Per-tool serverName routing when multiple servers are configured.
Convenience tools for listing players, broadcasting messages, saving the world, and reading the game log.
Centralized configuration through config.json.
Unit-tested command helpers for input validation and output shaping.
Related MCP server: gmod-mcp
Node.js 20 or newer.
One or more Ark: Survival Ascended servers with RCON enabled.
The RCON host, port, and password for each configured server.
Developer mode:
npm install
npm run buildUser mode:
Download ark-asa-mcp-win-x64.zip from a GitHub release, extract it, copy config.example.json to config.json, and point your MCP client at ark-asa-mcp.exe.
Copy config.example.json to config.json and edit the server definitions for your ASA hosts. The local config.json file is ignored by Git because it contains RCON passwords.
{
"defaultServerName": "azer",
"timeoutMs": 10000,
"maxResponseChars": 20000,
"servers": [
{
"serverName": "azer",
"host": "127.0.0.1",
"port": 27020,
"password": "change-me"
},
{
"serverName": "island",
"host": "127.0.0.2",
"port": 27020,
"password": "change-me-too"
}
]
}By default, ark-asa-mcp reads config.json from the process working directory. You can point to another file with ARK_ASA_CONFIG_PATH:
ARK_ASA_CONFIG_PATH=D:/Repositories/ark-asa-mcp/config.jsonEach server object supports:
Field | Required | Default | Notes |
| yes | none | Stable name used by MCP tools, such as |
| no |
| ASA RCON host. |
| no |
| ASA RCON port. |
| yes | none | ASA RCON password. |
| no | top-level | Per-server timeout override. |
| no | top-level | Per-server response cap. |
defaultServerName is optional. If it is not set and only one server is configured, tools can omit serverName. If more than one server is configured, tools should pass serverName.
Environment fallback is still available for simple or containerized deployments:
ARK_ASA_RCON_SERVER_NAME=azer
ARK_ASA_RCON_HOST=127.0.0.1
ARK_ASA_RCON_PORT=27020
ARK_ASA_RCON_PASSWORD=change-meARK_ASA_RCON_SERVERS and ARK_RCON_* aliases are still accepted as fallbacks when no config file exists.
Release .exe mode:
{
"mcpServers": {
"ark-asa": {
"command": "C:/Tools/ark-asa-mcp/ark-asa-mcp.exe"
}
}
}If the config file lives elsewhere:
{
"mcpServers": {
"ark-asa": {
"command": "C:/Tools/ark-asa-mcp/ark-asa-mcp.exe",
"env": {
"ARK_ASA_CONFIG_PATH": "C:/Tools/ark-asa-mcp/config.json"
}
}
}
}Node mode:
{
"mcpServers": {
"ark-asa": {
"command": "node",
"args": ["D:/Repositories/ark-asa-mcp/dist/index.js"],
"env": {
"ARK_ASA_CONFIG_PATH": "D:/Repositories/ark-asa-mcp/config.json"
}
}
}
}For development, you can point the command at tsx:
{
"mcpServers": {
"ark-asa-dev": {
"command": "npx",
"args": ["tsx", "D:/Repositories/ark-asa-mcp/src/index.ts"],
"env": {
"ARK_ASA_CONFIG_PATH": "D:/Repositories/ark-asa-mcp/config.json"
}
}
}
}Tool | Purpose |
| Lists configured ASA RCON servers without exposing passwords. |
| Lists servers from |
| Creates or updates a server entry in |
| Removes a server entry from |
| Sets the default server in |
| Runs a raw RCON command. |
| Runs |
| Runs |
| Runs |
| Runs |
Server-bound tools accept an optional serverName argument. It becomes required when multiple servers are configured and no default server is set.
Config-writing tools never return passwords, but any password supplied through an MCP client is still visible to that client. For local setup, ark-asa-mcp configure is safer.
The MCP server can start before any server is configured so asa_config_upsert_server can create the first config.json. RCON tools will return a clear error until at least one server exists.
ark-asa-mcp configure
ark-asa-mcp configure --server-name azer --host 127.0.0.1 --port 27020 --password change-me --default
ark-asa-mcp config:list
ark-asa-mcp --versionconfigure creates or updates config.json interactively.
The release workflow builds a Windows x64 zip containing:
ark-asa-mcp.exe
config.example.json
README-USER.md
LICENSE
Push a tag like v0.1.0 to create or update a draft GitHub release asset.
npm run typecheck
npm test
npm run buildThe package entry point is src/index.ts. Build output is written to dist/.
Windows executable packaging uses Node.js single executable applications:
npm run package:winThis script expects Node.js 26 or newer.
RCON has server administrator authority. Treat every RCON password like a production secret, avoid committing .env files, and only expose this MCP server to clients you trust.
The raw command tool intentionally supports arbitrary single-line RCON commands. Newline characters are rejected to prevent accidental command batching.
Broadcast a message to connected Ark: Survival Ascended players.
| Name | Required | Description | Default |
|---|---|---|---|
| serverName | No | Configured ASA serverName. Required when more than one server is configured. | |
| message | Yes | Message to broadcast to the ASA server. |
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 only states the action without disclosing behavioral traits such as whether it requires the server to be running, logs messages, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded, zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple broadcast tool with no output schema and two parameters, the description is minimally adequate. It states the action but omits details like return behavior or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds no extra meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Broadcast') and resource ('message to connected Ark: Survival Ascended players'). It distinguishes from sibling tools like asa_rcon_command which sends commands, but does not explicitly contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., asa_rcon_command for commands). No when/when-not scenarios provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List servers from config.json without exposing passwords.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a behavioral note about not exposing passwords, which is useful for safety. However, since there are no annotations, the description should also disclose other behaviors like read-only nature, authentication requirements, or whether it lists all servers or a subset. This is a minimal addition beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and direct. It contains no unnecessary words and effectively communicates the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no output schema, the description should explain what information is returned (e.g., server names, IPs). It only states 'list servers' without specifying the output format or fields. This lack of detail makes it incomplete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and description coverage is 100%, so the baseline is 3. The description does not add any parameter information, but none is needed. It could mention that no parameters are required, but that is not necessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (list), the resource (servers from config.json), and an important constraint (without exposing passwords). However, it does not differentiate from the sibling tool 'asa_list_servers', which could cause confusion about which tool to use for listing servers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'asa_list_servers' or other config-related tools. The description lacks context about prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a named ASA RCON server from config.json.
| Name | Required | Description | Default |
|---|---|---|---|
| serverName | Yes | Configured ASA serverName to remove. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description must disclose behavior. It only states the removal action without explaining consequences (e.g., irreversibility, error handling if server does not exist, or permission requirements). This is insufficient for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that communicates the purpose without redundancy. While extremely brief, it is efficient for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one required parameter, no output schema, low complexity), the description is minimally adequate. However, it lacks context about post-removal effects or relationship to sibling config tools, which could improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'serverName', which is well-described. The description adds no extra meaning, but none is needed since the schema already explains it. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and the resource ('a named ASA RCON server from config.json'), effectively distinguishing it from sibling tools like asa_config_upsert_server or asa_config_list_servers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, nor are prerequisites or conditions mentioned. The description only states what the tool does, not when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the default ASA RCON serverName in config.json.
| Name | Required | Description | Default |
|---|---|---|---|
| serverName | Yes | Configured ASA serverName to use by default. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavior. It only states it sets a default but omits side effects like overwriting previous defaults, persistence details, or any impact on running services.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence with no wasted words. It directly conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter, the description is minimally adequate given the parameter is fully described in the schema. However, it lacks context about when the change takes effect or if it requires a restart, and misses usage guidance compared to siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the parameter's schema description, which already says 'Configured ASA serverName to use by default.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (set) and the resource (default ASA RCON serverName in config.json), distinguishing it from sibling tools like asa_config_upsert_server and asa_config_list_servers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as asa_config_upsert_server or asa_config_remove_server. The description does not specify prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create or update a named ASA RCON server in config.json.
| Name | Required | Description | Default |
|---|---|---|---|
| serverName | Yes | Stable name used by MCP tools, such as azer. | |
| host | No | ASA RCON host. | |
| port | No | ASA RCON port. | |
| password | No | ASA RCON password. Required when adding a new server. | |
| timeoutMs | No | Optional per-server timeout. | |
| maxResponseChars | No | Optional per-server response cap. | |
| makeDefault | No | Set this server as the default. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions 'create or update' indicating mutation, but lacks details on side effects (e.g., what happens on update), required permissions, or how the config.json is modified. Minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no unnecessary words. However, it is too brief to cover essential guidance for a 7-parameter tool. Conciseness is good but at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and no annotations, the description is insufficient. It doesn't explain return value, update vs create behavior, or how to handle defaults. Sibling tools exist but no context provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and parameter descriptions are clear. The description adds little beyond the schema (e.g., implying serverName is key). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (create/update) and resource (ASA RCON server in config.json). It distinguishes from sibling tools like asa_config_list_servers and asa_config_remove_server by focusing on creation/update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. For example, it doesn't mention that asa_config_set_default_server should be used to change the default, or that asa_config_list_servers is for listing. No prerequisites or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run GetGameLog on the Ark: Survival Ascended server.
| Name | Required | Description | Default |
|---|---|---|---|
| serverName | No | Configured ASA serverName. Required when more than one server is configured. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It only states 'Run GetGameLog' without indicating whether it's read-only, how large the log might be, or error handling. This is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it essentially restates the tool name without adding meaningful context. It could be more informative while remaining brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description fails to explain what the tool returns or how to interpret the log. For a simple tool, it is minimally adequate but leaves gaps about expected output and behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, and its description is provided in the schema. The tool description adds no extra semantic value beyond what the schema already offers, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs GetGameLog on the ASA server, which aligns with the name and title. It distinguishes from sibling tools like asa_broadcast or asa_list_players by focusing on log retrieval, but it does not elaborate on the log's content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, nor any conditions or prerequisites. The agent is left to infer the use case from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run ListPlayers and return raw output plus parsed player entries.
| Name | Required | Description | Default |
|---|---|---|---|
| serverName | No | Configured ASA serverName. Required when more than one server is configured. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description provides basic behavioral info (runs command, returns raw + parsed output). However, it omits side effects (likely read-only), permission needs, or error behavior. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It front-loads the action and output clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity, the description lacks context about what 'ListPlayers' is, when it's needed, or how the output is structured. Given no output schema and no annotations, the description should provide more background for proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the single optional parameter (serverName) with a clear description. The tool description adds no additional parameter details, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool runs the 'ListPlayers' command and returns both raw output and parsed player entries. This clearly differentiates it from sibling tools like asa_broadcast (messages) and asa_rcon_command (arbitrary commands).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool instead of alternatives such as asa_rcon_command for custom queries or asa_get_game_log for log retrieval. The description lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List configured Ark: Survival Ascended RCON servers without exposing passwords.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description proactively reassures that passwords are not exposed, which adds trust. However, no mention of any other behaviors (e.g., whether servers are queried or just read from config).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, short sentence that is front-loaded with the action and includes a safety qualifier. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool, the description is complete. No output schema expected, and the tool's function is fully described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, schema coverage is 100%, so description need not add parameter info. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists configured ASA RCON servers, with a specific security qualifier ('without exposing passwords'), distinguishing it from sibling tools like asa_list_players or asa_broadcast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., asa_rcon_command). Usage is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run one raw Ark: Survival Ascended RCON command.
| Name | Required | Description | Default |
|---|---|---|---|
| serverName | No | Configured ASA serverName. Required when more than one server is configured. | |
| command | Yes | Single-line RCON command to execute. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits like destructiveness, permissions, or error behavior. It does not—running a raw RCON command could be highly destructive, yet no warnings are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence), but it lacks structure and detail. Being too terse undermines its utility; a balance between brevity and completeness is needed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should explain return values, error handling, or potential side effects. It provides none of this context, leaving the agent underinformed for a raw command tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds no additional meaning beyond the schema, scoring at the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Run' and the resource 'one raw Ark: Survival Ascended RCON command,' distinguishing it from sibling tools like asa_broadcast or asa_list_players. However, it does not elaborate on what RCON commands are or the scope of supported commands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., asa_broadcast for broadcasting messages). The agent receives no context about prerequisites, limitations, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run SaveWorld on the Ark: Survival Ascended server.
| Name | Required | Description | Default |
|---|---|---|---|
| serverName | No | Configured ASA serverName. Required when more than one server is configured. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the action without disclosing behavioral traits (e.g., impact on server, required permissions, or side effects).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but lacks structure and additional context. It could benefit from a brief note on behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity, the description barely covers the tool's role. It omits usage guidance and behavioral context, leaving an agent with limited information to decide or invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters, so the description adds no extra meaning. Baseline 3 is appropriate as the schema already describes the parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs SaveWorld on the server, specifying the exact action and resource. It distinguishes from sibling tools like asa_broadcast or asa_rcon_command, 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.
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. It does not mention prerequisites, success conditions, 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.1asa_config_list_serversasa_config_remove_serverasa_config_set_default_serverasa_config_upsert_serverv0.1.0asa_broadcastasa_get_game_logasa_list_playersasa_list_serversasa_rcon_commandasa_save_worldScored across 10 tools
Most tools target distinct actions, but asa_list_servers and asa_config_list_servers appear to do nearly the same thing, creating real selection risk. The specialized RCON wrappers are clearly described, though asa_rcon_command can overlap with them by design.
All names use the asa_ prefix and snake_case, and most follow a verb_noun pattern such as asa_list_players and asa_save_world. The config tools consistently use asa_config_<verb>_<object>, with minor deviations like asa_rcon_command and asa_broadcast.
10 tools is well-scoped for a server that manages ASA RCON server configuration and provides common RCON operations. Each tool has a plausible role in the workflow, and the count is solidly within the ideal range.
The config lifecycle is covered with list, upsert, remove, and set-default, while RCON coverage includes a raw command plus wrappers for players, broadcast, save world, and game log. A direct status or connection-check tool is missing, but the raw RCON command provides a fallback for many edge cases.
MCP server for AI dialogue using various LLM models via AceDataCloud
An MCP server for deep research or task groups
An MCP server that integrates with Discord to provide AI-powered features.
MCP server for Flux AI image generation