cesium-mcp

getLayerSchema

Read-onlyIdempotent

Inspect fields, entity counts, and metadata for a layer. For vector/3D Tiles, metadata.tileStyle returns the applied style expressions. Returns { success: boolean, data?: unknown, message?: string, error?: string }.

Instructions

Input Schema

Name	Required	Description	Default
`layerId`	Yes	Layer ID (get via listLayers)
`sessionId`	No	Target browser session ID for multi-browser routing (optional)

Output Schema

Name	Required	Description	Default
`data`	No
`error`	No
`message`	No
`success`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.139.19Aug 19, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "data": {},
+    "error": {
+      "type": "string"
+    },
+    "message": {
+      "type": "string"
+    },
+    "success": {
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "success"
+  ],
+  "type": "object"
+}

Changed1 schema field changedv1.139.18Aug 12, 2026
- removedInput schema / $schema
```
Removed value: -"http://json-schema.org/draft-07/schema#"
```
Changed2 schema fields changedv1.139.17Jul 29, 2026
- addedInput schema / properties / layerId / maxLength
```
Added value: +200
```
- addedInput schema / properties / layerId / minLength
```
Added value: +1
```
Addedv1.139.14Apr 30, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already establish the read-only, idempotent, non-destructive profile, so the description correctly spends its words on behavior instead. It adds the useful detail that for vector/3D Tiles the metadata.tileStyle field surfaces applied style expressions, which an agent would not know from annotations alone. It does not cover behavior for a bad or missing layerId, which keeps it out of the top band.

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?

Three short sentences, front-loaded with the capability and followed by the one non-obvious field note. The trailing return-envelope sentence is largely redundant given a formal output schema exists, so it does not fully earn 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?

A two-parameter read tool with full schema coverage, an output schema, and explicit read-only annotations needs little more than this. The description tells the agent what the call yields and one special-case field. Only the lack of failure-mode or per-layer-type context keeps it below 5.

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%, and layerId even points at listLayers as its source, so the schema does the heavy lifting. The description adds no meaning about layerId or sessionId beyond what the schema documents, which is the expected baseline here.

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?

The description opens with a specific verb and resource: 'Inspect fields, entity counts, and metadata for a layer.' That is clearly distinct from listLayers (enumeration) and updateLayerStyle (mutation). It stops short of naming a sibling or stating scope boundaries, but the purpose is unambiguous.

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 tileStyle note hints that this is the tool to call before or after styling, but there is no explicit 'use this when…' or 'use listLayers instead if…' guidance. The agent must infer from the sibling list when this beats queryEntities or getEntityProperties.

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