Open
Description
🧭 Epic
Title: Test Server Connectivity from Gateway UI
Goal: Help administrators debug server setup issues by interactively sending custom HTTP requests to configured MCP servers
Why now: When adding a new MCP server, it's often unclear if a given URL or endpoint is live, secure, or responding as expected. Today, users must use curl/Postman to debug. This feature allows testing any method, path, headers, or body directly from the Gateway UI.
🧭 Type of Feature
- New functionality
🙋♂️ User Story 1
As a: Gateway administrator
I want: to send custom HTTP requests (GET, POST, etc.) to any path on the server I'm configuring
So that: I can debug connectivity, validate endpoint behavior, and inspect the actual server responses before saving
✅ Acceptance Criteria
Scenario: Send a custom request to the server before saving
Given I am adding a new server in the Gateway UI
And I enter a server base URL
When I click "Test Server"
Then I should be able to:
- Choose an HTTP method (GET, POST, PUT, DELETE, etc.)
- Enter a relative path (e.g., /health)
- Provide optional headers and request body
When I click "Send"
Then the system sends the request to base_url + path
And I should see:
- HTTP status code
- Total response time (latency)
- Response body (pretty-printed JSON if possible)📐 Design Sketch (optional)
+-------------------- Gateway UI ---------------------+
| Server URL: https://api.example.com |
| |
| [ Test Server ] ← opens test panel |
+----------------------------------------------------+
⇣ click
+-------------------- Test Server --------------------+
| Method: [GET ▼] |
| Path: /version |
| Headers (JSON): { "Authorization": "Bearer xyz" } |
| Body (JSON): { "foo": "bar" } (for POST, PUT...) |
| [ Send ] |
| |
| ⇣ Results |
| ➤ Status: 200 OK |
| ➤ Latency: 120 ms |
| ➤ Response: |
| { |
| "version": "1.0.0", |
| "status": "healthy" |
| } |
+-----------------------------------------------------+
🔗 MCP Standards Check
- No impact on protocol or server discovery logic
- Safe, diagnostic-only feature
- Follows existing conventions for JSON and HTTP tooling
🔄 Alternatives Considered
| Option | Pros | Cons |
|---|---|---|
| Predefined test list (/health, /version) | Simpler UI | Not flexible, less useful for real-world debugging |
| Silent background ping | No UI work | Less control, can miss issues with specific headers/methods |
| CLI-only debug tools | No frontend work | Fragments experience, not user-friendly |
📓 Additional Context
- This is especially useful when:
- Testing authenticated or proxied servers
- Verifying custom response structures
- Diagnosing CORS or TLS errors from browser context
- Future enhancements could include:
- Copy-as-curl button
- History of past test requests
- Auto-fill common headers like
Content-Type: application/json