Skip to main content
Glama
ahamedfo

IBM Content Services MCP Server

by ahamedfo

map_easement_to_parcel

Read-only

Chains and closure-checks an easement survey traverse, then anchors it to real-world coordinates using county parcel or PLSS data, returning GeoJSON.

Instructions

Places an easement survey traverse onto real-world map coordinates and returns GeoJSON. The traverse (from the survey's line table or prose metes-and-bounds courses) is chained and closure-checked, then anchored to the ground using county parcel and/or PLSS section GIS data.

This tool performs no repository operations — it is a pure geospatial computation using public county GIS data.

:param line_table_json: JSON array of the traverse courses in order, e.g. '[{"line": "L1", "bearing": "S00-07-32E", "distance_ft": 10.30}, ...]'. Bearings accept degree symbols or dashes (N89°51'34"E or N89-51-34E). :param apn: Assessor's Parcel Number as printed (e.g. "200-18-001S"). Optional if address or subdivision+lot is given, or when pob_anchor="section_corner". :param address: Street address printed in the document (e.g. "6361 S Power Rd") — alternative way to find the parcel when the APN is missing or illegible. :param subdivision: Subdivision/plat name (e.g. "Sundance Groves") — used with lot as a third way to find the parcel. :param lot: Lot number within the subdivision (e.g. "104"). :param county: County whose GIS to query. Currently supported: maricopa. :param pob_anchor: How the Point of Beginning is located (required choice): - "parcel_edge": POB lies ON a parcel edge, pob_from_corner_ft from one end. Uses pob_edge / pob_from_end / pob_from_corner_ft. (e.g. "a point on the north line of the parcel, 122.93 feet west of the NE corner") - "parcel_corner": POB IS a named corner of the parcel/lot. Uses pob_corner. (e.g. "BEGINNING at the southwest corner of said Lot 104") - "section_corner": POB is reached by walking tie course(s) from a named corner of a PLSS section. Uses pob_corner, section, township, range_, tie_courses_json. (e.g. "COMMENCING at the SE corner of Section 32... THENCE N89-29-34W 65.00 FEET; THENCE ... TO THE POINT OF BEGINNING") :param pob_edge: (parcel_edge) Which parcel edge: north, south, east, west. :param pob_from_end: (parcel_edge) Which end of that edge the tie is measured from. :param pob_from_corner_ft: (parcel_edge) Distance in feet from that end to the POB. :param pob_corner: (parcel_corner / section_corner) Named corner: NW, NE, SW or SE. :param section: (section_corner) PLSS section number as printed, e.g. "31". :param township: (section_corner) Township, e.g. "1S" or "T1S". :param range_: (section_corner) Range, e.g. "7E" or "R7E". :param tie_courses_json: (section_corner) JSON array (same row format as line_table_json) of the course(s) walked from the section corner to the POB, in order. Use [] or omit if the POB is the section corner itself.

:returns: If successful, returns a dictionary containing: - summary (dict): flat result fields — report these values verbatim. - geojson_io_url (str): ready-made link opening the exact polygons on an interactive map. Present as a link; NEVER re-type coordinates. - geojson (dict): full-precision FeatureCollection for programmatic consumers only — do not reproduce it in a chat response. If unsuccessful, returns a ToolError with details about the failure.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
apnNo
lotNo
countyNomaricopa
range_No
addressNo
sectionNo
pob_edgeNonorth
townshipNo
pob_anchorNoparcel_edge
pob_cornerNo
subdivisionNo
pob_from_endNoeast
line_table_jsonYes
tie_courses_jsonNo
pob_from_corner_ftNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

Aligns with readOnlyHint annotation, describing no repository operations. Details return structure (summary, geojson_io_url, geojson) and failure behavior (ToolError). Adds guidance on how to present results, e.g., 'NEVER re-type coordinates.'

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?

Well-structured with clear sections: purpose, parameter details, returns. Some verbosity, but each part earns its place given complexity. Could be slightly more compact but still effective.

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?

Comprehensive for a tool with 15 parameters and geospatial context. Covers purpose, every parameter, return values, and usage instructions. Output schema exists, so return description is adequate.

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?

Despite 0% schema description coverage, the description provides thorough explanations for all 15 parameters, including formats, examples, conditional usage, and defaults. Compensates fully.

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?

Stated clearly: 'Places an easement survey traverse onto real-world map coordinates and returns GeoJSON.' Differentiated from sibling tools (document management) by being a pure geospatial computation.

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

Usage Guidelines4/5

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

Explicitly states it performs no repository operations and is a pure computation, indicating when to use. For parameters, describes optional conditions. Could be improved by stating when not to use, but context is clear enough.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ahamedfo/ibm-content-services-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server