Anatomy of our MCP server: OAuth, .well-known discovery, and tool design

MCP OAuth connects a scheduling conversation to the authority of the person approving it. For developers building dispatch integrations for fleets of 50+ trucks, that boundary deserves attention before the first job changes. Crisphive's MCP server brings discovery, authorization, and scheduling tools into the same connection. Follow a request from connection setup to execution. Check what the client discovers and whose permissions it receives, then inspect what dispatch sees when the action succeeds or stalls.

The context

Consider a hypothetical regional dispatch team preparing to let an assistant help with bookings. The developer wants a connection that can survive normal use, while dispatch wants to know which business the assistant is working in and whether a proposed change has actually happened. Have the developer and dispatch manager review the connection together.

The Crisphive MCP server documentation describes a hosted remote server at https://api.crisphive.com/mcp. It exposes the public Developer API as tools over Streamable HTTP. Clients can connect through OAuth, or use an API key when they support a custom authorization header. The documented scheduling path uses a deterministic solver; the conversation leads to tool calls against that scheduling system.

Start your review with the business and environment the connection should reach. A sandbox exercise and a live scheduling change have different consequences. Ask the client to identify which environment the agency is testing, who approves access, and who owns the connection after handover. Write the answers beside the deployment settings, where the next developer can find them.

When reviewing MCP server examples, prefer an example that explains its authorization boundary. A successful connection alone doesn't demonstrate that an operator has the right access. You can use the Model Context Protocol reference for the protocol side of the integration while checking deployment behavior against the server documentation.

How it works

The connection begins with discovery. Crisphive documents a protected-resource document at /.well-known/oauth-protected-resource and authorization-server metadata at /.well-known/oauth-authorization-server. The first identifies the authorization server; the second supplies the endpoints the client needs, so treat well-known discovery as configuration you can inspect, especially when a client is connecting to a tool profile rather than the general endpoint.

The documented flow continues through dynamic client registration, member authorization, and a token exchange. PKCE S256 is required. PKCE lets the authorization flow bind the exchange to the client that began it without giving a public client a shared secret. During consent, a business member approves the connection. The resulting access follows that member's role, with narrower requested scopes available.

Decide which member should approve the integration. Choose an approving account whose permissions match the work. Decide what the workflow needs first. The documentation says the token is bound to the approving member's business, region, and environment; test the intended access with the role your client plans to use.

Refresh handling needs its own check.

The server returns a rotated token pair on refresh. Persist the newest pair before another worker tries to refresh the connection, and avoid keeping an old refresh token in a separate job, because Crisphive documents a short duplicate-refresh grace period followed by connection revocation when a replaced token is reused later. Build recovery around the documented lifecycle instead of assuming a retry is harmless.

MCP tool design then brings the scheduling request into view. The server documentation describes tools generated from the public API specification, with path, query, and body fields flattened into one arguments object. For function calling scheduling work, inspect the actual tool schema before supplying an argument. An AI agent tools API label won't tell you which field identifies the job or which operation commits the change.

What users experience

The operator approves access in a browser and returns to a conversation about work. Keep the explanation there in dispatch language: which job, which crew, and what changed. OAuth terminology is useful in a diagnostic log. It shouldn't be the only explanation a dispatch manager receives after a failed connection.

For a hypothetical emergency insertion, distinguish looking for candidates from previewing a reschedule and committing it. The Crisphive documentation lists those as separate operations. Use that distinction in the experience you build: let the manager inspect the proposed changes, then make the approval point clear before anything is committed. A preview is still a proposal.

Plan for interruption.

A manager may leave the conversation midway through that review. On return, they need to understand what the last response established. If an integration loses contact after submitting a change, a confident sentence isn't evidence that the change succeeded. Give the operator a way to inspect the schedule and escalate an uncertain result before repeating the request.

Client setup also needs an owner. For a Claude integration, consult Claude's documentation for the client-side instructions. Check setup separately. For announcements, use Anthropic's news page. A product announcement doesn't replace the connection settings your deployment uses.

Someone researching MCP OAuth for small business may begin with one approving member. A multi-branch rollout needs an explicit review of the intended access for each workflow. Use MCP OAuth examples with the people who actually own dispatch, including the person expected to investigate a mismatch between the conversation and the job record.

Lessons learned

Test the boundary. Searching for best MCP OAuth doesn't settle whether your chosen role can perform the required scheduling work. To decide how to improve MCP OAuth in a client deployment, turn the access requirement into a test with an expected result. Include a refusal case, so the team can recognize correct enforcement.

Work through these scenarios with development and dispatch together:

• Connect with the intended member role and inspect the available scheduling actions.
• Request an action beyond the intended permissions and record what the operator sees.
• Interrupt a scheduling request, then establish how the team checks its outcome before trying again.
• Refresh the connection and verify that the application stores the new token pair.

These are proposed acceptance tests, not accounts of customer incidents. Keep the test evidence with the integration settings so a future maintainer can distinguish a protection supplied by the server from a confirmation step your agency built into the client experience without having to reconstruct the original design discussion.

For MCP OAuth software, support ownership belongs beside configuration. Who can reauthorize the connection? Who investigates a job that appears unchanged? Useful MCP OAuth tips answer those questions with an owner and a recovery path. For MCP OAuth cost discussions, separate implementation work from ongoing support; an authorization protocol by itself doesn't establish a project price.

Agencies can charge for building the scheduling or dispatch workflow while Crisphive provides the engine underneath. The Crisphive partner program describes the available tracks and recurring commercial arrangements. Choose the track that matches your delivery and support responsibilities. Keep its economics separate from claims about how much time a particular fleet will save.

What's next

For an MCP OAuth 2026 implementation review, choose a sandbox workflow the dispatch team can explain from beginning to end. Connect with the intended role, inspect discovery, and follow one request through the relevant tools. Keep the actual result beside the expected result. If they differ, investigate that difference before widening access.

A shared review record should identify the member role and environment, then describe the point where a proposed scheduling change becomes a committed one. Add the recovery steps the team tested, especially after an interruption or expired connection. Give the person taking the support call enough detail to investigate without finding the original developer.

Bring a dispatch manager into the acceptance test before the agency hands over the integration. Ask them to carry out the workflow and explain what they'll do if the last response is uncertain, watching where they stop or ask the developer for help instead of stepping in as soon as they hesitate. Revise that step, repeat the test, and use the result to decide whether this workflow can move into live operations.