Đến, rời & thời gian lưu tại cơ sở
Dùng tọa độ cơ sở và geofence để đánh giá việc đến, rời, khoảng cách gần và thời gian lưu, sau đó kết nối các sự kiện production được phê duyệt với cảnh báo hoặc quy trình downstream.
A tested facility event workflow that can distinguish outside, arrival, exit, and dwell conditions and route approved events into downstream operations.
The job today
Arrival and dwell checks often send people between telematics or mobile data, a map, a facility record, appointment information, and timestamps just to answer whether a vehicle or worker reached the right place and how long it remained there.
A useful first agent request
Validate the approved facility coordinates and geofence, then check the supplied subject point against that geofence. Report coordinate or geometry problems and the point-in-geofence result. Do not dispatch an alert, change the geofence, or write an arrival event.
Use this playbook when
- Operations need to know when a truck, technician, asset, or other tracked subject reaches or leaves a known facility.
- A facility event should trigger an alert, workflow, appointment action, or other downstream process.
- Teams need to prove the geofence and telemetry logic before wiring it into production notifications.
What you need
- A reviewed facility location with valid coordinates.
- A geofence shape or point-radius definition appropriate for the physical site.
- Telemetry or location events containing subject identity, latitude, longitude, and timestamps.
- The business thresholds for arrival, exit, dwell duration, proximity, or wrong-site behavior.
What this should produce
- A validated geofence and sample point behavior that can be reproduced.
- A clear event state model for arrival, exit, dwell, proximity, or outside conditions used by the workflow.
- An approved downstream event path for alerts, webhooks, Intercept, or another business application.
Operating playbook
- 1
Validate the facility before defining the event
Confirm the facility coordinates and physical footprint. A perfect event engine cannot compensate for a geofence centered on the wrong entrance, building, yard, or customer site.
- 2
Choose a geofence that matches the operation
Use a point-radius geofence when that is sufficient; use polygon geometry when the operational boundary needs a specific shape. Keep the geometry understandable and testable.
- 3
Test points before wiring live telemetry
Preview the geofence and test known inside/outside points. Validate GeoJSON or coordinates before blaming event processing.
- 4
Define event and dwell rules
Specify what counts as arrival, exit, proximity, and dwell, including the timestamps and minimum duration needed to avoid noisy or duplicate events.
- 5
Connect telemetry to the reviewed facility identity
Ingest location events with stable subject and facility identifiers so an event can be connected to the right vehicle, job, shipment, customer, or appointment.
- 6
Attach downstream action only after event accuracy is proven
Use approved APIs, Intercept, webhooks, or notification workflows for production action. MCP can validate geography and test point relationships; it should not be treated as the event dispatcher.
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
- Supplied facility coordinates and GeoJSON/geofence geometry through the current validation and preview tools.
- A supplied subject point for point-in-geofence evaluation.
- Authorized DataSynch status/activity when diagnosing whether the telemetry or integration feed is healthy.
What this Atlasemoji MCP tool set is not authorized to do
- The current public Atlasemoji MCP tool set is not authorized to continuously track a person or vehicle, create production events, send alerts, or modify a production geofence.
- A point-in-geofence result by itself does not establish dwell time; timestamps and approved event logic are still required.
Where a person stays in control
- A person approves the facility geometry, arrival/exit/dwell rules, thresholds, and the business meaning of the event.
- Alerts, customer notifications, dispatch changes, or downstream writes run only through separately approved production paths.
How the data stays bounded
Give the agent only the approved facility/geofence and the subject coordinates needed for the evaluation. Current public MCP can validate and evaluate geometry; live telemetry ingestion, event processing, alerts, and downstream actions remain in approved production integrations.
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
- Point tests are wrong: fix coordinates or geofence geometry before changing dwell or notification logic.
- Point tests are right but live events are wrong: inspect telemetry coordinates, timestamps, subject identity, and event ordering.
- Arrival/exit is correct but dwell is noisy: adjust the dwell threshold and duplicate-event handling rather than expanding the geofence blindly.
- The event must update another system: send it through the approved API/webhook/integration path with the necessary authorization.
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 the DataSynch geofence API to create reviewed geofences, including `/api/datasynch/geofences` where that route is enabled in your environment.
- Use approved telemetry/integration APIs to receive subject coordinates and timestamps with stable identifiers.
- Use the geofence/event workflow to evaluate operational states such as entry, exit, dwell, wrong-site, and proximity where configured.
- Use Intercept, webhooks, notifications, or downstream integrations for approved business action after event behavior is accepted.
Các đường dẫn API và trợ giúp liên quan
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, telemetry, geofence, geofence events, and dispatch. That sequence mirrors the learning path: define the place, receive the event, evaluate the boundary, then decide what downstream action belongs in production.
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.
Use this before building polygon geofences if GeoJSON geometry and coordinate arrays are unfamiliar. A valid API call is easier to reason about when the geometry itself makes sense.
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 geofence, telemetry, dispatch, and run-log workflows to prove the event chain before connecting it to a live alert or downstream system.
Geofencing →
The Geofencing solution explains how locations, boundaries, entry, exit, dwell, proximity, and downstream events fit together. Use it before designing an arrival or dwell workflow.
Use this to understand entry, exit, dwell, proximity, and operational triggers before choosing thresholds or event names.
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 to clarify point, polygon, coordinates, Feature, and FeatureCollection before debugging the same concepts inside telemetry or geofence payloads.
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.
validate_coordinatesvalidate_geojsonpreview_geofencecheck_point_in_geofencevalidate_manifest_schemaValidate the approved facility coordinates and geofence, then check the supplied subject point against that geofence. Report coordinate or geometry problems and the point-in-geofence result. Do not dispatch an alert, change the geofence, or write an arrival event.
Current MCP tools used
validate_coordinatesvalidate_geojsonpreview_geofencecheck_point_in_geofencevalidate_manifest_schemaValidate the facility and geofence before live testing
Validate the supplied facility coordinates and geofence geometry, preview the geofence, and report any geometry or schema issue that should be corrected before live telemetry is tested.
Check a specific point against the facility
Check whether the supplied latitude and longitude are inside the approved facility geofence. Report the point-in-geofence result and any coordinate validation issue. Do not dispatch an event or change the geofence.