MCP Caching چیست؟ آموزش ttlMs و cacheScope در AI Agent

یک AI Agent متصل به MCP Server ممکن است پیش از اجرای هر درخواست، اطلاعات مختلفی را دریافت کند:

• مشخصات MCP Server
• فهرست Toolها
• تعریف و Input Schema هر Tool
• فهرست Promptها
• فهرست Resourceها
• محتوای بعضی Resourceها
• Resource Templateها

اگر Client این اطلاعات را در هر درخواست دوباره از Server دریافت کند، تعداد ارتباط‌های شبکه، Latency و بار Server افزایش پیدا می‌کند.

این مشکل زمانی جدی‌تر می‌شود که Agent به چند MCP Server متصل باشد یا هر Server صدها Tool و Resource ارائه کند.

نسخه 2026-07-28 پروتکل MCP یک مدل استاندارد برای Cache کردن بعضی پاسخ‌ها تعریف کرده است. در این مدل، Server با دو فیلد اصلی به Client اعلام می‌کند پاسخ تا چه زمانی و در چه محدوده‌ای قابل‌استفاده مجدد است:

ttlMs
cacheScope

این قابلیت با Cache معمولی برنامه، Prompt Caching مدل‌های زبانی و Cache کردن نتیجه Toolها تفاوت دارد.

در این راهنما معماری MCP Caching، پاسخ‌های قابل Cache، مدیریت انقضا، Invalidation و کاربرد آن در AI Agentهای متصل به API درواره را بررسی می‌کنیم.

MCP Caching چیست؟

MCP Caching مکانیزمی است که به Client اجازه می‌دهد بعضی پاسخ‌های MCP Server را برای مدتی ذخیره و دوباره استفاده کند.

Server داخل پاسخ مشخص می‌کند:

• پاسخ تا چه مدت Fresh در نظر گرفته شود.
• آیا Cache می‌تواند میان کاربران مشترک باشد.
• آیا Cache باید به همان Authorization Context محدود بماند.

نمونه پاسخ tools/list:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "complete",
    "tools": [
      {
        "name": "summarize_document",
        "description": "خلاصه‌سازی یک سند متنی",
        "inputSchema": {
          "type": "object",
          "properties": {
            "document": {
              "type": "string"
            }
          },
          "required": [
            "document"
          ]
        }
      }
    ],
    "ttlMs": 300000,
    "cacheScope": "public"
  }
}

در این مثال، Client می‌تواند فهرست Toolها را ذخیره کند و تا زمان انقضای TTL دوباره tools/list را فراخوانی نکند.

کدام پاسخ‌های MCP قابل Cache هستند؟

براساس Specification نسخه 2026-07-28، Server باید برای نتایج کامل بعضی عملیات‌ها اطلاعات Cache را ارائه کند.

عملیات قابل Cache عبارت‌اند از:

این پاسخ‌ها باید دارای مقدار زیر باشند:

{
  "resultType": "complete"
}

همه عملیات MCP قابل Cache نیستند. برای مثال، نتیجه اجرای عمومی یک Tool در فهرست استاندارد پاسخ‌های قابل Cache قرار ندارد:

tools/call

اگر می‌خواهید خروجی Toolها را Cache کنید، باید آن را در سطح Application و براساس ماهیت Tool طراحی کنید.

ttlMs چیست؟

فیلد ttlMs مخفف Time to Live برحسب میلی‌ثانیه است.

این فیلد مشخص می‌کند Client تا چه مدت می‌تواند پاسخ را Fresh در نظر بگیرد:

{
  "ttlMs": 300000
}

در این مثال، پاسخ برای پنج دقیقه قابل‌استفاده مجدد است.

چند نمونه متداول:

TTL یک Hint برای تازگی است، نه تضمین اینکه داده تا پایان این زمان تغییر نمی‌کند.

Client می‌تواند در صورت مشاهده نشانه‌ای از تغییر، پاسخ را زودتر از موعد از Cache خارج کند.

برای مثال، اگر Tool موجود در Cache هنگام فراخوانی با خطای «Tool پیدا نشد» مواجه شود، Client می‌تواند فهرست Toolها را دوباره دریافت کند.

اگر ttlMs وجود نداشته باشد چه اتفاقی می‌افتد؟

در نسخه جدید MCP، Server باید برای عملیات قابل Cache اطلاعات مربوط به Cache را برگرداند.

اما Client ممکن است با Server قدیمی‌تری روبه‌رو شود که ttlMs ندارد.

در این حالت Client باید مقدار پیش‌فرض را صفر در نظر بگیرد:

ttlMs = 0

یعنی پاسخ بلافاصله Stale است و Client نباید فرض کند می‌تواند آن را برای مدت طولانی استفاده کند.

cacheScope چیست؟

فیلد cacheScope مشخص می‌کند Cache در چه محدوده‌ای قابل‌استفاده است.

این فیلد یکی از دو مقدار زیر را می‌پذیرد:

public
private

cacheScope عمومی

مقدار public یعنی پاسخ حاوی اطلاعات اختصاصی کاربر نیست و می‌تواند میان کاربران مختلف به اشتراک گذاشته شود:

{
  "cacheScope": "public"
}

نمونه‌های مناسب:

• فهرست عمومی Toolها
• Promptهای یکسان برای همه کاربران
• Resource Templateهای عمومی
• مشخصات عمومی MCP Server
• مستندات عمومی

یک Gateway یا Client مشترک می‌تواند این پاسخ را یک بار دریافت و برای کاربران مختلف استفاده کند.

cacheScope خصوصی

مقدار private یعنی پاسخ به کاربر، Token یا Authorization Context مشخصی وابسته است:

{
  "cacheScope": "private"
}

نمونه‌های مناسب:

• Toolهای متفاوت براساس سطح دسترسی
• Resourceهای متعلق به یک کاربر
• اطلاعات یک Workspace خصوصی
• Promptهای سازمانی
• فهرست پروژه‌های یک حساب
• اسناد قابل‌مشاهده توسط یک کاربر مشخص

Cache خصوصی نباید میان Access Tokenها یا کاربران مختلف به اشتراک گذاشته شود.

تفاوت Cache عمومی و خصوصی

حتی اگر Endpoint نیازمند Authentication باشد، پاسخ می‌تواند public باشد؛ اما تنها زمانی که واقعاً برای تمام کاربران یکسان است.

وجود Authentication به‌تنهایی Scope را خصوصی نمی‌کند. محتوای پاسخ تعیین می‌کند Cache باید عمومی یا خصوصی باشد.

Cache Key در MCP چگونه ساخته می‌شود؟

Client باید هر پاسخ را براساس متد و پارامترهای مؤثر همان درخواست ذخیره کند.

برای مثال، این دو درخواست نباید یک Cache Entry داشته باشند:

{
  "method": "resources/read",
  "params": {
    "uri": "file:///documents/report-a.txt"
  }
}

{
  "method": "resources/read",
  "params": {
    "uri": "file:///documents/report-b.txt"
  }
}

هر URI محتوای متفاوتی دارد و باید Cache Key مستقل داشته باشد.

برای درخواست‌های Paginated نیز Cursor بخشی از Cache Key است:

{
  "method": "tools/list",
  "params": {
    "cursor": "page-2"
  }
}

Client نباید پاسخ یک درخواست را برای متدی با پارامترهای متفاوت استفاده کند.

در Cache خصوصی، Authorization Context نیز باید بخشی از تفکیک Cache باشد؛ بدون اینکه Access Token خام داخل Log یا نام قابل‌مشاهده Cache ذخیره شود.

چه پاسخ‌هایی نباید Cache شوند؟

پاسخ‌های input_required

پاسخ‌های موقت Multi Round-Trip Requests قابل Cache نیستند:

{
  "resultType": "input_required"
}

این پاسخ‌ها برای ادامه یک Workflow خاص ساخته شده‌اند و ممکن است حاوی requestState یا درخواست دریافت اطلاعات از کاربر باشند.

درخواست‌های دارای inputResponses

اگر Client یک درخواست را همراه پاسخ‌های کاربر تکرار کند، نتیجه آن نباید براساس مدل استاندارد MCP Cache شود:

{
  "inputResponses": {}
}

درخواست‌های دارای requestState

درخواست‌های حاوی requestState نیز به مرحله‌ای مشخص از یک Workflow وابسته‌اند و نباید در Cache عمومی قرار گیرند.

اجرای Toolها

نتیجه tools/call به‌طور عمومی در فهرست Cacheable Results پروتکل قرار ندارد.

بعضی Toolها ماهیت تغییرپذیر دارند:

• ایجاد سفارش
• ارسال پیام
• ثبت پرداخت
• تغییر وضعیت کاربر
• تولید گزارش جدید
• فراخوانی مدل هوش مصنوعی
• دریافت قیمت لحظه‌ای

Cache کردن چنین عملیات‌هایی بدون طراحی دقیق می‌تواند نتیجه نادرست ایجاد کند.

تفاوت MCP Caching با Prompt Caching

MCP Caching و Prompt Caching دو لایه متفاوت‌اند.

MCP Caching

در این روش، Client پاسخ MCP Server را ذخیره می‌کند:

• فهرست Toolها
• فهرست Resourceها
• محتوای Resource
• اطلاعات Server
• فهرست Promptها

هدف اصلی کاهش دریافت دوباره اطلاعات از MCP Server است.

Prompt Caching

Prompt Caching در سطح مدل یا LLM Provider اجرا می‌شود. در این روش بخش تکراری Prompt، System Message، Tool Schema یا Context طولانی ممکن است توسط Provider دوباره پردازش نشود.

هدف اصلی کاهش Latency یا هزینه پردازش ورودی مدل است.

این دو قابلیت می‌توانند هم‌زمان استفاده شوند.

چرا ترتیب Toolها اهمیت دارد؟

در نسخه جدید MCP توصیه شده است Server فهرست Toolها را با ترتیب ثابت و Deterministic برگرداند.

فرض کنید Server در هر بار اجرای tools/list همان Toolها را با ترتیب تصادفی برگرداند:

search
summarize
translate

و در درخواست بعدی:

translate
search
summarize

از نظر منطقی مجموعه Toolها تغییری نکرده است، اما ساختار ورودی مدل متفاوت خواهد بود.

این تغییر می‌تواند باعث کاهش احتمال استفاده مجدد از Prompt Cache مدل شود.

بهتر است Toolها با یک ترتیب ثابت، مانند ترتیب نام، برگردانده شوند:

tools = sorted(
    tools,
    key=lambda item: item["name"],
)

ترتیب ثابت دو مزیت دارد:

• Cache کردن فهرست Toolها در MCP Client قابل‌اعتمادتر می‌شود.
• ساختار Tool Schema ارسالی به مدل ثابت باقی می‌ماند.

ارتباط MCP Caching با API درواره

در یک AI Agent متصل به API درواره، جریان معمول می‌تواند چنین باشد:

1. Client به MCP Server متصل می‌شود.
2. server/discover را اجرا می‌کند.
3. tools/list را دریافت می‌کند.
4. Tool Schemaها را به قالب موردنیاز مدل تبدیل می‌کند.
5. مدل را از طریق API درواره فراخوانی می‌کند.
6. مدل Tool مناسب را انتخاب می‌کند.
7. Client Tool را روی MCP Server اجرا می‌کند.
8. نتیجه Tool را برای تولید پاسخ نهایی به مدل می‌دهد.

Base URL رسمی درواره:

https://api.darvareh.ir/v1

اگر Client در هر درخواست مراحل دوم و سوم را دوباره اجرا کند، چند ارتباط غیرضروری ایجاد می‌شود.

با MCP Caching، نتیجه Discovery و Tool List تا پایان TTL در Cache باقی می‌مانند:

MCP Server
    ↓
server/discover
    ↓
Discovery Cache
    ↓
tools/list
    ↓
Tool Catalog Cache
    ↓
API درواره

این معماری زمان آماده‌سازی Agent را کاهش می‌دهد.

آیا MCP Caching مصرف Token را کاهش می‌دهد؟

Cache کردن پاسخ MCP Server به‌تنهایی لزوماً مصرف Token مدل را کاهش نمی‌دهد.

اگر Tool Schemaهای Cache‌شده همچنان در هر درخواست به مدل ارسال شوند، تعداد Tokenهای ورودی ممکن است تغییر نکند.

MCP Caching مستقیماً این موارد را کاهش می‌دهد:

• تعداد درخواست‌های MCP
• Latency دریافت Toolها
• بار MCP Server
• پردازش تکراری فهرست‌ها
• ترافیک شبکه

برای کاهش Token باید علاوه بر Cache، Toolهای مرتبط را انتخاب کنید و فقط همان‌ها را به مدل بفرستید.

این الگو با Progressive Tool Discovery ترکیب می‌شود:

1. Tool Catalog از Cache خوانده می‌شود.
2. Toolها براساس درخواست کاربر فیلتر می‌شوند.
3. فقط Toolهای مرتبط به مدل ارسال می‌شوند.
4. مدل از طریق API درواره اجرا می‌شود.

نمونه پیاده‌سازی Cache ساده در Python

ابتدا یک ساختار برای Cache Entry تعریف می‌کنیم:

from dataclasses import dataclass
from time import monotonic
from typing import Any


@dataclass
class CacheEntry:
    value: Any
    expires_at: float
    scope: str

سپس یک Cache حافظه‌ای ساده می‌سازیم:

class MCPMemoryCache:
    def __init__(self):
        self._entries: dict[str, CacheEntry] = {}

    def get(self, key: str):
        entry = self._entries.get(key)

        if entry is None:
            return None

        if monotonic() >= entry.expires_at:
            self._entries.pop(key, None)
            return None

        return entry.value

    def set(
        self,
        key: str,
        value,
        ttl_ms: int,
        scope: str,
    ):
        if ttl_ms <= 0:
            return

        self._entries[key] = CacheEntry(
            value=value,
            expires_at=monotonic() + (ttl_ms / 1000),
            scope=scope,
        )

    def invalidate(self, key: str):
        self._entries.pop(key, None)

این نمونه برای آموزش مناسب است، اما در محیط چندسروری باید درباره Cache اشتراکی، Serialization و تفکیک کاربران تصمیم‌گیری شود.

Cache کردن tools/list

تابع زیر ابتدا Cache را بررسی می‌کند و فقط در صورت نبود پاسخ Fresh به MCP Server درخواست می‌فرستد:

import hashlib
import json

cache = MCPMemoryCache()


def create_cache_key(
    method: str,
    params: dict,
    auth_context: str | None = None,
) -> str:
    payload = {
        "method": method,
        "params": params,
        "auth_context": auth_context,
    }

    serialized = json.dumps(
        payload,
        sort_keys=True,
        ensure_ascii=False,
    )

    return hashlib.sha256(
        serialized.encode("utf-8")
    ).hexdigest()

تابع دریافت Toolها:

async def get_tools(
    mcp_client,
    auth_context: str | None = None,
) -> list[dict]:
    params = {}

    cache_key = create_cache_key(
        method="tools/list",
        params=params,
        auth_context=auth_context,
    )

    cached = cache.get(cache_key)

    if cached is not None:
        return cached

    response = await mcp_client.request(
        method="tools/list",
        params=params,
    )

    result = response["result"]

    if result.get("resultType") != "complete":
        raise RuntimeError("Unexpected tools/list response")

    tools = sorted(
        result.get("tools", []),
        key=lambda item: item["name"],
    )

    cache.set(
        key=cache_key,
        value=tools,
        ttl_ms=result.get("ttlMs", 0),
        scope=result.get("cacheScope", "private"),
    )

    return tools

در پروژه واقعی، auth_context نباید Access Token خام باشد. می‌توانید از شناسه داخلی کاربر، Tenant یا Hash کنترل‌شده استفاده کنید.

استفاده از Toolهای Cache‌شده با API درواره

ابتدا Client مربوط به مدل را می‌سازیم:

import os

from openai import AsyncOpenAI

llm_client = AsyncOpenAI(
    api_key=os.environ["DARVAREH_API_KEY"],
    base_url="https://api.darvareh.ir/v1",
)

MODEL_ID = os.environ["DARVAREH_MODEL_ID"]

سپس Toolهای Cache‌شده را به ساختار سازگار با API تبدیل می‌کنیم:

def convert_mcp_tools_to_llm_tools(
    mcp_tools: list[dict],
) -> list[dict]:
    return [
        {
            "type": "function",
            "function": {
                "name": tool["name"],
                "description": tool.get(
                    "description",
                    "",
                ),
                "parameters": tool["inputSchema"],
            },
        }
        for tool in mcp_tools
    ]

فراخوانی مدل:

async def run_agent(
    user_message: str,
    mcp_client,
    auth_context: str,
):
    mcp_tools = await get_tools(
        mcp_client=mcp_client,
        auth_context=auth_context,
    )

    llm_tools = convert_mcp_tools_to_llm_tools(
        mcp_tools
    )

    response = await llm_client.chat.completions.create(
        model=MODEL_ID,
        messages=[
            {
                "role": "system",
                "content": (
                    "شما یک AI Agent هستید. "
                    "در صورت نیاز ابزار مناسب را انتخاب کنید."
                ),
            },
            {
                "role": "user",
                "content": user_message,
            },
        ],
        tools=llm_tools,
        tool_choice="auto",
    )

    return response

در این معماری، Tool Catalog فقط زمانی از MCP Server دریافت می‌شود که Cache موجود نباشد یا TTL آن منقضی شده باشد.

برای انتخاب مدل مناسب Tool Calling، Model ID فعال را از صفحه مدل‌های درواره بررسی کنید.

Cache در معماری چندسروری

Cache حافظه‌ای برای یک Process کافی است، اما در معماری چند Instance محدودیت دارد.

فرض کنید سه نسخه از Agent Runtime اجرا شده‌اند:

Agent Instance 1
Agent Instance 2
Agent Instance 3

اگر هر Instance Cache مستقل داشته باشد، هرکدام جداگانه tools/list را دریافت می‌کنند.

برای Cache عمومی می‌توان از یک Cache مشترک استفاده کرد:

• Redis
• Database
• Distributed Cache
• Cache داخلی API Gateway

معماری نمونه:

Agent Runtimeها
       ↓
Shared Cache
       ↓
MCP Serverها
       ↓
API درواره

Cache مشترک برای فهرست‌های عمومی مفید است. برای داده خصوصی باید Namespace و Authorization Context با دقت تفکیک شوند.

Invalidation با Notification

TTL تنها راه تشخیص تغییر داده نیست.

MCP Server می‌تواند اعلام کند فهرست Toolها تغییر کرده است:

{
  "jsonrpc": "2.0",
  "method": "notifications/tools/list_changed"
}

Clientی که جریان subscriptions/listen را برای این Notification باز کرده است، پس از دریافت پیام باید Cache مربوط به tools/list را Stale در نظر بگیرد.

حتی اگر TTL هنوز تمام نشده باشد، Notification بر تازگی Cache اولویت دارد.

جریان کار:

1. Client فهرست Toolها را Cache می‌کند.
2. Server یک Tool جدید اضافه می‌کند.
3. Server Notification تغییر فهرست را ارسال می‌کند.
4. Client Cache را Invalidate می‌کند.
5. در استفاده بعدی، tools/list دوباره فراخوانی می‌شود.

TTL و Notification مکمل یکدیگرند:

• TTL از ماندگاری طولانی داده قدیمی جلوگیری می‌کند.
• Notification تغییر را سریع‌تر به Client اعلام می‌کند.

اگر Notification پشتیبانی نشود چه کنیم؟

Server مجبور نیست برای هر تغییر Notification ارسال کند.

اگر قابلیت listChanged فعال نباشد، Client فقط به TTL متکی خواهد بود:

{
  "capabilities": {
    "tools": {
      "listChanged": false
    }
  }
}

در این شرایط TTL باید متناسب با نرخ تغییر Toolها انتخاب شود.

برای یک Server با Toolهای ثابت، TTL طولانی مناسب است. برای Serverی که Toolهای آن مرتب تغییر می‌کنند، TTL کوتاه‌تر انتخاب بهتری است.

Cache و Pagination

فهرست Toolها، Promptها یا Resourceها ممکن است Paginated باشد.

هر صفحه Cache Entry مستقل دارد:

{
  "method": "resources/list",
  "params": {
    "cursor": "page-2"
  }
}

هر صفحه می‌تواند ttlMs متفاوتی داشته باشد، اما Scope تمام صفحات همان فهرست باید یکسان باشد.

اگر Cursor قدیمی نامعتبر شود، Client بهتر است تمام صفحات مربوط به آن فهرست را حذف و دریافت را از صفحه اول آغاز کند.

اگر سازگاری کامل میان صفحات اهمیت دارد، Client باید کل فهرست را دوباره از ابتدا دریافت کند؛ زیرا داده ممکن است میان دریافت دو صفحه تغییر کند.

انتخاب TTL مناسب

TTL به نوع داده و نرخ تغییر آن بستگی دارد.

این مقادیر قانون ثابت نیستند. TTL باید براساس رفتار واقعی محصول تنظیم شود.

TTL بسیار کوتاه، مزیت Cache را کاهش می‌دهد. TTL بسیار طولانی نیز احتمال استفاده از اطلاعات قدیمی را افزایش می‌دهد.

آیا باید Cache را در شروع برنامه پر کنیم؟

معمولاً نیازی نیست تمام Cacheها هنگام Startup پر شوند.

روش Lazy Loading ساده‌تر است:

1. Agent به داده نیاز پیدا می‌کند.
2. Cache بررسی می‌شود.
3. اگر داده موجود نبود، Server فراخوانی می‌شود.
4. نتیجه در Cache قرار می‌گیرد.

Warm-up زمانی مفید است که:

• تعداد Serverها محدود و مشخص باشد.
• اولین درخواست نباید Latency زیادی داشته باشد.
• Tool Catalog کوچک باشد.
• زیرساخت بعد از Deployment نیاز به آماده‌سازی اولیه داشته باشد.

برای صدها MCP Server، Warm-up کامل ممکن است درخواست‌های غیرضروری زیادی ایجاد کند.

خطاهای متداول در MCP Caching

Cache کردن تمام پاسخ‌ها

فقط عملیات مشخص‌شده یا داده‌هایی که در Application به‌درستی تحلیل شده‌اند باید Cache شوند.

نادیده‌گرفتن cacheScope

پاسخ خصوصی نباید میان کاربران مختلف به اشتراک گذاشته شود.

استفاده از Access Token به‌عنوان Cache Key قابل‌مشاهده

Token خام نباید داخل Log، Redis Key یا ابزارهای مانیتورینگ قرار گیرد.

Cache کردن input_required

پاسخ‌های موقت MRTR به Workflow مشخصی وابسته‌اند و قابل Cache نیستند.

نادیده‌گرفتن Notification تغییر

دریافت notifications/tools/list_changed باید Cache مرتبط را باطل کند.

ترتیب تصادفی Toolها

ترتیب ناپایدار Toolها می‌تواند Prompt Cache مدل را کم‌اثر کند.

ارسال تمام Toolهای Cache‌شده به مدل

Cache شدن Toolها به این معنی نیست که تمام آن‌ها باید وارد Context مدل شوند.

استفاده از TTL ثابت برای همه داده‌ها

Resource عمومی ثابت و فهرست پروژه‌های کاربر نرخ تغییر یکسانی ندارند.

Cache کردن خروجی مدل بدون توجه به ورودی

پاسخ مدل هوش مصنوعی به Prompt، Model ID، پارامترها و Context وابسته است. MCP Caching به‌صورت خودکار این پاسخ‌ها را مدیریت نمی‌کند.

معماری پیشنهادی برای AI Agent

یک معماری Production می‌تواند چهار لایه Cache متفاوت داشته باشد:

MCP Metadata Cache

برای ذخیره:

• server/discover
• tools/list
• prompts/list
• resources/list

Resource Cache

برای ذخیره محتوای Resourceها براساس URI و Authorization Context.

Application Cache

برای نتیجه عملیات قابل‌تکرار و بدون Side Effect که برنامه به‌صورت جداگانه مدیریت می‌کند.

Provider Prompt Cache

قابلیتی که ممکن است مدل یا Provider برای بخش تکراری Context ارائه کند.

این لایه‌ها باید مستقل طراحی شوند. یک Cache عمومی برای تمام انواع داده معمولاً کنترل کافی ایجاد نمی‌کند.

چک‌لیست پیاده‌سازی MCP Caching

پیش از استقرار Cache این موارد را بررسی کنید:

• فقط عملیات مناسب Cache شوند.
• نتیجه دارای resultType: complete باشد.
• ttlMs منفی پذیرفته نشود.
• مقدار صفر به معنی Stale فوری در نظر گرفته شود.
• نبود TTL مانند مقدار صفر مدیریت شود.
• cacheScope عمومی و خصوصی تفکیک شود.
• Authorization Context بخشی از Cache خصوصی باشد.
• Access Token خام در Cache Key قرار نگیرد.
• متد و پارامترها در Cache Key لحاظ شوند.
• Cursor در Cache صفحات Paginated لحاظ شود.
• Notificationهای تغییر باعث Invalidation شوند.
• پاسخ‌های input_required Cache نشوند.
• درخواست‌های MRTR Cache نشوند.
• Toolها با ترتیب ثابت برگردانده شوند.
• Toolهای مرتبط قبل از ارسال به مدل فیلتر شوند.
• رفتار Cache هنگام قطعی MCP Server مشخص باشد.
• نرخ Cache Hit و Cache Miss ثبت شود.
• امکان پاک‌کردن Cache پس از Deployment وجود داشته باشد.

جمع‌بندی

MCP Caching در نسخه 2026-07-28 روشی استاندارد برای کاهش دریافت تکراری اطلاعات از MCP Server است.

Server با دو فیلد اصلی رفتار Cache را مشخص می‌کند:

• ttlMs برای مدت تازگی پاسخ
• cacheScope برای تعیین عمومی یا خصوصی بودن Cache

عملیات استاندارد قابل Cache شامل این موارد هستند:

• server/discover
• tools/list
• prompts/list
• resources/list
• resources/templates/list
• resources/read

پاسخ‌های input_required و درخواست‌های وابسته به MRTR نباید Cache شوند.

در یک AI Agent متصل به API درواره، MCP Caching می‌تواند فهرست Serverها، Toolها و Resourceها را سریع‌تر در اختیار Agent قرار دهد. سپس Progressive Tool Discovery مشخص می‌کند کدام Toolها واقعاً باید به مدل ارسال شوند.

این ترکیب باعث می‌شود:

• درخواست‌های MCP کمتری ارسال شود.
• Latency آماده‌سازی Agent کاهش پیدا کند.
• بار MCP Server کمتر شود.
• فهرست Toolها پایدارتر باشد.
• استفاده از Prompt Cache مدل‌ها امکان بیشتری پیدا کند.
• Agent در معماری چندسروری مقیاس‌پذیرتر شود.

برای ساخت Agent و استفاده از مدل‌های دارای Tool Calling، در درواره حساب بسازید و مدل مناسب را از صفحه مدل‌ها انتخاب کنید.

پرسش‌های متداول

MCP Caching چیست؟

روشی استاندارد برای ذخیره موقت بعضی پاسخ‌های MCP Server مانند فهرست Toolها، Promptها، Resourceها و اطلاعات Discovery است.

ttlMs چیست؟

مدت زمانی برحسب میلی‌ثانیه است که Client می‌تواند پاسخ را Fresh در نظر بگیرد.

cacheScope عمومی چیست؟

یعنی پاسخ اختصاصی یک کاربر نیست و می‌تواند میان Clientها یا کاربران مختلف به اشتراک گذاشته شود.

cacheScope خصوصی چیست؟

یعنی پاسخ به Authorization Context مشخصی وابسته است و نباید میان کاربران مختلف مشترک باشد.

آیا نتیجه tools/call قابل Cache است؟

tools/call در فهرست استاندارد Cacheable Results نسخه جدید MCP قرار ندارد. Cache کردن نتیجه Tool باید در سطح Application و براساس رفتار همان Tool طراحی شود.

آیا پاسخ input_required قابل Cache است؟

خیر. این پاسخ به مرحله خاصی از MRTR وابسته است و نباید Cache شود.

تفاوت MCP Caching و Prompt Caching چیست؟

MCP Caching پاسخ‌های MCP Server را ذخیره می‌کند. Prompt Caching پردازش بخش‌های تکراری ورودی مدل را در سطح LLM Provider بهینه می‌کند.

آیا MCP Caching مصرف Token را کاهش می‌دهد؟

به‌تنهایی لزوماً خیر. برای کاهش Token باید فقط Toolهای مرتبط را از Cache انتخاب و به مدل ارسال کنید.

Notification چه اثری روی Cache دارد؟

Notification مرتبط با تغییر فهرست، Cache موجود را حتی پیش از پایان TTL باطل می‌کند.

آیا MCP Caching با API درواره کار می‌کند؟

بله. MCP Caching در لایه ابزارهای Agent اجرا می‌شود و API درواره مدل هوش مصنوعی را فراهم می‌کند. این دو لایه می‌توانند در یک Agent واحد استفاده شوند.

مقالات مرتبط

• Progressive Tool Discovery چیست؟ مدیریت صدها ابزار در AI Agent
• MCP چیست؟ راهنمای جامع Model Context Protocol
• MCP Elicitation چیست؟ دریافت ورودی کاربر در AI Agent
• Tool Calling چیست؟ راهنمای جامع فراخوانی ابزار
• چگونه هزینه API هوش مصنوعی را کاهش دهیم؟
• PydanticAI چیست؟ آموزش ساخت AI Agent با پایتون و API درواره

منابع اصلی

• مستندات رسمی Caching در MCP
• مستندات MCP Tools
• مستندات MCP Resources
• مستندات MCP Server Discovery
• تغییرات نسخه ۲۰۲۶-۰۷-۲۸ پروتکل MCP

این مقاله صرفاً با هدف آموزش و اطلاع‌رسانی تهیه شده است. پیش از استفاده عملی، مستندات رسمی سرویس‌ها و صفحه سلب مسئولیت را مطالعه کنید.