Provides tools for interacting with Stripe's REST API, enabling listing customers and optionally other operations.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Server: SaaS Gateway list stripe customers and postmaid profile"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A small TypeScript template for building one Model Context Protocol server that fronts many REST APIs.
One gateway, N apps. Drop tokens in env vars, expose each API as a slug, ship a single MCP entry to Claude Desktop / Claude Code.
The default pattern in the MCP ecosystem is one server per backend. That works fine when you only need Slack OR GitHub. It gets messy fast when you actually want Claude to orchestrate across several of your own SaaS APIs in a single conversation — every backend becomes another entry in claude_desktop_config.json, with its own token to rotate.
This template flips the model: one gateway server, N apps. Each app is a slug + baseUrl + Bearer token. Tools are named {app_slug}_{action} so Claude understands which API does what.
Born from a real production setup that fronts 4 internal SaaS (PostMaid, Daiv, Botlers, AGSteel) and exposes ~30 tools through one MCP entry — total config footprint in Claude Desktop: 6 lines.
This is not a published npm package — it's a template. Fork it, edit src/index.ts and src/config.ts, ship your own gateway.
Related MCP server: InfraClaude
# 1. Clone the template
git clone https://github.com/grobinson3108/mcp-server-saas-gateway.git my-gateway
cd my-gateway
# 2. Install + build
npm install
npm run build
# 3. Run with your tokens
EXAMPLE_API_TOKEN=your-token npm startWire into Claude Desktop:
{
"mcpServers": {
"my-gateway": {
"command": "node",
"args": ["/absolute/path/to/my-gateway/dist/index.js"],
"env": {
"EXAMPLE_API_TOKEN": "your-token"
}
}
}
}Restart Claude Desktop. Your tools appear under the 🔌 icon.
File | Role |
| Tiny generic HTTP client. Bearer auth, JSON in/out, consistent error format. |
| Config schema + |
| The entry point — also the example. This is the file you edit to register your apps and tools. |
| Real-world example: 4 apps, ~30 tools. |
| Smallest possible setup: one third-party API, two tools. |
// 1. Declare your apps
const config = loadConfigFromEnv('my-gateway', [
{ slug: 'postmaid', name: 'PostMaid', defaultBaseUrl: '...', type: 'internal' },
{ slug: 'stripe', name: 'Stripe', defaultBaseUrl: 'https://api.stripe.com/v1', type: 'external' },
]);
// 2. Build a client per app
const clients = Object.fromEntries(
Object.entries(config.apps).map(([slug, app]) => [slug, new ApiClient(app)])
);
// 3. Register tools, namespaced by slug
server.tool('postmaid_get_profile', 'Get PostMaid editorial profile', {}, async () => {
return wrap(await clients.postmaid.get('/profile'));
});
server.tool('stripe_list_customers', 'List recent Stripe customers',
{ limit: z.number().optional() },
async ({ limit }) => wrap(await clients.stripe.get('/customers', { limit: String(limit ?? 10) }))
);That's it. No registry magic, no codegen, no schema crawling. Each tool is a 3-line lambda that calls one endpoint.
Setup | Best for |
This template | You own / use several REST APIs and want Claude to orchestrate across them. |
One MCP server per API (punkpeye/awesome-mcp-servers) | You only need one backend and want to use someone else's published server. |
Anthropic TS SDK raw | You're building something significantly more complex than HTTP gateway. |
laravel-mcp-server (PHP/Laravel) | Your app is the backend and is built in Laravel. |
No schema introspection / OpenAPI codegen. Adding it would buy you 10 minutes per tool while costing a lot of maintenance complexity. Tools are 3 lines of TypeScript — writing them by hand stays fast and readable.
stdio only. HTTP/SSE transport is on the roadmap if a real use case shows up.
No per-tool authorization. All apps share the gateway's spawn-time env. If you need per-call scopes, do it inside the tool callback (the Bearer token of the app is yours to scope however you want).
Not on npm. This is a starter template — fork-and-edit beats install-and-configure for this kind of code.
examples/multi-saas-gateway/ — A 4-app gateway inspired by a real production setup
examples/stripe-only/ — Minimal Stripe wrapper
MIT — see LICENSE.
Greg Robinson — AI Architect, RAG and agentic systems, Audelalia (🇫🇷 Montpellier).
Companion package for the PHP side: laravel-mcp-server — same idea, but for Laravel apps where the SaaS itself is the backend.
⭐ If this saved you an hour, drop a star.
Fetch a resource from the Example API by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| resource_id | Yes | The resource ID to fetch |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only states 'Fetch', implying a read operation, but omits critical details such as error responses, authentication requirements, or what happens if the resource ID does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It communicates the essence effectively and fits the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is minimally adequate. However, it lacks context about return value format or potential failure modes, which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the input schema already defines the single parameter with a description. The tool description adds no extra meaning beyond the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and resource type 'a resource from the Example API' with the method 'by ID'. Although it does not explicitly distinguish from sibling 'gateway_list_apps', the sibling name implies listing multiple resources, so the purpose is sufficiently clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'gateway_list_apps'. The description provides no context about when to choose this tool over others, leaving the agent to infer from the tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all SaaS apps wired into this gateway, with their type and configuration status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the tool lists apps with type and status, but does not mention pagination, rate limits, authentication, or if the list is complete. Adequate but could be more thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that front-loads the verb and resource, with no extraneous information. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description provides the key output fields (type and configuration status). Missing details on ordering, pagination, or potential errors, but acceptable for a simple list-all tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description need not add meaning beyond the schema. The description correctly focuses on the output shape (type and configuration status).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists all SaaS apps wired into the gateway, including type and configuration status, which distinguishes it from the sibling tool example_get_resource that likely gets a single resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing all apps, but does not explicitly state when to use versus alternatives or when not to use it. A brief note on context would improve.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The two tools have clearly distinct purposes: one fetches a resource by ID, the other lists all apps configured in the gateway. There is no overlap in functionality.
Both tools follow a consistent verb_noun pattern using snake_case (example_get_resource, gateway_list_apps), maintaining predictable naming.
With only 2 tools, the server is at the low end of the borderline range. While not extreme, it feels thin for a SaaS gateway that would typically require more operations.
The tool set is missing essential CRUD operations for resources, app management (create, update, delete), and configuration details. Agents would fail when trying to perform common gateway tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
One MCP endpoint for Claude, GPT & Gemini: 100+ tools + no-code connectors + agent workers.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
Unified MCP Server is a remote MCP connector for AI agents and vertical AI products that provides access to 22,000+ authorized SaaS tools across 400+ integrations and 24 categories directly inside LLMs (Claude, GPT, Gemini, Cohere). Tools operate only on explicitly authorized customer connections, enabling agents to safely read and write against live third-party systems.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/grobinson3108/mcp-server-saas-gateway'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
