Skip to main content
Glama

map_search

Import cited excerpts from 1880 DC Sanborn maps to support property-history research without georeferencing historical parcels.

Instructions

Import a cited excerpt from the 1880 DC Sanborn service. This does not georeference historical parcels.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bboxYes
runIdYes
widthNo
heightNo
projectIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this is a non-destructive mutation; the description's 'Import' verb is consistent with that. The one genuinely additive behavioral fact is the scope exclusion that it does not georeference historical parcels, but nothing is said about side effects, overwrite behavior, or what is created.

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?

Two terse sentences with no filler and the action front-loaded. But the brevity is under-specification rather than disciplined conciseness given the five undocumented parameters and absence of any guidance.

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

Completeness1/5

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

For a five-parameter mutating tool with 0% schema coverage, no output schema, and only partial annotations, the description omits nearly everything an agent needs: parameter meaning, pagination/return behavior, and prerequisites. It is not complete enough to invoke correctly.

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?

Schema description coverage is 0% across five parameters (projectId, runId, bbox, width, height). The description explains none of them — not the bbox coordinate order, not the relationship between projectId and runId — so an agent must guess at invocation inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and subject ('Import a cited excerpt from the 1880 DC Sanborn service') and even scopes it negatively. However, the tool name 'map_search' implies a search/read operation while the description describes an import, creating a mismatch, and it gives no differentiation from siblings like source_import or import_inbox that plausibly do overlapping work.

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?

There is no statement of when to use this tool versus alternatives such as source_import, import_inbox, or map_candidate. The only guidance is a negative scope note ('does not georeference'), which does not tell the agent when this tool is the right choice.

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