Remote MCP server in action: a new entry point for SaaS products in the AI era

This article is created by Logto, an open-source solution that helps developers implement secure auth in minutes instead of months.

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:

• MCP vs. Agent Skills: why we chose MCP
• Problems we met when shipping an MCP server, and how we solved them
• How we design MCP tools, and how you should design yours
• Our expectations for the future of MCP

The OAuth implementation of the Logto MCP Server is based on mcp-auth and Logto. If you are interested in MCP server OAuth, you can refer to this open source project.

MCP vs. Agent Skills: why we chose MCP

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.

User experience

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.

Ecosystem reach

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.

Delivery and maintenance cost

Agent Skills depend on platform APIs or CLIs, which quickly brings problems:

• What if the API changes?
• What if the CLI breaks compatibility?
• How do you upgrade and redistribute the Skill?

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.

Problems we met when shipping an MCP server, and how we solved them

MCP is not perfect. Most issues are ecosystem maturity problems. They will improve over time. Before that, we use workarounds to meet real needs.

Fragmented MCP feature support

The MCP spec defines many features, but client support varies:

• Tools: widely supported
• OAuth: well supported in VS Code; tools like Cursor need mcp-remote as a bridge
• Other features (Resources, Prompts, Instructions): inconsistent support

Right 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.

LLM does not know how to use your 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:

• The usage scenarios
• The call order
• The business constraints

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:

• Descriptions become complex. Multi-tool workflows create tangled logic and are hard to maintain.
• As tool count grows, descriptions consume large parts of the context window.

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.

LLM may leak your secrets

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.

How we design MCP tools

Our path

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".

How to design MCP tools

The rule becomes clear:

• If users directly use your service (like a console), tools should be business-oriented.
• If you provide base capabilities for others to build on, tools should stay atomic and simple. Example: a filesystem MCP server with read_file, write_file, then coding agents combine them.

Additional principles:

• Keep tool logic and descriptions simple to save context.
• For complex workflows, use getInstructions tools to load guidance on demand. Keep their descriptions simple too.

Our expectations for the future of MCP

While building the MCP server, we also thought about what could improve the ecosystem.

Skill-level capability delivery

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.

Session-level MCP enablement

Clients connect to many MCP servers, but not every session needs all of them. Session-level enable/disable could reduce context waste.

Context isolation for MCP tool calls

Tool calls consume a lot of context. If MCP interactions are handled by sub-agents, the main conversation could receive only condensed results.

Conclusion

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.