Skip to main content
Glama
putervision
by putervision

get_spatial_map

Read-onlyIdempotent

Export full spatial environment snapshots or 3D meshes as JSON, GeoJSON, graphs, summaries, or compact decision slices, with region and confidence filters.

Instructions

Export the known world as json, geojson, topological_graph, gltf, obj, joint, spatial_vlm, summary, or compact_slice. Optional region_id and min_confidence filters. Read-only snapshot of current SQLite state (not a live renderer). Returns the payload in requested format. Use get_spatial_map instead of query_entities when exporting full environment snapshots or 3D meshes rather than filtering entities.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kNoMax nearest entities to include in compact_slice (default: 16)
formatNoExport or view format (default: json, use "summary" for high-level environment overview, "compact_slice" for fast System One decision slice)
projectNoOptional project identifier
region_idNoOptional region ID to filter
min_confidenceNoFilter out entities below confidence threshold
observer_headingNoOptional heading angle in degrees for compact_slice bearing calculation
observer_positionNoOptional [x, y, z] observer position for compact_slice

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.5.1
    • changedInput schema / properties / format / description
      Previous value: -"Export or view format (default: json, use \"summary\" for high-level environment overview)"New value: +"Export or view format (default: json, use \"summary\" for high-level environment overview, \"compact_slice\" for fast System One decision slice)"
    • changedInput schema / properties / format / enum
      Previous value: -[
      -  "json",
      -  "geojson",
      -  "topological_graph",
      -  "gltf",
      -  "obj",
      -  "joint",
      -  "spatial_vlm",
      -  "summary"
      -]New value: +[
      +  "json",
      +  "geojson",
      +  "topological_graph",
      +  "gltf",
      +  "obj",
      +  "joint",
      +  "spatial_vlm",
      +  "summary",
      +  "compact_slice"
      +]
    • addedInput schema / properties / k
      Added value: +{
      +  "description": "Max nearest entities to include in compact_slice (default: 16)",
      +  "type": "number"
      +}
    • addedInput schema / properties / observer_heading
      Added value: +{
      +  "description": "Optional heading angle in degrees for compact_slice bearing calculation",
      +  "type": "number"
      +}
    • addedInput schema / properties / observer_position
      Added value: +{
      +  "description": "Optional [x, y, z] observer position for compact_slice",
      +  "items": {
      +    "type": "number"
      +  },
      +  "type": "array"
      +}
  2. Changed2 schema fields changedv0.4.1
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • removedInput schema / additionalProperties
      Removed value: -false
  3. First observedv0.3.1

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely new context: it is a snapshot of current SQLite state, explicitly 'not a live renderer,' and the payload is returned in the requested format. It stops short of noting snapshot staleness timing or size limits, hence not a 5.

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 and the format list, then filters, then the routing rule. Efficient overall, though the long inline enumeration of nine formats partially duplicates the schema enum and makes the opening sentence dense.

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 7-parameter, multi-format export tool with no output schema, the description covers what is produced, the read-only snapshot nature, and the key filters. It does not explain what the non-obvious formats (spatial_vlm, joint, compact_slice) contain, leaving some format choices under-specified.

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 100%, so the baseline is 3. The description re-states region_id and min_confidence as optional filters and mentions the format enum, but adds no syntax, defaults, or interaction detail beyond what the schema descriptions already provide.

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?

Specific verb+resource: 'Export the known world' with the full set of supported formats enumerated, and it explicitly distinguishes itself from the sibling query_entities. An agent can tell what it produces and when it differs from the filtering tool without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

States the alternative by name and the condition that selects it: 'Use get_spatial_map instead of query_entities when exporting full environment snapshots or 3D meshes rather than filtering entities.' This is an explicit when-to-use / when-not-to-use routing rule.

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