How We Built a Remote MCP Server for Field Service Scheduling

An MCP server becomes interesting when it stops being a demo and starts carrying a real workflow. For Crisphive, that workflow was field service scheduling: the messy, ordinary work of looking at jobs, people, locations, availability, and dispatch context without asking an operator to copy everything into a chat window. This build note is the origin story of our remote MCP server: why we built it, the architecture choices we made, where OAuth fit, and how we thought about the path toward the Claude Connectors Directory.

The context

Field service scheduling is not a tidy single action. A dispatcher may need to check whether a job is ready, find the right technician, understand what changed since the last customer message, and avoid creating a new conflict while doing it. That is exactly the kind of work where an AI assistant needs more than a prompt. It needs tools that can ask the scheduling system precise questions and return precise answers.

The brief for our remote MCP server was therefore simple: expose scheduling capability as a tool interface that an AI client could use without turning the scheduling product into a generic chat toy. The model context protocol gave us a way to describe tools, keep the integration shape predictable, and separate the assistant experience from the operational system behind it. For readers who want the protocol home base, the project lives at modelcontextprotocol.io.

That framing also kept us from chasing a generic MCP server 2026 checklist. The useful question was narrower: which scheduling tasks become safer or faster when the assistant can ask the system directly, and which tasks still belong in the product UI with a human making the call?

We also had to be honest about the audience. Developers and AI builders do not need a sales tour of MCP server software. They need to know where the boundary sits: what the assistant can call, what the scheduling system still owns, and what happens when a request is ambiguous. That boundary shaped the whole build.

How it works

The architecture starts with a remote MCP server rather than a local-only experiment. The server sits between the AI client and Crisphive scheduling APIs. It defines the tools, validates input, calls the scheduling backend, and returns a response that is useful without leaking unnecessary internal structure. In other words, it behaves less like a shortcut and more like a deliberately narrow AI agent tools API.

OAuth mattered because scheduling data is operational data. A connector that can read or act on dispatch context has to know whose workspace it is operating in and which permissions apply. The remote server gives us one place to handle that authorization path, attach the right account context, and keep tool calls from becoming anonymous backend traffic.

We kept the first tool surface close to the field service use case. That meant thinking in terms of function calling scheduling rather than generic CRUD. A useful tool should speak the operator's language: jobs, availability, assignments, time windows, customer context, and dispatch constraints. The best MCP server for this job is not the one with the most tools. It is the one whose tools are small enough to verify and specific enough to be useful.

The Claude side of the work influenced the packaging. Anthropic's connector ecosystem, including the public Anthropic news surface where product changes are announced, made it clear that a production connector is judged by trust as much as novelty. We treated directory readiness as a product constraint, not a launch-day chore.

What users experience

The user experience should feel quieter than the architecture. A dispatcher should not need to know which tool was called or how the remote MCP server resolved account context. They should be able to ask a scheduling question and get an answer that reflects the field operation they already manage.

For a small business, the difference is practical. A technician is delayed. A customer asks for an earlier slot. A manager wants to know whether tomorrow's route can absorb one more job. The assistant can only help if it has a safe way to inspect scheduling context. That is why an MCP server for small business has to be opinionated about scope. It should not expose everything simply because the backend can do it.

We also wanted the connector to make uncertainty visible. If a request needs a human decision, the tool response should say so. If a scheduling move would depend on a policy the tool cannot see, it should stop short. That is one of the more useful MCP server tips we learned during the build: design the tool for responsible refusal as carefully as you design it for successful calls.

Good documentation is part of the experience too. The implementation details that belong near the Claude integration live closer to docs.claude.com than inside an operator-facing workflow. Keeping those surfaces separate helps developers debug without making the dispatch product feel like an engineering console.

Lessons learned

The first lesson was that the model context protocol is only half the product decision. The other half is tool design. MCP server examples can make the protocol feel easy, but field service scheduling forces harder questions: what should be readable, what should be actionable, and which actions should stay out of the assistant path until the product can prove them safely.

The second lesson was to start with observability. Tool calls need logs that connect the assistant request, the authenticated workspace, the backend call, and the result. Without that chain, it becomes hard to tell whether a bad answer came from the prompt, the tool description, the scheduling API, or the user's wording. How to improve MCP server quality often comes down to boring traces before clever prompts.

The third lesson was restraint. A connector can become impressive and fragile at the same time. We avoided stuffing the surface with every idea that sounded useful. Instead, we worked from the scheduling workflow outward and asked whether each tool would help a real dispatcher make a better decision. That helped us avoid building a thin wrapper around everything.

The last lesson was commercial but still technical: MCP server cost is not only hosting. It includes review time, permission modeling, maintenance, and the support burden when an assistant touches live operations. Treating those costs as part of architecture made the build more grounded.

What's next

The next step is not to make the connector louder. It is to make it more dependable. That means expanding tool coverage only where the scheduling workflow clearly benefits, tightening validation around ambiguous requests, and improving the feedback loop between tool results and the operator's next action.

We expect the next improvements to be incremental: clearer tool descriptions, better failure messages, and tighter review of what each tool is allowed to return. That kind of polish rarely shows up in a launch screenshot, but it is what makes a connector trustworthy after the first week.

We also want better examples inside the product development process. Not public claims, not staged demos, but internal MCP server examples that show how a dispatcher actually asks for help and where the assistant should pause. Those examples are how a remote MCP server moves from a protocol integration to a useful part of a field service workflow.

The broader direction is clear enough: AI builders are going to keep connecting assistants to operational systems. Our view is that field service deserves connectors built with the same discipline as the scheduling tools themselves. Small tools, explicit permissions, careful logs, and no pretending that a chat interface removes the need for judgment. That is the standard we are trying to meet as this MCP server moves from build note to production habit.