Building a Mercedes-Benz Service Reminder MCP Server in TypeScript

Ask most AI assistants when your Mercedes-Benz is next due for a service and you will get a confident, generic answer. Sometimes it is right, often it is vague, and occasionally it is simply invented. At SilberArrows, a Mercedes-Benz specialist in Dubai since 2011, we hear the same questions every day from owners: Is it Service A or Service B next? What does it include? Is that warning light serious?

So we built a small, open-source Model Context Protocol (MCP) server that gives assistants such as Claude, Cursor and ChatGPT a deterministic answer instead of a guess. This article walks through what it does, how it is built, and how to use it.

• npm: mercedes-benz-service-reminder-mcp
• GitHub: gentlegiant96202/mercedes-benz-service-reminder-mcp
• Remote endpoint: https://silberarrows-mcp.netlify.app/mcp

Why an MCP server, not a prompt

A language model is good at conversation and poor at date arithmetic. Working out the next service involves two moving targets, time and distance, and the answer is whichever arrives first. It also alternates: on most modern models, Mercedes-Benz uses an ASSYST-style schedule in which Service A and Service B take turns, typically every 15,000 km or 12 months.

MCP lets us move that logic out of the model and into a tool. The assistant handles the conversation; the server does the maths and returns structured JSON. The result is the same every time, and it is testable.

The four tools

The server exposes four tools:

Tool	Purpose
get_next_service	Next service type (A or B), due date, due mileage and status from the last service details
explain_service	What a Mercedes-Benz Service A or Service B typically includes
warning_light_info	General guidance on common warning lights (check engine, limp mode, ABS/ESP, battery, service due)
find_specialist	Contact details for a Mercedes-Benz specialist in Dubai

There are no accounts, no API keys for local use, no network calls and no data collection. Everything runs on the user's machine.

How it is built

The server uses the official TypeScript SDK (@modelcontextprotocol/sdk) and zod for input validation. Registering a tool is short:

server.tool(
  "get_next_service",
  "Estimate the next Mercedes-Benz service (alternating Service A/B, ASSYST-style).",
  {
    last_service_type: z.enum(["A", "B", "a", "b"]),
    last_service_date: z.string().describe("YYYY-MM-DD"),
    last_service_km: z.number().nonnegative(),
    current_km: z.number().nonnegative().optional(),
    interval_months: z.number().int().min(1).max(36).optional(),
    interval_km: z.number().int().min(1000).max(50000).optional(),
  },
  async (a) => out(computeNextService({ /* mapped inputs */ }))
);

The zod schema matters more than it looks. It becomes the JSON Schema the assistant sees, so clear .describe() text on each field is effectively prompt engineering. A well-described parameter means the model asks the owner for the date of the last service instead of guessing it.

Getting the dates right

The core logic lives in a pure function, computeNextService, which makes it easy to unit test. A few details are worth mentioning:

• UTC calendar days. All dates are handled as UTC midnight, so daylight-saving changes and time zones cannot shift a due date by a day.
• Month-end clamping. Adding 12 months to 29 February, or one month to 31 January, clamps to the last valid day instead of spilling into the following month.
• Whichever comes first. When the current mileage is supplied, the server estimates the daily distance driven and compares the mileage due date with the time due date. It then reports which one applies (dueBy: "time" or "mileage").
• Status. Results are flagged as ok, due-soon (within 30 days or 1,500 km) or overdue.

Every response carries a disclaimer: intervals are general guidance, and owners should always follow their own vehicle's ASSYST indicator and the manufacturer's schedule for their model.

Keeping the content factual

explain_service and warning_light_info return curated, deliberately conservative text. A flashing check-engine light, for example, is treated as "reduce load and stop when safe", never as a diagnosis. Where an owner wants more depth, responses point to longer guides such as our breakdown of Mercedes-Benz Service A costs in Dubai and our scheduled maintenance page.

Two transports, one server

The createServer() factory is transport-agnostic. The npm package wires it to stdio for desktop clients. The same factory also runs as a stateless streamable-HTTP function on Netlify at https://silberarrows-mcp.netlify.app/mcp, for clients that only accept remote servers. An optional API key is supported for the hosted endpoint.

Using it

Claude Desktop or Cursor

Add the following to claude_desktop_config.json or ~/.cursor/mcp.json:

{
  "mcpServers": {
    "mercedes-benz-service-reminder": {
      "command": "npx",
      "args": ["-y", "mercedes-benz-service-reminder-mcp"]
    }
  }
}

Node.js 18 or later is required. Nothing else needs to be installed.

Remote clients

Point any client that supports streamable HTTP at https://silberarrows-mcp.netlify.app/mcp.

Try it

Once it is connected, ask your assistant:

"My Mercedes-Benz had a Service A on 1 March 2026 at 40,000 km and it's now on 50,000 km. When is the next service?"

The assistant calls get_next_service and receives structured output: next type B, due by time on 1 March 2027 or at 55,000 km, with an estimated date based on your driving rate. You can follow up with "What does Service B include?" or "My dashboard shows a yellow engine light, what should I do?"

What we learned

1. Small tools beat big prompts. Four focused tools with tight schemas outperform a long system prompt full of service rules.
2. Descriptions are the interface. Most of the quality improvement came from rewriting tool and parameter descriptions, not from code.
3. Be honest about limits. A service reminder is guidance. Saying so in every response builds more trust than false precision.
4. Publish everywhere developers look. We published to npm and the official MCP Registry and added a Dockerfile, so the same server reaches every client.

About SilberArrows

SilberArrows is an independent Mercedes-Benz service centre in Al Quoz, Dubai, founded in 2011. We specialise in Mercedes-Benz servicing and repairs, service contracts and transparent service pricing. If your assistant tells you a service is due, you can contact us or call [phone].

The server is MIT-licensed, and issues and pull requests are welcome on GitHub.