Convert GeoJSON to CSV/spreadsheet — one row per feature, properties as columns, geometry flattened into a column (e.g. "turn this GeoJSON into Excel/CSV", "I need a spreadsheet from these map features", "export GeoJSON as a table"). Returns the CSV as plain text.
| Name | Required | Description | Default |
|---|---|---|---|
| geojson | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses the conversion scheme (one row per feature, properties as columns, geometry flattened) and the return type (plain text CSV), giving the agent a clear behavioral model. However, it does not mention handling of nested properties or non-FeatureCollection inputs, which could be edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with a clear main clause, a dash-delimited detail section, and parenthetical examples. No wasted words; front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple conversion tool with a single parameter and an output schema not shown, the description covers purpose, usage intent, output format, and gives examples. It could add edge-case behavior (e.g., handling of geometry types) but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It identifies the input as GeoJSON and clarifies that it processes features, but it does not specify the expected structure (e.g., FeatureCollection vs single feature) or string format. The parameter name 'geojson' is self-explanatory, limiting the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Convert' plus resource 'GeoJSON to CSV/spreadsheet' clearly states the function. It distinguishes from sibling converters (geojson_to_kml, geojson_to_shapefile) by naming the target format, and the phrase 'one row per feature, properties as columns' adds precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides example user intents that signal when to use this tool ('turn this GeoJSON into Excel/CSV', 'I need a spreadsheet from these map features'), but it does not explicitly exclude alternatives like export_geojson_to_excel. The phrase 'Returns the CSV as plain text' hints at a distinction but could be more explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Many assess_* composite tools (datacenter, ev_charging, renewable, telecom, due_diligence) share the same building blocks of grid proximity, land cover, and terrain, making their boundaries fuzzy. assess_property_hazard_x402 also duplicates assess_property_hazard with only a payment-method difference, and bundle_* tools intentionally overlap with the free primitives they replace.
There is a mix of verb_noun tools (query_features, geocode_address), noun-first geometry tools (centroids_geojson, envelope_geojson), and inconsistent _geojson suffix usage (buffer_geojson, fix_geometry, geometry_stats). The assess_* and bundle_* prefixes offer some grouping, but no single naming pattern is followed across the set.
With 85 tools, the surface is extreme for an MCP server and far exceeds the typical well-scoped 3-15 range. Many tools are convenience bundles or variants that could be consolidated, making the count a significant usability burden.
The toolkit covers a broad range of GIS tasks: format conversions, GeoJSON analysis, FeatureServer query/inspection, geocoding, site assessment, and sharing. Minor gaps exist (e.g., no Excel-to-GeoJSON, no FeatureServer update/delete), but most missing functionality can be worked around by chaining existing tools.