How do I use gaea-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@gaea-mcp create a new terrain with mountain and erosion, then build it" 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.

gaea-mcp

by yushimatenjin

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

gaea-mcp

Gaea 2.0 terrain generation tool の MCP サーバー。 CLI ビルド自動化と .terrain ファイルのグラフ操作を提供します。

前提条件

Node.js v18 以上
Gaea 2.0 がインストール済みであること（Community / Professional）
- ビルド機能には Gaea.Swarm.exe が必要です

Related MCP server: Developer Toolbox MCP

セットアップ

git clone <repo-url>
cd gaea-mcp
npm install

1. Gaea インストールパスの設定

サーバーは以下の優先順位で Gaea のインストール先を探します:

環境変数 GAEA_INSTALL_DIR（.env または .mcp.json で指定）
自動検出 — %LOCALAPPDATA%\Programs\Gaea 2.0 など一般的なパスを順に確認

通常のインストール（Gaea のデフォルトインストーラー）であれば自動検出されるため、明示的な設定は不要です。

カスタムパスにインストールした場合のみ、以下のいずれかで GAEA_INSTALL_DIR を設定してください。指定するディレクトリには Gaea.exe と Gaea.Swarm.exe が含まれている必要があります。

2. 設定ファイルの作成

.env と .mcp.json はどちらも .gitignore に含まれており、リポジトリには同梱されません。利用環境に合わせてローカルで作成してください。

方法 A: `.env` ファイル（シンプル）

プロジェクトルートに .env を作成:

# Gaea のインストールディレクトリ（自動検出できる場合は省略可）
# GAEA_INSTALL_DIR=C:/Users/<ユーザー名>/AppData/Local/Programs/Gaea 2.0

# .terrain ファイルの保存先（省略時: ./projects）
# PROJECT_DIR=./projects

# ビルド出力先（省略時: ./output）
# OUTPUT_DIR=./output

方法 B: `.mcp.json`（Claude Code 連携用）

Claude Code から MCP サーバーとして利用する場合は .mcp.json を作成:

{
  "mcpServers": {
    "gaea": {
      "command": "npx",
      "args": ["tsx", "src/server.ts"],
      "env": {
        "GAEA_INSTALL_DIR": "C:/Users/<ユーザー名>/AppData/Local/Programs/Gaea 2.0"
      }
    }
  }
}

パスの書き方:

Windows でもスラッシュ / を使ってください（例: C:/Users/...）
<ユーザー名> は自分の Windows ユーザー名に置き換えてください
自動検出に任せる場合は GAEA_INSTALL_DIR 行を削除して構いません

環境変数一覧

変数名	必須	デフォルト	説明
`GAEA_INSTALL_DIR`	いいえ	自動検出	Gaea インストールディレクトリ
`PROJECT_DIR`	いいえ	`./projects`	`.terrain` ファイルの保存ディレクトリ
`OUTPUT_DIR`	いいえ	`./output`	ビルド出力ディレクトリ

3. 動作確認

# サーバーの起動テスト（stdio で起動し、Gaea 検出ログが stderr に出る）
npm run dev

# 正常なら以下のようなログが出力される:
# [config] Auto-detected Gaea install at: C:/Users/.../AppData/Local/Programs/Gaea 2.0
# [gaea-mcp-server] Server started on stdio transport

Ctrl+C で終了してください。このサーバーは MCP クライアント（Claude Code 等）経由で使うものなので、通常は直接起動する必要はありません。

使い方

Claude Code から使う

上記の .mcp.json をプロジェクトルートに配置
Claude Code のプロジェクトディレクトリでこのリポジトリを開く
Claude に「地形を作って」と言えば、MCP ツール経由でノードグラフの作成・ビルドが可能

典型的なワークフロー

create_terrain → add_node (Mountain) → add_node (Erosion2) → connect_nodes → build_terrain

Tools

Tool	Description
`check_gaea_status`	Gaea の検出状態とパスを確認
`get_gaea_version`	インストール済み Gaea のバージョン取得
`list_projects`	プロジェクトディレクトリの `.terrain` ファイル一覧
`build_terrain`	Gaea.Swarm.exe で地形をビルド
`list_node_types`	利用可能なノードタイプ一覧（120種、9カテゴリ）
`read_terrain_graph`	`.terrain` ファイルのノード・接続サマリー
`get_node_details`	特定ノードの詳細プロパティ
`create_terrain`	空の `.terrain` ファイルを作成
`add_node`	ノードを追加
`remove_node`	ノードを削除
`connect_nodes`	ノード間を接続
`disconnect_port`	ポートの接続を解除
`set_node_property`	ノードのプロパティを設定

開発

npm run dev          # tsx でサーバー起動（開発用）
npx tsc --noEmit     # 型チェック
npm run build        # dist/ にコンパイル

ディレクトリ構成

src/
  config.ts       - Gaea インストールパス自動検出
  node-types.ts   - ノードタイプレジストリ（120種）
  terrain-io.ts   - .terrain JSON 読み書き（カスタムシリアライザ）
  server.ts       - MCP サーバー + LLM向け instructions
scripts/
  scan-examples.ts - Gaea Examples からノードタイプを抽出するスクリプト

Available Tools

8 tools

build_terrainA

Build a terrain using Gaea.Swarm.exe CLI. Renders all output nodes in the .terrain file. The -v (variables) argument is always placed last automatically. Typical build time: seconds to minutes depending on resolution and node complexity.

ParametersJSON Schema

Name	Required	Description
`seed`	No	Mutation seed (integer) for terrain variations
`region`	No	Region name to build
`profile`	No	Build Profile name
`verbose`	No	Enable verbose build log
`filename`	Yes	Path to .terrain file (name in project dir or absolute path)
`varsFile`	No	Path to a .json or .txt variables file
`variables`	No	Variable overrides as key-value pairs, e.g. {"erosion": "0.35", "snowline": "0.7"}
`ignoreCache`	No	Ignore baked cache and force full rebuild

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses the CLI usage, rendering behavior, automatic placement of -v argument, and typical build times, but lacks disclosure of side effects (e.g., file modifications), error conditions, or prerequisites like Gaea installation.

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 three sentences, front-loaded with purpose, and contains no superfluous information; each sentence contributes essential context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 8 parameters and a potentially time-consuming process with no output schema, the description lacks information on output location, success indicators, blocking behavior, error handling, and prerequisites, leaving significant gaps.

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?

With 100% schema description coverage, the baseline is 3. The description adds only a minor note about the -v argument being placed last, providing no further parameter-level meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly uses the verb 'build' with the resource 'terrain' and specifies it uses a CLI to render all output nodes, effectively distinguishing it from sibling tools like create_terrain or read_terrain_graph.

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 after terrain creation (since build is distinct from create), but does not explicitly state when to use this tool versus alternatives or provide any exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_gaea_statusA

Check if Gaea is installed and report executable paths, project directory, and readiness. Call this first to verify the environment.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full transparency burden. It discloses what is reported (executable paths, project directory, readiness), which is adequate for a read-only status check. No side effects or contradictions.

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 two sentences, front-loaded with purpose, and contains no unnecessary words. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters, no output schema), the description adequately covers what the agent needs to know: its purpose and output. Sibling tools are more complex, so this is sufficient.

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 description appropriately adds no parameter info. Baseline of 4 is applied as per guidelines for no parameters.

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: checking if Gaea is installed and reporting executable paths, project directory, and readiness. It uses a specific verb ('check') and resource ('Gaea installation status'), distinguishing it from sibling tools like get_gaea_version or list_projects.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises calling this tool first to verify the environment, providing clear when-to-use guidance. While no when-not-to-use or alternatives are mentioned, the context of a status check makes this sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_terrainA

Create a new empty .terrain file compatible with Gaea 2.2.9. The file is saved in the project directory. After creation, use add_node to populate the graph. A typical workflow: create_terrain → add_node (generators: Mountain, RadialGradient) → add_node (processors: Erosion2, Thermal2, Rivers, Craggy, Snow) → add_node (colorizers: SatMap, ColorErosion) → add_node (outputs: Export, Mesher) → connect_nodes to wire the chain.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Filename without extension (e.g. 'my_mountain' creates my_mountain.terrain)

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. The description states creation of an empty file, but does not disclose whether it overwrites existing files, permissions required, or other side effects. It adds context about saving in project directory but lacks full behavioral transparency for a creation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loaded with main purpose. The workflow example is helpful but slightly lengthy; could be more concise. Still, every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool is simple with one parameter and no output schema, the description covers the essential purpose and usage. The workflow example provides context for how this tool fits into a larger process, making it reasonably complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 100% coverage with description for 'name' parameter, but the tool description adds value by providing an example ('my_mountain' creates my_mountain.terrain) and clarifying the extension behavior, which aids understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a new empty .terrain file compatible with Gaea 2.2.9, saved in the project directory. It distinguishes from sibling tools like add_node and build_terrain, which are later steps in the workflow.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a typical workflow starting with create_terrain followed by add_node, connect_nodes, etc. It implies when to use this tool (starting a new terrain) and gives subsequent steps. No explicit alternatives, but no sibling does this creation step.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_node_detailsA

Get all properties and port connections of a specific node. Use read_terrain_graph first to find node IDs.

ParametersJSON Schema

Name	Required	Description	Default
`nodeId`	Yes	Node ID (from read_terrain_graph output)
`filename`	Yes	Path to .terrain file

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It implies a read-only operation ('Get') but does not explicitly state that it is non-destructive or discuss potential errors (e.g., invalid nodeId). The behavioral information is adequate for a simple tool but lacks depth.

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 only two sentences, no repetition, and essential information front-loaded. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 parameters, no output schema, no nested objects), the description covers the core functionality and prerequisite. It lacks details about the return format, but that is partially mitigated by describing 'all properties and port connections'.

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?

The input schema already provides clear descriptions for both parameters, achieving 100% coverage. The description does not add new semantic meaning to the parameters beyond what is in the schema, so a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get') and identifies the resource ('all properties and port connections of a specific node'). It clearly distinguishes from sibling tools like 'read_terrain_graph' and 'list_node_types' by stating the exact scope of data returned.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states a prerequisite: 'Use read_terrain_graph first to find node IDs.' This provides clear guidance on when to use the tool. However, it does not mention when not to use it or explicitly compare to alternative tools for reading node data.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_projectsB

List .terrain files in the project directory. Use absolute paths for files outside this directory.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description explains the tool's basic function but includes a confusing statement about absolute paths that has no corresponding parameter, creating ambiguity.

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, but the second sentence is misplaced given the absence of parameters, reducing efficiency.

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?

Lacks details about the output format (e.g., names or paths) and does not clarify the misleading absolute paths suggestion, making it incomplete.

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?

No parameters exist, and the schema coverage is 100%. The description does not add meaning beyond the empty schema, 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 clearly states that the tool lists .terrain files in the project directory, which is specific and distinct from sibling tools like list_node_types or build_terrain.

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. The note about absolute paths is present but irrelevant since the tool has no parameters.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_terrain_graphA

Read a .terrain file and return a complete summary: all nodes, their properties, ports, and connections. Call this first when working with an existing terrain to understand the current graph structure. Each node has an "id" that you use in connect_nodes, set_node_property, remove_node, etc.

ParametersJSON Schema

Name	Required	Description	Default
`filename`	Yes	Path to .terrain file (name in project dir or absolute path)

TDQS

A4.2/5.0

Behavior3/5

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 a read operation with no side effects, but lacks details on error handling, permissions, or output format specifics. Adequate but not fully transparent.

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?

Three concise sentences, each serving a distinct purpose: action, usage guidance, and additional context. No redundancy or unnecessary information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read tool with no output schema, the description adequately covers the output contents and how to use the results with sibling tools. Minor omissions about limitations or error conditions, but overall complete enough.

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% for the single parameter 'filename', providing a baseline of 3. The description adds marginal value by mentioning 'project dir' context but does not significantly enhance parameter understanding 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 clearly states the tool reads a .terrain file and returns a complete summary, using the verb 'Read' and specifying the resource. It distinguishes from sibling tools by indicating it should be called first to understand the graph structure.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises 'Call this first when working with an existing terrain' and explains that node IDs from this tool are used in other tools like connect_nodes, set_node_property, etc., providing clear context for when and why to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

remove_nodeA

Remove a node and all its connections (both incoming and outgoing) from the terrain graph.

ParametersJSON Schema

Name	Required	Description	Default
`nodeId`	Yes	Node ID to remove
`filename`	Yes	Path to .terrain file

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description bears full burden. It discloses the key side effect of removing all connections, which is good. However, it omits details such as permanence, required permissions, or potential impacts on other graph elements, leaving some behavioral uncertainty.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the action and scope. It contains no redundant or extraneous information, earning its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given low complexity (2 simple params, no output schema), the description is mostly complete. It covers the core operation and the side effect on connections. Could be slightly improved by mentioning error conditions or node existence, but it's sufficient for a simple mutation.

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 coverage is 100%, so baseline is 3. The description does not add any parameter-specific meaning beyond what is already in the schema descriptions (nodeId and filename). No additional context or format guidance is provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Remove' and clearly identifies the resource 'a node and all its connections' in the context of 'the terrain graph'. This distinguishes it from sibling tools like add_node, connect_nodes, and disconnect_port, which have different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for deleting a node, but does not explicitly state when to use versus alternatives (e.g., disconnect_port for selective disconnection) or mention prerequisites like node existence. The context is clear but lacks exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

set_node_propertyA

Set a property value on a node. Properties vary by node type. Common properties: Seed (int), Duration (float), Scale (float), Style (string enum). Use get_node_details to see current properties and their values. Only non-default values are stored — setting a property to its default effectively removes it.

ParametersJSON Schema

Name	Required	Description
`value`	Yes	Value: number, string, boolean, or object like {X: 0.5, Y: 1.0}
`nodeId`	Yes	Node ID
`filename`	Yes	Path to .terrain file
`property`	Yes	Property name (case-sensitive, e.g. Seed, Duration, Scale, Style)

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Discloses that only non-default values are stored and setting to default removes the property. Does not mention error handling, validation, or whether changes persist immediately.

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?

Four concise sentences, each contributing unique information: purpose, examples, sibling reference, and default behavior. No wasted words; front-loaded with main action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, no output schema, and 4 parameters, the description covers purpose, property scope, how to check values, and property removal. Missing details on return values and error handling, but adequate for a simple property setter.

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 coverage is 100%, so baseline 3. Description adds value by listing common property names and reiterating the value type from schema, but does not significantly extend parameter understanding beyond 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?

Clearly states the action ('Set a property value on a node') and distinguishes from siblings by giving examples of common properties and referencing get_node_details. The verb+resource is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit guidance to use get_node_details to see current properties, implying when to read vs. write. Also explains how to remove a property (set to default). Missing explicit exclusions or when-not-to-use contexts.

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.

8 tool updatesv1.0.0Jul 21, 2026
- First observedbuild_terrain
- First observedcheck_gaea_status
- First observedcreate_terrain
- First observedget_node_details
- First observedlist_projects
- First observedread_terrain_graph
- First observedremove_node
- First observedset_node_property

Deploy Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0

Scored 2026-07-22 00:59 across 8 tools

Disambiguation5/5

Each tool targets a distinct operation on the terrain graph: environment check, file creation, graph reading, node inspection, property setting, node removal, building, and project listing. There is no overlap in purpose.

Naming Consistency5/5

All eight tools follow a consistent verb_noun pattern using snake_case (e.g., build_terrain, read_terrain_graph), which is predictable and easy to parse.

Tool Count5/5

With 8 tools, the set is well-scoped for a terrain generation workflow. It covers the essential CRUD-like operations without being bloated or too thin.

Completeness2/5

Critical tools are missing: there is no add_node or connect_nodes tool, despite being mentioned in the create_terrain description. This makes the typical workflow impossible for an agent, as it cannot add or wire nodes.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

asset-auto-generator
io.github.TranThienTrong
An MCP server that provides asset auto generator
Developer Tools App Automation
2
strata
ai.klavis
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Agent Orchestration Autonomous Agents Developer Tools
25,748
mcp-grokOAuth
io.github.AceDataCloud
MCP server for Grok Imagine AI video generation
AI & Machine Learning Image & Video Processing
31
mcp-flux-proOAuth
io.github.AceDataCloud
MCP server for Flux AI image generation
Image & Video Processing Multimedia Processing
23

Related MCP Servers

MCP Terraform Assistant
Cloud Platforms Developer Tools
guilhermeyoshida
A
license
Not graded
quality
D
maintenance
MCP server for managing Terraform infrastructure as code, enabling initialization, planning, applying, destroying, validating, and showing state of Terraform configurations.
Updated a year ago (2025-04-08 04:10 UTC)
1
MIT
Developer Toolbox MCP
Developer Tools File Systems Command Line
Apoorva5544
F
license
Not graded
quality
C
maintenance
A production-ready MCP server providing file, system, math, and text utilities through a simple CLI client.
Updated 3 months ago (2026-06-28 08:13 UTC)
-
gaea-mcp
Design Tools App Automation
nghia-peirth
F
license
A
quality
D
maintenance
MCP server for Gaea 2.0 terrain generation, enabling CLI build automation and .terrain file graph manipulation through natural language.
Updated 7 months ago (2026-02-22 11:57 UTC)
13
-
Zip Hive Scaffold
File Systems Developer Tools
Dqrshan
A
license
A
quality
B
maintenance
MCP server for bulk-creating files and folders for any project, with built-in templates and custom scaffold support.
Updated a month ago (2026-08-11 18:44 UTC)
5
10
MIT

gaea-mcp

前提条件

セットアップ

1. Gaea インストールパスの設定

2. 設定ファイルの作成

方法 A: .env ファイル（シンプル）

方法 B: .mcp.json（Claude Code 連携用）

環境変数一覧

3. 動作確認

使い方

Claude Code から使う

典型的なワークフロー

Tools

開発

ディレクトリ構成

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

方法 A: `.env` ファイル（シンプル）

方法 B: `.mcp.json`（Claude Code 連携用）