ข้ามไปยังเนื้อหา

เนื้อหาหลักของหน้านี้เป็นภาษาอังกฤษแปลหน้านี้

AI และหัวข้อมาแรง

MCP: Model Context Protocol roadmap

The Model Context Protocol (MCP) is an open standard for connecting AI applications to tools, data and prompts. Build an MCP server once, and many AI clients can use it. Learn the concepts, build servers in Python, and deploy them securely.

เวลา
⏱ 2–3 weeks
Level
Intermediate
Steps
5 steps
Architecture ↓Cheat sheet ↓6 interview Q&As ↓
แชร์

The roadmap

Click a step to open the full guide.

Best architecture: MCP in an organisation

How AI apps reach company tools through MCP servers safely.

MCP deployment

  1. AI app (host)
  2. MCP client
  3. Remote MCP server (OAuth)
  4. Company APIs / DBs (least privilege)
  5. Audit logs

Why it's built this way

  • One MCP server per system, owned by that system's team.
  • Remote servers use OAuth and per-user permissions.
  • Read-only tools by default; writes need approval.
  • Audit logs สำหรับปี every tool call.

MCP: Model Context Protocol cheat sheet

The essentials on one screen. Bookmark it for revision.

Concepts

HostThe AI app (chat, IDE, agent)
ClientConnector inside the host, one per server
เซิร์ฟเวอร์Exposes tools, resources, prompts
ToolModel-called action, e.g. get_order(id)
ResourceRead-only data with a URI
PromptUser-picked template

Python SDK (FastMCP)

Create servermcp = FastMCP("name")
Tool@mcp.tool() on a typed function with a docstring
Resource@mcp.resource("docs://faq")
Prompt@mcp.prompt()
Run (local)mcp.run() (stdio)
TestMCP Inspector

Improve performance

  • Return short, structured results; huge tool outputs slow the model and cost tokens.
  • Paginate list tools (e.g. limit and cursor parameters) instead of returning everything.
  • Cache slow lookups inside the server.
  • Keep the number of tools per server focused; too many similar tools confuse the model.
  • For remote servers, keep them stateless where possible so they scale horizontally.

Security checklist

  • Install only trusted servers; review what third-party servers can access.
  • Always require authentication for remote servers; enforce per-user permissions.
  • Validate and sanitise every tool argument.
  • Treat tool outputs (web pages, emails, files) as untrusted text that may contain injected instructions.
  • Require human approval for actions that send, pay, delete or change permissions.
  • Log every tool call with user, arguments and result for auditing.

Most important interview questions

Click a question to see a strong answer. Each step also has its own questions.

1the Model Context Protocol คืออะไร

An open standard that lets AI applications connect to external tools, data and prompt templates through MCP servers, so integrations are built once and reused across apps.

2Describe the MCP architecture.

A host application contains MCP clients; each client connects to one MCP server over a transport (stdio or HTTP); servers expose tools, resources and prompts that the host makes available to the model.

3How does a model actually use an MCP tool?

The host fetches the tool list and schemas from the server, passes them to the model as callable functions, the model requests a call, the client forwards it to the server, and the result is returned to the model.

4When would you build an MCP server instead of a direct integration?

When you want the same capability available in several AI apps or agents, or want users to plug your service into their own AI tools.

5How do you design good MCP tools?

One clear job per tool, descriptive names, precise docstrings with examples, simple typed inputs, concise structured outputs, and safe defaults (read-only first).

6prompt injection in the context of MCP คืออะไร

Text returned by a tool, such as a web page or email, containing instructions that try to make the model misuse other tools. Mitigate with least privilege, approvals and treating outputs as data.

Related โรดแมป

1

MCP: Model Context Protocol · Step 1 of 5 · 1 day

What MCP is and why it exists

One standard instead of many custom integrations.

Before MCP, every AI app needed custom code for every tool. MCP standardises this: a server exposes capabilities, and any MCP-compatible client inside an AI host application can discover and use them.

Servers offer tools (actions the model can call), resources (data the app can read) and prompts (reusable templates).

What you'll learn

  • Hosts, clients and servers
  • Tools, resources and prompts
  • Transports: stdio and HTTP
  • How MCP relates to tool calling
  • Where MCP is used

One host, many MCP servers

AI app (host + MCP client)
  • Files server
  • Database server
  • GitHub server
  • Your company API
  • Search server
  • Calendar server

Key concepts

Host
The AI application the user works in, such as a chat app, editor or agent.
เซิร์ฟเวอร์
Your program that exposes tools, resources and prompts over MCP.
Tool vs resource
Tools are called by the model to act; resources are data chosen by the app or user.

Step by step

  1. 1.1

    Learn the roles

    Host (the AI app), client (connector inside it), server (your tools and data).

  2. 1.2

    Learn the building blocks

    Tools (actions), resources (data), prompts (templates).

  3. 1.3

    Learn the transports

    stdio for local servers, streamable HTTP for remote ones.

Notes

  • MCP does not replace tool calling; it standardises how tools are described and connected.

Tips & tricks

  • Read the official specification's overview page once.

Interview questions

What problem does MCP solve?

Without it, every AI app needs custom code for every tool (M×N integrations). MCP makes it M+N: each tool is built once as a server and works with any MCP-compatible app.

How is MCP different from function calling?

Function calling is how a model asks to run a function inside one app. MCP is a standard protocol for discovering and connecting tools, data and prompts across apps. MCP tools are typically exposed to the model through function calling.

The quick way to study this

Remember: server = capabilities, client = connector, host = the AI app.

2

MCP: Model Context Protocol · Step 2 of 5 · 2 days

Build your first MCP server

A working tool server in Python.

The official Python SDK lets you turn functions into tools with a decorator. The function name, type hints and docstring become the tool's name, input schema and description, which the model reads to decide when to use it.

Test your server with an MCP inspector before connecting it to an AI client.

What you'll learn

  • Installing the official Python SDK
  • Defining tools with type hints and docstrings
  • Running over stdio
  • Testing with an inspector
  • Connecting to a desktop AI client

From function to tool call

  1. Python function + docstring
  2. MCP tool schema
  3. Client lists เครื่องมือ
  4. Model picks tool
  5. Server runs it
  6. Result back to model

Key concepts

FastMCP
The Python SDK's simple API: functions become tools with a decorator.
Tool schema
Generated from type hints (inputs) and the docstring (description).
MCP Inspector
A developer tool to connect to and test servers without an AI model.

Step by step

  1. 2.1

    Install the SDK

    Create a virtual environment and install the official mcp package.

  2. 2.2

    Write a tool

    Decorate a typed function with a clear docstring using FastMCP.

  3. 2.3

    Test with the Inspector

    List tools, call them by hand, check inputs and errors.

  4. 2.4

    Connect to an app

    Add the server command in the app's MCP settings and try it in chat.

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("store")

@mcp.tool()
def order_status(order_id: str) -> str:
    """Look up the delivery status of an order by its ID."""
    return lookup_order(order_id)  # your code

if __name__ == "__main__":
    mcp.run()  # stdio by default

Notes

  • Clear docstrings matter: the model chooses tools by reading them.

Tips & tricks

  • Start with a read-only tool, such as looking up data.

Interview questions

Why do tool descriptions matter so much?

The model decides which tool to call, and with what arguments, by reading names and descriptions. Vague descriptions cause wrong or missed tool calls.

How would you test an MCP server?

Unit-test the underlying functions, then use the MCP Inspector to call each tool with valid and invalid inputs, and finally test end-to-end in an AI client with realistic prompts.

The quick way to study this

Copy the example, change it to a tool you would actually use, and connect it.

Practice project

An MCP server that exposes two tools for your own notes or tasks.

3

MCP: Model Context Protocol · Step 3 of 5 · 2 days

Resources and prompts

Share data and reusable templates.

Resources expose read-only data (files, records, documentation) that the host can load into context. Prompts are reusable templates users can pick, such as 'summarise this ticket'.

Use tools for actions or queries with parameters, and resources for data the app or user selects.

What you'll learn

  • Resources with URIs
  • Dynamic resource templates
  • Prompt templates
  • When to use a tool vs a resource

Tools, resources and prompts

Tools

  • Actions or lookups
  • Chosen by the model
  • Example: create_ticket

Resources

  • Read-only data
  • Chosen by app or user
  • Example: docs://faq

Prompts

  • Reusable templates
  • Chosen by the user
  • Example: summarise_ticket

Key concepts

Resource URI
An address for a piece of data, like file:///notes.md or docs://faq.
Prompt template
A ready-made instruction with arguments that users can pick in the host.

Step by step

  1. 3.1

    Add a resource

    Expose read-only data with a URI such as docs://handbook.

  2. 3.2

    Add a resource template

    Use parameters like orders://{id} สำหรับปี many similar items.

  3. 3.3

    Add a prompt

    Create a reusable template such as 'summarise this ticket'.

Notes

  • Resources are usually chosen by the app or user; tools are chosen by the model.

Tips & tricks

  • Expose your project's documentation as resources for coding assistants.

Interview questions

When should something be a resource instead of a tool?

When it's data to read that the user or app selects (a file, a record, docs). Use a tool when the model needs to decide to fetch something with parameters or take an action.

The quick way to study this

Add one resource and one prompt to your server.

4

MCP: Model Context Protocol · Step 4 of 5 · 3 days

Remote servers over HTTP

Serve many users from the cloud.

Local servers use stdio; shared servers run over HTTP so many users and clients can connect. Remote servers need authentication so each user only accesses their own data.

Deploy them like any web service, with logging, rate limits and monitoring.

What you'll learn

  • Streamable HTTP transport
  • Authentication (OAuth)
  • Deploying a server
  • Statelessness and scaling
  • Versioning เครื่องมือ

Local vs remote servers

Local (stdio)

  • Runs on the user's machine
  • Started by the host app
  • Uses the user's own access
  • Great for personal เครื่องมือ

Remote (HTTP)

  • Runs in the cloud
  • Many users connect
  • Needs authentication
  • Great for company services

Key concepts

stdio transport
The host starts the server as a local process and talks through standard input/output.
Streamable HTTP
Transport for remote servers shared by many users over the network.
OAuth
A standard way to let users grant access without sharing passwords.

Step by step

  1. 4.1

    Switch transport

    Run the server over streamable HTTP instead of stdio.

  2. 4.2

    Add authentication

    Use OAuth so each user connects with their own identity and permissions.

  3. 4.3

    Deploy

    Containerise and deploy like any web service with logs and rate limits.

  4. 4.4

    Version carefully

    Avoid renaming tools or changing inputs without a migration plan.

Notes

  • Never expose a remote MCP server without authentication.

Tips & tricks

  • Keep tool names and schemas stable; clients may depend on them.

Interview questions

What changes when you move an MCP server from local to remote?

You need authentication and per-user authorization, TLS, rate limiting, logging, horizontal scaling and careful handling of state, just like any public API.

The quick way to study this

Run your server over HTTP locally, then deploy it behind authentication.

5

MCP: Model Context Protocol · Step 5 of 5 · 2 days

Security and best practices

Safe tools for powerful models.

Tools give models real power, so design them carefully. Validate every input, limit what each tool can access, and require confirmation for actions that send, pay or delete.

Treat text returned by tools (web pages, emails) as untrusted: it may contain instructions meant to hijack the model.

What you'll learn

  • Least-privilege เครื่องมือ
  • Input validation
  • Prompt injection through tool results
  • Human approval for risky actions
  • Auditing and logs
  • Trusting third-party servers

Defence in depth for MCP

  1. Trusted servers only
  2. Authentication & per-user permissions
  3. Input validation
  4. Human approval for risky actions
  5. Audit logs & monitoring

Key concepts

Least privilege
Each tool gets only the access it needs and nothing more.
Tool poisoning
A malicious server whose tool descriptions or outputs try to manipulate the model.
Human in the loop
A person approves actions with real-world effects.

Step by step

  1. 5.1

    Threat-model each tool

    Ask: what's the worst thing this tool could do if misused?

  2. 5.2

    Limit power

    Prefer read-only tools; scope tokens and database users narrowly.

  3. 5.3

    Validate everything

    Check every argument; never build SQL or shell commands from raw input.

  4. 5.4

    Add approvals and logs

    Confirm risky actions with the user and log all calls.

Notes

  • Only install MCP servers from sources you trust.

Tips & tricks

  • Prefer many small, specific tools over one 'run anything' tool.

Interview questions

What are the main security risks with MCP servers?

Over-privileged tools, prompt injection via tool results, malicious third-party servers, missing auth on remote servers, and unvalidated inputs reaching databases or shells.

How would you design a safe 'send email' tool?

Separate drafting from sending; the tool creates a draft and shows it, a human approves, sending is rate-limited and restricted to allowed recipients, and every action is logged.

The quick way to study this

Review each tool: what is the worst thing it could do, and how do you limit it?

แชร์หน้านี้