Connect services and publish tools
- Add a Streamable HTTP service under MCP backends, or organize REST API / OpenAPI tools under HTTP tool groups.
- Configure the connection and upstream credentials; check probe or import results. An enabled HTTP group does not itself prove upstream connectivity.
- Explicitly publish reviewed tools using original backend names in
published_tools. Newly discovered tools stay unpublished. Manage HTTP publication through the tool/import editors. - In Tool permissions, set
read/write, required scopes and business-resource limits. All required scopes must be present. Argument restrictions complement the backend's own authorization. - Validate with one authorized user and a read tool before configuring writes or broader access.
Upstream headers/OAuth authenticate Hub to the business service; client scopes authorize users at Hub. Configure them separately. Updates use revision checks: after 409 revision_conflict, reread and reconcile instead of overwriting another administrator's changes. With configuration approval enabled, a successful submission may still await approval before application.
See backend fields, HTTP tool groups, publication and resources, and rate limits.
The overview’s Verify your first integration checks the selected service, tool and user: service availability → published read-only tool → group access → client authorization → actual execution. The final step reads successful tools/call requests for that user and tool in the last 24 hours; catalog reads and simulations do not count. Check selected user access lets you enter resource arguments and inspect current policies without executing a business tool. Have the user pair their Agent and complete a read-only call, then select Check again. Verify HTTP group connectivity with actual calls; past success does not prove current credentials are valid.
Console navigation
Services unifies MCP and HTTP connections with connection/accounts, capabilities, access and runtime/diagnostics entry points. Existing protocol editors retain their behavior. HTTP uses shared headers/OAuth; personal Vault accounts remain limited to MCP. Services have stable endpoint UIDs. IDs cannot change; delete/recreate assigns a new UID.
Save and review changes and Review import changes create encrypted drafts; the configuration is not yet active. Validate draft checks the current revision and candidate runtime, then shows a redacted diff, credential-change marker and estimated affected groups, users, sessions and grants. Estimates do not mean every session will be revoked. Validation never calls tools. Application revalidates and cannot overwrite concurrent updates. Operations groups status into runtime/configuration, identity/audit and backup/recovery. The change list shows draft, validated, awaiting approval, applied, failed and discarded states. Expand deployment and backup commands when needed.
Rollback uses a historical before snapshot to create a new draft, validates the current revision and increments it. It does not roll back sessions, revocations or approval outcomes. Create records have no previous configuration; deletion remains direct. Up to 200 records are retained; completed records can be removed, preferably after a backup.
Existing creation/update APIs accept X-MCPHub-Change-Mode: draft, returning a 201 draft without applying. GET /api/v1/configuration-changes lists records. POST /api/v1/configuration-changes/{id}/validate|apply|discard|rollback requires draft If-Match; DELETE removes completed records only. Ordinary writes retain immediate-apply/security-approval contracts. GET /api/v1/services provides the unified inventory. GET /api/v1/operations returns versions, sources, enterprise verification, backup/drill results, request-record failures and external audit delivery.
YAML/environment owns deployment listeners, public URLs, storage and authentication defaults; the database owns managed configuration. YAML backends are imported once into an empty database. Runtime remains one instance. Deployment parameters and encryption keys remain operator-managed.
The console groups daily operations into four areas. Navigation shows only pages available to the current role; reviewers without configuration access land directly in the approval center.
| Area | Page | What to do |
|---|---|---|
| Workspace | Overview | Inspect real backend connectivity, group/HTTP-tool totals and recent changes. Unavailable backends appear first, with direct access to configuration. |
| Connections | MCP backends | Connect Streamable HTTP MCP servers; search, filter, probe, enable/disable and configure publication, upstream credentials and rate limits. |
| Connections | HTTP tool groups | Turn REST APIs into tools, manually or through OpenAPI, with shared connections, credentials and access policies. |
| Access control | Tool permissions | Inspect publication, read/write classification, effective scopes, business resource rules and approvals; edit policies or run a side-effect-free access check. |
| Access control | Users & groups | Create users and groups, manage account state and membership, and assign roles, scopes, tools and resources to groups. Enterprise memberships from the identity source are read-only. |
| Access control | Identity services | Configure and test LDAP and OIDC together, replace encrypted credentials and enable/disable enterprise login; retain the local administrator. |
| Access control | Client authorization | Filter grants by user, client, endpoint and status; inspect full scope, navigate to related requests or revoke a grant. |
| Governance & audit | Approval center | Review permitted write operations and configuration changes, including previews, approval progress, execution outcomes and audit history. Request IDs, issuer and client binding IDs are expandable under Technical details; the applicant, target and complete request remain available for review. |
| Governance & audit | Request diagnostics | Inspect recent outcomes, denial reasons and latency; expand request details and navigate directly to the relevant tool policy. |
| Governance & audit | Activity | Review the latest 50 management changes and their actors, without exposing credentials. |
Recommended workflow: connect services → publish and classify tools → configure group access and memberships → client sign-in and consent → approvals and diagnostics. Users connect through mcpbridge setup / connect and confirm their own grants in the personal authorization portal; administrators maintain policy in this console. Default built-in deployments configure LDAP and OIDC in the Identity services UI. Listener, database and audit-delivery settings remain in YAML/environment configuration.
Both editors follow connection → upstream credentials → client access. New MCP backends default to No authentication; explicitly choose Header, OAuth or Vault when the service requires credentials. Upstream credentials authorize MCPHub to call the service. Empty required scopes add no scope restriction: built-in and enterprise users still need group access, and tools must be published. A nonempty list requires every listed scope.
After testing the MCP connection, select approved tools in Published tools. Existing backend editors load the current catalog; unavailable discovery does not remove saved names. Advanced input accepts original tool names, and discovery never publishes new tools automatically. New and required backends need another test after their connection URL, authentication or timeout changes; publication changes alone do not invalidate the test. Lists show published and discovered counts separately. Edit individual rules in Tool permissions, or use advanced JSON; unclassified tools still require approval. An HTTP tool group's Test saved connection checks persisted configuration; save connection edits first.
Users & groups filters users, permission groups and organization groups/departments separately. Creating a permission group opens its editor so you can continue configuring access and organization mappings. In the group editor, choose the service and select its published tools and resource conditions; derived mode saves required scopes as a snapshot, while advanced explicit mode requires complete scopes, then assign group memberships. Changing a service clears the tools in that access entry so identical names do not carry over to another service. Advanced manual tool-name input remains available. Leave an existing secret blank to retain it; removing its Header row removes that credential.
For OpenAPI, choose a URL or upload a specification, parse it, then select the interfaces to import. Changing the source clears its previous preview and selection; parse the new source before importing. Imported tools are limited to the selected interfaces.
Several endpoints may share the same required scopes. Without the SSO bridge, the external issuer grants those scopes. With auth.sso, Users & groups grants permissions only to groups/departments; users inherit their groups. Locally managed memberships are edited in the console; verified login claims or directory snapshots own enterprise memberships. HTTP tool groups share settings within a REST API; they do not group multiple MCP backends. Publication, scopes, business resources, client grants and write approvals jointly constrain calls.
Use the language control to switch between Chinese and English. Narrow screens use a navigation drawer with keyboard and Escape support. Refresh reloads current configuration and shows the last successful update time; failures keep a visible error and retry action. Overview values come from actual configuration and connection state. Request history follows database retention; it is not full monitoring or a tamper-evident audit archive.
Closing an editor, refreshing configuration, navigating or filtering Users & groups prompts before discarding unsaved changes. Cancel keeps the draft available. Language changes preserve open editor drafts; Users & groups prompts before rebuilding its forms. Browser close or reload also uses its native warning. Forms lock while saving so a response cannot overwrite later input. Changes are not saved automatically, and credential drafts are never written to browser storage.