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-gateway check authentication status of all systems"
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.
统一认证网关 —— 让 AI 快速接入企业内部系统。
通过一份 YAML 配置文件或运行时动态注册，自动将内部系统的 API 注册为 MCP (Model Context Protocol) Tools，统一处理 SSO / JWT / 用户名密码 / Playwright 交互式认证，AI 客户端（Claude Desktop、Cursor 等）即装即用。
配置驱动：新增系统只需编辑 systems.yaml，无需写代码
无状态模式：不写配置文件也能用，AI 客户端通过 system_register 工具运行时动态注册系统
四种认证：SSO (OAuth2 + PKCE)、JWT (自动刷新)、用户名密码 (Cookie 管理)、Playwright (浏览器交互式登录)
自动重认证：Token 过期自动刷新，401/403 自动重新登录
Playwright 浏览器登录：无 OAuth2 clientId、验证码/2FA/滑块等复杂场景，打开浏览器手动登录后自动复用会话
SSO 浏览器登录：OAuth2 系统自动打开浏览器，登录后回调自动完成
TypeScript：完整类型支持，易于扩展
Related MCP server: Nervora
pnpm install
pnpm build编辑 src/config/systems.yaml，按示例添加你的内部系统：
systems:
- name: my-system
description: 我的内部系统
baseUrl: https://app.example.com
auth:
type: sso # sso | jwt | basic | playwright
sso:
authorizeUrl: https://sso.example.com/oauth2/authorize
tokenUrl: https://sso.example.com/oauth2/token
clientId: your-client-id
scope: user_id
callbackPort: 9527
tools:
- name: get_data
method: GET
path: /api/data
description: 获取数据不创建任何配置文件，直接启动 Gateway，由 AI 客户端通过 MCP 工具动态注册系统：
# 无需 systems.yaml，直接启动
node dist/index.jsAI 客户端连接后，调用 system_register 工具传入系统配置 JSON 即可动态注册，使用完毕后调用 system_remove 注销。
在 Claude Desktop 的 claude_desktop_config.json 或 Cursor 的 MCP 设置中添加：
{
"mcpServers": {
"gateway": {
"command": "node",
"args": ["/path/to/mcp-gateway/dist/index.js"]
}
}
}pnpm devMCP_GATEWAY_CONFIG=/path/to/your/systems.yaml node dist/index.js适用于接入企业 SSO 的系统。首次调用时自动打开浏览器完成登录，Token 自动缓存和刷新。
auth:
type: sso
sso:
authorizeUrl: https://sso.example.com/oauth2/authorize
tokenUrl: https://sso.example.com/oauth2/token
loginPortal: https://sso.example.com/login # 可选：统一登录门户
clientId: your-client-id
scope: user_id
callbackPort: 9527适用于有独立登录 API 的系统。支持自动 Token 刷新。
auth:
type: jwt
jwt:
loginUrl: https://api.example.com/auth/login
refreshUrl: https://api.example.com/auth/refresh
tokenField: access_token
refreshField: refresh_token
expiresIn: 3600适用于传统 Web 系统。自动管理 Cookie/Session。
auth:
type: basic
basic:
loginUrl: https://erp.example.com/api/login
cookieName: SESSION_ID适用于没有 OAuth2 clientId、或登录流程复杂（验证码/2FA/滑块）的系统。首次登录打开浏览器让用户手动操作，登录后自动保存会话并复用。
auth:
type: playwright
playwright:
loginUrl: https://sso.example.com/login # 登录页 URL（必填）
successUrl: dashboard # 登录成功标志（必填）
probeUrl: https://app.example.com/api/profile # 会话探测 URL（可选）
expiresIn: 1800000 # 会话有效期（默认 30 分钟）
channel: chrome # 使用系统 Chrome（可选，避免下载 Chromium）
# script: ./scripts/login.ts # 可选：录制脚本自动登录，失败降级交互式浏览器引擎说明（无需手动安装）：
默认使用 Playwright 内置 Chromium，首次运行时自动下载（约 150MB）
设 channel: chrome 直接使用系统已安装的 Chrome，无需下载
设 channel: msedge 直接使用系统已安装的 Edge，无需下载
设 executablePath 指定浏览器路径（优先级最高）
Tool | 说明 |
| 查看所有系统的认证状态 |
| 登录指定系统（SSO/Playwright 弹浏览器，JWT/Basic 传用户名密码） |
| 登出指定系统或所有系统 |
Tool | 说明 |
| 动态注册系统及 API 工具，传入系统配置 JSON |
| 列出所有已注册系统的名称、类型、工具列表和认证状态 |
| 注销指定系统，移除其所有工具和认证信息 |
src/
├── index.ts # MCP Server 入口 + Tool 注册
├── system-manager.ts # 动态系统注册/注销 + 工具增删管理
├── config/
│ ├── systems.yaml # 系统配置（可选，无状态模式不需要）
│ ├── types.ts # 类型定义
│ └── loader.ts # 配置加载（无配置时返回空列表）
├── auth/
│ ├── types.ts # AuthProvider 接口
│ ├── sso-provider.ts # OAuth2 SSO 认证
│ ├── jwt-provider.ts # JWT 认证 + 自动刷新
│ ├── basic-provider.ts # 用户名密码认证
│ ├── playwright-provider.ts # Playwright 交互式登录
│ └── manager.ts # 统一认证管理
└── proxy/
└── requester.ts # HTTP 请求 + 凭据注入 + 自动重认证MIT
登录指定内部系统（JWT/Basic 需要用户名密码，SSO 会打开浏览器，Playwright 会打开浏览器交互登录）
| Name | Required | Description | Default |
|---|---|---|---|
| system | Yes | 系统名称 | |
| password | No | 密码（JWT/Basic 认证需要） | |
| username | No | 用户名（JWT/Basic 认证需要） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds behavioral context about browser interaction for SSO/Playwright, but does not mention that this is a state-changing action (side effects like session creation) or potential errors. Moderately transparent.
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?
One dense sentence covers key information without redundancy. However, it could be structured more clearly (e.g., bullet points) for easier parsing, but remains concise.
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?
Adequately describes the main behavior and parameter usage context, but lacks details on return values, error conditions, or prerequisites. Given no output schema, more completeness would be beneficial.
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 covers all parameters with descriptions. The description adds value by specifying which parameters are needed for which authentication type (e.g., password only for JWT/Basic). Enhances semantic understanding beyond schema.
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?
Clearly states it logs into an internal system and distinguishes different authentication methods (JWT/Basic, SSO, Playwright). Differentiates from sibling tools like auth_logout and auth_status.
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?
Implies usage context by describing different login flows depending on the system, but does not explicitly state when not to use this tool (e.g., if already logged in). Could be clearer about prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
登出指定系统（或所有系统）
| Name | Required | Description | Default |
|---|---|---|---|
| system | No | 系统名称，不填则登出所有 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks behavioral details such as idempotency, error handling, or side effects. The agent is left unaware of what happens if the system is invalid or if already logged out.
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, concise sentence with no unnecessary words. It is front-loaded with the core action and parameter behavior.
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 optional parameter, the description is mostly complete. However, it lacks information about return values or error conditions, especially since no output schema exists. This leaves some ambiguity for the agent.
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?
The schema covers 100% of parameters with a clear description for 'system' (leave blank to logout all). The tool description echoes this, providing sufficient clarity. Though the description doesn't add new info beyond the schema, it is accurate and helpful.
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 action (logout) and the target resource (specified system or all systems). It effectively distinguishes from sibling tools like auth_login.
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 provides no guidance on when to use this tool versus alternatives (e.g., auth_login, auth_status). It simply states what the tool does without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查看所有已注册系统的认证状态
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states basic function without disclosing behavioral traits such as read-only nature, rate limits, or data refresh behavior.
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, front-loaded with core purpose. Efficient but could benefit from additional context without being verbose.
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 output schema and no annotations, the description is under-specified. Does not cover return format, potential errors, or behavior when no systems are registered.
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?
No parameters, so schema coverage is 100%. Description adds basic meaning beyond empty schema but does not provide extra semantics like output format or behavior.
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 it views authentication status of all registered systems. Differentiates from sibling tools like auth_login/auth_logout and system_list/system_register/system_remove.
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. Context implies it's for checking status but lacks when-not or alternative usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出所有已注册的系统及其工具和认证状态
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states what is listed (systems, tools, auth status) but does not disclose any behavioral aspects like side effects (none expected), performance, pagination, or data freshness. Adequate but minimal.
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?
A single sentence that directly states the tool's functionality with no wasted words. Efficient and front-loaded.
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 list tool with no parameters, the description adequately specifies what is returned (systems, tools, auth status). However, it lacks details on ordering, filtering, or limits. Acceptable but slightly incomplete.
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?
No parameters exist, so schema coverage is 100%. The description adds no parameter info, but baseline for zero parameters is 4. No need to describe non-existent parameters.
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 'list' and the resource 'registered systems' along with their tools and authentication status. It distinguishes from sibling tools like system_register and system_remove which are mutations, and auth_login/logout/status which are authentication-related.
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 when to use (to list systems) but provides no explicit guidance on when not to use or alternatives. With sibling tools for registration and removal, some usage context would improve selectability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
动态注册一个内部系统及其 API 工具。传入完整的系统配置 JSON（与 systems.yaml 格式一致）
| Name | Required | Description | Default |
|---|---|---|---|
| config | Yes | 系统配置 JSON 字符串，格式示例： { "name": "my-api", "description": "我的 API 系统", "baseUrl": "https://api.example.com", "auth": { "type": "basic", "basic": { "loginUrl": "https://api.example.com/login" } }, "tools": [{ "name": "get_user", "method": "GET", "path": "/api/users/{userId}", "description": "获取用户信息", "params": { "userId": { "type": "string", "description": "用户 ID", "required": true } } }] } |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description only mentions registering without discussing side effects, overwrite behavior, or authentication needs, leaving significant gaps for a mutation tool.
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 short and front-loaded, but could be more concise while still providing necessary context.
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 complex registration tool, the description lacks details on return values, validation, and effects on existing systems. No output schema or annotations to compensate.
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% with a detailed example in the schema description; the tool description adds little beyond stating the config is complete, so baseline score applies.
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 tool registers a system and its API tools using a JSON config, distinguishing it from sibling tools like system_list and system_remove.
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 vs alternatives. The context is implied by sibling names but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
注销指定系统，移除其所有工具和认证信息
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | 要注销的系统名称 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavior. It states the main effect (removing tools and auth info) but does not mention if the action is irreversible, requires authorization, or any side effects.
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?
One sentence that is clear and front-loaded, with no unnecessary words.
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 destructive action, the description covers the core effect but lacks details about reversibility, dependencies, or warnings. Adequate but with gaps.
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%, so baseline is 3. The description does not add extra meaning beyond the schema's parameter description.
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 tool's action: deregister a system and remove all its tools and authentication information. It distinguishes from sibling tools like system_list (list) and system_register (register).
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 when you want to remove a system, but does not provide explicit guidance on when to use versus alternatives, nor does it mention prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.1auth_loginauth_logoutauth_statussystem_listsystem_registersystem_removeEach tool has a clearly distinct purpose: authentication (login, logout, status) vs system management (list, register, remove). No overlap.
All tools follow a consistent verb_noun pattern in snake_case (auth_login, system_register, etc.), creating a predictable naming convention.
With 6 tools, the set is well-scoped for a gateway server covering authentication and system registration without being too sparse or bloated.
Covers core CRUD-like operations for authentication and system management. Minor gap: missing an update operation for systems or token refresh.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
Self-hosted MCP gateway: turn any API, database or MCP server into AI connectors — no code.
The OpenRouter for tools. One MCP connection gives any AI agent 254 hosted tools, pay per call.
Zero-secret MCP gateway for AI agents: risk-scored, audited calls with human-in-the-loop approval.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/cancyChen/mcp-gateway'
If you have feedback or need assistance with the MCP directory API, please join our Discord server