Give your support team a connector to your helpdesk

Give your customer-support team a connector, and their assistant can look up an order, pull a ticket, check a shipment's status, and draft a reply, all against your own systems, without anyone leaving the chat window. A connector is a hosted MCP server the assistant installs by pasting one URL. You write the tools that read from your helpdesk and order database; DenkOps hosts them and runs the whole login flow. Access is limited to the support team, and every use is on record.

What does the support team's day look like with a connector?

A customer writes in: "where is my order?" The agent on shift asks their assistant, and the assistant calls lookup_order with the order number, then check_shipment with the tracking id it got back. It composes a status summary and hands it to the agent, who reads it, adjusts the tone, and sends. No tab-switching between the order tool, the carrier page, and the ticket queue. The same connector answers "has this customer contacted us before?" with find_tickets by email, so the agent walks into the reply already knowing the history.

The point is that these are your systems. The connector is not a generic bot, it is a thin set of tools that speak to the exact database and helpdesk your team already uses.

Which tools should a support connector have?

Start read-mostly. Support work is overwhelmingly about finding the truth and phrasing it well, not mutating records, so the highest-value tools only read. Here is a connector with three of them.

import { defineMcp } from "@denkopsai/sdk/mcp";
import { z } from "zod";

const HELPDESK = "https://api.helpdesk.internal";

async function api(path: string) {
  const res = await fetch(`${HELPDESK}${path}`, {
    headers: { authorization: `Bearer ${process.env.HELPDESK_TOKEN}` },
  });
  if (!res.ok) throw new Error(`helpdesk answered ${res.status}`);
  return res.json();
}

export default defineMcp({
  name: "support-tools",
  version: "1.0.0",
  tools: {
    lookup_order: {
      description: "Look up an order by its order number.",
      input: z.object({ orderNumber: z.string() }),
      handler: ({ orderNumber }) => api(`/orders/${orderNumber}`),
    },
    find_tickets: {
      description: "Find recent support tickets for a customer email.",
      input: z.object({ email: z.string().email() }),
      handler: ({ email }) => api(`/tickets?email=${encodeURIComponent(email)}`),
    },
    check_shipment: {
      description: "Check delivery status for a tracking id.",
      input: z.object({ trackingId: z.string() }),
      handler: ({ trackingId }) => api(`/shipments/${trackingId}`),
    },
  },
});

Each tool has a Zod input schema, so the assistant sees exactly what it takes and self-corrects a bad call instead of failing inside your code. The HELPDESK_TOKEN is read from process.env, never pasted into the assistant. On DenkOps that secret is write-only after you save it: the tools use it, no one reads it back.

How do I make sure only the support team can use it?

Two lines of config and one list. Set "connector": true in denkops.json and DenkOps runs the full OAuth flow in front of your tools: discovery, client registration, login, and consent. Your code contains no auth plumbing.

{ "name": "support-tools", "slug": "support-tools", "runtime": "bun", "connector": true }

Then set the project's access policy to an allowed-email list in the dashboard and add your support agents. Everyone else is refused at login, before a single tool call runs. When an agent joins or leaves the team, you change the list, not the code. This is the same access model a SaaS connector uses for design partners, pointed inward at one team.

How do I stay accountable for what the assistant did?

Because the connector reads live customer data, you want a record. Every access grant and membership change lands in your workspace audit log, so "who could reach customer records this month" has a real answer. Keeping the tools read-mostly is the other half: an assistant that can look things up but cannot delete a ticket is a bounded risk. When you do add a write tool, like tagging a ticket, add exactly that one, with a narrow schema.

Your support team already lives in a chat window. Give them the connector that reads from the systems behind it. Start with deploying your first MCP server, then flip on the connector flag.