Skip to content
MCP Server Development / Moon Sherpa LabsMOON SHERPA / LABS

Your tools.
Ready for AI.

An assistant becomes useful when it can reach the right information and perform a well-defined action. Our MCP server development services design the interface between your business systems and the AI clients your team wants to use.

  • Model Context Protocol
  • Existing APIs
  • Scoped permissions

MCP development / A boundary with a contract

Useful access starts with clear limits.

An MCP server exposes defined capabilities. The application still needs identity, permissions, validation, and a deliberate policy for changes.

SUBJECT STUDY / 06
Return the context a task can use.A resource can expose content to an authorized client. Choose the scope carefully and keep sensitive information inside the intended boundary. Input: An authorized context request. Result: A scoped resource response. An illustrative application policy around MCP. Nothing here connects to a real account or executes an external operation.Return the context a task can use.A resource can expose content to an authorized client. Choose the scope carefully and keep sensitive information inside the intended boundary. Input: An authorized context request. Result: A scoped resource response. An illustrative application policy around MCP. Nothing here connects to a real account or executes an external operation.

An illustrative application policy around MCP. Nothing here connects to a real account or executes an external operation.

Choose a capability

THE DECISION IN VIEW

Return the context a task can use.

A resource can expose content to an authorized client. Choose the scope carefully and keep sensitive information inside the intended boundary.

Start with
An authorized context request
Make possible
A scoped resource response

The host decides how returned context becomes part of the user’s work.

The opportunity

Make the right action easy to choose.

An MCP server gives a compatible AI client a structured interface to tools and information. It can sit in front of APIs you already have, with the connection logic and permissions handled on the server.

The quality of that interface matters. A tool must be understandable to the model, useful to the person asking, and narrow enough that its behavior can be verified. We treat names, descriptions, inputs, and results as product design.

What we can build

Build a useful tool surface.

Find the right record

Search contacts, documents, and internal data with filters that match the way people ask for information. Return identifiers and source context for the next step.

Prepare or perform an action

Create a task, update an allowed field, or prepare a document through a defined operation. Separate actions with different permission or review requirements.

Connect to existing systems

Reuse supported APIs and business logic rather than rebuilding the source system. Handle authentication, pagination, and rate limits within the connection.

Make failures understandable

Return enough information to distinguish a missing record, a permission issue, invalid input, and an unavailable source. The client should know how to proceed.

The decision, made clearer

A tool is more than an endpoint.

Part of the contractWhat it should answerExample
PurposeWhen should the assistant use this?Create a follow-up task for an existing contact
InputWhat must be known first?Contact identifier, task description, due date
PermissionWho may perform the operation?A connected user with access to that contact
ResultWhat actually happened?The task reference, or a specific reason it was not created

A good starting point

You have useful business operations or data and want to make them available through compatible AI clients without duplicating the integration for every workflow.

A boundary worth discussing

MCP does not create permissions, source data, or missing APIs. If the underlying operation is unreliable or unsupported, that needs to be resolved as part of the scope.

Working together

From tool inventory to a verified connection.

  1. Inventory the useful actions

    Start with representative user requests and the operations they require. Keep the first surface focused.

  2. Design the contracts

    Write the descriptions, schemas, permissions, and result shapes together. Separate reads from consequential writes.

  3. Build the connection

    Implement the transport, authentication, source-system calls, validation, and operational visibility.

  4. Test in the intended clients

    Verify discovery, tool selection, denied requests, successful actions, and failures in the clients the team will actually use.

In practice

Your CRM, inside the assistant.

Follow Up Ace connects Follow Up Boss workflows to Claude, ChatGPT, and other compatible clients. Its case study shows how MCP fits into a broader product rather than becoming a separate destination.

AI Platform · CRM Intelligence

Follow Up Ace

An AI layer for Follow Up Boss that ranks the day and prepares personal follow-up drafts, with a shared assistant across the CRM, Claude, ChatGPT, and an iPhone companion.

Inside the build

Explore the working pattern

Watch a connected tool workflow.

Explore the work around a tool connection: gather context, prepare an output, and review the next step. An MCP server supplies authorized capabilities; the surrounding application controls this illustrative sequence.

Workflow laboratory / 04

The work, in motion.

Illustrative workflow
No live customer data

Ready when you areSYS / 00
Contact historyAgent notesMessage preferencesHUMAN FEEDBACKSignal01Context02Prepare03Review04Handoff05CONTEXT → CAPABILITY → CONTROLEvery handoff has a human boundary.
Inside the workflow01 / 05

A useful starting point

A conversation worth continuing

Signal

A fictional buyer asked about a garden and a quieter street. Their agent opens the follow-up queue.

Run the scenario to follow the whole path, or take it one step at a time.

See the real work: Follow Up Ace

Try disconnecting the source to see how missing information changes the path.

Before we begin

The useful questions.

What is MCP server development?

It is the design and implementation of a server that exposes tools or information through the Model Context Protocol. For a business system, that includes the operations, schemas, access checks, source connections, and deployment needed to make the interface useful.

Is MCP a replacement for our API?

Usually it is an additional interface over an existing API or service. The source system still owns its records and business rules. The MCP layer makes selected operations discoverable and callable by compatible clients.

Will the same server work with Claude and ChatGPT?

It can, when each client supports the server’s transport and authorization setup. We verify the intended client and account configurations during delivery instead of assuming every client exposes identical capabilities.

Can the server update records?

Yes, when the underlying system supports the operation and the authenticated user has permission. We scope write tools carefully and define any review or confirmation step as part of the workflow.

How many tools should we start with?

Enough to complete one useful workflow. A smaller surface with precise descriptions and reliable results is easier to evaluate than a large collection of loosely related operations.

Where does the server run?

A local server can run with a client on a user’s machine; a remote server can serve authorized users over the network. Hosting depends on the intended clients, authentication, source systems, and operational requirements.

How do you price an MCP project?

We scope the source systems, actions, permissions, intended clients, and deployment work. Tool count alone does not capture the effort: a simple lookup and a cross-system write have very different requirements.

Do you work as an MCP development agency, or do we need an in-house developer?

We work as the agency: you bring the business systems and the workflows people want an assistant to handle, and we design, build, and deploy the MCP server that connects them. Follow Up Ace is a shipped example of that arrangement — a product built around an MCP connection to Follow Up Boss, not an internal tool maintained by the client's own developer.

Is there an MCP server for Follow Up Boss?

Yes. Follow Up Ace, built by Moon Sherpa Labs, is a production MCP server exposing 242 Follow Up Boss CRM tool definitions to Claude and ChatGPT—contact lookups, stage updates, lead scoring, and follow-up sequencing—so an AI agent can manage a real estate pipeline through natural-language requests instead of the FUB UI. It's a real-world example of the tool-surface pattern described on this page, built and run in production, not a demo.

Can I build my own MCP server?

Yes. MCP is an open, publicly documented protocol with official SDKs, so any engineering team can build a basic server—a minimal server with a handful of tools can be working in a day or two. What takes longer, and is where most in-house attempts stall, is production hardening: authentication, rate limiting, structured error handling, multi-tenant isolation, and tool descriptions precise enough for a model to call reliably. That production layer is what Moon Sherpa Labs specializes in building.

How long does MCP server development take?

A focused MCP server—10 to 20 well-defined tools wrapping a single system—typically takes three to six weeks from scoping to production. Larger surfaces (50+ tools, multi-system integrations, complex authentication flows) take longer. We start every engagement with a tool-surface scoping session before committing to a timeline.

Let’s make it concrete

What should your assistant be able to do?

Bring a few real requests and the systems behind them. We’ll turn them into a practical tool inventory.

Scope an MCP connection