Learn how to build a Remote MCP Server for your SaaS product. We share our experience with MCP vs Agent Skills, OAuth integration, and MCP tools design.
SaaS products have a long-standing problem: time-to-value is too slow. A lot of users churn before they reach the “aha” moment.
We’ve iterated on Logto onboarding a bunch of times. It helped, but the bottleneck didn’t go away. You still end up reading docs, skimming tutorials, installing SDKs, wiring configs, writing code, then debugging the last 10% before anything works.
So we tried a different approach: a remote MCP server as Logto’s IDE-native control plane. Instead of clicking through an admin console, you configure Logto and generate integration code through a conversation, right where you’re building the app.
One prompt can take you from zero to a working integration. The agent doesn’t just generate code, it also creates and configures the Logto application in your tenant. All from inside your IDE. (Try Logto MCP Server)
In this article, I will share our experience and thinking around building the Logto MCP Server, including:
Before deciding how AI should access Logto, we evaluated two options: MCP servers and Agent Skills.
MCP servers have two forms: local and remote.
A local MCP server runs on the user’s machine. It requires service installation, environment setup, credentials, or special login flows. In usage and delivery, it is very similar to skills.
A remote MCP server is hosted on the server side. Users connect by URL and authorize with OAuth. This model is closer to SaaS service extension.
From a structure view, an Agent Skill is a combination of "business logic + underlying capabilities". Those capabilities can be tools, CLIs, or API calls. MCP tools can carry this layer in a unified way.
So the key question is not how capabilities are implemented, but how they are delivered to users.
Agent Skills deliver: a full local toolchain (Skill package + local runtime + API keys or platform credentials + CLI tools + install, config, upgrade, and maintenance flow).
In essence, you give the capability to users to run by themselves.
Remote MCP servers deliver: a remote service entry (URL + OAuth login).
In essence, you provide the capability as a service.
Below, we compare them from user experience, ecosystem reach, and delivery and maintenance cost.
Agent Skills usually depend on platform APIs or CLIs. Users must create API keys or install and log in to CLIs first. These steps are not complex, but they raise the entry barrier.
MCP servers support OAuth. Users log in with their SaaS account. The experience is like “Sign in with Google.”
For users, using an MCP server is simple: enter a URL, log in, connect. This is the experience we want to deliver.
On the MCP website, there are already 104 AI apps that support MCP, including tools like VS Code, Cursor, and Windsurf.
Agent Skills are still platform-specific. Even if many platforms start to support them, when we ship an MCP server, users can use it immediately. When we ship a Skill, only users on that platform can use it.
MCP is also included by the Agentic AI Foundation (AAIF). It is a protocol-level standard. The ecosystem will keep growing. For us, this makes MCP worth long-term investment.
Agent Skills depend on platform APIs or CLIs, which quickly brings problems:
You also need to distribute CLIs, manage scattered credentials, adapt to multiple platforms, and guide users to upgrade. The ROI is very low.
MCP servers are much simpler. Users connect to a URL. It always points to the latest version. When we update the MCP server, users get it next time they connect. No upgrades needed. If APIs change, we update them inside the MCP server.
Most SaaS products already have strong infrastructure: solid APIs and mature auth systems. An MCP server fits naturally as the “AI interface” of the API, just like an admin console is another interface on top of the same APIs.
For Logto, choosing an MCP server fits our architecture and uses our strengths.
It also centralizes all requests into one entry point. Logs and audits are easier. Permissions are clear: AI can only do what the user authorizes. This model is structurally cleaner for enterprise and compliance scenarios.
MCP is not perfect. Most issues are ecosystem maturity problems. They will improve over time. Before that, we use workarounds to meet real needs.
The MCP spec defines many features, but client support varies:
mcp-remote as a bridgeRight now, tools are the most reliable common layer (check out the MCP Community Page to see what features each client supports).
So our strategy is simple: build on tools.
This is a business-layer problem.
With Agent Skills, business logic and context are packaged together. The LLM knows how to use them. MCP only provides tools. After connection, the LLM does not know:
MCP has the concept of Instructions, but not all clients support it. Instructions also push all content into context at connection time, which wastes tokens.
Another idea is to put guidance into tool descriptions. But this causes two problems:
Our workaround: provide a getInstructions tool
The idea is simple: if Instructions are not well supported, turn them into tools.
The LLM can call getInstructions on demand.
For task A, it calls getTaskAInstructions. The MCP server returns a prompt that explains how to complete task A and how to combine other tools.
Complex business logic stays behind the instruction tools. Other tools stay simple. Tool descriptions focus only on their own function.
This is similar to Agent Skills: prompts are loaded on demand. It is also more efficient than global Instructions because it avoids dumping everything into context.
For many SaaS products, some secrets must never be exposed (for example, client secrets, API keys, or webhook signing keys). If they leak, others can impersonate you or gain direct access to resources.
The risk with LLMs is that a chat is not a secure channel. Conversations can be logged, copied, forwarded, or end up in debugging logs. You cannot assume “only me and the model can see this.” So handing a long-lived secret to an LLM, or asking it to output a secret for users to copy, is high risk.
This is common in traditional web app integrations: developers often need a secret, put it into server environment variables or config files, and then finish steps like initializing SDKs.
To keep onboarding easy without weakening secret safety, we do three things:
Use temporary secrets during integration
During the chat-based setup, the MCP server only returns short-lived temporary secrets (for example, valid for 1 hour). They are enough to get the integration working, and they often expire before you go live. Before going live, developers create and replace them with long-lived production secrets outside the chat.
Make the security boundary explicit
We clearly warn users: do not create, paste, or store production secrets in the chat. We also remind developers that even environment variables or config files can leak if an agent / LLM can read them through tools or indirect access. Put production secrets only in environments where no AI-assisted integration is used.
Do not handle production secrets in chat; guide users to the console
Long-lived secrets are not generated or distributed through the chat. They are created and managed in the console credentials page. In the chat, we only provide a direct link to the console so users can complete production secret setup there.
Logto has a full Management API. Our first idea was simple: expose every API endpoint as an MCP tool.
This failed quickly.
First, context explosion. Logto has many APIs. Mapping them one-to-one fills the context window. Each tool description costs tokens.
Second, loss of meaning. APIs are atomic building blocks for developers. But users of the Logto MCP Server are not building systems. They just want to finish tasks. They do not care how many APIs exist.
Example: Logto has a sign-in-experience API for branding, sign-in methods, sign-up methods, and security policies.
At first, we thought about how to expose all parameters to the LLM. How to teach it to combine calls.
But this is the wrong mindset. Users are not calling APIs. They want to change branding or configure login methods.
So tools should be updateBranding, updateSignInMethod, updateSignUpMethod. The MCP server handles API composition internally.
Logto MCP Server should be treated as a product, not an API wrapper. It is "another admin console".
The rule becomes clear:
read_file, write_file, then coding agents combine them.Additional principles:
getInstructions tools to load guidance on demand. Keep their descriptions simple too.While building the MCP server, we also thought about what could improve the ecosystem.
Sometimes MCP servers need to provide not just tools, but guidance on how to combine them into tasks, like Agent Skills.
This is common in SaaS. For example, GitHub MCP Server, Logto MCP Server, or analytics platforms. Users want workflows, not atomic calls.
getInstructions tool is a workaround. Protocol-level support would be better.
Clients connect to many MCP servers, but not every session needs all of them. Session-level enable/disable could reduce context waste.
Tool calls consume a lot of context. If MCP interactions are handled by sub-agents, the main conversation could receive only condensed results.
This is our experience with building a remote MCP server.
If you are exploring this direction, try the Logto MCP Server or join our Discord to exchange real-world implementation experience with the community.
We will also share architecture design and OAuth flow details in future posts.