GICT knowledge base
InterServer MCP Server: Endpoints, Access, and Connection Checks
Published
The InterServer MCP server is an interface for connecting compatible AI clients to hosting tools. This guide distinguishes the public discovery service from customer-account access, explains credential handling, and shows how to diagnose a failed connection without exposing account secrets.
Connection status checked October 14, 2026: InterServer’s public developer index now advertises the mcp.interserver.net endpoints below. That hostname did not resolve from either of our two test environments. The previously linked server-card and protected-resource URLs on my.interserver.net returned HTTP 404. We could not complete an MCP connection test. Treat the new addresses as advertised configuration, not a verified working connection; confirm availability through an InterServer support ticket before relying on unattended automation.
InterServer MCP endpoints
The InterServer developer index lists these addresses. It identifies the transport as Streamable HTTP.
| Purpose | Advertised address |
|---|---|
| Public tools, without account authentication | https://mcp.interserver.net/public |
| Authenticated customer tools | https://mcp.interserver.net/client |
| Client MCP server card | https://mcp.interserver.net/client/server-card |
| REST API documentation | InterServer API documentation |
Older copies of this article used https://my.interserver.net/mcp and https://my.interserver.net/mcp/private/client. Those are not the MCP addresses currently advertised in the developer index. Do not assume an old endpoint redirects or substitute a guessed IP address to work around a connection failure.
Public tools versus account access
Use public discovery only for information intended to be public. Account-specific inspection or changes require the client service and authorization. A public connection should not be treated as permission to view invoices, tickets, credentials, or private service details.
After a connection succeeds, inspect the tool list actually returned to your client. Read each tool’s description and input schema before using it. This page does not maintain a hard-coded inventory or promise that a particular operation is enabled for every account. A tool being visible is not proof that your credentials can execute it.
Authentication and credential handling
The developer index documents OAuth bearer tokens, the X-API-KEY header, and a sessionid header. It points customers to account security in the portal for API-key management. These mechanisms are not interchangeable in every client.
- Interactive clients: Prefer a supported OAuth connection. Check the destination and requested access in the authorization screen. Let the client follow the service’s discovery response instead of guessing token endpoints.
- Trusted automation: If using an API key, store it through the client’s protected credential facility. A header name alone does not make the key safe. Avoid literal secrets in exported configuration, prompts, logs, screenshots, and repositories.
- Existing sessions: A session identifier is an active login credential. Do not copy a browser session into an unfamiliar AI tool or a public support conversation.
Do not assume a general API key has the same restrictions as an OAuth grant. Inspect the permissions available for that credential. Use read-only access where supported and verify that a write attempt is denied in a suitable test account. If the available credential is broader than the task, do not attach it to an unattended agent.
Connect and verify before enabling automation
- Confirm the advertised hostname resolves and the service presents a valid HTTPS certificate. If it does not, stop before sending credentials.
- Choose a client that supports the service’s remote MCP transport and authentication method. Configuration-file names and JSON schemas differ between clients; there is no universal block to paste into every application.
- Add the appropriate endpoint and complete authorization through the client’s connection controls.
- Inspect the returned tools. Start with a documented, read-only operation and compare the result with the customer portal.
- Review the client’s model-provider and logging settings. Account data returned by a tool may become model input. MCP does not by itself keep that information on your workstation or on InterServer infrastructure.
- Leave actions such as purchases, cancellations, DNS changes, and service restarts behind explicit approval. Test authorization boundaries and failure handling before scheduling any workflow.
A successful public connection does not validate private authentication. Likewise, listing tools does not test an account-changing operation. Record exactly what was tested rather than treating the presence of a connected indicator as a complete deployment check.
Manual protocol tests
Use the version supported by both the client and service. In the 2025-11-25 Streamable HTTP specification, the client initializes first, sends the initialized notification, then makes requests using the negotiated protocol-version header. A session header is required on later requests only if the server assigned one. Other protocol revisions may differ.
The earlier examples on this page omitted shell continuation characters and parts of that sequence. They have been withdrawn rather than relabeled as working examples. A new end-to-end command transcript requires a successful test against the currently advertised InterServer service.
Troubleshooting
| Symptom | Next check |
|---|---|
| Hostname does not resolve | Check the spelling and current developer index. Include the hostname, timestamp, and resolver error in a support ticket. Changing an API key cannot fix DNS. |
| 404 from an old discovery URL | Confirm the currently advertised endpoint. Do not infer that the entire API is unavailable from one missing metadata file. |
| 403 or an HTML security page | Record the URL and response identifier for support. A security challenge is not an MCP JSON response. Do not disable certificate checks or expose credentials while troubleshooting. |
| 401 from an account endpoint | Check the client’s supported authentication flow and whether the grant has expired or been revoked. Redact tokens from diagnostic logs. |
| Tool missing or operation denied | Compare the discovered tools and granted permissions. Do not broaden access merely to make an unexpected operation succeed. |
Until MCP availability is confirmed, the customer portal remains the place to review and manage services. Developers who already use the REST API can consult its separate documentation; REST and MCP do not share an identical request format.
Related guides
Related guides
How to Secure the Ollama API with Nginx
Protect a private Ollama API with Nginx authentication and restricted routes. Verify allowed requests, denied management calls and direct-port isolation.
AIHow to Set Up an LLM Gateway with LiteLLM
Configure a LiteLLM gateway with private administration, virtual keys and model restrictions. Test allowed requests and understand budget limitations.
AIHow to Self-Host Karakeep with AI Tagging on a VPS
Self-host Karakeep with local Ollama tagging. Restrict first-user setup, disable public registration and verify collection, search and suggested tags.
AIHow to Categorize Support Tickets with a Local AI Model
Suggest support-ticket categories from a CSV using a CPU-only AI model. Keep inference local, preserve ticket IDs, and review uncertain classifications.