Skip to main content
Glama
Sign In
CityEngine Cloud MCP Server

CityEngine Cloud MCP Server

by cgajs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

parse_cga

Parses CGA rule source into 3D glTF/glb models using CityEngine, applying attribute overrides and initial plot shapes, with reproducible seeds and downloadable output.

Instructions

用 CityEngine 引擎解析 CGA 规则源码，生成三维模型（glTF/glb）。

Args: cga_source: CGA 规则源码全文（手写或 generate_cga 的产物）。 attributes: CGA attr 覆盖，如 {"height": 30}；键必须在规则的 attr 声明内。 initial_shape: 初始地块多边形 {"type":"Polygon","pts":[[x,z],...]}，米制； 缺省用 30m x 20m 调试地块。 seed: 随机种子，固定后可复现结果。 download_glb: 是否把 glb 下载到本地（默认 True）。 output_dir: glb 落盘目录（默认环境变量 CITYENGINE_OUTPUT_DIR 或当前目录下 cityengine_mcp_output/）。 timeout_s: 轮询 job 的最长秒数（上限 300）。

Returns: job_id、模型统计(nodes/vertices/triangles/textures_embedded)、glb 本地路径、 签名下载地址(24h 有效)、sha256、计费用量、告警列表。

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "cga_source": "<cga_source>"
    },
    "name": "parse_cga"
  }
}

Input Schema

NameRequiredDescriptionDefault
seedNo
timeout_sNo
attributesNo
cga_sourceYes
output_dirNo
download_glbNo
initial_shapeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses an asynchronous job model (job_id plus 300s polling cap), a default 30m x 20m debug plot when initial_shape is omitted, seed reproducibility, download-to-disk default True, output directory resolution via CITYENGINE_OUTPUT_DIR, a 24h-expiring signed URL, and billing/warnings in the return. Not disclosed: authentication requirements or rate/quota limits, which matters for a billed server-side rendering call.

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?

Front-loaded with a one-line purpose, then a scannable Args block and a Returns block; nearly every line adds constraint or default information. Slightly verbose docstring formatting and the inline multi-line wrapping for initial_shape/output_dir cost a little readability, but no sentence is filler.

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

Completeness5/5

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

There is no output schema, yet the Returns block enumerates job_id, model statistics (nodes/vertices/triangles/textures_embedded), local glb path, signed download URL with validity, sha256, billing usage, and warnings. Combined with input documentation for all 7 params, an agent has everything needed to call this billed, asynchronous tool correctly.

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

Parameters5/5

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

Schema coverage is 0% (titles only, no descriptions), so the description must do all the work and it does: every one of the 7 parameters gets meaning beyond its name. Notably it constrains attributes keys to the rule's declared attrs, specifies initial_shape's exact structure {"type":"Polygon","pts":[[x,z],...]} in meters, states the timeout cap of 300, and gives defaults plus the env-var fallback for output_dir.

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

Purpose4/5

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

First sentence gives a specific verb (parse CGA rule source with the CityEngine engine) and an explicit output (3D model in glTF/glb). It also positions itself downstream of generate_cga by noting the source may be hand-written or a generate_cga product, which helps separate the two. It does not distinguish itself from generate_model, the other plausibly overlapping sibling.

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?

Usage is only implied: the agent can infer 'call this when you already have CGA source and need a model' from the cga_source arg description. There is no explicit when-to-use/when-not-to-use statement and no routing to an alternative tool when the input is absent (e.g., call generate_cga first).

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

Deploy Server

Other Tools