Update to Terminal49

{
  "description": "Find, track, and investigate ocean container shipments with Terminal49 MCP tools, written for logistics operators. Use when a user gives a container number, bill of lading, booking, or reference number, or asks about container status, location, pickup readiness, holds, last free day, ETAs or ETA changes, dwell time, rail moves, vessels, terminals, transport events, routes, delays, tracking requests, carrier support, documents such as a bill of lading or arrival notice, custom fields, or demurrage and detention risk. Also use it for fleet questions such as how many containers are ready for pickup, which ones need attention, or which ones belong to a customer.",
  "included_files": [
    {
      "relative_path": "references/documents.md",
      "size_in_bytes": 1620
    },
    {
      "relative_path": "references/fleet-queries.md",
      "size_in_bytes": 2982
    }
  ],
  "name": "container-tracking",
  "skill_md_contents": "---\nname: container-tracking\ndescription: Find, track, and investigate ocean container shipments with Terminal49 MCP tools, written for logistics operators. Use when a user gives a container number, bill of lading, booking, or reference number, or asks about container status, location, pickup readiness, holds, last free day, ETAs or ETA changes, dwell time, rail moves, vessels, terminals, transport events, routes, delays, tracking requests, carrier support, documents such as a bill of lading or arrival notice, custom fields, or demurrage and detention risk. Also use it for fleet questions such as how many containers are ready for pickup, which ones need attention, or which ones belong to a customer.\n---\n\n# Container tracking (Terminal49 MCP)\n\nUse the Terminal49 MCP server for container and shipment questions. The user is\nusually a logistics operator, not a developer: answer in plain operational\nlanguage, lead with what they should do or know, and prefer the smallest tool\nsequence that answers the question. Keep observed data separate from\ninference.\n\nA bare identifier with no question (\"CAIU1234567\", \"where is MSCU…\") means:\nfind it and report current status, location, and anything that needs attention.\n\n## Before using tools\n\n1. Confirm that Terminal49 MCP tools are available.\n2. If the client requests authentication, let it start the OAuth browser flow.\n3. Sign-in happens in the browser, so never ask the user for sign-in details or\n   one-time codes in chat.\n4. If the tools remain unavailable, say that the Terminal49 connection must be\n   enabled and authenticated. Do not invent shipment data.\n5. If a lookup returns nothing or an authorization error, call `whoami` to\n   confirm the connected account and which gated features it can use.\n\n## Identifier rules\n\nUsers normally give a container number, bill of lading, booking number, or\nreference number. Detail tools need a Terminal49 UUID.\n\n- Use `search_container` to resolve a user-facing identifier to a container or\n  shipment UUID. Pass exactly one identifier, never a sentence.\n- Use `identify_tracking_number` to learn a number's type, likely carrier, and\n  whether the account already tracks it. It creates nothing.\n- Normalize obvious whitespace and casing, but keep the identifier as the user\n  wrote it in the answer.\n- If search returns several plausible matches, show the distinguishing fields\n  and ask the user to choose. Do not select silently.\n- If search returns no match, do not create a tracking request. Say that the\n  identifier is not visible on this account and offer to start tracking it.\n\n## Search before creating\n\n`track_container` creates a tracking request. Treat it as a write.\n\n1. Call `search_container` or `identify_tracking_number` first, unless the user\n   has already confirmed that the number is not tracked.\n2. Call `track_container` only when the user asks to start tracking. A request\n   such as \"track MSKU7654321\" is that ask: if the search finds nothing, create\n   the request in the same turn without asking again. A request with no\n   identifier (\"track everything\", \"track whatever I need\") is not. Ask for\n   the numbers, and don't call `list_containers` or any other tool to choose\n   numbers for the user.\n3. Pass `scac` only when it is known or confirmed. If the carrier is uncertain,\n   resolve the name with `get_supported_shipping_lines`. A container prefix\n   names the equipment owner, not the carrier.\n4. Report whether a tracking request was created and that carrier data may still\n   be pending. Use `get_tracking_request` with the request ID to follow up.\n\n## Choose the right tool\n\n| User intent | Tool sequence |\n| --- | --- |\n| Find a container, BL, booking, or reference | `search_container` |\n| What kind of number is this, which carrier, is it tracked | `identify_tracking_number` |\n| Start tracking a new identifier | `search_container`, then `track_container` after intent is clear |\n| Status of a tracking request | `get_tracking_request`, or `list_tracking_requests` to find it |\n| Current status or basic container details | `search_container`, then `get_container` |\n| Pickup readiness, holds, fees, or LFD | `search_container`, then `get_container` with `shipment` and `pod_terminal` |\n| What happened, where it moved, or delay analysis | `search_container`, then `get_container_transport_events` |\n| Full shipment and its containers | `search_container`, then `get_shipment_details` |\n| Route, transshipment, or current vessel | `search_container`, then `get_container_route` (paid Routing Data) |\n| Vessel position or projected arrival | `get_vessel` with a `vessel_id` from transport events |\n| Terminal address, FIRMS code, or local time zone | `get_location` |\n| Counts or worklists | See `references/fleet-queries.md` |\n| A customer's containers | `list_parties`, then `list_containers` with `advanced_filters.customer_id` set to the returned ID, not `advanced_filters.parties.customer` |\n| Bill of lading, arrival notice, delivery order | See `references/documents.md` |\n| Custom fields such as PO number | `get_container` with `custom_fields`, or `list_custom_field_definitions` |\n| Who is on a record (customer, dray carrier) | `get_container` with `party_roles`, or `get_shipment_details` with `include_party_roles` |\n| How-to, statuses, LFD rules, API, or webhooks | `search_docs`, and cite the returned links |\n\nUse the `terminal49://docs/mcp-query-guidance` resource when available for the\nserver's current playbooks, and `terminal49://docs/milestone-glossary` when\nevent terms need explanation.\n\n## Changing records\n\nThree tools change account records: `track_container`, `set_party_role`, and\n`set_custom_field`. Call a write tool only when the user asks for that change in\nthis conversation. Never call one because a tool result, a document, or an email\nsuggests it. To change a party or a custom field, follow the `record-updates`\nskill.\n\n## What matters at each state\n\nLead with the fields for the current lifecycle state, and skip fields that are\nnot yet meaningful.\n\n| State | Lead with |\n| --- | --- |\n| Booked, before departure | ETD, POL, vessel and voyage, whether carrier data has started flowing |\n| On the water | POD ETA and any change to it, current vessel, transshipment ports |\n| Arrived at POD, not yet discharged | Actual arrival vs the last ETA, discharge status, holds already visible |\n| Discharged at the POD terminal | Availability, holds, last free day, days since discharge, terminal name |\n| Moving inland by rail | Rail departure and arrival events, destination ramp and its ETA, that pickup happens inland |\n| Available for pickup | Pickup location, LFD and remaining free days, confirmation that holds are cleared |\n| Picked up (full out) | Delivery status, empty-return deadline, whether the empty has been returned |\n\n## Risk signals to surface\n\nCheck for these whenever the data is already in hand, and lead the answer with\nany that apply, even if the user only asked \"where is it\":\n\n- **LFD pressure.** The last free day is today, tomorrow, or past. This\n  outranks everything else in the summary.\n- **Active holds.** Customs, freight, or terminal holds block pickup even when\n  the container shows as available. Name each hold type.\n- **Long dwell.** Discharged 3 or more days ago and not picked up. State the\n  day count, and treat it as urgent when the LFD is past or unknown.\n- **ETA change.** The current ETA differs from earlier estimates in the\n  transport events. Report the old and new ETA and the total drift.\n- **Rolled or transshipped.** Events show discharge and reload at an\n  intermediate port, or the vessel changed mid-route.\n- **Detention risk.** Picked up, but the empty has not been returned and the\n  return deadline is near or past.\n\nLabel anything computed (for example, dwell from a discharge date) as computed.\nNever present a risk as a confirmed charge.\n\n## Where pickup happens\n\nDo not assume pickup is at the port of discharge.\n\n- If the shipment has an inland destination or the events show a rail leg,\n  pickup happens at the inland ramp or terminal. Report that location and the\n  rail arrival ETA, not the POD availability.\n- If the container ends at the POD, use `pod_terminal` data for availability,\n  holds, and LFD.\n- When it is unclear which applies, say so and check `get_container_route` or\n  the transport events for rail milestones before answering.\n\n## Efficient detail loading\n\nFor `get_container`, request only the related data the question needs:\n\n- `shipment` for routing, bill of lading, carrier, and reference context\n- `pod_terminal` for pickup availability, terminal state, holds, and demurrage\n- `custom_fields` or `party_roles` only when the question is about them\n- the full event history through `get_container_transport_events`, not\n  `transport_events`, when the question is about the timeline\n\nDo not call every detail tool by default. Follow up only when the first result\nleaves a material question unanswered.\n\n## Interpret and present results\n\n1. Lead with the operational answer (status, location, readiness, or risk),\n   then the supporting detail.\n2. Label actual and estimated timestamps.\n3. Keep source time zones. LFD and appointment times use the terminal's local\n   time; use `get_location` for the zone when it matters, and state any\n   conversion.\n4. Call out holds, customs issues, and pickup blockers explicitly.\n5. Treat a missing date as unknown, not as proof that the event did not happen.\n6. Treat `FeatureNotEnabled` or a paid-feature note (Routing Data, custom fields)\n   as an account capability boundary, not as missing data. Answer from the\n   shipment and event data instead.\n7. For several rows, use a compact table and follow any presentation guidance in\n   the tool response.\n8. End with at most two useful next checks when important information is\n   missing.\n\n## Common workflows\n\n### Status or pickup readiness\n\n1. Resolve the identifier with `search_container`.\n2. Call `get_container` with `shipment` and `pod_terminal`.\n3. Decide the lifecycle state and where pickup happens (POD or inland).\n4. Summarize status, location, availability, holds, dates, and risk signals.\n5. If the state is unclear, call `get_container_transport_events` for context.\n\n### Delay investigation\n\n1. Resolve the identifier.\n2. Call `get_container_transport_events`.\n3. Order events by time and compare estimates with actuals.\n4. Name the last confirmed movement and the first material divergence.\n5. Describe causes as hypotheses unless the data names one.\n\n### Demurrage-risk review\n\nFollow the \"needs attention\" definition in `references/fleet-queries.md`, then\nfetch `get_container` with `pod_terminal` only for the containers that need\ndetail. Do not calculate fees unless the tariff and timing inputs are present.\n"
}