project Β· 2025-2026

Two MCP servers, one design pattern

Two production Model Context Protocol servers giving AI agents structured access to TomTom APIs. Both open source, both authored end-to-end (TypeScript, design + impl + docs).

Two production Model Context Protocol servers giving AI agents structured access to TomTom APIs. Both open source, both authored end-to-end (TypeScript, design + impl + docs).

See it work (scripted demo)

Press play. The agent receives a plain-language request, picks the right MCP tool to invoke, sends a structured tool-call, and synthesises a grounded response from the result. Hardcoded transcript, but the tool names and argument shapes mirror the real tomtom-mcp server.

tomtom-mcp: plain-language β†’ tool calls β†’ grounded answer
step 0 / 7scripted demo, no live data

The agent never invented a cafe and never guessed a distance. Every claim in the verdict is backed by a structured tool result. That separation is the whole point of MCP: the LLM does narrative, the server does facts.

And the same pattern, applied to traffic analytics

The traffic-analytics MCP exposes the same shape of tools, just over a different API surface. Below is a different scenario, same flow.

tomtom-traffic-analytics-mcp: corridor anomaly investigation
step 0 / 6scripted demo, no live data

Notice how an agent uses the same protocol across two completely different domains: search-and-routing on one server, traffic-anomaly investigation on the other. That portability is what MCP enables.

tomtom-mcp

General-purpose MCP for location, search, geocoding, and routing. First TomTom MCP server, coordinated with Microsoft for Azure Marketplace publication.

tomtom-traffic-analytics-mcp

Specialised MCP exposing TomTom’s MOVE traffic-analytics services for real-time and historical reasoning over road networks.

The shared design pattern

Both servers share the same opinionated layout:

  1. API client first, hand-rolled, fully typed, no auto-generated bloat.
  2. Tools as thin wrappers over the client. Each tool is a single function with a schema for argument validation.
  3. Error envelopes so agents can recover gracefully when an API call fails.
  4. Streamable HTTP transport for proper multi-step agent runs.

links

← all projects