What Is MCP? How Does Model Context Protocol Connect AI Agents, Tools, APIs And JSON Schema?

MCP Model Context Protocol is the right integration layer when you need one AI application to discover and use tools, resources, and prompt templates through a consistent interface. It is not a model and does not replace Function Calling: the MCP Client discovers the MCP Server’s tools and schemas, while the Host or platform controls execution, credentials, permissions, and lifecycle.

This guide is for:

• MCP Server developers who need to expose reliable tools and accurate schemas.
• Agent platform engineers connecting multiple clients and models to business systems.
• Operations and security teams responsible for deployment, authentication, auditing, and tool permissions.

What MCP Model Context Protocol actually connects

MCP standardizes the connection between an AI application and external capabilities. The official architecture separates four roles:

The official architecture gives each Host multiple Client instances, with each Client maintaining an isolated relationship with a particular Server. Servers can run as local processes or remote services. The Host remains responsible for connection permissions, user authorization, lifecycle management, and context aggregation. (MCP architecture specification)

That separation answers a common question: what is the relationship between MCP and a large language model? The model chooses or requests an action based on the available tool descriptions. MCP defines how the application discovers and invokes that capability. The Host decides whether the request is allowed and how the result returns to the model.

MCP also exposes more than executable tools. The official server model distinguishes:

• Prompts, usually selected or controlled by the user.
• Resources, such as files, records, or repository history managed by the application.
• Tools, which are model-controlled functions that can retrieve data or perform actions. (MCP server concepts)

MCP is not Function Calling

Function Calling usually describes a model API feature: the model returns a structured function request, and your application executes it. MCP is a protocol for connecting applications to reusable external capabilities.

The layers should remain separate:

1. The model decides that a tool may help.
2. The Host or AI platform maps that request to an available MCP tool.
3. The MCP Client sends a protocol message.
4. The MCP Server validates the arguments.
5. The Server calls the underlying API or local system.
6. The result returns through MCP and is passed back to the model.

You can use MCP behind a platform that supports Function Calling, but MCP is not a synonym for it. Treating them as interchangeable often produces confused ownership of validation, authentication, and retries.

First step: assign Host, Client, Server, and API boundaries

Before writing an MCP Server, draw the ownership boundary. A useful example is an internal release assistant:

• The Host is your approved AI workspace or agent platform.
• The Client is the connector instance created for the release Server.
• The MCP Server exposes tools such as list_builds, get_test_status, and create_release_candidate.
• The API layer communicates with your CI system, issue tracker, artifact store, or deployment service.

The model normally does not open a raw network socket to your production API. The Host manages the model session and asks the Client to use an approved Server. This reduces accidental cross-server access and gives the platform one place to enforce consent and policy.

A Server should reveal only the capability needed for its job. If an agent only needs to read build status, do not expose a general-purpose shell tool or unrestricted database query tool.

For teams comparing operating environments, keep the business boundary separate from the machine boundary. Most MCP Servers can run on ordinary Linux, Windows, or cloud infrastructure. Consider a persistent remote Mac only when the tool genuinely depends on macOS resources, Xcode, code signing, Apple automation, or a physical Apple software environment. Kvmjet’s infrastructure overview is useful when that specific dependency becomes part of your deployment design.

How does the connection lifecycle work?

Use this sequence as the implementation model:

User request
    |
    v
Host + model
    |
    | 1. Start or select MCP Client
    v
MCP Client <==== initialize / capability negotiation ====> MCP Server
    |
    | 2. tools/list
    v
Tool name + description + inputSchema + outputSchema
    |
    | 3. Model selects a tool
    v
MCP Client ---- tools/call + validated arguments ----> MCP Server
                                                         |
                                                         | 4. Execute
                                                         v
                                                  Business API / local system
                                                         |
    MCP Client <---- structuredContent / content / error ---- MCP Server
    |
    v
Host validates, displays, or returns result to model

This lifecycle has five operational phases: transport, initialization, discovery, invocation, and controlled completion. It is more useful than memorizing every protocol field because each phase has a different failure mode.

Phase one: choose the transport

The official protocol defines STDIO and Streamable HTTP as standard transports. STDIO passes MCP messages over standard input and output. Streamable HTTP supports a networked service and is the normal direction for remote deployment. (MCP transport specification)

Do not change a local Server into a public HTTP service by simply adding a web listener. You also need request authentication, token validation, network controls, rate limits, structured logging, and a defined lifecycle for sessions.

Phase two: initialize and negotiate capabilities

At initialization, the Client and Server establish protocol compatibility and advertise supported capabilities. These capabilities determine which features the session may use. For example, a Server that supports tools must advertise the relevant capability, and a Client must not assume that every implementation supports every optional feature. (MCP architecture specification)

This is where compatibility testing matters. A protocol revision can define a feature while an individual client supports only a subset. Record at least:

• The protocol revision used during testing.
• The MCP SDK or implementation version.
• The transport.
• The advertised Server and Client capabilities.
• Whether the Client supports structured tool output, notifications, cancellation, or long-running tasks.

Do not document “MCP supports feature X” as if every application supports it. Document “the tested Client and Server negotiated feature X.”

Phase three: discover tools and read JSON Schema

The Client normally requests the Server’s available tools. Each tool definition includes a name, description, and inputSchema. An optional outputSchema can describe structured results. The official tools specification states that the input schema must be a valid JSON Schema object, with JSON Schema 2020-12 as the default when no $schema field is present. (MCP tools specification)

This explains why MCP uses JSON Schema: the Client needs a machine-readable contract for arguments, while the model and user interface need enough semantic information to select the correct tool.

A good tool definition should make these points explicit:

{
  "name": "get_build_status",
  "description": "Read the latest build status for a repository and branch.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "repository": {
        "type": "string",
        "description": "Repository identifier, such as mobile-app"
      },
      "branch": {
        "type": "string",
        "description": "Branch name to inspect"
      }
    },
    "required": ["repository", "branch"],
    "additionalProperties": false
  },
  "outputSchema": {
    "type": "object",
    "properties": {
      "status": { "type": "string" },
      "commit": { "type": "string" },
      "updatedAt": { "type": "string" }
    },
    "required": ["status", "commit", "updatedAt"],
    "additionalProperties": false
  }
}

Schema alone is not enough. Tool descriptions influence model selection, so vague descriptions create operational errors even when validation is strict. State whether a tool is read-only, whether it changes state, what identifiers it accepts, and what it does not do.

Tool names should be unique within a Server and should use a restricted, predictable naming style. The official specification recommends names between 1 and 128 characters and advises against spaces and unusual punctuation. (MCP tools specification)

Important: Treat tool annotations and descriptions as untrusted input unless the Server is trusted. A convincing tool name does not prove that the operation is safe.

What happens when an MCP tool is called?

Tool execution has two different contracts: the protocol contract and the business contract.

The protocol contract checks whether the message is valid, whether the tool exists, and whether the request shape is acceptable. The business contract checks whether the repository exists, whether the user can access it, and whether the requested operation is allowed.

A reliable call path looks like this:

1. The model proposes a tool and arguments.
2. The Host applies allowlists, confirmation rules, and user context.
3. The Client sends tools/call.
4. The Server validates the arguments against inputSchema.
5. The Server applies authorization and business rules.
6. The Server calls the underlying API or local process.
7. The Server returns text, resource content, or structured content.
8. The Client validates the result when an outputSchema exists.
9. The Host decides whether to show the result, pass it to the model, or request confirmation for a next action.

MCP distinguishes protocol errors from tool execution errors. A malformed request or unknown tool is a protocol-level problem. An API outage, rejected business operation, or invalid date can be returned as a tool result with isError: true, allowing the model to receive actionable feedback without treating the entire session as malformed. (MCP tools specification)

For production systems, add these controls:

• Timeouts: Every external API call needs a bounded deadline.
• Cancellation: Stop work when the user abandons the request or the Client cancels it.
• Idempotency: Use request keys for operations such as creating releases, tickets, or payments.
• Retry limits: Retry transient failures only, with a maximum attempt count.
• Result size limits: Avoid returning an entire repository or database table to the model.
• Correlation IDs: Link the Host request, MCP call, Server log, and downstream API request.
• Loop limits: Stop an Agent after a defined number of dependent tool calls or repeated failures.

Structured output is especially useful when the next workflow step depends on stable fields. The specification allows structuredContent and recommends also returning serialized JSON in a text content block for compatibility. When an outputSchema is supplied, the Server must produce conforming structured results, while Clients should validate them. (MCP tools specification)

How should you control permissions and credentials?

Do not let the model decide its own privileges. Build permission levels around the actual consequence of each tool:

Credentials should stay in the Host, environment, secret manager, or a controlled execution layer. Never place API keys in a tool schema, prompt template, error message, public repository, or client configuration that is distributed to users.

For HTTP-based authorization, the MCP authorization specification defines the Server as an OAuth resource server and the Client as the OAuth client acting on behalf of a resource owner. Servers must publish protected resource metadata so Clients can discover the relevant authorization server. Access tokens must be sent in the Authorization header, not in query parameters, and the Server must validate that the token was issued for the intended audience. (MCP authorization specification)

For STDIO, the official guidance points toward retrieving credentials from the environment rather than applying the HTTP authorization flow. That does not mean local Servers are automatically safe. A local process can still read sensitive files, invoke dangerous commands, or leak credentials through logs.

Local-to-remote deployment decisions

Use these decision rules before changing deployment:

• If one developer owns the workflow, local files are involved, and no shared access is needed, choose local STDIO.
• If multiple users need the same API integration, choose remote Streamable HTTP with authentication and centralized logs.
• If the Server needs both private local automation and shared business data, choose a hybrid design with separate Servers and explicit trust boundaries.
• If the tool requires Xcode, macOS automation, signing identities, or Apple-only build resources, evaluate a persistent remote Mac only for that tool group.
• If the workload is ordinary API access or database queries, do not deploy it on a Mac merely because the connected Agent runs on one.

A local-to-remote migration should follow an operational sequence rather than a code-only change:

1. Define the public MCP endpoint and its canonical resource identity.
2. Replace local process assumptions with explicit configuration.
3. Add TLS termination and network access controls.
4. Implement OAuth discovery and token validation for HTTP access.
5. Separate read and write tools, scopes, and confirmation rules.
6. Add request IDs, structured logs, latency records, and error classification.
7. Test initialization, capability negotiation, tool discovery, valid calls, invalid calls, timeout, cancellation, and unauthorized access.
8. Run the Server under a restricted service account or container identity.
9. Document rollback to the local implementation.
10. Re-test after protocol revisions or transport changes.

For a team that needs an always-on Apple build or automation environment, the machine is only one part of the design. You still need the MCP Server process, network policy, credentials, logging, and client compatibility. Review remote Mac support options only after confirming that your tool actually depends on macOS. If you need to discuss a persistent Xcode or Apple automation setup, use the deployment contact path rather than assuming every MCP workload requires rented hardware.

A deployment decision you can apply today

Choose the smallest architecture that meets the access requirement:

• Local STDIO: Best for individual development, local repositories, and private automation.
• Team remote HTTP: Best for shared APIs, centralized credentials, and audit requirements.
• Hybrid: Best when some tools must stay beside a developer workstation or Mac build environment.
• Remote Mac: Best only when Xcode, signing, macOS automation, or Apple-specific runtime access is a hard dependency.

The advantage of MCP is not that it makes every Agent autonomous. Its value is that a compatible Host can connect to focused Servers without rebuilding a custom integration for every model and application. The security cost is also clear: every newly exposed tool becomes a new action surface that needs validation, authorization, monitoring, and operational ownership.

If your current approach is a collection of one-off model integrations, embedded API keys, duplicated function definitions, and manually maintained client adapters, it will usually become difficult to audit and inconsistent across Agents. A properly designed MCP layer gives you reusable discovery, explicit schemas, bounded execution, and a clearer path to shared tools. If that layer must continuously access Xcode, signing identities, or Apple automation, renting a managed remote Mac from Kvmjet can be more practical than keeping a dedicated Mac online, provided you have already confirmed the workload needs macOS and does not require physical peripherals.

A sound first deployment is not “put every tool behind MCP.” Start with one read-only Server, verify discovery and error handling with an official SDK or compatible Client, then add narrowly scoped write tools after the audit path works.