StackJack MCP Proxy: Architecture, Authentication, and Operational Verification

Scope and the direct answer

StackJack is best understood as a remote MCP proxy rather than a set of integrations bundled into one AI client. Your AI client — Claude, ChatGPT, Copilot, Cursor, or any remote-MCP-capable agent — is configured with one MCP endpoint. StackJack receives each request, resolves which connector should handle it, attaches the authenticated user's stored credentials, applies that user's policy, and forwards the call to the downstream platform such as a PSA, RMM, or Microsoft 365 tenant.

This article covers the architecture and the verification workflow. It does not recommend a specific plan, connector count, or provider. Where you need a concrete endpoint or network recommendation, use the RPC Assistant rather than treating this page as a provider listicle.

The practical consequence of the proxy model is that identity moves to the proxy layer. Every teammate signs in as themselves, and the proxy decides what tools that identity may invoke. That is a different security boundary from a shared service account embedded in a client configuration.

• One client-side endpoint, many downstream connectors.
• Per-user authentication instead of a shared API key in the client.
• Policy and catalog filtering applied at the proxy, not the client.
• Audit metadata captured at the broker, ideally without retaining business payloads.

Prerequisites and assumptions

The procedures below assume you have an MCP-capable client, an account on the proxy service, and at least one connector configured with valid credentials. They also assume you can read the service's documentation for its exact MCP URL and OAuth discovery metadata; the examples use placeholders such as MCP_URL and CONNECTOR_ID deliberately, because hard-coding a vendor URL into a runbook is a maintenance trap.

You should have curl and either Node.js or Python available for the diagnostic scripts. For the audit checks, you need permission to view the workspace audit log. For any write-path test, use a non-production tenant or a sandbox connector, because tool calls that open tickets or modify devices are real side effects.

Mental model: how a remote MCP proxy brokers a call

A remote MCP proxy sits between the AI client and N downstream systems. The client performs MCP initialization against the proxy and receives a tool catalog. When the model selects a tool, the client sends a tools/call request to the proxy. The proxy maps the tool name to a connector, retrieves the caller's credential material from its vault, constructs the downstream API request, and returns a normalized result.

Two design choices matter operationally. First, statelessness: a proxy that keeps session state in memory will drop sessions during deploys; a stateless endpoint that re-authenticates per request survives rolling restarts. Second, catalog shaping: every major AI client has a ceiling on how many tools it can hold in context, and some clients truncate alphabetically or stop loading beyond that ceiling. A proxy that exposes thousands of tools must offer compact or search-on-demand catalog modes so the client is not silently starved of the tools it needs.

Think of the proxy as an API gateway with three responsibilities layered on top of routing: identity federation, credential custody, and catalog governance. Each layer is independently testable, which is what the diagnostic sections below exploit.

Authentication boundary: OAuth, PKCE, and credential custody

In a per-user model, the human authenticates to the proxy using OAuth, ideally with PKCE for public clients. The proxy then holds downstream credentials — either an API key pasted into a vault or an OAuth grant to the downstream platform — associated with that user. When the user's AI client calls a tool, the proxy uses that user's credential, not a workspace-wide service account.

This changes incident response. Revoking a departing employee's proxy identity should immediately remove their ability to invoke downstream tools, even if the downstream API key itself is unchanged. Verify that assumption explicitly rather than trusting the architecture diagram: disable a test user, then confirm a tool call made under that identity fails at the proxy before reaching the connector.

Credential custody also determines your blast radius. If the proxy stores downstream keys, a proxy compromise is a downstream compromise. Ask whether credentials are encrypted at rest, whether they are ever returned to the client, and whether the audit log records metadata only or payloads. The strongest posture is metadata-only logging with zero retention of business data, but you should confirm it from the vendor's documentation and your own log inspection, not from marketing copy.

Diagnostic procedure: reachability and OAuth discovery

Start by confirming the endpoint is reachable and advertises its authorization metadata. Replace MCP_URL with the MCP endpoint from your workspace settings. A healthy remote MCP endpoint typically responds to an unauthenticated request with a 401 or 403 and, where supported, exposes protected-resource metadata that points at the authorization server.

Record the status code, the WWW-Authenticate header, and any discovery document URL. These three values tell you whether a failure is a network problem, a misconfigured client, or an authorization-server problem.

curl -sS -D - -o /dev/null "$MCP_URL" \
  -H 'Accept: application/json, text/event-stream'

# If the response advertises protected-resource metadata, fetch it:
curl -sS "$MCP_URL/.well-known/oauth-protected-resource" | jq .

Diagnostic procedure: enumerate the tool catalog

Once authenticated, list the tools the proxy exposes to your identity. The count and names are your baseline. Save the output so you can diff it after a catalog-mode change or a connector update.

The script below performs an MCP initialize followed by tools/list over streamable HTTP. It uses MCP_TOKEN as a placeholder for a bearer token obtained through your client's OAuth flow; many clients handle this internally, in which case use the client's own tool-inspection view and compare against this baseline.

import json, os, urllib.request

MCP_URL = os.environ["MCP_URL"]
TOKEN = os.environ["MCP_TOKEN"]

def rpc(method, params=None, session=None):
    body = json.dumps({"jsonrpc": "2.0", "id": 1, "method": method, "params": params or {}}).encode()
    headers = {
        "Authorization": f"Bearer {TOKEN}",
        "Content-Type": "application/json",
        "Accept": "application/json, text/event-stream",
    }
    if session:
        headers["Mcp-Session-Id"] = session
    req = urllib.request.Request(MCP_URL, data=body, headers=headers, method="POST")
    with urllib.request.urlopen(req) as resp:
        return resp.headers.get("Mcp-Session-Id"), resp.read().decode()

session, _ = rpc("initialize", {
    "protocolVersion": "2025-06-18",
    "capabilities": {},
    "clientInfo": {"name": "catalog-baseline", "version": "0.1.0"},
})
_, listing = rpc("tools/list", {}, session)
print(listing[:2000])

Expected verification result and the results table

A successful run produces a 401 or 403 on the unauthenticated probe, a discovery document naming an authorization server, and a tools/list response whose tool names map cleanly to the connectors you configured. If the catalog is truncated relative to the connector's documented tool count, switch to a compact or search-on-demand catalog mode and re-run the enumeration.

Record your own measurements rather than relying on any figure quoted in vendor material. Use a table like the one below, filling each cell from your run:

• | Check | Command or view | Observed value | Pass criteria |
• | Unauthenticated probe status | curl -D - against MCP_URL | record | 401 or 403 |
• | Discovery document | /.well-known/oauth-protected-resource | record | Names an authorization server |
• | Tool count, default catalog | tools/list | record | Matches configured connectors |
• | Tool count, compact catalog | tools/list after mode switch | record | Fits client ceiling |
• | Audit entry for a test call | Workspace audit log | record | Timestamped, metadata only |

Audit verification: metadata versus payload retention

Audit logs are the accountability layer of a proxy. The claim to verify is narrow: every tool call is recorded with timestamp, user, connector, and tool name, and the record does not contain the business payload the AI saw. Test it with a read-only tool call against a sandbox connector, then inspect the corresponding audit entry.

If the entry contains ticket bodies, device inventories, or message content, the retention posture is different from what a metadata-only design promises, and you should treat the audit store as sensitive business data with its own access controls. If the entry is missing entirely, the proxy is not giving you the trail you need for client-facing accountability.

curl -sS "$PROXY_API_URL/audit/events?limit=5" \
  -H "Authorization: Bearer $PROXY_API_TOKEN" \
  | jq '.events[] | {ts, user, connector, tool, payload_retained}'

Troubleshooting common failure modes

Most failures fall into four buckets: the client cannot reach the endpoint, the OAuth flow completes but tools are missing, a tool call returns a downstream authorization error, or sessions drop during deploys.

For reachability, check egress rules and whether the client supports streamable HTTP with server-sent events. For missing tools, compare the catalog baseline against the connector's documented tool list and check whether the client truncated the catalog. For downstream authorization errors, confirm the user's own credential is valid — a proxy that silently falls back to a workspace credential masks per-user failures. For dropped sessions, prefer a stateless endpoint and re-initialize on reconnect.

• 401 on every call: token expired or audience mismatch; re-run the OAuth flow.
• Tools present but calls fail: downstream credential invalid for that user.
• Catalog smaller than expected: client ceiling reached; enable compact mode.
• Intermittent disconnects: session state lost on deploy; use stateless endpoint.
• Audit gaps: logging disabled for that connector or user scope.

Limitations and tradeoffs of the proxy model

A proxy concentrates risk. It is a single point through which every AI-initiated action flows, so its availability, authorization logic, and audit integrity become part of your operational surface. Per-user credentials improve attribution but multiply the number of secrets to rotate. Catalog shaping solves the client ceiling but adds a search step that can hide tools the model would otherwise have selected directly.

There is also a governance tradeoff between breadth and control. Exposing hundreds of connectors accelerates cross-system workflows, but each connector is an independent downstream API with its own rate limits, error semantics, and permission model. The proxy normalizes the interface, not the underlying behavior. Budget for per-connector testing rather than assuming uniform reliability.

Next steps: from verification to production use

Once the four checks pass, promote the configuration in stages: a read-only connector first, then a write-capable connector in a sandbox tenant, then scheduled automations. Keep the catalog baseline and audit query in your runbook so regressions are detected quickly.

If your AI workflows also touch blockchain data, the same discipline applies to RPC endpoints: verify reachability, authentication, and response consistency before trusting a provider. The RPC Assistant can help you choose a concrete endpoint, and the Learn library covers the surrounding methodology in guides such as choosing reliable RPC endpoints, multi-chain endpoint planning, and dedicated node hosting. For cost modeling of infrastructure that backs these workflows, see RPC pricing, and browse supported networks before committing to a topology.