Directory Connector, Self-Hosted MCP, or Custom Build: Three Ways to Connect Claude to Field Service Scheduling

The short answer: there are three ways to give an AI assistant control of a field service schedule — a one-click connector from the Claude connectors directory, a self-hosted MCP server you run and maintain yourself, or a custom integration built directly on a scheduling API. The directory connector is the right default for operators: OAuth sign-in, zero maintenance, nothing to install. Self-hosting wins when you need custom tools or restricted egress, and a custom build wins when the agent lives inside your own product.

If you run — or build software for — a field service operation, you have probably seen the tutorials: "connect Claude to ServiceTitan", "a ServiceM8 MCP server", "wire GPT into your dispatch board". They all solve the same problem: an AI assistant is only as useful as the systems it can act on, and for a field service business the system that matters is the schedule.

What those tutorials rarely make explicit is that there are three structurally different ways to make that connection, with very different costs of ownership. This post lays them out honestly — including the cases where the path we ship is the wrong choice.

The Directory Connector: One Click, Zero Maintenance

The scheduling platform hosts a remote MCP (Model Context Protocol) server and lists it in the assistant's connector directory. You click Connect, authorize with OAuth, and start asking questions. Nothing runs on your machine; the vendor maintains the server, the auth, and the tool definitions.

When to Choose It

This is the path most field service operators should take, for one reason: the person who benefits from an AI dispatcher is usually not the person who can maintain one. A directory connector means the vendor runs the server — when a new tool ships or a bug gets fixed, every connected user gets it immediately, with no version to bump. Authorization is OAuth: the owner signs in once, can revoke from either side at any time, and no API key ever gets pasted into a chat window.

Concretely, with Crisphive — available natively in the Claude connectors directory — the flow is: connect from the listing, authorize as the business owner, and ask. The connector exposes 43 scheduling tools behind one URL: job booking, work-order tracking, dispatch and availability, customer sync, service catalogs, crew rosters, service territories and fleet data. Anything that would move existing work comes back as a reviewable plan first — which jobs move, the new ETAs, the SLA impact — and commits only after you approve it. The full connector guide, prompt library included, lives on the MCP for Claude page.

When It Is the Wrong Choice

You get the vendor's tool set, not yours. If you need a tool the server doesn't expose, you wait for the vendor or drop to path 2 or 3. You are also constrained to assistants whose plans support remote connectors. And if your platform doesn't ship a hosted connector at all — the situation most of those third-party "Claude + your FSM" tutorials are written for — this path simply doesn't exist for you, which is exactly why the other two do.

The Self-Hosted MCP Server: Pin, Audit, Extend

You run the MCP server yourself — an official package, a community-built server for a platform that doesn't ship one, or your own wrapper. Your assistant talks to your server; your server talks to the platform's API with credentials you manage.

When to Choose It

Self-hosting is the developer's path, and there are honest reasons to take it even when a directory connector exists. You run stdio-only or restricted clients that can't reach remote servers, or a corporate network that won't let them — a local server or an mcp-remote bridge solves both. You want to pin and audit: a directory connector updates when the vendor updates, and if your compliance process requires reviewing every change that can touch customer data, running a pinned, audited version yourself is the defensible choice. You need custom tools: fork the server, add the tool your workflow needs, keep the rest. Or your platform has no hosted server, making a community MCP server the only MCP path available.

For Crisphive, the self-hosted option is the open-source @crisphive/mcp package pointed at the same API with a key you manage — including a free chsk_test_ sandbox key that keeps experiments in an isolated test environment.

When It Is the Wrong Choice

You now operate infrastructure. The server needs a process to run in, keys need storage and rotation, and every upstream update is a redeploy you have to notice, test, and ship. For a software team that's Tuesday; for a plumbing company it's a liability with no owner. If nobody on the team will own uptime, key rotation and updates, this path quietly becomes the least secure option, not the most.

The Custom Build: Your Product, Your Rules

You skip MCP and integrate the scheduling API directly into your own agent — function calling against REST endpoints, your own tool schemas, your own orchestration. Maximum control, maximum ownership.

When to Choose It

Three situations justify it. The agent lives inside your product: if you're an FSM vendor, a vertical SaaS, or an agency shipping a branded dispatch assistant, your users should never see a third-party connector consent screen — you want the scheduling engine as an invisible dependency with your own UX on top. Your framework isn't MCP-native: plenty of production agent stacks do plain function calling, and wrapping a REST API in your own tool schemas keeps the stack uniform. Or you need a curated tool surface: an agent with 43 tools reasons more slowly, and spends more tokens, than an agent with the 6 tools its job needs — hand-picking endpoints for exactly your use case is a real optimization an off-the-shelf server can't make for you.

The dividing line with Crisphive is clean because the MCP server and the REST API expose the same engine: MCP is the front door for assistants people already use; the REST API at docs.crisphive.com is the front door for software you're building. Same constraints, same solver, same answers.

When It Is the Wrong Choice

The cost is permanence: you own the integration forever. Schema design, error handling, API version migrations, security review — all yours, for as long as the agent runs. If a hosted connector already covers your workflow, building custom middleware buys you technical debt, not capability.

At a Glance

• Directory connector: one click + OAuth, zero maintenance, vendor-curated tools, updates arrive silently. Built for operators and dispatchers from day one. Wrong when you need custom tools or your platform isn't in a directory.

• Self-hosted MCP: any MCP client including stdio-only, pinnable and auditable, extensible by forking — but you own uptime, key storage, rotation and every redeploy. Wrong for teams without an infrastructure owner.

• Custom build: exactly the tools you define, embedded in your own product UX — and yours to maintain through every API change. Wrong for standard workflows a connector already covers.

What All Three Paths Inherit (and What None of Them Fix)

Whichever transport you choose, the quality of the agent is capped by the engine behind it. A language model should not be computing schedules — it can't reliably solve travel time, skill matching, protected breaks and SLA cascades as hard constraints, and it will confidently hand you a plan that violates all four. In Crisphive's architecture, the assistant interprets intent and the deterministic constraint solver computes every change: same input, same schedule, every time. When an emergency lands mid-day, a full cascade reschedule computes in under 3 seconds — measured on a 20-location, 3-vehicle fleet simulation with mobilization, travel time, supply runs and breaks as hard constraints. Teams operating this way see, as an illustrative operating model rather than measured customer averages, 20–35% less windshield time and 25–40% more jobs per day.

No integration path fixes a solver that isn't there. If the platform you're wiring up "schedules" by letting the LLM guess, the transport is the least of your problems.

Choosing in 30 Seconds

• A dispatcher, owner, or ops lead who wants to talk to the schedule today → directory connector. One click, OAuth, plans before changes.

• A developer who needs custom tools, pinned versions, or stdio clients → self-hosted MCP.

• A product team embedding scheduling into its own software → custom build on the REST API.

• Not sure? Start with the connector — it's the only path with zero switching cost. Nothing about trying it locks you out of the other two, because all three speak to the same API.

Frequently Asked Questions

Is a directory connector less secure than self-hosting?

Generally the opposite for non-engineering teams: OAuth means no long-lived API keys to store, and access is revocable from either side. Self-hosting is more controllable, but only more secure if someone actually manages the keys, updates and audit trail.

Can I mix paths?

Yes, and mature setups do: dispatchers use the directory connector in Claude while the product team calls the same API from backend code. The tool surface and constraints are identical, so the two never disagree about the schedule.

Do I need a paid Claude plan for the connector?

Connector support depends on your assistant's plan. Crisphive itself is licensed per fleet, not per assistant — and MCP calls are never billed.

My FSM isn't in any connector directory. What's my real option?

A community or self-built MCP server against its API, with you owning credentials and upkeep — or moving the scheduling layer to an engine that ships a hosted connector and syncs back to your FSM as the system of record.

Does the assistant ever change the schedule on its own?

Not on any of the three paths, if the engine is designed correctly: every mutating flow should return a preview — jobs moved, new ETAs, SLA impact — and commit only on explicit approval. That's how the Crisphive tools behave on all three transports.

Want to see the connector path end to end? The companion tutorial walks it step by step — connect Claude, book a job, absorb a P0 emergency. Developers can grab a free chsk_test_ sandbox key on the developers page — no credit card, no sales call.