Tool interfaces and MCP

Once an executor can call functions, how does it integrate several external services? MCP standardizes capability exchange; the host still maps model tools to specific servers and handles identity, versions and results. This article focuses on invocation contracts; reusable task methods follow in Skills.

Host, Client, and Server

MCP (Model Context Protocol) defines the protocol for applications and services to exchange context and capabilities. The Host is the application using the model, the Client is the component within the Host that connects to a specific Server, and the Server provides tools, resources, or prompt templates. A Host can connect to multiple Servers; they do not need to use the same business APIs or be deployed on the same machine. MCP Architecture

The tool invocation format of model vendors and MCP messages are not the same protocol. The Host usually maps MCP tool descriptions into tools visible to the model, converts model invocations into MCP requests, and converts service results back into observations for this round. This adaptation layer needs to handle name mapping, parameters, result types, errors, and invocation correlation; you cannot directly pass the Server list as input that all models can understand.

The common "M×N becomes M+N" explanation refers to the benefits of interface reuse: if M applications each connect to N systems, a large amount of adaptation is implemented repeatedly; a standard protocol allows some work on the application side and the service side to be reusable. However, authentication, business semantics, capability compatibility, and user experience still need to be integrated; the actual integration cost will not strictly equal M+N, nor will it disappear automatically.

Transport and Execution Location

Local stdio usually exchanges protocol messages via subprocess standard input and output; logs should not be mixed into the protocol output stream arbitrarily. Streamable HTTP uses HTTP to carry requests and optional streaming capabilities. The former is often used for local processes, while the latter is suitable for service-oriented connections, but the transport method itself does not provide business permission isolation. MCP Transport Overview

For example, if a local file Server inherits the user's broad file permissions, the model may access these files once it selects it; "local" does not mean a small access scope. Remote Servers also need to know the request subject, allowed scope, and credential validity; "already connected" only proves that the communication layer is established.

Three Types of Server Capabilities

The three are distinguished by intent, although the actual interface may differ: a resource might also be read by a tool, and a tool might only read data. What matters is that the caller understands "this is an action," "this is a resource," or "this is an optional interaction template," rather than elevating all returned text into task instructions. MCP Primitives

Both MCP prompts and Skills can contain method information, but their organization differs. A prompt is a template provided by the service via the protocol; a Skill is a distributable package containing instructions and optional files, which may be associated with scripts, templates, and multiple reference documents. They can overlap; you cannot draw a boundary solely based on "prompts are temporary, Skills are permanent": prompt templates can also be reused long-term.

The Boundary from Discovery to Invocation

Protocol Versions Precede Example Code

The protocol evolves. The 2026-07-28 version being reviewed uses server/discover to find supported versions and capabilities, and carries protocol version information in request metadata; do not mix stateful initialization flows from older versions with requests in this version. When maintaining old clients, check the specification according to the version they actually support, and upgrading the SDK also requires verifying peer compatibility. Versioned Architecture Description

Statelessness at the protocol layer does not mean the service cannot maintain shopping carts, browser pages, or long-running tasks. Business state can still exist, but requires clear identity and state positioning, such as explicit resource handles; you cannot assume that the next tool invocation automatically binds to the previous business object just because the TCP connection is still alive.

Discovery Does Not Mean Dumping Everything into Context

The Host can obtain the tool directory and then choose the exposure scope based on the current task. MCP capability discovery and the Host's semantic tool search are two different things; integrating MCP does not automatically guarantee that all tool schemas are loaded on demand. Tool selection, caching, and context budget belong to Host design.

Assume two services both provide search; the Host must maintain a mapping that accurately locates the service source. You cannot just display tools with the same name and let the invocation fall to the wrong backend; nor can you rely on the service's self-reported name to determine it is a trusted original service. The mapping should rely on connection identities configured and confirmed by the Host.

Below is an MCP tool definition object, omitting the outer protocol message. Note the use of inputSchema; it is different from the input_schema field in some model APIs.

{
  "name": "search_tickets",
  "description": "Read-only query for tickets within a specified project; returns entries and subsequent pagination positions.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "project": {"type": "string"},
      "query": {"type": "string"}
    },
    "required": ["project", "query"],
    "additionalProperties": false
  }
}

MCP tools support discovery, invocation, and structured description; results may contain various content types, and execution errors can be indicated via isError. Schema or annotations are not security proofs: the server must still validate parameters and access permissions, and the Host cannot blindly trust untrusted services claiming to be read-only. MCP Tools Specification

There Are Multiple Failure Points Even After Successful Connection

This layered troubleshooting avoids repeatedly modifying prompts when the transport is not connected, and avoids unconditionally expanding business permissions just to make the model "see more tools."

Two search tools: which one runs?

Connecting two servers does not make locally unique tool names globally unique. Establish connection identity and map model-visible names to tools; name resolution and JSON-RPC correlation are distinct responsibilities.

Connecting to task methods

The tool catalog describes callable capabilities; the host selects and maps them. Reporting methods, field meanings and templates belong in Skills and reusable task methods. Connect them through concrete tool names, arguments and result structures, and revalidate those dependencies after interface changes.

Continue with：Skills and reusable task methods。