Skip to main content
Glama
CityEngine Cloud MCP Server

CityEngine Cloud MCP Server

get_demo

Fetches public snapshot details of a CityEngine showcase demo—including property schema, material and node counts, and engine timing—to support parameter design without paid CGA source.

Instructions

查看某个官网 demo 案例的详情:属性面板定义、材质数、节点数、引擎耗时。

注意:demo 的 CGA 源码属付费内容(官网商城),本工具返回公开快照信息 (属性 schema / 规模 / 引擎指标),适合做参数设计参考。

Args: demo_id: list_demos 返回的 id,如 building-glass-20260928。

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": {
      "demo_id": "<demo_id>"
    },
    "name": "get_demo"
  }
}

Input Schema

NameRequiredDescriptionDefault
demo_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/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 meaningful work: it discloses that the CGA source is paid mall content and therefore not returned, and that only a public snapshot (schema/scale/engine metrics) is exposed. It does not state auth requirements, rate limits, or explicitly that the call is read-only, though '查看' implies it.

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 purpose, then a scoped caveat, then the argument. Every sentence carries information. The Args block is slightly redundant with the schema field name but adds the id-source and format detail, so it earns its place.

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?

A single-parameter read tool with no output schema, and the description enumerates the returned fields and the one significant exclusion (paid CGA source). Nothing an agent needs in order to decide to call it and interpret the result is missing.

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?

Schema coverage is 0%, so the description must compensate, and it does: demo_id is defined as the id returned by list_demos plus a concrete format example. That is enough to construct the argument correctly; it lacks only edge-case behavior such as what happens for an unknown or paid-only id.

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?

States a specific verb and resource (view details of a single official-site demo case) and enumerates exactly what comes back: attribute panel definition, material count, node count, engine timing. That enumeration separates it cleanly from the sibling list_demos, which only enumerates cases.

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 Args note ties the tool to list_demos as the id source and gives a concrete id example (building-glass-20260928), and the note explains the intended use case: parameter design reference. It stops short of naming alternatives or stating when not to call it (e.g. when full CGA source is needed, use parse_cga/generate_cga instead).

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