Start with a customer task your API can complete reliably, then expose the smallest set of MCP tools needed to complete it. Choose actions with clear inputs, a result the assistant can explain, and permissions you can enforce. Add higher-consequence actions only after you have defined confirmation, retry, and recovery behaviour.

For a first release, we recommend choosing one complete workflow rather than trying to cover your entire API. An appointment service, for example, could start with finding available times and retrieving appointment details. Booking and cancellation can follow once the team has designed the controls they need.

This guide gives you a practical way to make that selection. The appointment service is an illustrative example, not a customer case study.

What is the difference between an API endpoint and an MCP tool?

An API endpoint is an operation exposed by your service. An MCP tool describes a capability an assistant can discover and invoke. A tool has a name and an input schema, and can include a description and an output schema. See the MCP tools specification.

The mapping is a design decision. A tool might call one endpoint, combine several calls, or expose only a carefully limited part of an existing operation. If your API already has a well-defined appointment search endpoint, wrapping it directly may be appropriate. If finding a bookable time requires separate location, practitioner, and availability lookups, you need to decide where that coordination belongs.

For background on how these interfaces fit together, read our overview of MCP servers, apps, and connectors.

1. Write down what the customer would actually ask

Begin with requests from support conversations, product research, or your own documented workflows. Keep each request concrete enough to evaluate:

These requests reveal different dependencies. Searching needs a location, a date range, and a time zone. Retrieving an existing appointment needs the customer's identity. Moving one needs availability, access to the original booking, and a policy for what happens if the new slot disappears.

Do not start by counting routes in an OpenAPI file. Start by describing what a successful answer or completed action looks like for the customer.

2. Separate looking up information from changing it

For each candidate, write down its effect. Does it retrieve information, create a record, change a commitment, or remove something?

Our suggested first-release shortlist for the appointment example is:

A read operation can still expose sensitive information. “Does not modify data” and “safe for anyone to call” are separate questions. Test both the action's effect and the caller's access.

3. Give every tool a clear boundary

A useful tool description says when to use the tool, what it needs, and what it does not do.

For example, an illustrative description for search_available_appointments could be:

Find bookable appointment slots at one clinic within a date range. Returns slot identifiers and start times with time zones. Does not reserve or book a slot.

That last sentence prevents a common product misunderstanding: seeing an available slot does not mean it is being held. The assistant needs to explain that distinction, and the booking operation must check availability again.

Avoid vague names such as process_request. Also avoid a single tool with dozens of unrelated operating modes. If you cannot explain its boundary in a short paragraph, revisit the workflow before expanding the schema.

4. Define the result before wiring up the API

Write down the information the assistant needs after a successful call. For appointment search, our example would return a slot ID, start time, time zone, location, and appointment type. For booking, it would return a booking reference and an explicit status.

Then describe the main unsuccessful outcomes. “No appointments match” is a valid search result. “The service is unavailable” means the search could not be completed. “That slot was just taken” means the booking did not succeed. The assistant should be able to tell these situations apart.

MCP supports structured tool results and optional output schemas. When an output schema is provided, the server must return structured results that conform to it. Behaviour annotations are descriptive metadata; clients must treat them as untrusted unless they come from a trusted server. See the tool result and schema requirements.

For your implementation, use those structures to express meaningful outcomes. A technically valid response that leaves the booking state ambiguous is still a poor customer experience.

5. Decide where permission and confirmation are enforced

Write a permission rule for each tool. Which account does it operate on? Which records may that account access? What additional authority is needed to change them?

For protected remote MCP services, the MCP authorization specification describes an HTTP authorization flow based on OAuth. That connection-level authorization does not replace your application's checks on individual appointments or customer records.

In our appointment example, the server should check ownership on every retrieval and cancellation. A supplied appointment ID is not proof of access. For a booking, define what the customer is approving: the appointment type, location, time, and any applicable conditions. Enforce the required state transition in your service, and test the intended assistant client's confirmation experience.

Treat retries as part of this design. If a booking succeeds but the response is lost, repeating the request should not create a second appointment. Use a documented duplicate-prevention mechanism, and give the assistant a way to check the outcome before trying again.

6. Test the workflow through realistic requests

Before adding more tools, evaluate the first workflow with the assistant clients you intend to support. Our suggested evaluation set includes:

  1. A complete request with a clear location and date.
  2. A request missing a required detail, where clarification is necessary.
  3. A search that returns no matching results.
  4. A request for another customer's appointment.
  5. A booking attempt after availability has changed.
  6. A repeated request after a simulated response timeout.

Record whether the assistant chose the appropriate tool, supplied valid inputs, respected access boundaries, and described the actual result. Keep the test requests so you can repeat them when tool descriptions or API behaviour change.

How many MCP tools should you launch with?

There is no universal tool count that makes an integration useful. Our recommendation is to launch the smallest set that completes one valuable workflow, with enough supporting lookups to avoid guesswork.

If a proposed tool adds an entirely new permission model or an unresolved failure case, leave it out of the first release. If an additional lookup lets the assistant resolve a location correctly, it may belong in the initial set even though it increases the count.

The release decision should be based on demonstrated usefulness and predictable behaviour. A customer who asks an assistant for an outcome needs the workflow to finish correctly.

Your first selection checklist

Before you approve a candidate tool, be able to answer these questions:

Use the answers as the brief for your first MCP integration. If you want a starting assessment of your existing documentation, the free Agent Readiness Audit proposes tools, provides a readiness score, and gives a fixed setup price. You can then refine that proposed scope around the customer workflow you want to support first.