Click on "Install 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., "@War Thunder Replay MCP download replay for user 12345 session abc-def"
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.
War Thunder 서버 리플레이의 모든 .wrpl 조각을 내려받는 독립 로컬 MCP
서버입니다.
USER_ID로 리플레이를 검색하고 정확한 SESSION_ID를 찾은 뒤, War Thunder
리플레이 API에서 메타데이터를 읽어 세션별 폴더에 병렬로 다운로드합니다.
Python 3.13
warthunder.com에 로그인된 Microsoft Edge
Edge 쿠키를 사용할 수 없는 환경에서는 WARTHUNDER_LOGIN_COOKIE 환경변수에
쿠키 문자열을 설정할 수 있습니다. 쿠키 값은 MCP 도구의 인자나 결과에 노출되지
않습니다.
Related MCP server: PCC Downloader MCP Server
cd <warthunder-replay-mcp-directory>
uv sync
uv run pytest
uv run ruff check .uv run warthunder-replay-mcp서버는 로컬 MCP 클라이언트용 stdio 전송을 사용합니다. stdout은 MCP 메시지
전용이며 다운로드 진행 상황은 stderr에 출력됩니다.
제공 도구:
get_mcp_status: 저장 위치와 인증 방식을 확인합니다.
download_replay: user_id, session_id, max_workers를 받아 리플레이를
다운로드합니다.
파일은 항상 WARTHUNDER_REPLAY_DOWNLOAD_ROOT\<session_id>\ 아래에 저장됩니다.
환경변수를 생략하면 현재 작업 폴더의 Downloads\<session_id>\를 사용합니다.
[mcp_servers.warthunder_replay]
command = "C:\\path\\to\\warthunder-replay-mcp\\.venv\\Scripts\\warthunder-replay-mcp.exe"
cwd = "C:\\path\\to\\warthunder-replay-mcp"
[mcp_servers.warthunder_replay.env]
WARTHUNDER_REPLAY_DOWNLOAD_ROOT = "C:\\path\\to\\replay-downloads"기본값은 browser-cookie3를 이용한 Microsoft Edge 쿠키 자동 로드입니다.
Edge가 실행 중이거나 Windows 보안 정책이 쿠키 복호화를 막으면 자동 로드가 실패할 수 있습니다.
이때 WARTHUNDER_LOGIN_COOKIE를 MCP 서버 프로세스 환경에만 설정하세요.
높은 동시 다운로드 수는 연결 초기화를 늘릴 수 있어 2~3개부터 권장합니다.
src/warthunder_replay_mcp/
cli.py
config.py
downloader.py
server.py
tests/docs/, scripts/, examples/는 로컬 보조 자료로 기본 .gitignore 대상입니다.
Download every .wrpl part for one user/session pair.
Args: user_id: Numeric War Thunder player ID used by replay search. session_id: Hexadecimal replay session ID. max_workers: Parallel downloads from 1 through 8.
| Name | Required | Description | Default |
|---|---|---|---|
| user_id | Yes | ||
| session_id | Yes | ||
| max_workers | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It indicates the tool performs downloads, which is typically non-destructive, and mentions parallelism via the 'max_workers' parameter. However, it does not disclose potential side effects (e.g., overwriting existing files), authentication requirements, or idempotency. The description provides minimal behavioral context.
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 extremely concise: two sentences followed by a parameter list. It front-loads the core purpose in the first sentence, and every line provides necessary information. There is no redundant or filler text.
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 tool's simplicity (downloading replay parts with three parameters) and the presence of an output schema (which likely covers return values), the description covers the main use case well. It specifies the parameters with acceptable detail. However, it omits potential error conditions, prerequisites (e.g., authentication), or how to interpret the output file(s). Still, it is fairly complete for a straightforward download 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?
The input schema provides only titles for properties (e.g., 'User Id', 'Session Id', 'Max Workers'), with no descriptions. The tool description compensates by explaining each parameter: user_id is 'Numeric War Thunder player ID', session_id is 'Hexadecimal replay session ID', max_workers is 'Parallel downloads from 1 through 8'. This adds crucial type and constraint information beyond the bare schema.
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 and resource: 'Download every .wrpl part for one user/session pair.' It uses a specific verb ('download') and explicitly identifies the resource ('.wrpl parts') and scope (one user/session pair). The sibling tool 'get_mcp_status' is distinct, so no confusion about purpose.
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?
The description implies the tool is used when you want to download replay parts for a specific user and session. However, it does not explicitly provide guidance on when not to use it or mention alternatives. Given only one sibling (get_mcp_status), the context is clear but the description lacks explicit usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return local output and authentication settings without exposing cookie values.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 specific data types but does not explain the format, potential side effects, or any constraints beyond cookie exposure. The description is too brief to fully inform the agent about behavioral traits.
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, well-structured sentence that immediately states the action and key details. It is appropriately sized with no wasted words, front-loading the core functionality.
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 tool's low complexity (no parameters, simple return of settings) and the presence of an output schema, the description is sufficiently complete. It covers what the tool does and what it avoids, without needing to elaborate on return values since the output schema handles that.
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 is empty, and schema description coverage is trivially 100%. The description adds meaning by specifying what the tool returns, providing context beyond the schema. Although the baseline for high coverage is 3, the description effectively communicates the tool's purpose and output, warranting a 4.
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 returns 'local output and authentication settings' and explicitly notes what it does not expose ('cookie values'). It uses a specific verb ('Return') and resource, effectively distinguishing its purpose from the sibling tool 'download_replay' which likely focuses on replay actions.
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?
The description provides no guidance on when to use this tool versus alternatives. It lacks explicit usage context, prerequisites, or scenarios. The mention of not exposing cookie values hints at a privacy consideration but does not direct the agent on appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The two tools have completely distinct purposes: one checks server status and authentication settings, the other downloads replay files. There is no overlap or ambiguity between them.
Both tool names follow a consistent verb_noun pattern (get_mcp_status, download_replay), making it easy to predict their functionality.
With only 2 tools, the server feels thin for a replay management system. While it may cover the core download function, additional tools for searching or listing replays would be expected.
The server lacks tools for discovering or searching replays; it assumes users already have user_id and session_id. This is a significant gap that forces agents to obtain IDs from external sources, limiting the server's standalone usefulness.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Source-first URL clone, capture, rebuild, and fidelity verification tools.
Stealth web browser for agents: search, fetch, click, download and type in persistent MCP sessions.
Fetch transcripts, subtitles, chapters, metadata and frames from YouTube and 10+ video platforms
Get share links, publish and manage websites, artifacts and agents. No account needed.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/SMOKE-19/warthunder-replay-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server