Bereinigung von Standortstammdaten
Erkennen Sie Adress-, Stadt-, Postleitzahl-, Breiten- und Längengradfelder, validieren Sie Koordinaten und GeoJSON und bereiten Sie sauberere Standortdatensätze zur Wiederverwendung in Geschäftsabläufen vor.
A cleaner, reusable location master with validated coordinates, stable identifiers, known exceptions, and a safe path into downstream geofencing, routing, CRM, or supply-chain workflows.
The job today
Location cleanup often starts with exports from several systems, inconsistent addresses and codes, latitude/longitude columns of uncertain quality, duplicates, and spreadsheet review before anyone is comfortable feeding the records into routing, geofencing, CRM, inventory, or field workflows.
A useful first agent request
Profile this authorized location dataset. Identify likely location fields, validate the supplied coordinates or GeoJSON, flag missing or structurally unsafe records, and produce a review list. Do not overwrite the location master or invent a precise location for records that lack enough evidence.
Use this playbook when
- Location records arrive from multiple systems with inconsistent addresses, coordinates, codes, or duplicate facilities.
- Geofencing, routing, field service, inventory, or customer-site workflows are producing unreliable results because the location master is weak.
- A team needs to understand the quality of a location file before importing or overwriting production records.
What you need
- A representative location extract with the identifiers, names, addresses, and coordinates currently available.
- The identifier that should remain stable across systems, plus any partner/customer codes that need XREF.
- The downstream uses that matter: mapping, geofencing, routing, inventory, CRM, service territory, or another location-aware workflow.
What this should produce
- A location-quality report covering columns, coordinate validity, missing values, and obvious structural problems.
- A normalized target shape with stable IDs and a list of records requiring human review.
- A controlled import/update path that avoids silently overwriting uncertain locations.
Operating playbook
- 1
Profile the location source
Identify address, city, region, postal, country, latitude, longitude, and location-code fields. Determine which values are actually populated and whether coordinate order or units are consistent.
- 2
Choose the durable identifier
Decide which location ID is authoritative inside the target workflow. Preserve external partner/customer codes through XREF rather than replacing stable IDs with whichever code appeared in the latest file.
- 3
Validate geometry before enrichment
Validate latitude/longitude ranges, coordinate order, GeoJSON shape when present, and obvious outliers. Do not geocode or enrich records that are already structurally wrong.
- 4
Resolve missing or conflicting geography
Use approved geocoding/location services for records that need coordinates, but keep low-confidence or conflicting results in review rather than presenting them as certain.
- 5
Review duplicates and cross-system identity
Compare stable IDs, partner codes, addresses, and coordinates to identify duplicates or records that represent the same physical site under different business identifiers.
- 6
Import only reviewed changes
Write accepted records through the approved DataSynch/location API path and preserve an exception set for records that still need human or source-system correction.
Agent access for this playbook
Think of each MCP tool as a bounded API capability packaged for an agent: a defined operation, accepted inputs, approved tenant/resource scope, and returned result. The agent can reason across the tools it has been given, but the connection and underlying API authorization still determine what those tools can reach and do.
What the agent may inspect
- Detected location columns and bounded sample rows supplied through approved tools.
- Coordinate and GeoJSON validation results for supplied records.
- Proposed corrections or review flags derived from the evidence available to the agent.
What this Atlasemoji MCP tool set is not authorized to do
- The current public Atlasemoji MCP tool set is not authorized to overwrite the customer location master, merge ambiguous facilities, or silently manufacture coordinates.
- Validation tools do not imply access to every CRM, ERP, WMS, customer, or partner location record.
Where a person stays in control
- A person resolves ambiguous identity, duplicate, merge, and low-confidence geography cases.
- A person or approved production workflow authorizes imports, master-data updates, and downstream geofence or routing use.
How the data stays bounded
Limit the agent to the supplied or authorized location dataset and the validation tools required for the review. Geocoding, enrichment, merges, and master-data writes should use approved services and review paths rather than being inferred from a validation prompt.
Atlasemoji bounds agent access through the connection and the API-backed capabilities behind each tool. Issued credentials or API keys, tenant context, tool scope, resource identifiers such as workspace or manifest, permitted action, and environment all contribute to the authorization boundary. The agent works through the approved tool contract rather than receiving blanket platform access.
Read-only is the policy of the public Atlasemoji MCP tool set documented today, not a limitation of MCP itself. A customer or partner can separately approve additional API-backed tools with narrower or broader read, write, execution, or production scopes for a specific relationship.
Decision points
- Valid stable ID but bad coordinates: correct geography without changing business identity.
- Same coordinates/address but conflicting IDs: review XREF/duplicate logic before merging records.
- No reliable address or coordinates: keep the record in an exception queue instead of manufacturing a precise location.
- Location is structurally valid but downstream geofence or route behavior is wrong: troubleshoot the downstream geometry/rules separately.
Two access patterns, one Atlasemoji platform
Atlasemoji APIs are foundational in both patterns. A direct REST integration calls documented APIs from your application. An MCP integration lets an AI agent use selected Atlasemoji API and service capabilities through typed tools, with agent-oriented discovery, tool scoping, tenant/resource context, and policy controls around those calls.
Call Atlasemoji APIs directly from your code
Use the direct API path when your application already knows the exact operation it needs to perform. Your code authenticates, calls the documented endpoint, supplies the required company/workspace/manifest or object context, and receives the machine-readable result. This is ideal for repeatable, deterministic integration behavior.
Application / integration → API credential → Atlasemoji API → approved capability → resultLet an agent work through approved API-backed tools
Use MCP when the request is variable and benefits from an agent choosing among approved capabilities, comparing evidence, validating context, or explaining the next step. The agent calls MCP tools; Atlasemoji maps those tools to the underlying authorized API/service capabilities. The current public Atlasemoji tool set is intentionally read-only.
Person / AI agent → Atlasemoji MCP → approved tool → Atlasemoji API/service → approved capability → resultMCP is not a black box around the APIs
The MCP layer packages selected Atlasemoji API/service capabilities as tools an agent can discover and call. That lets Atlasemoji keep API credentials, tenant/resource boundaries, permitted actions, and audit context attached to the capability while giving the agent a simpler task-oriented interface. The tool may orchestrate one or more underlying calls, but it does not bypass the API and authorization model.
You can build both paths for the same business question and compare them. Useful measures include time to answer, manual searches removed, latency, successful-answer rate, escalation rate, cost per task, and how often a person needs to intervene. Many production designs will use both: direct APIs for deterministic automation and MCP for agent-led investigation, interpretation, and orchestration.
Direct REST/API production path
Keep the system of record where it already belongs. Atlasemoji can normalize, connect, validate, add geographic context, expose APIs, host integrations, and coordinate exceptions without forcing the entire process into one application.
- Use DataSynch and Atlasemoji location APIs to import, validate, normalize, and update reviewed location records.
- Use geocoding, GeoJSON, geofencing, and routing services as downstream capabilities after the location identity and geometry are trustworthy.
- Preserve external codes and partner identifiers through XREF/mapping rather than overloading one field with every source system's identity.
Relevante API- und Hilfepfade
These pages are not duplicates. Each one answers a different question in the build process: what route exists, how several routes work together, what a valid request looks like, or what a business capability is meant to do.
DataSynch API Explorer →
The searchable DataSynch API reference. Search by business job, route, schema, tag, object type, or app surface. Each route explains what it does, the context it requires, its related schema, the next logical route, and the full Swagger contract.
Search locations, normalize, geofence, and master tables. Use the schemas to understand how location records enter DataSynch and what shape downstream geographic workflows expect.
GeoJSON quick start →
A beginner-friendly GeoJSON quick start showing how an application can send GeoJSON to Atlasemoji and turn a small geographic dataset into a larger map workflow. Use it before treating GeoJSON as an unexplained blob of coordinates.
Start here if Feature, geometry, coordinates, or FeatureCollection are new concepts. The point is to understand the shape of geographic JSON before debugging it through an API.
Atlasemoji glossary →
Plain-language definitions for mapping concepts such as coordinates, geometry, points, Features, FeatureCollections, datasets, and workspaces. Use it when a route or GeoJSON example uses a term you do not yet recognize.
Use the glossary when you encounter a mapping term you do not recognize; learn the object first, then decide whether the record is actually invalid.
DataSynch Workbench →
A guided build surface for seeing how DataSynch routes work together. It includes workflows for imports, XREF, geofences, telemetry, dispatch, and run logs so you can understand the sequence before wiring it into your own application.
Use guided location/import workflows to see how records are loaded and validated before automating the same sequence.
DataSynch API Examples →
Known-good DataSynch request bodies. Use these after you know which route you need and want a concrete payload to compare with your own JSON, partner data, or integration test.
Compare your location payload with known-good requests before blaming coordinates, mapping, or GeoJSON for a request-shape problem.
Agentic path through MCP and Atlasemoji APIs
Atlasemoji MCP is an agent-facing way to use selected Atlasemoji API and service capabilities through typed tools. The MCP server authenticates the connection, exposes the approved tool surface, and invokes the underlying capabilities with the permitted company, workspace, manifest, resource, and action context. Atlasemoji's current public tool set is read-only and non-destructive by design; that is a property of this tool set, not a limitation of MCP or APIs.
Connect this playbook to ChatGPT
Start by proving the playbook in one ChatGPT conversation. Connect Atlasemoji as a remote MCP app, verify the exact tools this playbook needs, and run the first request with authorized IDs. Remember what is happening underneath: ChatGPT calls the Atlasemoji MCP tool; Atlasemoji authorizes that tool and uses the corresponding API/service capability within the approved tenant and resource scope.
- 1
Get approved Atlasemoji MCP access
Obtain approved Atlasemoji MCP access and the company, workspace, or manifest identifiers you are authorized to use. Atlasemoji-issued credentials are part of the connection and authorization boundary; the endpoint alone does not grant tenant data access.
- 2
Open ChatGPT custom-app setup
On a supported ChatGPT web plan/workspace, enable Developer mode and open Settings → Apps → Create. Workspace administrators can also create the app from Workspace settings → Apps → Create. If those controls are not available, check the current OpenAI help page below or ask your workspace administrator.
- 3
Add the Atlasemoji remote MCP endpoint
Enter https://atlasemoji.com/api/mcp as the remote server endpoint. Atlasemoji documents Streamable HTTP transport and an Atlasemoji-issued bearer credential. Select the ChatGPT authentication option that matches the access method provided for your Atlasemoji relationship; Atlasemoji support can help if your workspace needs a different supported connection method.
- 4
Scan the tools and compare them with this playbook
Use ChatGPT's Scan Tools step, then compare the discovered tools with the list shown below. Each listed tool represents a bounded Atlasemoji capability with defined inputs and outputs; behind the MCP surface, Atlasemoji invokes the corresponding authorized API/service logic rather than giving the agent unrestricted platform access.
- 5
Run one real test in a new chat
Select the Atlasemoji draft app in a new ChatGPT conversation and paste the first test request below. Replace placeholder IDs with authorized values. Evaluate both the answer and the path used to get there: which tools were called, which tenant/resource context was used, and whether the evidence was sufficient.
- 6
Make the working pattern reusable
After the test works, make the pattern reusable if your ChatGPT workspace supports Workspace Agents. Add only the apps/tools needed for the job and choose the appropriate end-user or agent-owned connection model. You can also keep the workflow as a normal ChatGPT conversation or pair it with a direct REST integration.
https://atlasemoji.com/api/mcpTransport: Streamable HTTP. Authentication: Atlasemoji-issued bearer credential. MCP tools are backed by approved Atlasemoji API/service capabilities and remain bounded by the connection, tool scope, tenant/resource context, and permitted action.
detect_location_columnsvalidate_coordinatesvalidate_geojsonvalidate_manifest_schemasuggest_field_mappingProfile this authorized location dataset. Identify likely location fields, validate the supplied coordinates or GeoJSON, flag missing or structurally unsafe records, and produce a review list. Do not overwrite the location master or invent a precise location for records that lack enough evidence.
Current MCP tools used
detect_location_columnsvalidate_coordinatesvalidate_geojsonvalidate_manifest_schemasuggest_field_mappingProfile a location file before import
Inspect this location dataset. Detect the likely location columns, validate coordinate fields and sample values, identify structural problems and missing fields, and list the records or patterns that should be reviewed before import.
Validate a proposed geographic record
Validate the supplied coordinates or GeoJSON for this location and report any range, order, geometry, or schema issue that would make the record unsafe for geofencing or routing.