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., "@gaea-mcp Create terrain, add Mountain node, and build"
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 2.0 terrain generation tool の MCP サーバー。
CLI ビルド自動化と .terrain ファイルのグラフ操作を提供します。
Node.js v18 以上
Gaea 2.0 がインストール済みであること（Community / Professional）
ビルド機能には Gaea.Swarm.exe が必要です
Related MCP server: Agentic AI MCP Server
git clone <repo-url>
cd gaea-mcp
npm installサーバーは以下の優先順位で Gaea のインストール先を探します:
環境変数 GAEA_INSTALL_DIR（.env または .mcp.json で指定）
自動検出 — %LOCALAPPDATA%\Programs\Gaea 2.0 など一般的なパスを順に確認
通常のインストール（Gaea のデフォルトインストーラー）であれば自動検出されるため、明示的な設定は不要です。
カスタムパスにインストールした場合のみ、以下のいずれかで GAEA_INSTALL_DIR を設定してください。
指定するディレクトリには Gaea.exe と Gaea.Swarm.exe が含まれている必要があります。
.env と .mcp.json はどちらも .gitignore に含まれており、リポジトリには同梱されません。
利用環境に合わせてローカルで作成してください。
.env ファイル（シンプル）プロジェクトルートに .env を作成:
# Gaea のインストールディレクトリ（自動検出できる場合は省略可）
# GAEA_INSTALL_DIR=C:/Users/<ユーザー名>/AppData/Local/Programs/Gaea 2.0
# .terrain ファイルの保存先（省略時: ./projects）
# PROJECT_DIR=./projects
# ビルド出力先（省略時: ./output）
# OUTPUT_DIR=./output.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 インストールディレクトリ |
| いいえ |
|
|
| いいえ |
| ビルド出力ディレクトリ |
# サーバーの起動テスト（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 transportCtrl+C で終了してください。このサーバーは MCP クライアント（Claude Code 等）経由で使うものなので、 通常は直接起動する必要はありません。
上記の .mcp.json をプロジェクトルートに配置
Claude Code のプロジェクトディレクトリでこのリポジトリを開く
Claude に「地形を作って」と言えば、MCP ツール経由でノードグラフの作成・ビルドが可能
create_terrain → add_node (Mountain) → add_node (Erosion2) → connect_nodes → build_terrainTool | Description |
| Gaea の検出状態とパスを確認 |
| インストール済み Gaea のバージョン取得 |
| プロジェクトディレクトリの |
| Gaea.Swarm.exe で地形をビルド |
| 利用可能なノードタイプ一覧（120種、9カテゴリ） |
|
|
| 特定ノードの詳細プロパティ |
| 空の |
| ノードを追加 |
| ノードを削除 |
| ノード間を接続 |
| ポートの接続を解除 |
| ノードのプロパティを設定 |
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 からノードタイプを抽出するスクリプトAdd a node to the terrain graph. Use list_node_types to see available types and their ports. Common types: Mountain, Erosion2, Combine, SatMap, Export. Set initial properties for best results, e.g. Mountain: {Scale: 1.5, Height: 3}, Erosion2: {Duration: 15}, Combine: {Method: "Multiply"}, Mesher: {Format: "GLB"}. Position nodes left-to-right by increasing X (spacing ~300-500). Y=26250 for a single row. After adding, use connect_nodes to wire it into the graph.
| Name | Required | Description | Default |
|---|---|---|---|
| x | No | X position on graph canvas (default: 26500, increase by ~300 per node) | |
| y | No | Y position on graph canvas (default: 26250) | |
| name | No | Custom display name (defaults to the type name) | |
| filename | Yes | Path to .terrain file | |
| nodeType | Yes | Node type key from list_node_types (e.g. Mountain, Erosion2, Combine, Export) | |
| properties | No | Initial property values, e.g. {Seed: 12345, Duration: 10} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. Discloses addition behavior, positioning constraints, and property examples. Does not cover error handling, permissions, or persistence details, leaving gaps in behavioral transparency.
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?
Efficient multi-sentence structure with front-loaded purpose. Each sentence adds value (common types, properties, positioning, next steps). Slightly verbose but well-organized and readable.
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?
Covers purpose, type discovery, property examples, positioning, and follow-up actions. Lacks output description (no output schema), but for an 'add' tool the context is sufficiently complete for typical use.
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% (baseline 3). Description adds significant semantic value: example property values per type (Mountain, Erosion2, etc.) and explicit positioning logic (X spacing, Y default). Enhances understanding beyond raw 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?
Clearly states 'Add a node to the terrain graph' with specific verb and resource. Differentiates from siblings by mentioning list_node_types for type discovery and connect_nodes for wiring, thus distinguishing its role.
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?
Provides clear context: use after list_node_types and before connect_nodes. Includes positioning tips and common type examples. Lacks explicit 'when not to use' but effectively guides typical workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 |
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.
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.
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.
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.
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.
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 if Gaea is installed and report executable paths, project directory, and readiness. Call this first to verify the environment.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Connect two nodes by wiring an output port to an input port. Default ports: "Out" → "In" (works for most simple chains). For nodes with multiple ports (e.g. Combine has Input2, Mask; Erosion2 outputs Flow, Wear, Deposits), specify the port names explicitly. For Combine, set Method property before connecting (e.g. "Multiply" for masking, "Max" for blending terrains, "Screen" for color compositing). Each input port accepts only one connection — connecting replaces any existing connection on that input.
| Name | Required | Description | Default |
|---|---|---|---|
| toPort | No | Destination input port name (default: "In") | In |
| filename | Yes | Path to .terrain file | |
| fromPort | No | Source output port name (default: "Out") | Out |
| toNodeId | Yes | Destination node ID (the node receiving data) | |
| fromNodeId | Yes | Source node ID (the node producing data) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses key behavioral traits: connecting replaces existing connections on the input port, and for certain nodes (like Combine) the Method property must be set first. However, it does not mention whether changes are immediately persisted or reversible, but the core behavior is transparent.
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 concise at 5 sentences, well-structured with a clear progression: purpose, default usage, special cases, and important constraint. No redundant information.
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?
The description covers the action and important nuances but lacks information about return values or post-call state. Given no output schema and the tool's nature (mutation), completeness could be improved by mentioning what happens after connection (e.g., the graph is updated) or verifying nodes exist. However, it is fairly complete for a connect operation.
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?
With 100% schema coverage, the baseline is 3. The description enhances parameter understanding by explaining default port values ('Out' → 'In'), giving concrete examples for nodes with multiple ports, and tying the filename parameter to a .terrain file. This adds value beyond the schema definitions.
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 connects two nodes by wiring an output port to an input port, with explicit default ports and examples for nodes with multiple ports. It distinguishes itself from siblings like 'disconnect_port' by focusing on connection, not disconnection.
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 explicit guidance on when to use default ports, how to specify port names for multi-port nodes (e.g., Combine, Erosion2), and the prerequisite of setting the Method property for Combine nodes before connecting. It also warns that each input port accepts only one connection and connecting replaces existing ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Filename without extension (e.g. 'my_mountain' creates my_mountain.terrain) |
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.
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.
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.
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.
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.
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.
Remove the incoming connection on a specific input port of a node.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | Node ID | |
| filename | Yes | Path to .terrain file | |
| portName | Yes | Input port name to disconnect (e.g. In, Mask, Alternate, Input2) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose side effects, reversibility, permissions, or prerequisites (e.g., node must exist, connection must be present).
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 of 12 words, front-loading the action and resource with zero wasted words. It is appropriately sized 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?
For a straightforward disconnect action, the description covers the purpose but lacks behavioral context (e.g., whether the operation is reversible, if the node must be disconnected first, or any prerequisites). Schema covers parameters, output schema is absent so return value is not explained.
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 covers 100% of parameters with descriptions, providing meaning for 'nodeId', 'filename', and 'portName'. The description adds no additional semantic value beyond what the schema already 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 clearly states the action ('Remove') and the resource ('incoming connection on a specific input port of a node'), differentiating it from siblings like 'connect_nodes' (opposite) and 'remove_node' (removes entire node).
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 usage when wanting to disconnect a port, but lacks explicit guidance on when not to use it or alternatives (e.g., 'connect_nodes' is the reverse operation).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the installed Gaea version number.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Explicitly read-only (get version). No annotations, but description accurately reflects behavior. Lacks return format details, but acceptable for a simple query.
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 sentence, front-loaded, no unnecessary 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?
Fully describes the tool's function given zero complexity and no annotations or output schema.
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?
No parameters; schema has 100% coverage. Description adds no parameter info, but none needed.
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?
Clearly states it retrieves the installed Gaea version. Distinct from siblings like list_node_types or check_gaea_status.
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 versus other tools. Simple tool but lacks any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all properties and port connections of a specific node. Use read_terrain_graph first to find node IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | Node ID (from read_terrain_graph output) | |
| filename | Yes | Path to .terrain file |
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.
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.
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.
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.
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.
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 available Gaea node types with their categories and port definitions. Categories: Primitive, Terrain, Simulate, Surface, Modify, Derive, Colorize, Utility, Output. Use the "key" value (e.g. "Mountain") as the nodeType parameter in add_node.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Filter by category name (e.g. Terrain, Simulate, Modify, Output) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description is adequate but minimal. It indicates a read-only list operation but does not specify behavioral aspects like side effects or authorization requirements. It could be more explicit about being non-destructive.
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 concise with two sentences, front-loading the purpose and immediately explaining the usage pattern. Every word adds value with no unnecessary repetition or fluff.
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 absence of an output schema, the description sufficiently covers what the tool returns (categories and port definitions) and how to use the output. It is complete enough for an agent to understand and invoke the tool 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 already describes the category parameter with examples. The description adds concrete category names (e.g., Terrain, Simulate), which provides direct enumeration beyond the schema's generic description, enhancing the agent's ability to filter correctly.
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 lists Gaea node types with categories and port definitions, and provides a concrete list of categories. This clearly identifies the resource and action, distinguishing it from sibling tools like get_node_details.
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 clearly explains that the 'key' value from the output should be used as the nodeType parameter in add_node, providing direct guidance on when to use the tool. However, it does not explicitly state when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List .terrain files in the project directory. Use absolute paths for files outside this directory.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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 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.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | Path to .terrain file (name in project dir or absolute path) |
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.
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.
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.
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.
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.
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 a node and all its connections (both incoming and outgoing) from the terrain graph.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | Node ID to remove | |
| filename | Yes | Path to .terrain file |
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.
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.
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.
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.
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.
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 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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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) |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0add_nodebuild_terraincheck_gaea_statusconnect_nodescreate_terraindisconnect_portget_gaea_versionget_node_detailslist_node_typeslist_projectsread_terrain_graphremove_nodeset_node_propertyScored across 13 tools
Each tool targets a distinct operation: listing node types, getting node details, checking status, version, projects, building, reading graph, creating terrain, adding/removing nodes, connecting/disconnecting, and setting properties. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern (e.g., list_node_types, set_node_property, build_terrain), with no mixing of conventions.
13 tools are well-scoped for a terrain generation MCP server, covering environment checks, project management, graph creation/editing, and building without excess or deficiency.
The tool surface covers the full workflow: environment setup, terrain creation, node manipulation (add/remove/connect/disconnect/properties), graph inspection, and building. No critical gaps are evident for the domain.
MCP server for Grok Imagine AI video generation
MCP server for Flux AI image generation
MCP server for generating rough-draft project plans from natural-language prompts.
Generate game-ready 3D models, textures, and audio from natural language, over MCP.
