One Endpoint for Your Private AI Stack

Define what stays private in the stack

Consider a team using a desktop assistant for research, Claude Code for implementation, a local model for sensitive analysis and a nightly Python report. All four need deployment records and an internal runbook. Configuring each directly against those systems creates four places to maintain connection details, credentials and tool definitions. A shared MCP service moves that integration work behind an address each compatible host can call.

Draw two paths before choosing the service. The inference path carries prompts, retrieved material and model responses. The tool path carries arguments to the MCP endpoint, requests to connected systems and results back to the host. A locally running model can still send sensitive arguments to a hosted tool service. Conversely, a private MCP deployment can return internal records to an assistant whose inference runs elsewhere.

Decide which records each host may receive, whether the connection layer may process them and whether its logs may retain them. These are separate decisions from model selection. Use the shared endpoint to standardize access while evaluating data handling across the complete request path.

Place the endpoint where every intended caller can reach it

The MCP transport specification describes Streamable HTTP as HTTP POST messages to a single MCP endpoint, with JSON or request-scoped SSE responses. That is the network interface to evaluate for a service shared across machines. A local stdio server instead runs as a client-launched subprocess; putting its launch command into several editors does not create a shared remote service.

Reachability depends on the actual caller. Anthropic documents that Claude remote custom connectors originate from its cloud infrastructure, including when used through Claude Desktop. A URL reachable through your laptop's VPN therefore does not establish that the desktop connector can reach it. This differs from Desktop's separate local-server mechanism.

For each host, record the request origin, DNS resolution and permitted network route. If a required assistant calls from a vendor cloud, choose an authenticated endpoint reachable from that origin or reconsider that assistant's place in the private workflow. Do not solve the routing problem by exposing the underlying database directly.

Keep one address and small client-specific configurations

Use a placeholder such as https://mcp.example.com/mcp while documenting the architecture. Replace it with your deployed endpoint before connecting. Claude Code's documented HTTP setup can make that address available across projects for the current user:

claude mcp add --transport http workspace-tools --scope user https://mcp.example.com/mcp

For an OAuth-enabled server, open /mcp in an interactive Claude Code session and complete authentication. Adding the server configuration alone does not prove an authorized tool call succeeds.

Cursor documents a different JSON wrapper and supports remote URLs with authentication headers. For a server accepting bearer credentials, a personal ~/.cursor/mcp.json entry can have this shape:

{
  "mcpServers": {
    "workspace-tools": {
      "url": "https://mcp.example.com/mcp",
      "headers": {
        "Authorization": "Bearer REPLACE_WITH_CURSOR_SCOPED_KEY"
      }
    }
  }
}

The key text is a placeholder, not environment-variable expansion. Provision a credential limited to this caller, and keep populated configuration out of the repository. Cursor also supports project configuration at .cursor/mcp.json; sharing the address there should not distribute one person's bearer credential. The clients retain their own configuration formats while the integration address stays stable.

Put the local model behind an explicit tool-execution loop

A model server and an MCP client perform different jobs. Ollama's tool-calling examples pass function definitions to a model, inspect its returned tool calls, execute application code and send the resulting tool messages back for another response. Tool calling does not itself make a model open an MCP connection.

For your local-model host, implement that boundary explicitly: discover the authorized MCP tools, translate the selected schemas into the model's supported function format, validate returned arguments and dispatch approved calls through the MCP client. Return the tool result to the local model. Test name and schema translation rather than assuming every model accepts the endpoint's tool definitions unchanged.

A scheduled report can use the same connection without model inference. The official MCP Python SDK supports clients and Streamable HTTP, allowing a script to invoke a known tool directly. Keep its credential distinct from the interactive local-model host's credential. The script needs a deterministic query and error handling; the model host additionally needs a bounded decision loop. Local models with hosted MCP tools develops that adapter boundary further.

Share a discoverable working set of tools and context

The MCP tools specification defines tools/list discovery and tools/call invocation, with schemas describing tool inputs. Make those contracts understandable across the hosts you selected. A deployment lookup should identify the deployment and return useful evidence whether it is called from an editor, a local-model loop or the nightly report.

Do not equate one connection with loading every tool and runbook into every prompt. Anthropic's context-engineering guidance describes retaining lightweight references and retrieving detail when needed. For this stack, start an investigation with the deployment source and the relevant runbook reference. Fetch the procedure and current deployment record when the task needs them.

Keep durable context outside a particular assistant's transcript if another host must retrieve it later. A shared runbook can travel through retrieval, but the consuming application must still decide when to load it and how to treat its contents. Ask the second assistant to retrieve the runbook from the service, rather than assuming the first assistant's loaded context followed it. An agent-independent context layer covers that storage contract.

Separate caller identity and operate the shared dependency

A common address should accept independently revocable caller credentials. Give the research assistant access to selected records, the implementation agent only its required systems and the reporting script its fixed read operations. Enforce authorization when executing each call, even if a client remembers a previously discovered tool.

The MCP authorization specification requires OAuth access tokens to target the MCP server and travel in the authorization header, not a query string. Its security guidance rejects accepting tokens issued for some other service. Authenticate the caller to the connection layer, then use separately managed upstream authorization to reach connected systems. Copying database or provider tokens into every assistant defeats the credential boundary you introduced.

Centralizing this path also makes its outage affect several workflows at once. Set request deadlines, preserve upstream error details and record enough call metadata to identify the failing source without recording secrets. Decide which local tasks may continue without tools. A model can still produce prose during an outage, so require a failed deployment lookup to remain visibly failed rather than becoming an invented status. Test credential rotation and upstream outages through each host before moving the report onto the shared service.

Where SPYN3 fits

SPYN3 provides one MCP endpoint per workspace at https://api.spyn3.com/agent/mcp, with API-key or OAuth authentication. Upstream credentials stay envelope-encrypted in the workspace; agents hold only SPYN3 credentials. Keys can be restricted to chosen sources, with separate grants for read-only and write tools. Sources open on demand, and proxied calls are audit-logged. Opt-in Memory & skills adds shared context tools; memory writes require write:memory. Revoking a key takes effect on the next call. Automatic memory uses a plugin for Claude Code and Codex.

Verify portability with the same small investigation

Use a fictional deployment and a non-sensitive runbook for an acceptance exercise across the desktop assistant, coding agent, local-model host and report script:

1. Connect each host to the same endpoint with its own credential. Confirm the request originates where your network design expects.
2. Retrieve the deployment record through each host. Compare the underlying tool arguments and returned evidence, rather than the assistants' wording.
3. Have the interactive hosts retrieve the runbook. Confirm the local-model adapter returns tool results to local inference, and identify where the cloud assistant receives them.
4. Attempt an operation outside the report credential's permissions. Require a server-side denial even when invoked directly by name.
5. Revoke one caller, then disconnect the test upstream. Verify independent revocation and visible upstream failure across the remaining clients.

Keep the observed results with your architecture decision. The replacement test is whether another compatible host can obtain the authorized evidence through the existing service without receiving the upstream credentials.