MCP Access and Security

Understand MCP architecture, transports, and permission boundaries, and securely connect to third-party or self-hosted MCP servers.

Model Context Protocol (MCP) is an open protocol that connects AI applications with external systems. Compatible clients can access context, invoke tools, or use predefined prompts via the MCP Server without having to design separate access protocols for each data source.

MCP and model APIs are different access layers

The AGTCloud API handles model calls, while an MCP server exposes tools and context to compatible clients. When connecting to MCP, use the installation commands, URLs, and authentication methods provided by the server publisher or administrator. An AGTCloud model API address is not an MCP server endpoint.

How MCP works

An MCP Host can connect to multiple MCP Servers and create independent MCP Clients for each server.

Participants	Main responsibilities	Common forms
MCP Host	Runs the AI application and manages connections, permissions, and user confirmations	Coding agents, IDEs, desktop assistants
MCP Client	Establish a dedicated connection to an MCP Server and provide Server capabilities to the Host	It is usually built into the Host
MCP Server	Exposes specific tools, data, or prompt templates	Local subprocesses, remote services

MCP has a data layer and a transport layer. The data layer defines JSON-RPC messages, capability discovery, and primitives; the transport layer defines how messages move between local processes or across a network. Clients usually handle these protocol details, so follow the MCP configuration interface provided by the client.

What can the Server provide?

MCP Server mainly exposes three types of Primitives:

Primitive	Control methods	Function	Focus on checking when connecting
Tools	The model can be called selectively, and the Host is responsible for executing policies and authorizations	Perform operations or queries, such as calling APIs, writing files, or querying databases	Input schema, write operations, external side effects, and whether manual approval is required
Resources	Selected and managed by the application	Provide the model with contextual information such as files, records, and API responses	Data scope, sensitive information, update frequency, content credibility
Prompts	Usually chosen by users proactively	Provides reusable interaction templates and parameters	Template source, parameter meaning, and whether it contains external commands

The server declares its capabilities, and the client discovers the available Tools, Resources, and Prompts. A declared capability is not necessarily enabled; the final behavior also depends on the Host version, permission policy, and user choices.

Treat the server's returned content as external input

Resources, tool results, and prompts may all contain untrusted content. Do not automatically allow instructions to access other files, credentials, or system services just because they return through MCP.

Select a transport

The current MCP specification defines two standard transports: stdio and Streamable HTTP.

Transport	How it works	Best suited for	Main risks
`stdio`	The client starts a local server subprocess and exchanges JSON-RPC messages through standard input and output	Local tools, controlled directories, and servers that do not require network deployment	The startup command runs locally; the server inherits process permissions and some environment information
Streamable HTTP	The client sends an HTTP POST request to a single MCP endpoint; the server returns JSON or an SSE stream for that request	Remote services, shared team capabilities, and servers that require network authentication	Service identity, OAuth or token handling, network boundaries, data exposure, and remote side effects

For stdio, the server must write only MCP messages to stdout; logs should go to stderr. When a connection fails, inspect the stderr logs captured by the client, but do not send logs containing credentials to third parties.

Streamable HTTP currently uses a single POST endpoint and does not require separate GET or legacy HTTP+SSE addresses. Authentication is determined by the server. If the server provides an OAuth flow, use its authorization page instead of writing long-lived credentials directly into shared configuration.

Understand the configuration structure

Field names and configuration locations vary by client. The following examples show common structures and cannot be used as-is. Replace every placeholder with the commands, arguments, URLs, and authentication method supplied by the server publisher.

{
  "mcpServers": {
    "replace-with-server-name": {
      "command": "/absolute/path/to/server-command",
      "args": [
        "--replace-with-required-argument"
      ],
      "env": {
        "SERVICE_API_KEY": "replace-with-client-supported-secret-reference"
      }
    }
  }
}

command is the program actually executed by the client; before connecting, the full path and source must be verified;
args may include accessible directories, configuration files, or Server parameters;
env should pass only the minimum environment variables required by the server. Credential-reference syntax varies by client.

Do not directly copy unknown startup commands

command and args in the local MCP configuration will run on your computer. Do not run one-click install commands from unknown sources, and do not use the entire home directory, SSH directory, or system directory as the default access range.

Steps for secure access

1. Check client support

Confirm that the client supports MCP and check whether it supports stdio or Streamable HTTP. Use the configuration format corresponding to the current client version; do not guess fields based on examples from other clients.

2. Verify the server identity

Obtain installation instructions from the official server repository, vendor console, or organization administrator. Check the publisher, version, update history, dependencies, and uninstall procedure. For a remote server, also verify the domain, HTTPS configuration, and authentication flow.

3. Inventory capabilities and permissions

Review the Tools, Resources, and Prompts exposed by the server before enabling it. Record each tool's inputs, read scope, write operations, and external side effects, and disable capabilities unrelated to the current task.

4. Configure the minimum range

For local servers, allow only the required directories and environment variables. For remote servers, use least-privilege accounts or scopes. Do not send model API keys to unknown servers as generic MCP credentials.

5. Reload and check

Reload the configuration according to the client's instructions, confirm that the server can connect, and check that the client's displayed capability list matches expectations. A successful connection does not mean all Tools should be enabled.

6. Start with read-only operations

First, list the capability, read a non-sensitive resource, or call a tool without side effects. After confirming input, output, and logs, allow file writing, data modification, or external system calls item by item.

Permission review checklist

Scope	Confirm before connecting
Local files	Which directories can the server read and write to, and whether it follows symbolic links or accesses files outside the directory
Run commands	Which programs the Tool runs, and whether parameters are directly controlled by the model or external content
Network access	Which domains, intranet services, and third-party APIs the Server accesses
Credentials	Where the Key or Token is stored, which process or domain receives it, and whether it can be revoked independently
Data processing	Whether inputs and results leave the local machine, and how service providers store logs and call data
Write operations	Whether modifications, deletions, submissions, payments, or messages require explicit confirmation
Update	When server packages or remote capabilities change, will the client redisplay permissions?

For remote servers, connect only to trusted HTTPS endpoints and follow the documented authentication flow. For local servers, prefer absolute command paths, isolated directories, and standard user privileges. Do not run with administrator privileges merely for convenience.

Frequently Asked Questions

Issue	What to check	Resolution
Server cannot start	Command path, runtime, parameters, and working directory	Confirm the program exists in a regular terminal, but do not bypass the client to execute unknown commands directly
The client shows connected, but no Tool is available	Server capabilities, client permissions, and versions	Reload the capability list and confirm that the client supports the Primitive
`stdio` disconnects immediately after connecting	Whether the server writes ordinary logs to `stdout`	Write logs to `stderr` and reserve `stdout` for MCP messages only
Remote Endpoint returns `401` or `403`	Server authentication methods, tokens, and scope	Reauthorize according to the Server documentation; do not switch to tokens from other services
Remote Endpoint returns `404`	Does the URL contain the full MCP path?	Use the Endpoint provided by the Server publisher; do not add the model API path yourself
Tools can read but cannot write	Tool permissions, directory scope, and manual confirmation	Only expand permissions when truly necessary and revoke tests again
Tool behavior does not match the description	Server version, Tool Schema, and external inputs	Disable the tool immediately, save redacted evidence, and contact the server publisher
Unexpected external requests occur after connection	Server network permissions and data flow directions	Disconnect the server, revoke credentials, and check logs and host network activity

Continued use recommendations

Regularly review the list and authorization scope of connected servers, versions, tools, and scopes;
Use separate, revocable, least-privilege credentials for different servers;
Maintain manual confirmation, especially for deletion, writing, payment, message sending, and production system operations;
Do not treat instructions in unknown Resources or Tool results as trusted system instructions;
Logs, screenshots, and error reports must remove Keys, Tokens, customer data, and sensitive paths;
When you stop using the server, remove the configuration from the client and revoke the related credentials.

If you need to configure AGTCloud for a model client, start with the CC-Switch integration guide, or choose a specific tool from Third-party integrations in the sidebar. To understand model endpoints and request fields, see API Reference. For protocol details and version changes, refer to the official MCP documentation.

On this page