Skip to main content
Glama

docugis_map

Generate a TSV of named place coordinates for DocuGIS2 import, enabling map visualization with optional dates and popup text; no geocoding, only formats coordinates you provide.

Instructions

Put places on a map in DocuSky's own DocuGIS2 tool.

Takes coordinates you already have — from the user, from a placeInfo in search_documents, from a gazetteer, or from your own knowledge of where a place is — and returns the TSV that DocuGIS2's import box accepts. This tool does no geocoding and no searching: never invent coordinates for a place you are unsure of; leave that row out, or ask the user.

DocuGIS2 cannot be fed data through a URL, so the last step belongs to the user: MCP Apps-capable hosts show the TSV with a copy button next to the embedded tool, and the user pastes it into DocuGIS2's box and presses 匯入 (the rendered map then does time filtering, routes, clustering, heatmaps and export). Other hosts get the same TSV as text plus webUrl, to paste into DocuGIS2 in a browser. Tell the user that paste step is theirs.

Args: rows: One entry per place. name plus x (WGS84 longitude) and y (latitude) are required; date, text and any other keys are optional and become extra columns in DocuGIS2's popups. Common aliases are understood (lng/lon/經度 -> x, lat/緯度 -> y, 地名 -> name). Example: [{"name": "鹿港", "x": 120.434, "y": 24.057, "date": "1784-01-01", "text": "鹿港開港"}]. title: A name for this map, shown above the tool. include_dates: Leave unset to decide automatically. DocuGIS2 drops any row whose date cell is empty or a bare year, so a half-dated set ships without the date column (every place on the map, no time axis). Pass true to keep the timeline and lose the undated rows, false to drop dates entirely. max_rows: Keep at most this many places (default 2000).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rowsYes
titleNo
max_rowsNo
include_datesNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

TDQS

A5/5.0
Behavior5/5

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

No annotations exist, so the description carries the full burden and does so richly: it discloses it performs no geocoding/searching, that DocuGIS2 cannot be fed via URL, the host-dependent return path (embedded TSV with copy button vs. text + webUrl), and the non-obvious rule that DocuGIS2 silently drops rows whose date is empty or a bare year.

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?

Front-loaded with purpose, then sources, then the delivery/paste workflow, then an Args section. It is long, but with 0% schema coverage and no annotations nearly every sentence is load-bearing, and the Args block is cleanly scoped per parameter.

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?

An output schema exists, yet the description still usefully frames what comes back (TSV plus webUrl) and who completes the final step. For a tool whose real action happens in an external UI, nothing an agent needs to call it correctly is missing.

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 0%, and the description compensates thoroughly: it documents required fields (name, x, y), optional fields (date, text, arbitrary keys becoming popup columns), alias handling (lng/lon/經度, lat/緯度, 地名), a concrete example, and the exact semantics of include_dates and max_rows.

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?

States a specific verb and resource ('Put places on a map in DocuSky's own DocuGIS2 tool') and immediately frames what it produces (the TSV DocuGIS2's import box accepts). The explicit 'does no geocoding and no searching' boundary cleanly separates it from siblings like search_documents.

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?

Explains exactly when to reach for it and where coordinates come from (user, placeInfo from search_documents, gazetteer, own knowledge), and gives a clear when-not: never invent coordinates, leave the row out or ask the user. It also names the downstream alternative path (MCP Apps hosts vs. other hosts) and the human paste step.

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