molanko-mcp-avatar-generator
molanko-mcp-avatar-generator
molanko-avatar-generator 用の MCP サーバーです。
このサーバーは1つのツールを公開します:
generate_avatar— 提供された画像または Minecraft プレイヤー名/UUID から Molanko Avatar を生成し、生成された PNG を MCP 画像結果として返します。
ソースが必要です: image または minecraftPlayer のいずれか一方を正確に1つ指定してください。
実行
npm install
npm startこのサーバーは MCP stdio トランスポートを使用するため、ローカルの stdio サーバーをサポートする MCP クライアントから起動できます。
Related MCP server: mcp-xmorf
ツール: generate_avatar
ソース
次のうち正確に1つを指定してください:
image— MCP 形式の画像オブジェクト:{ "type": "image", "data": "<base64>", "mimeType": "image/png" }minecraftPlayer— Minecraft のユーザー名または UUID(UUID のハイフンの有無は問いません)。サーバーは Mojang のプロフィール API とセッション API を使用して現在のスキンを解決し、Mojang が提供するテクスチャ URL からスキンを直接ダウンロードします。
例:
{ "minecraftPlayer": "Notch" }{ "minecraftPlayer": "069a79f4-44e9-4726-a5be-fca90e38aaf5" }image と minecraftPlayer の両方が指定された場合、暗黙的にどちらかを選択するのではなく、リクエストは拒否されます。
オプション
scale— 最近傍補間による出力スケールoutlineMode— アウトラインの半径。0でアウトラインを無効化outlineColor—auto、auto_darker、auto_lighter、または 16 進数の色bgColor—auto、auto_lighter、auto_darker、または 16 進数の色fillBackground— 出力の背景を塗りつぶすかどうかupscale48— 32x32 のアバターを 48x48 のキャンバスの中央に描画averageColor— 自動のアウトライン/背景色で使用される色の任意の上書き値。auto、#RRGGBB、または#RGBを使用
averageColor は独立したツールではありません。ジェネレーターが自動計算した平均色を上書きします。省略するか auto に設定した場合、基盤となるジェネレーターがソーススキンから平均色を計算します。16 進数値は { r, g, b } に解析され、averageColor として molanko-avatar-generator に渡されます。
結果は PNG を含む MCP image コンテンツアイテムとして返されます。
Minecraft プレイヤーの解決
minecraftPlayer は Android 版アバタージェネレーターと同じ基本的なアプローチに従います: UUID は直接正規化され、ユーザー名は api.mojang.com/users/profiles/minecraft/{name} を通じて解決され、その後 UUID は Mojang のセッションプロフィール API を通じて解決され、プレイヤーの textures プロパティとスキン URL を取得します。サードパーティのスキンレンダリングサービスやスキンミラーリングサービスは必要ありません。
サーバーは、無効なプレイヤー識別子、プレイヤーが見つからない、スキンテクスチャがない、Mojang のレート制限、Mojang サーバーエラー、ネットワーク/ダウンロードエラーなど、有用な失敗情報を報告します。
アーキテクチャ
このリポジトリは意図的に薄い MCP アダプターです。Minecraft プレイヤーの解決とアバターレンダリングはサーバー側で行われますが、実際のアバターレンダリングは molanko-avatar-generator に残ります。
Available Tools
1 toolgenerate_avatarGenerate Molanko AvatarA
Generate a Molanko Avatar. Provide exactly one source: image or minecraftPlayer. minecraftPlayer accepts a Minecraft username or UUID (with or without hyphens); the server resolves the current skin through Mojang APIs. Returns the generated PNG as an MCP image result.
| Name | Required | Description | Default |
|---|---|---|---|
| image | No | A source Minecraft skin/image. | |
| scale | No | Nearest-neighbor output scale. | |
| bgColor | No | Background color: auto, auto_lighter, auto_darker, or a hex color. | auto |
| upscale48 | No | Render the avatar on a 48x48 canvas with the 32x32 avatar centered. | |
| outlineMode | No | Outline radius in pixels. 0 disables the outline. | |
| averageColor | No | Override the color used by automatic outline/background colors. Use auto (default), #RRGGBB, or #RGB. | |
| outlineColor | No | Outline color: auto, auto_darker, auto_lighter, or a hex color. | auto |
| fillBackground | No | Whether to fill the background. | |
| minecraftPlayer | No | Minecraft username or UUID, with or without hyphens. The server fetches the current skin through Mojang APIs. |
TDQS
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 output format (PNG as MCP image result) and the Minecraft skin resolution process. However, it does not mention error conditions, rate limits, or what happens if both sources are provided, which leaves gaps.
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 two sentences, front-loaded with the purpose and a critical usage rule. No redundant or filler content; every clause contributes to understanding how to invoke the 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?
With 9 parameters and no output schema, the description covers the essential aspects: the two source options and the return type. It does not elaborate on default behaviors of rendering options (scale, background, outline), but the schema fully documents these, so the description is sufficiently complete for an 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?
Schema description coverage is 100%, so baseline 3 applies. The description adds meaningful context beyond the schema by specifying the 'exactly one source' constraint and explaining how minecraftPlayer is resolved via Mojang APIs, which goes beyond the parameter's own schema description.
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 ('Generate') and the specific resource ('Molanko Avatar'). It also identifies the two mutually exclusive source types, clarifying the tool's scope even without sibling tools.
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?
It explicitly says 'Provide exactly one source', which is a direct usage rule. It also explains how minecraftPlayer works (username/UUID, Mojang API resolution). No alternatives are mentioned because no sibling tools exist, so this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.1.0- First observed
generate_avatar
TDQS
Scored across 1 tool
With only a single tool, there is no potential for confusion or overlap. The tool's purpose is clearly defined and unambiguous.
The single tool uses a clear verb_noun naming convention (generate_avatar) which is consistent and self-explanatory, even with only one tool.
The server has just one tool, which feels thin for a typical MCP server. However, it may be appropriate for the narrow scope of avatar generation, so it borders on acceptable.
The tool covers the domain comprehensively by accepting both image and Minecraft player sources, and there are no obvious missing operations for avatar generation.
Maintenance
Related MCP Connectors
MCP server for NanoBanana AI image generation and editing
MCP server for Flux AI image generation
MCP server for Qwen Image 3 AI image generation
MCP server for meme generation, template search, caption rendering, and AI meme creation.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceMCP server for generating images via text-to-image and image-to-image using lk888 API, returning base64 PNG and metadata.MIT
- AlicenseAqualityDmaintenanceMCP server for xmorf API enabling AI image editing and generation via natural language prompts.326 npmMIT
- AlicenseAqualityDmaintenanceMCP server providing image analysis tools for AI agents, including metadata extraction, favicon discovery, and placeholder generation.528 npmMIT
- FlicenseNot gradedqualityDmaintenanceAn MCP server that renders Minecraft structure files (NBT / Sponge schematic / Litematic) into PNG preview images using vanilla Minecraft resources.1-