Which integrations are available for this server?

Provides an optional LangChain agent CLI that uses MCP tools to interact directly with the 3DCityDB database. Provides integration with Ollama as a local LLM backend for the Gradio chat UI, allowing natural-language querying of the 3DCityDB. Provides integration with OpenAI's API as one of the supported LLM backends for the Gradio chat UI, allowing natural-language querying of the 3DCityDB.

How do I use 3DCityDB MCP Server?

1. Click on "Install 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., "@3DCityDB MCP Server find all buildings taller than 50 meters" 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.

3DCityDB MCP Server

Q: What can you do with this server?

This server enables AI assistants to interact with semantic 3D city models (CityGML) stored in a 3DCityDB v5 PostgreSQL database using natural language. Key capabilities include: * Read-only SQL execution: Run SELECT/WITH queries against the 3DCityDB (max 500 rows, writes blocked). * Schema discovery: Retrieve table structures, CityGML object class hierarchies (e.g. Building, Vegetation, LandUse), column details, and foreign key relationships. * Property resolution: Walk superclass hierarchies, filter existing properties, and resolve codelist meanings for any object class. * Generic attributes: Fetch user-defined attributes with automatic categorical detection, distinct string values, and numeric min/max ranges. * Database context: Retrieve coordinate system (SRS/EPSG), bounding box, feature counts, available Levels of Detail (LoDs), null value percentages, and supported spatial operations. * SQL guidance & examples: Access best practices, indexed columns, optimization tips, and example queries filtered to object classes present in the database. * Spatial analysis: Use SFCGAL functions (e.g. CG_Volume, CG_3DArea) for advanced 3D geometry calculations (requires PostGIS with SFCGAL support). * System prompt assembly: Orchestrate all dynamic information into a single structured prompt for LLM consumption (with compact mode for smaller context windows). * Session & feedback management: Create/manage sessions, narrow scope to specific modules or classes, view conversation history, and submit query ratings/error logs. * Gradio chat UI (Docker deployments): Browser-based interface with multi-LLM support (OpenAI, Anthropic, Ollama), SQL inspector, MCP inspector, and one-click CityGML/CityJSON import (fullstack mode).

Official

by tum-gis

Overview Schema Related Servers Score Discussions

Python

Hybrid

3DCityDB MCP Server

A Model Context Protocol (MCP) server giving AI assistants direct, natural language access to semantic 3D city models in CityGML managed within a 3DCityDB v5 geodatabase.

It dynamically resolves CityGML object classes, properties, codelists, and generic attributes from the database so the AI can answer both spatial and semantic queries stated in natural language, write and execute SQL queries, and reason about CityGML data — without any manual prompt engineering. By including the MCP server in agentic coding environments, it becomes easy to create software that can read and write complex structured 3D city models compliant to the OGC CityGML standard (and using 3DCityDB V5 as the data repository).

Furthermore, a Chat Assistant is included offering a simple GUI for interactive query asking, reasoning, and answering. It is an agentic AI tool based on LangChain utilising the ReAct pattern for carrying out multi-step reasoning and automated error corrections. The Chat Assistent currently can be configured to work with OpenAI and Anthropic commercial LLMs as well as with locally running Ollama LLMs. For example, when using the qwen3.6:27b LLM running in Ollama, the Chat Assistant is capable of performing very complex analyses on any kind of stored 3D city model.

The evaluation of the MCP Server for the paper (link coming soon) was done using 100 queries of 4 different complexity levels. The complete list of the queries can be found here.

Features

Dynamic schema resolution — walks the CityGML class hierarchy to discover available object classes and their properties
Property filtering — only includes properties that actually exist in the database
Country-aware codelist resolution — qualified <namespace>:<Class>.<attribute> keys, country selected via the database EPSG code; only codes actually present in the data are exposed
Generic attribute enrichment — automatic categorical detection for generic attributes
Read-only query execution — run_query enforces SELECT-only; writes are blocked
Prompt assembly — assemble_prompt orchestrates all tools into a complete system prompt in one call
Gradio chat UI — browser-based interface with multi-LLM support (Anthropic, OpenAI, Ollama)
CityGML 1.0-3.0/CityJSON import — one-click import via the Gradio UI (fullstack Docker mode only)

Related MCP server: PostGIS Yukon MCP

Deployment Options

There are three ways to run the 3DCityDB MCP Server:

	Option 1: PyPI	Option 2: Docker BYOD	Option 3: Docker Fullstack
Best for	Claude Code / Claude Desktop power users	Existing 3DCityDB instances	Starting from a `.gml` file
Requires	Python 3.10+, running 3DCityDB	Docker, running 3DCityDB	Docker only
Gradio UI	No (uses your AI client directly)	Yes (`localhost:7860`)	Yes (`localhost:7860`)
CityGML/CityJSON import	Manual	Manual	Via Gradio UI
Database	Your own	Your own	Bundled (PostgreSQL + PostGIS + SFCGAL)

Option 1: PyPI Package

Install the MCP server as a Python package and connect it to Claude Code, Claude Desktop, or any MCP-compatible client.

Prerequisites

Python 3.10 or later
A running 3DCityDB v5 PostgreSQL instance with PostGIS

Installation

pip install 3dcitydb-mcp-server

Or install from source for development:

git clone https://github.com/tum-gis/3dcitydb-mcp-server.git
cd 3dcitydb-mcp-server
pip install -e .

Configuration

Copy the example environment file and edit it:

# Linux / macOS
cp .env.example .env

# Windows (PowerShell)
Copy-Item .env.example .env

Then fill in your connection details:

# 3DCityDB PostgreSQL connection
CITYDB_HOST=localhost
CITYDB_PORT=5432
CITYDB_NAME=citydb
CITYDB_USER=postgres
CITYDB_PASSWORD=your_password_here
CITYDB_SCHEMA=citydb

# Query behaviour (optional)
CATEGORICAL_THRESHOLD=20
SAMPLE_VALUES_COUNT=5

# LLM API keys (only needed for the LangChain agent CLI, not for Claude Code/Desktop)
ANTHROPIC_API_KEY=sk-ant-...
# OPENAI_API_KEY=sk-...
# OLLAMA_BASE_URL=http://localhost:11434

The server loads .env automatically by searching upward from the working directory.

Verify your installation

3dcitydb-doctor

Checks Python version, required packages, database connectivity, PostGIS/SFCGAL extensions, and the 3DCityDB v5 schema. Exits 0 if all critical checks pass.

Connect to Claude Code (recommended)

From the directory containing your .env:

claude mcp add 3dcitydb -- 3dcitydb-mcp
claude

The MCP server starts automatically when you open a Claude session. Use /mcp inside the session to confirm it is connected.

Connect to Claude Desktop

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "3dcitydb": {
      "command": "3dcitydb-mcp",
      "cwd": "/path/to/your/project"
    }
  }
}

Restart Claude Desktop. The MCP server will be listed in Settings → Developer → MCP Servers.

SSE transport (remote / production)

Run the server over HTTP for remote clients:

3dcitydb-mcp-sse --host 0.0.0.0 --port 8080

Clients connect via: http://your-server:8080/sse
Health check: http://your-server:8080/health

LangChain agent CLI (optional)

A standalone CLI agent that uses the MCP tools directly:

3dcitydb-agent

Requires ANTHROPIC_API_KEY, OPENAI_API_KEY, or OLLAMA_BASE_URL in your .env.

Option 2: Docker — BYOD (Bring Your Own Database)

Run the Gradio chat UI as a Docker container, connected to your existing 3DCityDB instance.

Prerequisites

Docker with Compose (V2)
A running 3DCityDB v5 PostgreSQL instance accessible from the Docker host

⚠️ Spatial function support: The AI agent uses SFCGAL functions (CG_Volume, CG_3DArea, CG_MakeSolid) for geometry calculations. These require PostGIS to be compiled with SFCGAL support.
If your database lacks SFCGAL, volume and 3D area queries will fail silently or return errors. To get full spatial support, use Option 3 (Fullstack) instead — it ships a pre-patched 3dcitydb-pg image with PostGIS + SFCGAL already enabled.
You can verify SFCGAL availability on your instance with:
SELECT postgis_sfcgal_version();
If this returns an error, spatial queries will not work.

Quick Start

# 1. Clone the repository (or just download docker-compose.byod.yml + .env.example)
git clone https://github.com/tum-gis/3dcitydb-mcp-server.git
cd 3dcitydb-mcp-server/production

# 2. Copy and edit the environment file
cp .env.example .env   # Linux / macOS
# Copy-Item .env.example .env   # Windows PowerShell

Edit .env with your database connection and at least one LLM API key:

# Your existing 3DCityDB instance
CITYDB_HOST=your-db-host
CITYDB_PORT=5432
CITYDB_NAME=citydb
CITYDB_USER=citydb
CITYDB_PASSWORD=your_password
CITYDB_SCHEMA=citydb

# At least one LLM provider (the UI auto-selects based on what is available)
ANTHROPIC_API_KEY=sk-ant-...
# OPENAI_API_KEY=sk-...
# OLLAMA_BASE_URL=http://host.docker.internal:11434

# 3. Pull the pre-built image and start (works on all platforms, no build needed)
docker compose -f docker-compose.byod.yml up -d

# 4. Open the UI
# http://localhost:7860

The pre-built image (khaoulakanna1/citydb-mcp-agent:latest) is pulled automatically from Docker Hub on first run.

What it includes

Gradio chat UI — natural-language interface to your 3DCityDB
MCP server — spawned automatically as a subprocess inside the container
Auto provider detection — the UI selects Anthropic, OpenAI, or Ollama based on which keys are present in .env

Gradio UI overview

Tab	What it does
Chat	Send natural-language questions; the agent writes and executes SQL automatically
SQL Inspector	Shows the last SQL query dispatched to the database (below the chat input)
MCP Inspector	Lists all active MCP tools and lets you refresh the assembled system prompt
System Prompt	Displays the full assembled system prompt sent to the LLM — useful for debugging

While the agent is working, the chat bubble shows live status: Thinking… → Running query… → Interpreting results…

Ollama users: Models without native tool-calling support (e.g. Qwen3 with extended thinking enabled) are handled automatically via a prompt-based fallback — no configuration needed. Expect roughly two LLM round-trips per question instead of one.
Prompt mode (auto): Models with ≥ 14 B parameters receive the full system prompt; smaller models receive a compact version to fit the context window. Override this per-query with the Prompt mode radio button in the UI (Auto / Compact / Full).

Building locally (optional)

If you want to build the image from source instead of pulling it:

# Linux / macOS
docker compose -f docker-compose.byod.yml up -d --build

# Windows — Docker BuildKit has a known ordering bug on Windows/NTFS.
# Disable it for local builds:
$env:DOCKER_BUILDKIT=0; docker compose -f docker-compose.byod.yml up -d --build

Windows note: The DOCKER_BUILDKIT=0 flag is only needed when building locally. Pulling the pre-built image (docker compose up -d without --build) works on Windows without any workaround.

Useful commands

# View logs
docker compose -f docker-compose.byod.yml logs -f

# Stop
docker compose -f docker-compose.byod.yml down

Option 3: Docker — Fullstack (Bundled PostgreSQL)

Run everything — PostgreSQL (with PostGIS and SFCGAL), the 3DCityDB schema, the MCP server, and the Gradio UI — in a single Docker Compose stack. No pre-existing database needed.

Prerequisites

Docker with Compose (V2)
A CityGML or CityJSON file to import (optional — the database starts empty)

Quick Start

# 1. Clone the repository (or just download docker-compose.fullstack.yml + .env.example)
git clone https://github.com/tum-gis/3dcitydb-mcp-server.git
cd 3dcitydb-mcp-server/production

# 2. Copy and edit the environment file
cp .env.example .env   # Linux / macOS
# Copy-Item .env.example .env   # Windows PowerShell

Edit .env:

# PostgreSQL settings for the bundled database
POSTGRES_DB=citydb
POSTGRES_USER=citydb
POSTGRES_PASSWORD=citydb
SRID=25832          # EPSG code for your data's coordinate system

# At least one LLM provider
ANTHROPIC_API_KEY=sk-ant-...
# OPENAI_API_KEY=sk-...
# OLLAMA_BASE_URL=http://host.docker.internal:11434

# 3. (Optional) Place your CityGML file in the data directory
mkdir -p data
cp /path/to/your/city.gml data/

# 4. Pull the pre-built image and start (works on all platforms, no build needed)
docker compose -f docker-compose.fullstack.yml up -d

# 5. Open the UI
# http://localhost:7860

Both images are pulled automatically from Docker Hub on first run. The first start takes ~60 seconds while PostgreSQL initialises.

Building locally (optional)

# Linux / macOS
docker compose -f docker-compose.fullstack.yml up -d --build

# Windows — disable BuildKit to avoid a known NTFS ordering bug:
$env:DOCKER_BUILDKIT=0; docker compose -f docker-compose.fullstack.yml up -d --build

Windows note: Only needed when building locally with --build. The default docker compose up -d (pull from Docker Hub) works on Windows without any workaround.

Import CityGML/CityJSON

Once the UI is open:

Go to the Import CityGML/CityJSON tab
Click Refresh to see files in ./production/data/
Select your file and click Import
Watch the live log — the import runs using the Docker container ghcr.io/3dcitydb/citydb-tool. Note, this container is pulled automatically, if it is not available in your Docker environment so far. In this case, please be patient as it might take 30 seconds before the import process really starts.

The data directory is mounted at ./production/data/ on the host and /app/data/ inside the container.

Coordinate reference system

Set SRID to the EPSG code for your data before the first start. Common values:

Region	CRS	SRID
Germany (UTM Zone 32N)	ETRS89 / UTM Zone 32N	`25832`
Germany (UTM Zone 33N)	ETRS89 / UTM Zone 33N	`25833`
USA (NAD83 / UTM Zone 14N)	NAD83	`26914`
Global (WGS84)	WGS 84	`4326`

Useful commands

# View logs
docker compose -f docker-compose.fullstack.yml logs -f

# Stop (preserves database volume)
docker compose -f docker-compose.fullstack.yml down

# Stop and delete all data
docker compose -f docker-compose.fullstack.yml down -v

Configuration Reference

All options are set via environment variables (.env file or Docker Compose environment block).

Database connection

Variable	Default	Description
`CITYDB_HOST`	`localhost`	PostgreSQL host
`CITYDB_PORT`	`5432`	PostgreSQL port
`CITYDB_NAME`	`citydb`	Database name
`CITYDB_USER`	`citydb`	Database user
`CITYDB_PASSWORD`	(required)	Database password
`CITYDB_SCHEMA`	`citydb`	3DCityDB schema name
`DATABASE_URL`	(auto-built)	Full PostgreSQL URL (overrides individual vars)

Fullstack only

Variable	Default	Description
`POSTGRES_DB`	`citydb`	Database name for bundled PostgreSQL
`POSTGRES_USER`	`citydb`	Database user for bundled PostgreSQL
`POSTGRES_PASSWORD`	`citydb`	Database password for bundled PostgreSQL
`SRID`	`25832`	EPSG code for the 3DCityDB spatial reference
`POSTGIS_SFCGAL`	`true`	Enable SFCGAL extension (required for `CG_Volume`, `CG_3DArea`)

LLM providers

At least one must be configured for the Docker variants. The Gradio UI auto-selects the provider based on what is available (Anthropic → OpenAI → Ollama, in that priority order).

Variable	Description
`ANTHROPIC_API_KEY`	Anthropic API key (`sk-ant-...`)
`OPENAI_API_KEY`	OpenAI API key (`sk-...`)
`OLLAMA_BASE_URL`	Ollama base URL (e.g. `http://host.docker.internal:11434`)

Query behaviour

Variable	Default	Description
`CATEGORICAL_THRESHOLD`	`20`	Max distinct values before a column is treated as free text (only applied when no known codelist exists)
`SAMPLE_VALUES_COUNT`	`5`	Number of sample values shown per non-categorical column

Country-specific codelists

Code-type properties (core:Code) are resolved against country-specific codelist definitions. The country is selected from the database EPSG code (database_srs), falling back to a generic DEFAULT block for unknown countries:

DE (EPSG 25831–25833, 31466–31469, 5650) — ALKIS/AdV: function (31 codes), usage, roofType (roof form)
JP (EPSG 6668–6692, 2443–2461) — J-PLATEAU/MLIT: class, roofType (29 codes), usage
DEFAULT — SIG3D-standard roofType

Each codelist is keyed by a qualified composite key of the form <namespace-alias>:<Classname>.<attribute> — e.g. bldg:Building.function. The alias comes from the 3DCityDB namespace.alias column and the class name is the concrete feature class. Lookup is exact (case-insensitive); there is no fallback to bare attribute names, so same-named attributes in different classes (e.g. bldg:Building.function vs. brid:Bridge.function) never collide. Only codes that actually occur in the imported data are exposed to the LLM, with no artificial cap.

Codelists are defined in src/citydb_mcp/tools/dynamic_tools.py (COUNTRY_CODELISTS). Adding a class or country later (e.g. bldg:BuildingPart.*) is a pure data change — no code changes required.

Ollama tuning (optional)

Variable	Default	Description
`OLLAMA_NUM_CTX`	`32768`	Context window size (tokens) passed to the Ollama model
`LOCAL_MAX_TOKENS`	`16000`	Maximum tokens the local model may generate per response
`OLLAMA_TIMEOUT`	`300`	Timeout in seconds for Ollama requests

Available MCP Tools

Static (cached per session)

Tool	Description
`get_database_schema`	3DCityDB v5 table structures and foreign key relationships
`get_query_guidelines`	SQL best practices and optimisation tips for 3DCityDB

Dynamic (called at session start)

Tool	Description
`scan_objectclasses`	Discover available object classes with full CityGML hierarchy
`resolve_properties(objectclass_id)`	Resolve properties with codelists for a given class
`get_generic_attributes`	Generic attributes with categorical detection
`get_db_context_snapshot`	SRS, bounding box, feature counts, database statistics
`get_lod_config`	Available Levels of Detail in the database
`get_examples(objectclass_ids)`	SQL examples filtered to existing object classes

Runtime (per query)

Tool	Description
`run_query(sql)`	Execute read-only SQL (SELECT/WITH only) against 3DCityDB
`get_session_context`	Session management and state
`update_module_selection`	Narrow scope to specific object classes
`get_history`	Conversation history for a session
`submit_feedback`	Log query feedback

Assembly

Tool	Description
`assemble_prompt`	Orchestrates all tools into a complete system prompt in one call

Architecture

  Claude Code / Claude Desktop / any MCP client
                      │
               MCP Protocol (stdio / SSE)
                      │
       ┌──────────────┴──────────────┐
       │   3DCityDB MCP Server       │
       │   assemble_prompt()         │
       │   scan_objectclasses()      │
       │   run_query()               │
       └──────────────┬──────────────┘
                      │
                 3DCityDB v5
               (PostgreSQL + PostGIS)


  Browser ──► Gradio UI (port 7860)           [Docker variants only]
                      │
          ┌───────────┴────────────┐
          │                        │
   Anthropic / OpenAI          Ollama (local)
   LiteLLM cloud backend       LangChain ReAct
                                (ChatOllama)
          │                        │
          └───────────┬────────────┘
                      │
               MCP Client (spawns citydb-mcp subprocess)
                      │
               3DCityDB MCP Server
                      │
                 3DCityDB v5

Citation

This work was developed at the Chair of Geoinformatics, TUM, in the group of Prof. Dr. Thomas H. Kolbe.

License

The 3DCityDB MCP server is distributed under the Apache License 2.0. See LICENCE for details.

Available Tools

14 tools

assemble_promptA

Assembles the complete system prompt by orchestrating all static and dynamic tools. Returns a structured prompt string containing database schema, object classes with resolved properties and codelists, generic attributes, spatial context, and optionally SQL examples and query guidelines. Set include_query_agent_extras=false for non-query agents.

ParametersJSON Schema

Name	Required	Description	Default
`include_query_agent_extras`	No	Include SQL examples and query guidelines (default: true)
`compact`	No	Compact rendering for local models with small context windows (default: false)

TDQS

A4.4/5.0

Behavior3/5

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

No annotations provided, so the description must carry the full burden. It describes the return value and orchestration but does not disclose side effects, safety, or performance characteristics. The read-only nature is implied but not explicit.

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 with no fluff. First sentence defines purpose and output; second sentence provides key parameter usage. Every word 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?

Given no output schema, the description thoroughly lists the components of the returned prompt and handles both parameters. It covers the essential information for an agent to understand what the tool returns and when to use parameters.

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 100% and the description adds meaningful context beyond the schema: include_query_agent_extras is linked to non-query agents, compact is for local models. This adds semantic value.

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 'Assembles the complete system prompt by orchestrating all static and dynamic tools', specifying verb, resource, and scope. It distinguishes from sibling tools (which provide individual components) by being an orchestrator.

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 explicit guidance on parameter usage ('Set include_query_agent_extras=false for non-query agents'), but does not explicitly state when to use this tool versus alternatives like get_database_schema. Context implies usage for full prompt assembly.

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

get_database_schemaA

Returns the 3DCityDB v5 table structures, column details, and foreign key relationships. Called once and cached.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

Despite no annotations, the description conveys essential behavior: it is a read operation with caching. No 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?

A single sentence that efficiently communicates the action and caching behavior. No extraneous information.

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?

Given zero parameters and no output schema, the description fully explains the tool's purpose and return content, making it complete for an agent.

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 schema coverage is 100%. The description adds context on what is returned, exceeding the baseline expectation.

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 specifies the exact resource ('3DCityDB v5 table structures, column details, and foreign key relationships') and action ('returns'), clearly distinguishing it from siblings like 'get_db_context_snapshot'.

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 states 'Called once and cached,' guiding the agent to avoid repeated calls, though no alternative tools or when-not scenarios are mentioned.

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

get_db_context_snapshotA

Returns database-level context: coordinate system, EPSG code, bounding box, feature counts per class, available LoDs, null value percentages, and supported spatial operations.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior3/5

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

No annotations exist, so the description must carry the full burden. It correctly implies a read operation by naming return items, but does not explicitly state read-only behavior, side effects, performance, or authorization needs. It adds some value beyond the name by detailing outputs, but not enough to fully compensate for missing annotations.

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 sentence with no wasted words. It front-loads the purpose ('Returns database-level context') followed by a colon and a succinct list of returned items. Every part is necessary and clearly communicates the tool's output.

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 has no output schema, the description lists all significant return fields, making it relatively complete for a simple retrieval tool. However, it does not mention the format of the returned data (e.g., JSON object) or any edge cases (e.g., when context is unavailable). It provides sufficient information for most scenarios.

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 no parameters, and the input schema is fully covered (100%). The description does not need to explain parameters. The baseline of 4 applies because there are no parameters to document.

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 returns 'database-level context' and lists specific items (coordinate system, EPSG code, etc.), making the purpose unambiguous. The verb 'returns' and the resource 'database-level context' are specific and distinct from siblings like 'get_database_schema' which returns different information.

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?

The description provides no guidance on when to use this tool versus alternatives such as 'get_database_schema' or 'get_session_context'. There is no mention of prerequisites, limitations, or typical use cases. The agent must infer usage from the tool name and list of return items.

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

get_examplesA

Returns SQL query examples filtered to only include examples for object classes that exist in the database.

ParametersJSON Schema

Name	Required	Description	Default
`objectclass_ids`	Yes	List of available objectclass IDs to filter examples

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description must fully convey behavior. It only mentions filtering, but fails to disclose whether the operation is read-only, what happens with invalid IDs, the output format, or any side effects.

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 sentence, front-loaded with the action, and contains no unnecessary words. Every word contributes to understanding the tool's purpose.

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

Completeness3/5

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

For a simple one-parameter tool, the description is minimally complete. However, it lacks details about the return format, error handling, and any constraints on the objectclass_ids, which would be necessary for an agent to invoke it confidently without relying on prior knowledge.

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 fully documents the only parameter (objectclass_ids) with a description similar to the tool's description. The tool description adds no additional meaning beyond what the schema already provides, matching the baseline for high schema coverage.

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 returns SQL query examples, and specifies a filtering condition to only include examples for existing object classes. This distinguishes it from sibling tools like get_database_schema or run_query.

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 when to use: when you need filtered SQL examples. However, it does not provide explicit guidance on when not to use this tool or mention alternatives among the siblings, leaving it to the agent to infer.

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

get_generic_attributesA

Fetches generic attributes (namespace_id=3) with categorical detection. String attributes with few distinct values include all possible values. Numeric attributes include min/max range.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

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

Without annotations, the description discloses key behaviors: categorical detection includes all possible values for strings, and numeric attributes show min/max range. However, it does not mention read-only nature or side effects, which could be inferred but not explicit.

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?

Two sentences, front-loaded with the core purpose, concise and no redundant information. Every sentence adds value.

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?

Given no output schema and low complexity, the description sufficiently explains what is returned (all possible values for categorical, min/max for numeric). No missing critical information for the tool's purpose.

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?

Input schema has no parameters (0 count, 100% coverage), so the baseline is high. The description adds no parameter-level details but that's fine since none exist. It explains output behavior which compensates.

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 action ('Fetches generic attributes') and specifies the resource with a unique identifier (namespace_id=3), distinguishing it from sibling tools like run_query or get_database_schema.

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?

No explicit guidance on when to use or alternatives. The specialized namespace and categorical detection imply a specific use case, but lack of explicit context or when-not-to-use reduces clarity.

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

get_historyC

Returns the conversation history for a session.

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	Yes

TDQS

C2.8/5.0

Behavior2/5

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

No annotations provided, so the description must cover behavior. It only states the output type but omits details like ordering, pagination, or performance implications. Does not disclose if it's read-only, which is implied but unconfirmed.

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?

Single sentence, no filler, directly states purpose. Every word earns its place.

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

Completeness3/5

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

For a simple retrieval tool with no output schema, the description is minimally adequate. However, it lacks contextual details like whether history is ordered chronologically or how limits/errors are handled.

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

Parameters1/5

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

The single parameter session_id has no description in the schema (0% coverage) and the tool description adds no semantic meaning beyond the parameter name. An agent cannot infer format or constraints.

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 clearly states the tool returns conversation history for a session, matching the name. It distinguishes from siblings like get_session_context or get_examples by focusing on history. However, it could be more specific about what 'history' includes.

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 vs. alternatives like get_session_context. No context about prerequisites or when not to use it.

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

get_lod_configA

Returns available Levels of Detail in the database, with the most common LoD set as default.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are present, so the description must cover behavioral traits. It only states the tool returns data, which implies a read-only operation, but provides no additional disclosure about side effects, caching, or performance characteristics.

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 sentence that is concise and front-loaded, containing no unnecessary information.

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

Completeness3/5

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

Given no output schema, the description lacks detail on the return format or structure of the LoD data. It mentions a default but does not elaborate, leaving the agent with incomplete information for a simple tool.

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 no parameters, so the description does not add parameter meaning. According to guidelines, baseline is 4 for zero 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 returns available Levels of Detail and indicates a default is set. It uses a specific verb 'returns' and a specific resource 'available Levels of Detail', distinguishing it from sibling tools like get_database_schema which focus on different aspects.

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 is provided on when to use this tool versus alternatives. The description simply states what it does without offering context on selection criteria, prerequisites, or exclusions.

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

get_query_guidelinesA

Returns SQL best practices, indexed columns, optimization tips, and expensive operations to avoid for 3DCityDB queries.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It does not mention whether the tool is read-only, requires any authentication, or has side effects. The description only lists what is returned, omitting important behavioral traits like cost or data source.

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 sentence of 16 words that directly states the tool's purpose. It is concise and front-loaded with the main action, with no unnecessary words.

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

Completeness3/5

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

Given no output schema and no parameters, the description is the sole source of information. It lists the types of information returned but does not specify format (e.g., text, JSON) or provide example content. For a simple reference tool, this is minimally adequate but could be more 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 tool has zero parameters and schema coverage is 100%. The description does not need to add parameter info since there are none. Baseline of 4 is appropriate as no additional meaning is required 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 it returns SQL best practices, indexed columns, optimization tips, and expensive operations to avoid for 3DCityDB queries. The verb 'Returns' and specific resource names make the purpose unambiguous, and it is distinct from siblings like get_database_schema.

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 does not explicitly state when to use this tool versus alternatives. While the purpose implies consulting it for SQL guidelines, there is no guidance on when not to use it or which sibling tools to consider instead. The context is implied but not articulated.

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

get_session_contextB

Returns or creates the current user session context.

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	No	Optional session ID. Creates new session if not provided.

TDQS

B3/5.0

Behavior2/5

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

The description states the tool 'returns or creates', implying both read and write behavior, but does not disclose side effects, required permissions, or whether creation is idempotent. Since no annotations are provided, the description carries the full burden of transparency, which it fails to meet.

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 a single sentence that efficiently conveys the core function. However, it lacks structural elements like separate sections for behavior or examples, and could benefit from front-loading the primary action.

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 that the tool can both return and create session context, the description omits important information such as the return value format, any error conditions, or how the session context is represented. No output schema exists to fill this gap, so completeness is insufficient.

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 100%, but the description adds context: 'Optional session ID. Creates new session if not provided.' This explains the parameter's effect beyond the schema's basic description, aiding in correct usage.

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 clearly states the tool's function: returning or creating the current user session context. However, it does not differentiate this tool from siblings like get_db_context_snapshot or get_history, which might also involve session or context retrieval.

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 is provided on when to use this tool versus alternatives. The description does not mention prerequisites, when a session is created versus returned, or how this tool compares to other context-related siblings like get_db_context_snapshot.

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

resolve_propertiesC

For a given objectclass_id, walks the superclass hierarchy, collects all schema-defined properties, filters against the property table to keep only existing properties, determines value columns and join info, and resolves codelists for Code-type properties. Returns fully enriched PropertyDefinitions.

ParametersJSON Schema

Name	Required	Description	Default
`objectclass_id`	Yes	The objectclass ID to resolve properties for (e.g. 901 for Building)

TDQS

C2.8/5.0

Behavior2/5

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

Without annotations, the description must disclose behavioral traits. It outlines internal steps (walk hierarchy, filter, resolve codelists) but omits side effects, error conditions, or performance implications.

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?

The description is a single lengthy sentence that packs many steps. It is not optimally concise or front-loaded; restructuring would improve clarity.

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?

No output schema exists, and the description only vaguely mentions 'Returns fully enriched PropertyDefinitions.' Missing details on return format, errors, and edge cases for invalid inputs.

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% for the single parameter, so baseline is 3. The description does not add additional meaning beyond the schema's parameter description.

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 clearly states the tool resolves properties for a given objectclass_id by walking the superclass hierarchy and enriching. It is specific and distinguishes from general query tools, though no explicit sibling differentiation is provided.

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 vs alternatives like get_generic_attributes or scan_objectclasses. No when-not or prerequisites mentioned.

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

run_queryA

Executes a read-only SQL query against 3DCityDB. Only SELECT and WITH (CTE) statements are allowed. Results are automatically limited to 500 rows.

ParametersJSON Schema

Name	Required	Description	Default
`sql`	Yes	SQL SELECT query to execute

TDQS

A4.5/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 the full burden. It discloses read-only nature, allowed statements, and the automatic 500-row limit, covering key behavioral traits. It could mention error handling or performance, but the given details are sufficient.

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?

Two sentences, front-loaded with the main action, and every word serves a purpose. No redundancy or verbosity.

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 (1 param, no output schema, no annotations), the description covers essential aspects: what it does, allowed queries, result limit. It could mention that queries are executed against a specific database, but that is already stated.

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 100% for the single parameter 'sql', and the description adds valuable constraints: only SELECT/WITH queries are allowed and results are limited to 500 rows, enhancing the schema's basic description.

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?

Description clearly states it executes read-only SQL queries against 3DCityDB, specifying allowed statement types (SELECT and WITH), which distinguishes it from sibling tools that perform other database operations.

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 specifies allowed statements and implicitly guides against using it for mutations or unsupported queries. However, it doesn't explicitly compare to sibling tools or provide when-not-to-use scenarios.

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

scan_objectclassesA

Scans the database for existing object classes (e.g. Building, Vegetation, LandUse). Returns the full class hierarchy with superclass chain, namespace IDs, and schema definitions.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior2/5

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

No annotations provided, so description must carry full behavioral burden. It describes the output but does not disclose performance, authorization requirements, or that it is a read-only operation. Lacks details on side effects or error conditions.

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?

Two concise sentences with no redundant words. Front-loaded with verb and examples, immediate clarity.

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 zero-parameter tool with no output schema, the description adequately covers purpose and output. Lacks detail on output format or structure, but sufficient given simplicity.

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 has 0 parameters (100% coverage automatically). Description adds value by explaining what the tool returns beyond the schema, which only states no parameters. Baseline 4 applies as per guidelines.

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?

Description uses clear verb 'Scans' with specific resource 'existing object classes', provides examples (Building, Vegetation, LandUse), and specifies the return value (full class hierarchy with superclass chain, namespace IDs, schema definitions). Distinguishable from sibling tools like get_database_schema which returns broader schema.

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?

Description implies usage for retrieving object class hierarchy but does not explicitly state when to use this tool versus alternatives like get_database_schema or get_generic_attributes. No guidance on prerequisites or exclusion criteria.

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

submit_feedbackC

Logs feedback for a query execution (rating, errors).

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	Yes
`query`	Yes
`rating`	Yes
`execution_time_ms`	No
`result_count`	No
`error`	No

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the entire burden falls on the description. It only says 'Logs feedback,' which implies a write operation but lacks details on side effects, permissions, rate limits, or data persistence. The description does not clarify whether the operation is reversible or what happens on failure.

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 single-sentence description is concise and front-loaded with the primary action. However, it could include more context without becoming verbose, but remains appropriately sized for a simple tool.

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 the tool has 6 parameters, no output schema, and no annotations, the description is incomplete. It does not explain return values, success/failure signals, or how the feedback is used. The minimal information leaves gaps for an AI agent to correctly invoke the tool.

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

Parameters2/5

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

The schema has 6 parameters with 0% description coverage. The description mentions 'rating' and 'errors,' but omits session_id, query, execution_time_ms, and result_count. It adds some meaning for the mentioned params but fails to explain the purpose of the others, which is insufficient given the low schema coverage.

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: 'Logs feedback for a query execution (rating, errors).' It uses a specific verb ('Logs') and resource ('feedback for a query execution'), and distinguishes itself from sibling tools (no other tool logs feedback).

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?

The description provides no guidance on when to use this tool versus alternatives. While it implies use after a query execution, it does not specify prerequisites, exclusions, or mention related tools like 'run_query' for context.

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

update_module_selectionB

Narrows the user's scope to specific object classes or modules. Affects which properties, examples, and codelists are relevant.

ParametersJSON Schema

Name	Required	Description
`session_id`	Yes
`objectclass_ids`	Yes	Object class IDs to focus on
`modules`	No	Module names to focus on (e.g. ['building', 'vegetation'])

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description bears full responsibility for disclosing behavioral traits. It states the tool 'narrows scope' and 'affects relevancy', but does not clarify whether the selection is additive or overwriting, whether the change is persistent, or what side effects occur. The absence of output schema also leaves return behavior unclear.

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?

Two sentences are concise and front-loaded; the first states the core function, the second elaborates on the effect. No unnecessary words or repetition.

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 the complexity of a mutation tool with no annotations, no output schema, and a required session_id parameter lacking description, the description is incomplete. It does not explain error handling, parameter constraints, or how the tool fits into the broader workflow with siblings like get_session_context or run_query.

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 67% (two of three parameters have descriptions). The description echoes the schema by mentioning 'object classes or modules' but adds no new semantic detail beyond that. The baseline score of 3 is appropriate given moderate coverage and marginal added value.

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 clearly states the tool 'narrows the user's scope to specific object classes or modules' with a specific verb ('narrows') and resource ('object classes or modules'). It is clear but does not explicitly differentiate from sibling tools like get_session_context that also handle session state, though the action (update vs. retrieve) is implied.

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 when needing to focus on relevant properties, examples, and codelists, but provides no explicit when-to-use, when-not-to-use, or alternatives among sibling tools. No prerequisites (e.g., session must exist) are mentioned.

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. Dates show when Glama detected each change.

14 tool updatesv0.2.0May 26, 2026
- First observedassemble_prompt
- First observedget_database_schema
- First observedget_db_context_snapshot
- First observedget_examples
- First observedget_generic_attributes
- First observedget_history
- First observedget_lod_config
- First observedget_query_guidelines
- First observedget_session_context
- First observedresolve_properties
- First observedrun_query
- First observedscan_objectclasses
- First observedsubmit_feedback
- First observedupdate_module_selection

Install Server

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

TDQS

A3.8/5.0

Disambiguation5/5

All 14 tools have clearly distinct purposes—retrieving different types of metadata (schema, context, examples, attributes, etc.), executing queries, scanning object classes, updating module selections, and submitting feedback. No two tools overlap in functionality.

Naming Consistency5/5

Every tool follows the consistent verb_noun pattern using snake_case (e.g., get_database_schema, run_query, submit_feedback). Minor abbreviation ('db' vs 'database') is common and does not break consistency.

Tool Count5/5

14 tools is well-suited for a 3DCityDB query agent—covering metadata retrieval, query execution, configuration, and feedback without excess or deficiency. The count feels appropriate for the domain.

Completeness5/5

The tool set covers all necessary operations for a read-only query agent: database introspection (schema, context, classes, attributes), query building guidance (examples, guidelines), query execution, session management, and feedback logging. No obvious gaps exist for the stated purpose.

Maintenance

ActivityActive

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcpOAuth
com.gibsonai
GibsonAI MCP server: manage your databases with natural language
Databases Search
233
QCDatabase.AIOAuth
ai.qcdatabase
Connects AI assistants to QCDatabase.AI for everyday construction quality-control work.
Databases Project Management
1
Cayra Decision IntelligenceOAuth
io.cayra
Ask questions in plain language, get answers from your business database. No SQL required.
1
Dot - AI Data AnalystOAuth
io.github.zurferr
Ask data questions in natural language. Get SQL, insights, and charts from your databases.
Search Databases Data Visualization
2

Related MCP Servers

mcp-sql-api
Databases AI & Machine Learning
o-kunimatsu
F
license
Not graded
quality
D
maintenance
Enables natural language database querying through GPT-powered SQL generation and execution with metadata-driven validation and intermediate representation.
Updated 4 months ago (2026-05-03 08:44 UTC)
-
PostGIS Yukon MCP
Databases Location Services
zmGiser
A
license
Not graded
quality
F
maintenance
Enables natural language and geospatial queries on PostGIS databases, with 32 tools for spatial analysis, geometry operations, and database management.
Updated 10 months ago (2025-11-19 07:41 UTC)
4
MIT
GraphJinofficial
Databases Search
dosco
A
license
Not graded
quality
A
maintenance
Enables AI assistants to query databases using natural language, with automatic schema discovery and SQL compilation.
Updated 3 days ago (2026-09-03 07:19 UTC)
6,002
3,158
Apache 2.0
Civil 3D MCP Server
Design Tools Autonomous Agents
DaniGhosy
A
license
A
quality
B
maintenance
Enables AI assistants to interact with Autodesk Civil 3D through natural language, supporting tools for surfaces, alignments, profiles, corridors, pipe networks, COGO points, and AutoCAD geometry.
Updated 19 days ago (2026-08-18 19:17 UTC)
9
2
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/tum-gis/3dcitydb-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

3DCityDB MCP Server

Features

Deployment Options

Option 1: PyPI Package

Prerequisites

Installation

Configuration

Verify your installation

Connect to Claude Code (recommended)

Connect to Claude Desktop

SSE transport (remote / production)

LangChain agent CLI (optional)

Option 2: Docker — BYOD (Bring Your Own Database)

Prerequisites

Quick Start

What it includes

Gradio UI overview

Building locally (optional)

Useful commands

Option 3: Docker — Fullstack (Bundled PostgreSQL)

Prerequisites

Quick Start

Building locally (optional)

Import CityGML/CityJSON

Coordinate reference system

Useful commands

Configuration Reference

Database connection

Fullstack only

LLM providers

Query behaviour

Country-specific codelists

Ollama tuning (optional)

Available MCP Tools

Static (cached per session)

Dynamic (called at session start)

Runtime (per query)

Assembly

Architecture

Citation

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

GraphJinofficial

Latest Blog Posts

MCP directory API