TMS MCP server: connect Roadmark to any AI assistant

The Model Context Protocol (MCP) is an open standard for connecting AI applications to outside systems. A business system runs one MCP server, and any assistant that supports the protocol can use it: Claude, ChatGPT and Gemini all do, and so do tools such as Microsoft Copilot Studio and many developer tools.

For Roadmark, that means one connector for every assistant your team uses. Your freight stays in Roadmark, and the assistant asks for what a question needs, as the person asking.

How MCP works, in plain words

There are two sides. The assistant is the MCP client. The system that holds the data is the MCP server. When the two connect, the server lists the tools it offers, each with a name, a description and the inputs it takes. When someone asks a question, the assistant decides which tools it needs, calls them, and writes its answer from what comes back.

Two parts of the standard matter most for freight data:

• Sign-in. For servers reached over the internet, the MCP authorization specification is built on OAuth 2.1. The person signs in with the system that holds the data, and the assistant gets a token for that server, never a password.
• A person in the loop. The tools specification says there should always be a human able to deny a tool call, and that assistants should ask before sensitive operations and show which tools they're calling. Claude, ChatGPT and Gemini each add their own approval settings on top.

What Roadmark's MCP server offers

A small set of tools, in plain words, not a copy of the whole API. As the Developers page describes them, they let an assistant:

• find loads by customer, lane, status or date, the way a dispatcher would ask;
• read one load in full: stops, status, rate and documents;
• price a lane from contracts and rate history, and leave the result as a draft;
• record a new ETA from a check call or a delay, drafted for approval like any other update;
• find open, paid or overdue invoices for a customer;
• look up a customer's contract, contacts and recent loads.

Every call runs as the person signed in. It sees their companies and customers, and nothing else, and the same row-level isolation that separates the group's companies in the database applies whether a question comes from a screen, the API or an assistant. See Security.

An example, from question to approval

With Roadmark's example group, J. Park asks Claude to price the Lakeshore Grocers RFQ. The assistant calls Roadmark's quoting tool for each lane. The Quoting agent prices Mississauga to Joliet at $4,920.00, in US dollars, from 90 days of lane history, and leaves it, with every other lane that has history, as a draft. Lanes with no history, such as Toronto to Memphis, are left for a person. J. Park reviews the drafts in Roadmark, approves them and sends the quote to Lakeshore Grocers. The quote's history shows all three steps: asked in Claude, drafted by the Quoting agent, approved and sent by J. Park.

The same request from ChatGPT or Gemini would produce the same drafts, because the price comes from the same agent, contracts and history, not from the assistant.

Connecting a client

Every MCP client names the setting differently, and each vendor decides which plans can use it:

• Claude: a custom connector, on Free, Pro, Max, Team and Enterprise plans.
• ChatGPT: a custom app, created and published by a workspace admin on Business, Enterprise and Edu.
• Gemini: a custom app in the Gemini app on a personal Google Account, or a custom MCP server in Gemini Enterprise.

Any other client that can reach a remote MCP server and sign in to it can connect the same way, with the address from Roadmark's settings. Developers building their own agent can use the same server, with the same sign-in and the same limits, or the full Roadmark API and webhooks, starting from a sandbox with the Ashgrove example group already loaded.