A B2B SaaS product does not need to turn every API endpoint into an AI tool. The useful MCP server exposes a small set of customer jobs, preserves the product's existing permission model, and behaves predictably in the clients customers use. Here is a practical way to get there.
Start with customer requests, not endpoints
Collect a handful of requests customers want to make in an AI assistant: “Find the overdue invoices for this account,” “Summarize open support tickets,” or “Create a draft follow-up.” For each request, map the data needed, the action allowed, and the expected output. This gives you a tool design brief before you write protocol code.
Keep read and write tools distinct. A read tool can return a concise record. A write tool should describe its effect precisely and accept identifiers and values that the server validates. Avoid a generic execute_action tool that hides authorization and makes results hard to audit.
Use existing product services
Place the MCP server at the edge of your application. It can translate a tool call into your established service or API call, then return a clear result. Keep business rules, tenant lookup, and permissions in the same systems that protect the web app. This prevents a second implementation of customer access rules.
For example, a get_invoice tool might take invoice_id. The server identifies the caller, resolves that caller's organization, checks access to the invoice, and only then calls the billing service. Never trust a tenant_id supplied by the model as the authority for access.
Design a small, understandable tool set
- Give each tool a verb and object that match the customer's task.
- Explain when to use it, what it returns, and what it cannot do.
- Use structured inputs with required fields and meaningful constraints.
- Return stable identifiers and human-readable errors.
- Separate high-risk operations from ordinary reads; consider leaving them out of the first release.
The OpenAI MCP server guide also recommends building tools around recognizable user goals and exposing only the data and actions they require. There is no reliable universal maximum tool count; test whether your particular catalog produces correct selection in your target clients.
Make authorization a server responsibility
Decide whether the entire server or only selected tools require authentication. Publish the discovery metadata needed for the flow you choose, and verify each protected call. Check token validity, audience, scopes, tenant, and resource access. The OpenAI authentication guide emphasizes that server-side verification remains necessary even when tool metadata tells the client a tool requires authorization.
Test with two customers and at least two roles. A useful negative test asks one tenant's token to access another tenant's object. Another tries a write with a read-only role. These should fail in the server, even if the AI client sends a perfectly formed tool call.
Ship and test incrementally
- Implement one read workflow against local or test data.
- Use the MCP Inspector to check discovery, schemas, calls, and error handling.
- Connect a preview URL to the AI clients your customers use. Ask realistic questions and capture which tools they choose.
- Add authentication and cross-tenant tests before customer access.
- Add a narrowly scoped write flow only after the read path works reliably.
Manufact's mcp-use SDK supports building MCP servers, and Manufact Cloud supports deployment. A local public address from mcp-use Tunnel can help during client testing. The outcome to optimize is a customer completing a real task safely, not the number of endpoints you exposed.
