MCPStack tool for UrbanMapper that emits HF-only pipeline code strings (no execution).
This MCP server has significant definition quality gaps. While it registers 9 tools with names that follow verb conventions, most descriptions lack depth and parameter documentation is inconsistent. Tool #4 (um_build_pipeline_code) has extensive parameters but many lack descriptions or type constraints. Tool #1 (um_list_urban_layers) has empty input schema. No output schemas are documented, making it unclear what structures agents should expect. Error handling is minimal, no guidance on recovery steps or categorization of errors (retryable, user-fixable, fatal). The descriptions average 10-50 characters, well below the 194-char baseline for A+ tools, leaving LLMs unable to make confident selection decisions. The tool definitions are directly visible in the code (good), but the lack of schema completeness and sparse parameter documentation keeps scores conservative.
Generate complete UrbanMapper pipeline code string for geospatial data processing with optional visualization.
Explain a primitive technique for a given pipeline stage.
Get the generated pipeline code for a named example.
Inspect a Hugging Face dataset and extract schema, sample rows, and inferred column mappings.
List available pre-configured pipeline examples.
List available urban layer types.
List available visualizer types.
Empty input schemas on list/discovery tools (um_list_urban_layers, um_list_examples, um_list_visualisers), input: {} provides no parameter constraints and violates pattern:constrained-input. LLMs cannot validate input or understand what parameters are required.
Sparse parameter descriptions. um_build_pipeline_code has 22 parameters, but many (number_of_rows, streaming, include_imputer, address_column, include_filter, csv_path) lack descriptions in the schema spec. LLMs cannot determine when to use optional params or what values are valid.
No documented output schemas. All 9 tools lack description of return types and structures. LLMs cannot plan downstream calls or extract data reliably. E.g., um_list_urban_layers returns list[str], but um_build_pipeline_code returns str, agents don't know what to expect.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 41 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Get available style presets for a visualizer type.
Get the style schema and configuration options for a visualizer type.
Short, generic descriptions (avg <50 chars). Examples: 'List available urban layer types.' (30 chars), 'List available pre-configured pipeline examples.' (47 chars). Below the 194-char baseline for A+ tools. LLMs cannot distinguish when to select this tool vs similar discovery tools.
No error handling or recovery guidance. Actions in discovery.py and examples.py return raw dicts with 'error' key or raise ValueError, but no description of error categories (retryable, user-fixable, fatal) or suggested next steps. Agents cannot determine whether to retry, ask the user, or fail gracefully.
Parameter relationships undocumented. um_build_pipeline_code requires either (longitude_column + latitude_column) OR geometry_column, and values_from is required for non-count aggregations, but these mutual dependencies are not stated in parameter descriptions. LLMs may pass invalid combinations.
visualiser_style parameter is an untyped object dict without schema. No guidance on valid keys, types, or constraints. LLMs will hallucinate style configurations. Should define a proper JSON Schema or provide enum/preset guidance.