Búsqueda y visibilidad de transporte
Reúna el estado de envíos, instalaciones, rutas, ubicaciones y excepciones en una vista operativa para responder preguntas rutinarias de transporte sin repetir búsquedas en varios sistemas.
A repeatable transportation lookup workflow that combines operational records with location, route, geofence, and integration health context.
The job today
A transportation coordinator often opens a TMS, WMS or ERP, finds a shipment or load, checks the origin and destination, looks at status and exceptions, opens a facility or carrier record, compares related movements, and then explains what changed. The repeated work is finding and joining the context—not necessarily changing the TMS.
A useful first agent request
For companyId <COMPANY_ID>, workspaceId <WORKSPACE_ID>, and manifestId <MANIFEST_ID>, review the last 24 hours of transportation-related DataSynch activity using only the Atlasemoji MCP tools exposed to this agent. Those tools represent the approved API-backed capabilities for this connection. First use get_datasynch_run_status to establish whether the feed is current. Then use get_failed_runs to identify failed or incomplete processing and summarize_workspace_activity to show recent activity. If I supply facility coordinates or a geofence, use validate_coordinates and check_point_in_geofence for that supplied geography. Return four sections: Feed health; Failed or stale data; Geographic checks; Questions that still require shipment/TMS data.
Use this playbook when
- People repeatedly open a TMS, WMS, ERP, carrier portal, spreadsheet, or email thread to answer the same shipment or facility questions.
- A shipment record is useful only after it is connected to a customer, facility, route, waypoint, or geographic condition.
- The team needs a consistent way to distinguish a transportation problem from a stale or failed data feed.
What you need
- The recurring questions you want the workflow to answer, such as shipment status, destination, route, arrival, dwell, or exception.
- The shipment, order, load, customer, facility, or reference identifiers available from your existing systems.
- Location records or coordinates, plus the DataSynch company/workspace/manifest context when Atlasemoji is receiving the operational feed.
What this should produce
- One normalized lookup path for the covered transportation questions.
- Location, route, or geofence context tied to the operational record where that context is useful.
- A clear exception path when the answer is unavailable because the source feed, mapping, location, or workflow failed.
Operating playbook
- 1
Start with the questions, not the software
Write down the recurring questions people are answering today. Keep the first proof narrow: for example, where is the load, which facility is involved, did it arrive, and is the latest feed healthy?
- 2
Identify the source of truth for each answer
Decide which system owns the shipment, order, appointment, facility, or carrier status. Atlasemoji should augment those records rather than invent a second system of record.
- 3
Normalize the records that need to meet
Use DataSynch or an approved integration path to normalize the operational feed and preserve stable external identifiers. Connect the record to the customer, facility, location, or route identifiers needed by the workflow.
- 4
Add geographic context only where it changes the answer
Validate coordinates, connect facilities to locations, and use routing or geofences for questions such as proximity, arrival, exit, dwell, or route context. Do not add mapping steps to questions that do not need geography.
- 5
Separate data-health failures from transportation exceptions
If the record is missing or stale, inspect DataSynch run status and failures before treating the issue as a shipment exception. A failed feed and a late truck are different problems and should route differently.
- 6
Expose the proven answer as a production workflow
Once the lookup is reliable, expose the deterministic path through the approved Atlasemoji APIs, application workflow, webhook, or integration. Use MCP for investigation and explanation around the workflow, not as a substitute for production execution.
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
- Recent DataSynch workflow status, failed runs, and authorized workspace activity exposed by the current tools.
- Facility coordinates or geofence inputs supplied to approved GIS validation tools.
- Additional shipment or operational records only when a customer or partner has explicitly exposed those records through an approved Atlasemoji capability.
What this Atlasemoji MCP tool set is not authorized to do
- The current public Atlasemoji MCP tool set is not authorized to administer the TMS, tender loads, dispatch carriers, change appointments, or write shipment status.
- It does not gain access to another company, workspace, manifest, application, or tool simply because the model asks for it.
Where a person stays in control
- A person decides whether an observed exception requires a carrier, customer, facility, planning, or integration response.
- A person or approved production policy authorizes any write, notification, dispatch, retry, or downstream action.
How the data stays bounded
Scope the agent to the approved company/workspace/manifest and only the tools needed for the transportation question. Each exposed MCP tool is a defined API-backed Atlasemoji capability, and the connection credentials plus tenant/resource context determine what it can reach. The current public tool set can inspect DataSynch status, failures and workspace activity and validate supplied geographic context; broader shipment-record read access must be separately exposed and approved for that customer or partner relationship.
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
- No shipment or order record: check the upstream source and DataSynch run status before troubleshooting geography.
- Record exists but facility context is wrong: verify stable location identifiers, coordinates, and XREF/mapping before changing route logic.
- Record and location are valid but arrival or dwell is wrong: inspect the geofence geometry, point location, event timestamps, and threshold logic.
- The workflow needs to update another system: use an approved API, integration, or event path; the current public MCP tools should not perform that write.
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.
Build the same TMS workflow two ways
For a fair proof, choose one recurring transportation question and implement it once as a direct REST/API workflow and once as an agentic MCP workflow. Both paths use Atlasemoji APIs and services; the difference is whether your code chooses the call directly or an AI agent chooses among approved API-backed tools. Measure both before deciding where each belongs.
TMS search replacement with direct REST APIs
Use this path when you want deterministic code to answer the same transportation question every time. The public DataSynch API Explorer documents health, run, intake, normalization, location, telemetry, geofence, and dispatch surfaces; shipment-record read access may also be tenant-secured and relationship-specific.
- 1
Pick one question and one output contract. Example: “Is the transportation feed current, and which authorized records need attention?” Define the JSON fields your application must return before choosing routes.
- 2
Open the DataSynch API Explorer and search by job or route family. Start with health and runs; add intake/normalize, locations, telemetry, or geofences only when those capabilities are needed. Use the required-context and schema panels to identify the IDs and payload shape.
- 3
Use the approved API credential for the implementation and send the required company/workspace/manifest or object identifiers with each tenant-secured call. Keep the credential in the application or integration layer rather than embedding it in user-facing content.
- 4
Call the selected APIs in a deterministic sequence. Record status codes, timestamps, relevant run IDs, and the evidence used to classify the answer. If shipment-record reads are relationship-specific, use the tenant-secured route provided for that implementation.
- 5
Return the normalized result to the business application, dashboard, webhook, or downstream process. Keep human approval or a separately authorized action route for consequential writes.
- 6
Run the same test set repeatedly and record latency, success rate, stale-feed detection, errors, manual intervention, and cost. This becomes the baseline for comparing the agentic version.
TMS search replacement with ChatGPT + Atlasemoji MCP
Use this path when the transportation question varies and a person benefits from natural language, evidence gathering, comparison, and explanation. ChatGPT calls Atlasemoji MCP tools; Atlasemoji then invokes the approved API/service capabilities behind those tools within the authorized scope.
- 1
Connect ChatGPT to https://atlasemoji.com/api/mcp with the approved Atlasemoji access method, then scan the available tools. Confirm that the playbook tools you need are exposed before testing the workflow.
- 2
Give the agent the same authorized company/workspace/manifest context used by the REST proof. The MCP connection and API-backed tool scopes—not the wording of the prompt—determine what Atlasemoji data and capabilities are available.
- 3
Ask the same business question in natural language. Let the agent use get_datasynch_run_status, get_failed_runs, summarize_workspace_activity, and supplied GIS/geofence tools as needed to assemble the evidence.
- 4
Review which tools the agent selected and the evidence it returned. A good result should distinguish missing or stale integration data from geographic issues and from transportation questions that require additional authorized shipment data.
- 5
Keep consequential actions on separately authorized API/tool paths. If the playbook later needs a write or production action, expose only the specific capability required for that relationship and keep its permissions narrower than the full platform.
- 6
Run the same test set used for the REST implementation. Record the agent path, tools called, latency, answer quality, human review time, and cost so the comparison is based on evidence instead of preference.
Compare the two paths with the same scorecard
- Time to a usable answer, including the operator time spent searching or reviewing.
- Successful-answer rate across the same representative transportation questions.
- Ability to correctly separate stale/failed data from a real operational exception.
- Latency and cost per task, including API calls and agent usage where applicable.
- How often a person must intervene, clarify the question, or inspect another system.
- Which path is easier to maintain when routes, data sources, or business questions change.
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 or the integration hub to receive and normalize shipment, order, appointment, carrier, or facility records from the systems that already own them.
- Use Atlasemoji location, geofencing, and routing capabilities only for the geographic questions the workflow actually needs.
- Return a stable, machine-readable result to the business application so the same question does not require a new manual search every time.
- Use approved webhooks, Intercept, or downstream integrations for actions and notifications after the lookup or event has been proven.
Rutas de API y ayuda relevantes
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 runs, locations, telemetry, geofence, and dispatch. Start with /api/datasynch/runs when you need to prove the feed is current; use the location, telemetry, and geofence routes only when those facts change the transportation answer.
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 the telemetry, geofence, and run-log guided workflows to understand the sequence before building a transportation lookup into your own application.
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.
After you select a DataSynch route, compare your request body with a known-good example and replace only the IDs and business data your workflow owns.
Travel & Routing →
The Travel & Routing solution explains where route, waypoint, and movement context fits. Use it to decide whether a transportation question actually needs routing data or can be answered from operational status alone.
Read this before adding routing. If the question is only “is the feed current?” or “what status did the TMS send?”, you may not need a route calculation at all.
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 when the question involves arrival, exit, dwell, proximity, or wrong-site behavior. It helps separate a location-event design problem from a shipment-status 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.
get_datasynch_run_statusget_failed_runssummarize_workspace_activityvalidate_coordinatescheck_point_in_geofenceFor companyId <COMPANY_ID>, workspaceId <WORKSPACE_ID>, and manifestId <MANIFEST_ID>, review the last 24 hours of transportation-related DataSynch activity using only the Atlasemoji MCP tools exposed to this agent. Those tools represent the approved API-backed capabilities for this connection. First use get_datasynch_run_status to establish whether the feed is current. Then use get_failed_runs to identify failed or incomplete processing and summarize_workspace_activity to show recent activity. If I supply facility coordinates or a geofence, use validate_coordinates and check_point_in_geofence for that supplied geography. Return four sections: Feed health; Failed or stale data; Geographic checks; Questions that still require shipment/TMS data.
Current MCP tools used
get_datasynch_run_statusget_failed_runssummarize_workspace_activityvalidate_coordinatescheck_point_in_geofenceFind out whether the problem is the feed or the shipment
For companyId <COMPANY_ID>, workspaceId <WORKSPACE_ID>, manifestId <MANIFEST_ID>, and time window 24h: call get_datasynch_run_status, then get_failed_runs, then summarize_workspace_activity. Tell me whether transportation visibility may be stale because of the feed. Group evidence by run or repeated failure pattern, state what data may be missing, and list the next checks. Do not retry or change anything.
Validate the geographic part of the answer
Validate the supplied facility coordinates and determine whether the supplied point is inside the approved geofence. Report the validation result and any geographic issue that could explain an incorrect arrival or proximity result.