Clearing AI Confusion: Function Calling, MCP, Tools, Skills, Vectors, Tensors, Tokens, Embeddings

01 Introduction

When starting with AI, the difficulty often lies not in individual concepts but in similar terms appearing together and becoming mixed up. Function Calling and MCP both relate to tool use; Tool and Skill both extend AI capabilities; vectors and tensors both organize numbers; Tokens and Embeddings both appear when text enters a model. Confusion arises because these terms operate at different layers and answer different questions. The article provides a mapping table:

Model–tool interaction : Function Calling – how the model expresses “I want to call a tool”.

Application–external capability connection : MCP – how an AI application connects to and uses external capabilities.

Task execution : Tool, Skill – what can be done and how to do it well.

Internal data representation : Token, vector, tensor, Embedding – how text becomes numbers the model can compute.

With this map, the relationships become clearer.

02 Function Calling vs MCP

1. Function Calling: Model expresses tool‑call intent

Function Calling (also called Tool Calling) lets the model return a structured tool‑call request instead of plain text. For example, when a user asks “What’s the weather in Shanghai?” and the application has declared a get_weather tool, the model may return:

{
  "name": "get_weather",
  "arguments": {
    "city": "上海"
  }
}

This is a “call slip”, not the weather result. The external application executes the tool, handles errors, returns the result to the model, and the model then produces a natural‑language answer. OpenAI’s documentation splits the flow into: provide tools, receive call, execute code, return result, generate answer.

To use Function Calling in your own app you typically need three parts:

Tool description : tell the model the tool’s name, purpose, and parameters.

Tool implementation : the actual program that performs the query, write, or calculation.

Call orchestration : receive the model’s call request, run the corresponding program, and feed the result back to the model.

The model acts as the decision‑maker that fills out the call slip; the application handles execution and return.

2. Function Calling is a trained capability

The model’s ability to choose the right tool and fill parameters according to a given schema comes from training and alignment. It learns a general procedure, not a fixed tool:

Read tool description
  ↓
Judge whether current task needs a tool
  ↓
Select tool and generate parameters

Therefore, even if the model never saw get_weather during training, it can use it correctly based on the runtime name, description, and parameter structure. Different model platforms may have varying tool formats, fields, and limits, so switching models or APIs often requires adjusting tool descriptions and orchestration code.

3. MCP: AI applications connect to external capabilities via a unified protocol

MCP (Model Context Protocol) addresses a different concern: letting AI applications connect to external capabilities in a relatively uniform way. MCP is not a concrete tool and does not make decisions for the model. It uses a Host‑Client‑Server architecture:

Host : the AI application the user interacts with; manages model, context, permissions, and overall execution.

Client : a connection module inside the Host that establishes a session with a specific MCP Server and exchanges messages.

Server : the external capability provider; exposes tools, resources, and prompt templates according to the protocol.

For instance, a weather MCP Server can offer “query real‑time weather” and “query forecast” tools. Any MCP‑compatible AI application can discover and call them without redesigning service interfaces for each app.

AI Application (Host)
  ↓
MCP Client
  ↓
MCP Server
  ↓
Weather service, database, or local program

An MCP Server can run as a local process or a remote service. Regardless, the business logic, authentication, access control, and error handling behind the tools must still be implemented by developers.

4. How MCP and Function Calling work together

Function Calling and MCP often collaborate but handle separate segments:

Function Calling focuses on how the model expresses a tool‑call request.

MCP focuses on how the AI application discovers, connects to, and invokes external capabilities.

The application code wires the model, MCP, and the actual execution code together.

In a common implementation, the Host fetches tool descriptions from the MCP Server, converts them into the format the current model API expects, the model generates a call request, the Host invokes the corresponding Server via the MCP Client, and finally returns the result to the model. MCP standardizes Client‑Server communication and capability description; differences in Function Calling formats across model vendors are usually handled by the Host or developer framework.

If an internal app only connects to one or two fixed tools and the model rarely changes, direct Function Calling integration is simpler. MCP’s value becomes clear when the same set of tools must be reused across multiple AI applications, or when tools, resources, and prompt templates need to be managed in a standard way.

Function Calling lets the model express tool‑call intent; MCP lets AI applications connect to external capabilities via a unified protocol.

03 Skill: Organizing Methods and Tools

1. Too many tools strain context

With an MCP‑enabled Host, the same tool can serve different AI applications and models. In real projects, tool counts grow quickly: weather, file reading, web search, database access, messaging, etc. A single MCP Server may host multiple tools. The model must know available tools to decide whether to call them, so the application typically registers tool names, descriptions, and parameter schemas. If a Server provides 10 tools, the model reads 10 descriptions; adding more Servers lengthens the list further.

Problems arise:

Tool descriptions consume tokens, reducing context space for the actual task.

Excess irrelevant tools increase selection difficulty, leading to wrong tool choices or parameter errors.

However, MCP does not require “all tools permanently and fully injected into the model”. It only handles discovery and invocation; the Host or Agent framework decides which tools to present. When tools are numerous, the app can pre‑filter task‑relevant tools or use progressive tool discovery, then pass only candidates to the model. Thus, context pressure comes from “many tools plus full registration”, not from MCP itself.

2. What is a Skill?

Having tools doesn’t mean the model knows how to accomplish a task well. For example, a web‑search tool finds information but doesn’t know how to select topics for a beginner‑friendly technical article, verify facts, structure the piece, or decide where to add illustrations. Repeated steps and experience can be packaged into a Skill.

A Skill resembles an “operations manual” for an Agent. It specifies applicable scenarios, execution steps, available references and tools, and quality standards for the result. Following the Agent Skills specification, a Skill typically uses a SKILL.md entry point and may include scripts, reference materials, and templates. Content is loaded progressively:

Load metadata first : only the Skill name and brief description, so the model knows “what skills exist and when to use them”.

Load instructions on match : when the model decides a task needs a Skill, it reads the full SKILL.md and its execution steps.

Load resources on demand : during execution, scripts, references, or templates are fetched as needed.

This way, even with many stored Skills, each task starts with a lightweight skill directory; the model picks a direction, then expands into concrete methods and resources. Skills also make it easy to update knowledge and workflows after model training ends—developers simply modify SKILL.md, scripts, or references to add domain knowledge, personal experience, and task standards without retraining the model. Different products may vary in file structure, triggering, and loading process, but the idea is the same: save mature practices for a class of tasks so Agents can retrieve and reuse them on demand.

Progressive Skill loading does not conflict with MCP tool discovery. The former expands task methods and resources on demand; the latter discovers and invokes external capabilities. Real systems can further filter MCP Tools, passing only those relevant to the current task to the model.

3. Forms of Tools inside a Skill

A Skill primarily stores methods and instructions; writing steps does not grant execution ability. File reading, web search, and database queries still rely on concrete Tools. Common Tool forms used in Skills:

Built‑in or pre‑registered application Tools : the Skill specifies when to use search, file read, command execution, etc.; executed by the Agent’s host application.

Scripts bundled with the Skill : Python, Node.js scripts placed in the Skill directory with documented run conditions and parameters; executed by the Agent via a command environment.

Regular functions or business APIs : wrapped by the application as callable tools; the Skill defines when to call them and what inputs are required; executed by the application or backend service.

MCP Server‑provided Tools : the Skill guides the Agent to call a specific MCP tool at a certain step; the Host invokes it via the MCP Client.

For example, a “Technical Article Writing” Skill might instruct the Agent to first read the draft with a file tool, then verify facts with a search tool, and finally run a bundled checking script. The Skill sequences the steps; Tools and programs perform the actions. Together: Skill provides task methods on demand, Tools execute concrete actions, MCP connects external Tools to the AI application.

04 Vectors vs Tensors: Two Meanings of “Dimension”

1. Vector: an ordered list of numbers

A vector is simply an ordered sequence of numbers, e.g., [0.12, -0.85, 0.33, 0.47]. This has 4 components, so it is a 4‑dimensional vector. Here “4‑dimensional” means the vector contains 4 numbers. In AI, text, images, and audio can be turned into vectors. An Embedding model converts “apple” into a vector, allowing the computer to compare its relationship with “fruit”, “banana”, etc., in vector space. Practical Embeddings often have hundreds or thousands of components; “768‑dimensional Embedding” means the vector has 768 numbers.

2. Tensor: a general data structure for organizing numbers

A tensor is the universal data structure for organizing numbers in deep learning, with one or more axes. In frameworks like PyTorch, model inputs, outputs, and parameters are represented as tensors. A tensor’s shape records the length of each axis. An Excel analogy helps:

Single cell → scalar (0 axes) → shape () One row → vector / 1D tensor (1 axis) → shape (4,) One sheet → matrix / 2D tensor (2 axes) → shape (3, 4) Multiple same‑sized sheets → 3D tensor (3 axes) → shape (2, 3, 4) For a tensor with shape (2, 2, 3), there are 3 axes (3D tensor). Axis lengths are 2, 2, and 3, giving 2 × 2 × 3 = 12 numbers total. It can be visualized as 2 sheets, each with 2 rows and 3 columns:

[
  [ [1, 2, 3],
    [4, 5, 6] ],
  [ [7, 8, 9],
    [10, 11, 12] ]
]

3. Same word “dimension”, different meanings

“Dimension” has two common senses:

Vector dimension : number of components in the vector.

Tensor dimension (often called rank or order): number of axes the tensor has.

Data with shape (768,) can be called a 768‑dimensional vector (focusing on 768 components) or a 1‑dimensional tensor (focusing on 1 axis). Remember: “768‑dimensional vector” refers to component count; “2‑dimensional tensor” refers to axis count.

05 Tokens and Embeddings: One Splits, the Other Numerifies

1. Words are human segmentation; Tokens are model segmentation

Humans read sentences by characters or words. Models differ: text first passes through a Tokenizer (splitter) and is broken into Tokens. A Token can be:

a whole common word;

a single character or word fragment;

a morpheme or subword;

punctuation, whitespace, or other symbols;

special tokens used by the model.

Many models use subword tokenization. Frequent content stays as a single token; rare words are split into smaller pieces. This avoids an infinitely large vocabulary for all words and forms, while not fragmenting as heavily as character‑level processing. BPE, Unigram, and WordPiece are common subword methods.

The same text tokenized by different models yields different token counts. Vocabulary, splitting algorithm, and special tokens vary, so “one token equals how many Chinese characters or English words” has no fixed answer. To estimate cost or context length, use the target model’s Tokenizer directly.

2. How Tokens become computable numbers

Tokenization is only step one. The model processes numbers, so further conversions happen:

Each Token has an ID in the vocabulary. The model looks up the corresponding Embedding, turning the discrete ID into a vector of numbers that can participate in computation. Suppose a sentence is split into 10 Tokens, each with a 768‑component Embedding. Ignoring batch and other axes, the model receives a 2D tensor of shape (10, 768):

First axis length 10 → 10 Tokens.

Second axis length 768 → each Token represented by a 768‑dimensional vector.

Vectors, tensors, Tokens, and Embeddings now connect.

3. Another common use of “Embedding”

Inside large models, Embedding usually means mapping Token IDs to vectors. In knowledge‑base retrieval and semantic search, we also say “embed a document”. The result is a vector representing the entire text’s semantics, used to compare whether two pieces of content are similar. Both usages perform “content‑to‑vector” conversion but serve different stages:

Token Embedding serves internal model computation.

Text Embedding is commonly used for similarity comparison, retrieval, and clustering.

4. What Tokens affect

Tokens directly influence how we use models:

API costs are typically calculated per input and output Token.

Context window limits Token count, not document pages.

Longer input generally means more Tokens to process.

Large language models generate text by repeatedly predicting the next Token.

In short, Tokens determine how text is split; Embeddings turn the split pieces into computable vectors.

06 Conclusion

These terms frequently appear together in an AI application but each handles a different stage. Take the weather query example: user input is tokenized by the Tokenizer into Tokens, converted to Token IDs, each ID mapped to an Embedding vector, multiple vectors form a tensor fed to the model. These concepts describe how text becomes model‑processable data.

When the model realizes it lacks real‑time weather, it uses Function Calling to emit a call request. The actual weather lookup is done by a Tool. If that Tool comes from an MCP Server, the AI application connects via an MCP Client. Whether to first confirm city and date or query directly, and whether to include precipitation probability and travel advice in the result—these procedural decisions can be encoded in a Skill.