Remote MCP Integration Acceptance: What Discovery Proves and What Still Needs Verification

Product status update (checked 2026-10-09, Beijing time): the six-tool list in this article is a historical observation from 2026-09-04. everyinfra_chat was withdrawn with the general text API on 2026-09-12 and is available again with the AI API (free after a top-up, not streamed); the data cleanup tools have been discontinued. Always take the current tool list from live MCP discovery (tools/list).

Entering an MCP address into a client and seeing tool names appear is useful progress, but it does not yet answer whether keys can be passed correctly, whether actual calls fall within allowed scopes, whether errors are recognized by the client, and whether returned data meets task requirements.

Using the remote endpoint at EveryInfra as an example, this document divides integration acceptance into four layers: protocol discovery, authentication matching, client operation, and business results. It first provides a keyless discovery probe, then explains why three clients cannot share a single statement that entering an address is sufficient. This is an integration guide with tested boundaries, not a declaration that Claude, ChatGPT, and Cursor have all been successfully installed.

One Remote Address, Four Independent Evidence Layers

The entry point checked here is https://api.everyinfra.com/mcp. Protocol discovery tells us how the server describes itself and which tools it exposes; authentication matching resolves how the client obtains and passes approved credentials; client acceptance checks whether tools actually enter the current session; and business acceptance verifies actual results and errors.

The four layers should be recorded separately. A server responding to initialization does not mean the client accepted subsequent notifications; a client seeing the catalog does not mean it has business permissions; a tool returning content does not mean there are no business errors. Do not use a single boolean value of connection success to cover all cases.

Similarly, MCP and REST are different integration modalities. REST samples can help verify business semantics, but cannot independently prove that a client correctly handles MCP authentication, content blocks, errors, or confirmation flows.

After Initialization, There Is Also a Notification

This text checks this discovery path against the MCP 2025-06-18 version, without claiming it is the newest or only version for all clients. The client first sends initialize to check the server-selected version, then sends notifications/initialized, and only afterward enters tool discovery. Subsequent HTTP requests should include the negotiated protocol version. Protocol Lifecycle

When a Streamable HTTP notification is accepted, it should return HTTP 202 with no response body. If the server returns Mcp-Session-Id during initialization, the client must retain it in subsequent requests; a session cannot be fabricated without that response header. Request responses may be JSON or SSE, and actual clients must support the transport format required by the protocol. Transport Specification

The script below only checks the JSON response branch used by this server and is not a general MCP client. It stops when encountering SSE, paginated catalogs, or unsupported versions, leaving continued acceptance to a full client; it does not pretend that parsing a single JSON object covers the entire protocol.

A Discovery-Only Diagnostic Script

Use Node.js 22 or later with built-in fetch support. The script does not read keys from the environment, does not send tools/call, and does not install or modify any client. Output retains only status, tool names, and compatibility issues, without printing business marketing from server descriptions.

node --input-type=module <<'JS'
const endpoint = 'https://api.everyinfra.com/mcp';
const supportedVersion = '2025-06-18';
const headers = {
  'Content-Type': 'application/json',
  Accept: 'application/json, text/event-stream',
};
const issues = [];
async function post(message) {
  const response = await fetch(endpoint, {
    method: 'POST', headers, redirect: 'error',
    body: JSON.stringify(message),
    signal: AbortSignal.timeout(20000),
  });
  return { response, text: await response.text() };
}
function rpcResult(reply, id) {
  if (reply.response.status !== 200) {
    throw new Error('RPC HTTP ' + reply.response.status);
  }
  if (!reply.response.headers.get('content-type')?.includes('application/json')) {
    throw new Error('This probe only handles JSON; use a full MCP client');
  }
  const body = JSON.parse(reply.text);
  if (body.jsonrpc !== '2.0' || body.id !== id ||
      body.error || !body.result || typeof body.result !== 'object') {
    throw new Error('Invalid or failed RPC response');
  }
  return body.result;
}
const initReply = await post({
  jsonrpc: '2.0', id: 1, method: 'initialize',
  params: {
    protocolVersion: supportedVersion, capabilities: {},
    clientInfo: { name: 'bip-discovery-only', version: '1.0' },
  },
});
const init = rpcResult(initReply, 1);
if (init.protocolVersion !== supportedVersion ||
    init.serverInfo?.name !== 'EveryInfra' || !init.capabilities?.tools) {
  throw new Error('Unexpected version, server or tool capability');
}
headers['MCP-Protocol-Version'] = init.protocolVersion;
const session = initReply.response.headers.get('mcp-session-id');
if (session) headers['Mcp-Session-Id'] = session;
const notification = await post({
  jsonrpc: '2.0', method: 'notifications/initialized',
});
if (notification.response.status !== 202) {
  throw new Error('Initialization notification was not accepted');
}
const notificationBytes = Buffer.byteLength(notification.text);
if (notificationBytes !== 0) issues.push('notification_body_not_empty');
// Continue discovery for diagnosis only; never enter a business call.
const listed = rpcResult(await post({
  jsonrpc: '2.0', id: 2, method: 'tools/list', params: {},
}), 2);
if (!Array.isArray(listed.tools) || listed.tools.length === 0 ||
    listed.tools.some(tool => !tool.name || tool.inputSchema?.type !== 'object') ||
    listed.nextCursor) {
  throw new Error('Incomplete or unexpected tool list');
}
console.log(JSON.stringify({
  observedAt: new Date().toISOString(),
  protocolVersion: init.protocolVersion,
  sessionHeaderPresent: Boolean(session),
  notificationStatus: notification.response.status,
  notificationBodyBytes: notificationBytes,
  toolNames: listed.tools.map(tool => tool.name),
  issues,
  businessCallPerformed: false,
  hostAcceptanceVerified: false,
}, null, 2));
if (issues.length) process.exitCode = 2;
JS

Exit code 0 only indicates that this limited discovery check found no discrepancies, and is by no means publishable or three-client acceptance success. Exit code 2 indicates the catalog was retrieved but protocol discrepancies exist; other errors terminate execution. Connection failures and compatibility issues after successful discovery should be handled separately.

What This Discovery Succeeded In and What Issues It Found

In the unauthenticated re-check on 2026 9 4 at 20:43 (China Standard Time), initialization returned HTTP 200 and protocol version 2025-06-18, without providing a session ID response header. The tool catalog returned six names:

• everyinfra_list_capabilities
• everyinfra_call_api
• everyinfra_chat
• everyinfra_list_captcha_types
• everyinfra_solve_captcha
• everyinfra_search

However, when the initialization completion notification returned HTTP 202, the response body was JSON null rather than empty. This does not meet the notification response requirements of the aforementioned version. The catalog remains readable, which is insufficient to prove that all clients will tolerate this discrepancy; the script should explicitly report it rather than silently ignoring it.

This round did not invoke business tools or confirm whether clients failed as a result. Subsequent response discrepancies must be handled by service maintainers and re-tested in actual clients. The currently supported statement is "the public discovery path has observed six tools with a notification response discrepancy," which cannot be written as "fully compatible with MCP."

When running the same free discovery process again on 2026-09-08, the catalog returned eight tools, with the two newly added items being data cleanup tools; the initialization completion notification was HTTP 202 with a 0-byte response body, so the response discrepancy from September 4 did not reappear in this re-check. This update still only closes old observations at the public discovery layer, and does not mean Claude, ChatGPT, and Cursor have completed authentication or actual business calls.

Cursor: Verifying Config Header Support Separately from Real Permissions

Official Cursor documentation provides url and headers configurations for remote servers, supporting interpolation from environment variables. Below is the configuration shape to be used after user authorization; this round did not write it into user configurations or verify actual client calls. Cursor MCP Documentation

{
  "mcpServers": {
    "everyinfra": {
      "url": "https://api.everyinfra.com/mcp",
      "headers": {
        "Authorization": "Bearer ${env:EVERYINFRA_API_KEY}"
      }
    }
  }
}

The project's current server code includes Bearer header parsing, but the presence of this path in the source code does not prove that a given key is usable today. When preparing for actual integration, confirm that the client process can read specified environment variables and verify the key's business permissions; do not write real values into version-controlled configurations, screenshots, or error reports.

Subsequently, refresh the catalog in the current version of Cursor, select individual tools, and retain user confirmation. Do not enable automatic execution for all tools simply because the catalog is visible; keys with business permissions should not be treated as long-term authorization for all operations.

Claude: Remote Connectors Do Not Route Through Local Networks

Official remote connector documentation for Claude states that requests originate from the Anthropic cloud, including remote connectors for Claude Desktop. This is a different mechanism from local MCP configurations in desktop local settings. Therefore, local access to an address only proves local paths; it does not prove that cloud connectors can also access it. Claude Remote Connector Instructions

Integration should check connector entry points according to current account and organizational permissions, and then verify authentication flows supported by both service and client. OAuth configurations in official documentation cannot be rewritten as "any Bearer API key can be entered." If authentication models do not match, services or controlled adaptation schemes must be designed and accepted first; secrets cannot be crammed into URLs as a generic substitute.

Click-through screenshots or "add and succeed" steps unverified by this account are not provided here. Adding connectors, authorization, and final confirmation change account states and should be executed after user approval; protocol probes cannot replace such evidence.

ChatGPT and OpenAI API: Two Different Integration Entry Points

Official ChatGPT Developer mode documentation lists OAuth, no authentication, and hybrid authentication; hybrid authentication involves unauthenticated discovery and selecting authentication methods per tool security declarations. Discovery requiring no key does not equal unauthenticated invocation for all business tools. ChatGPT Developer mode

This tool catalog did not observe tool-level securitySchemes or _meta fields. This is an observation of this response rather than a complete audit of the entire service authentication implementation; however, it suffices to show that successful discovery alone cannot be claimed to satisfy ChatGPT hybrid authentication requirements.

Remote MCP configuration for the OpenAI Responses API represents yet another path, containing parameters such as server_url, tool selection, authentication, and call approval. It is not configuration instructions within the ChatGPT interface; constructing requests via API does not retroactively prove web interfaces are connected. OpenAI MCP and Connector Guide

This round only checked documentation, without running OpenAI API business requests or enabling Developer mode for users. If this path is used subsequently, the scope of data sent to remote services should be independently reviewed, and approval steps for sensitive calls maintained.

Authentication design should also independently review official MCP security best practices tutorials. Located at the 2025-11-25 documentation path, this page explains that tokens should target correct services and opposes unverified token passthrough; it does not turn third-party keys into generic MCP credentials or replace discovery checks performed above according to version 2025-06-18.

After HTTP 200, Two More Result Layers Must Be Checked

Protocol errors in MCP can appear at top-level JSON-RPC error; tool execution errors can also be expressed via result.isError. Declaring business success based solely on HTTP 200 or the presence of a text block is insufficient. Tools and Errors Specification

Actual operations should also inspect data structures returned by tools: whether output matches expected objects, whether it is empty or only partially complete, and whether asynchronous tasks still require querying. Multi-content blocks must be handled according to tool contracts, without assuming the first text block contains all metadata. Billing, usage, and balances require checking actual business responses; discovering catalogs does not provide proof of settlement for business calls.

For sending, purchasing, submitting, or other side-effecting operations, a client displaying a tool does not mean the user has authorized execution. Confirm targets and parameters before calling; determine whether initial results are known before retrying. The keyless probe in this document deliberately avoids entering this layer.

An Acceptance Record to Hand Over to the Next Integrator

Each client should separately record products and versions, running locations, transmission and authentication methods, installation/authorization evidence, actual tool names, desensitized inputs, result statuses, and errors. Record observation times and allowed call scopes without saving raw keys. Successful samples, explicit failures, and unknown results should be documented separately.

Recording methods can reference event correlation and data exclusion principles from OWASP logging guides: correlate single operations while avoiding writing tokens, sessions, or complete customer contents into debugging attachments. Logs are only part of acceptance evidence and do not replace actual client behavior checks.

What has been completed in this round is public discovery and document discrepancy verification. Notification empty-body fixes, installation and authentication for three clients, authorized business calls, and failure display acceptance remain incomplete. Only when each of these items obtains evidence can tutorial phrasing change from "pending verification configuration" to "tested and passed in specified versions."

You can run the discovery script in this text first to confirm whether current interfaces and records remain consistent, then proceed according to team-selected clients. Do not modify three accounts simultaneously or copy unverified configurations just to piece together a compatibility list. EveryInfra Documentation Entry