91欧美超碰AV自拍|国产成年人性爱视频免费看|亚洲 日韩 欧美一厂二区入|人人看人人爽人人操aV|丝袜美腿视频一区二区在线看|人人操人人爽人人爱|婷婷五月天超碰|97色色欧美亚州A√|另类A√无码精品一级av|欧美特级日韩特级

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評(píng)論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫(xiě)文章/發(fā)帖/加入社區(qū)
會(huì)員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識(shí)你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

最新MCP規(guī)范解讀,看這篇就夠了!

京東云 ? 來(lái)源:jf_75140285 ? 作者:jf_75140285 ? 2025-11-12 16:29 ? 次閱讀
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

一、MCP是什么? 為什么需要它?

wKgZPGkURWSAdlrEAAVtxuUlu2Q559.png


想象一下,你正在開(kāi)發(fā)一個(gè) AI 編程助手,它需要:

讀取和修改項(xiàng)目文件

查詢數(shù)據(jù)庫(kù)Schema

搜索代碼倉(cāng)庫(kù)

執(zhí)行Git操作

傳統(tǒng)做法是為每個(gè)數(shù)據(jù)源寫(xiě)一套專(zhuān)用代碼,不同團(tuán)隊(duì)重復(fù)造輪子。Model Context Protocol(MCP) 就是為了解決這個(gè)問(wèn)題而生的開(kāi)放標(biāo)準(zhǔn)協(xié)議。

通俗理解: MCP就像是「AI應(yīng)用的USB接口標(biāo)準(zhǔn)」。就像USB讓不同設(shè)備都能接入電腦一樣,MCP讓不同的數(shù)據(jù)源和工具都能以統(tǒng)一方式接入AI應(yīng)用。

實(shí)際案例: 在Claude Desktop中,你可以配置多個(gè)官方MCP服務(wù)器:

Filesystem服務(wù)器: 安全地讀寫(xiě)本地文件,有權(quán)限控制

SQLite服務(wù)器: 查詢和分析SQLite數(shù)據(jù)庫(kù),自動(dòng)生成SQL

GitHub服務(wù)器: 搜索倉(cāng)庫(kù)、創(chuàng)建Issue、管理PR

你的AI應(yīng)用只需實(shí)現(xiàn)一個(gè)MCP客戶端,就能連接所有服務(wù)器,無(wú)需為每個(gè)服務(wù)器寫(xiě)專(zhuān)用代碼。

二、架構(gòu)設(shè)計(jì): 三個(gè)角色的分工

MCP采用宿主-客戶端-服務(wù)器三層架構(gòu),就像一家公司的組織結(jié)構(gòu):

宿主(Host) = 總經(jīng)理

管理所有客戶端

控制安全策略和權(quán)限

負(fù)責(zé)AI模型的調(diào)用

客戶端(Client) = 部門(mén)經(jīng)理

客戶端負(fù)責(zé)連接服務(wù)器

負(fù)責(zé)雙方的溝通協(xié)調(diào)

轉(zhuǎn)發(fā)消息和通知

服務(wù)器(Server) = 業(yè)務(wù)專(zhuān)員

提供具體功能(資源、工具、提示模板)

可以是本地程序或遠(yuǎn)程服務(wù)

不知道其他服務(wù)器的存在

三、協(xié)議約定:統(tǒng)一規(guī)范與個(gè)性化擴(kuò)展

每個(gè)MCP服務(wù)器提供的工具、資源都不一樣,但它們都遵循相同的MCP協(xié)議規(guī)范。

3.1 協(xié)議的分層設(shè)計(jì)

MCP采用 基礎(chǔ)協(xié)議 + 功能擴(kuò)展 的設(shè)計(jì),就像HTTP協(xié)議一樣:

核心層(所有實(shí)現(xiàn)必須支持):

JSON-RPC 2.0消息格式

初始化握手流程(initialize/initialized)

基本錯(cuò)誤處理

功能層(按需選擇):

Resources、Prompts、Tools(服務(wù)器端)

Roots、Sampling、Elicitation(客戶端)

這樣設(shè)計(jì)的好處:

統(tǒng)一的基礎(chǔ)協(xié)議 → 保證互操作性
     +
靈活的功能選擇 → 滿足不同場(chǎng)景需求
     ↓
既標(biāo)準(zhǔn)化又可擴(kuò)展

3.2 協(xié)議約定的過(guò)程

步驟1: 基礎(chǔ)協(xié)議是固定的
所有MCP服務(wù)器和客戶端都遵循相同的JSON-RPC 2.0格式:

// 請(qǐng)求格式(固定)
{
  "jsonrpc": "2.0",      // 必須是2.0
  "id": 1,                // 唯一標(biāo)識(shí)
  "method": "方法名",     // 要調(diào)用的方法
  "params": {...}         // 參數(shù)對(duì)象
}

// 響應(yīng)格式(固定)
{
  "jsonrpc": "2.0",
  "id": 1,                // 對(duì)應(yīng)請(qǐng)求的ID
  "result": {...}         // 成功結(jié)果
  // 或 "error": {...}    // 錯(cuò)誤信息
}

步驟2: 能力在初始化時(shí)協(xié)商

// 客戶端發(fā)起初始化
{
  "method": "initialize",
  "params": {
    "protocolVersion": "2024-11-05",
    "capabilities": {
      "sampling": {},       // 我支持LLM采樣
      "roots": {}           // 我支持根目錄
    },
    "clientInfo": {"name": "MyClient", "version": "1.0"}
  }
}

// 服務(wù)器響應(yīng)
{
  "result": {
    "protocolVersion": "2024-11-05",
    "capabilities": {
      "tools": {},          // 我提供工具
      "resources": {}       // 我提供資源
    },
    "serverInfo": {"name": "SQLiteServer", "version": "2.0"}
  }
}

協(xié)商完成后,雙方都知道對(duì)方支持什么功能,只使用交集部分。

步驟3: 方法名稱(chēng)是標(biāo)準(zhǔn)化的
MCP規(guī)范定義了標(biāo)準(zhǔn)方法名:

功能 方法名 說(shuō)明
列出資源 resources/list 固定方法名
讀取資源 resources/read 固定方法名
列出工具 tools/list 固定方法名
調(diào)用工具 tools/call 固定方法名
列出提示 prompts/list 固定方法名
獲取提示 prompts/get 固定方法名

步驟4: 具體內(nèi)容是個(gè)性化的
雖然方法名固定,但每個(gè)服務(wù)器返回的具體數(shù)據(jù)不同:

// SQLite服務(wù)器的工具
{
  "tools": [
    {"name": "query", "description": "執(zhí)行SQL查詢"},
    {"name": "list_tables", "description": "列出所有表"}
  ]
}

// Filesystem服務(wù)器的工具
{
  "tools": [
    {"name": "read_file", "description": "讀取文件"},
    {"name": "write_file", "description": "寫(xiě)入文件"},
    {"name": "search_files", "description": "搜索文件"}
  ]
}

3.3 協(xié)議發(fā)現(xiàn)機(jī)制

客戶端如何知道服務(wù)器有哪些工具?

第一步:列舉

客戶端 → 服務(wù)器: {"method": "tools/list"}
服務(wù)器 → 客戶端: {
  "tools": [
    {
      "name": "query",
      "description": "執(zhí)行SQL查詢",
      "inputSchema": {           // JSON Schema定義輸入格式
        "type": "object",
        "properties": {
          "sql": {"type": "string"}
        }
      }
    }
  ]
}

第二步:調(diào)用

客戶端 → 服務(wù)器: {
  "method": "tools/call",
  "params": {
    "name": "query",           // 使用第一步獲得的工具名
    "arguments": {"sql": "SELECT * FROM users"}
  }
}

關(guān)鍵點(diǎn):通過(guò)JSON Schema,客戶端知道如何正確調(diào)用工具,無(wú)需硬編碼。

四、協(xié)議基礎(chǔ):如何通信?

MCP基于JSON-RPC 2.0構(gòu)建,這是一個(gè)成熟的遠(yuǎn)程過(guò)程調(diào)用協(xié)議。理解這一層對(duì)掌握MCP至關(guān)重要。

4.1 JSON-RPC 2.0基礎(chǔ)

消息類(lèi)型

MCP中有三種基本消息類(lèi)型。
1. 請(qǐng)求(Request) - 期待響應(yīng)

{
  "jsonrpc": "2.0",           // 協(xié)議版本,必須是"2.0"
  "id": 1,                     // 請(qǐng)求唯一標(biāo)識(shí)(字符串或數(shù)字)
  "method": "tools/list",     // 要調(diào)用的方法名
  "params": {                  // 可選的參數(shù)對(duì)象
    "cursor": "page2"
  }
}

2. 響應(yīng)(Response) - 對(duì)請(qǐng)求的回復(fù)

// 成功響應(yīng)
{
  "jsonrpc": "2.0",
  "id": 1,                     // 必須與請(qǐng)求的id相同
  "result": {                  // 成功結(jié)果
    "tools": [
      {"name": "query", "description": "執(zhí)行查詢"}
    ]
  }
}

// 錯(cuò)誤響應(yīng)
{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {                   // 錯(cuò)誤對(duì)象
    "code": -32602,            // 錯(cuò)誤碼(整數(shù))
    "message": "參數(shù)無(wú)效",      // 錯(cuò)誤描述
    "data": {                  // 可選的額外信息
      "field": "cursor",
      "reason": "格式錯(cuò)誤"
    }
  }
}

3. 通知(Notification) - 單向消息,無(wú)需響應(yīng)

{
  "jsonrpc": "2.0",
  "method": "notifications/resources/updated",  // 通知方法名
  "params": {                                   // 通知參數(shù)
    "uri": "file:///project/data.json"
  }
  // 注意:沒(méi)有id字段
}

標(biāo)準(zhǔn)錯(cuò)誤碼

MCP使用JSON-RPC 2.0的標(biāo)準(zhǔn)錯(cuò)誤碼:

錯(cuò)誤碼 含義 說(shuō)明
-32700 Parse error JSON解析錯(cuò)誤
-32600 Invalid Request 無(wú)效的請(qǐng)求格式
-32601 Method not found 方法不存在
-32602 Invalid params 參數(shù)無(wú)效
-32603 Internal error 服務(wù)器內(nèi)部錯(cuò)誤
-32002 Resource not found 資源未找到(MCP擴(kuò)展)

4.2 能力協(xié)商詳解

能力協(xié)商是MCP連接建立的第一步,決定了整個(gè)會(huì)話中可用的功能。

初始化流程詳解

階段1: 客戶端發(fā)起初始化

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2024-11-05",  // 客戶端支持的協(xié)議版本
    "capabilities": {                  // 客戶端能力聲明
      "roots": {                       // 支持根目錄
        "listChanged": true            // 支持根目錄變更通知
      },
      "sampling": {},                  // 支持LLM采樣
      "elicitation": {},               // 支持用戶詢問(wèn)
      "experimental": {                // 實(shí)驗(yàn)性功能
        "customFeature": {}            // 自定義功能
      }
    },
    "clientInfo": {                    // 客戶端信息
      "name": "MyAIApp",               // 程序名(必填)
      "version": "1.2.0",              // 版本號(hào)(必填)
      "title": "我的AI應(yīng)用"             // 顯示名稱(chēng)(可選)
    }
  }
}

階段2: 服務(wù)器響應(yīng)能力

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2024-11-05",  // 服務(wù)器選擇的協(xié)議版本
    "capabilities": {                  // 服務(wù)器能力聲明
      "resources": {                   // 支持資源
        "subscribe": true,             // 支持資源訂閱
        "listChanged": true            // 支持資源列表變更通知
      },
      "tools": {                       // 支持工具
        "listChanged": true
      },
      "prompts": {                     // 支持提示模板
        "listChanged": false           // 不支持列表變更通知
      },
      "logging": {}                    // 支持日志輸出
    },
    "serverInfo": {                    // 服務(wù)器信息
      "name": "sqlite-mcp-server",
      "version": "2.1.0",
      "title": "SQLite MCP服務(wù)器"
    },
    "instructions": "此服務(wù)器提供SQLite數(shù)據(jù)庫(kù)訪問(wèn)能力"  // 可選的使用說(shuō)明
  }
}

階段3: 客戶端確認(rèn)就緒

{
  "jsonrpc": "2.0",
  "method": "notifications/initialized"  // 無(wú)id,這是通知
}

協(xié)議版本協(xié)商規(guī)則

客戶端請(qǐng)求版本: "2024-11-05"
         ↓
    服務(wù)器支持?
    ↙        ↘
  支持        不支持
   ↓            ↓
返回相同版本  返回服務(wù)器支持的最新版本
   ↓            ↓
協(xié)商成功    客戶端檢查是否支持
              ↙        ↘
           支持        不支持
            ↓            ↓
         協(xié)商成功     斷開(kāi)連接

實(shí)際示例:

// 場(chǎng)景1: 版本匹配
客戶端: "protocolVersion": "2024-11-05"
服務(wù)器: "protocolVersion": "2024-11-05"  ? 成功

// 場(chǎng)景2: 服務(wù)器版本更新
客戶端: "protocolVersion": "2024-06-01"
服務(wù)器: "protocolVersion": "2024-11-05"  
→ 客戶端檢查是否支持2024-11-05 → 如果不支持則斷開(kāi)

// 場(chǎng)景3: 客戶端版本更新
客戶端: "protocolVersion": "2025-01-01"
服務(wù)器: "protocolVersion": "2024-11-05"  
→ 客戶端檢查是否支持2024-11-05 → 如果支持則降級(jí)使用

能力交集計(jì)算

初始化后,雙方只能使用共同支持的能力:

客戶端能力: {roots, sampling, elicitation}
服務(wù)器能力: {resources, tools, prompts}
         ↓
   可用功能集合
   ├─ 客戶端 → 服務(wù)器: resources, tools, prompts
   └─ 服務(wù)器 → 客戶端: roots, sampling, elicitation

示例:

# 客戶端代碼示例
if server_capabilities.get("tools"):
    # 服務(wù)器支持工具,可以調(diào)用
    tools = await session.list_tools()
else:
    # 服務(wù)器不支持工具,跳過(guò)
    print("服務(wù)器不提供工具功能")

if client_capabilities.get("sampling"):
    # 客戶端支持采樣,服務(wù)器可以請(qǐng)求
    # (服務(wù)器端會(huì)檢查這個(gè)能力)
    pass

4.3 連接生命周期深入

完整的消息時(shí)序圖

客戶端                                            服務(wù)器
  │                                              │
  │  1. initialize (請(qǐng)求)                         │
  ├──────────────────────────────────────>│
  │     {protocolVersion, capabilities}          │
  │                                              │
  │  2. initialize (響應(yīng))                         │
  ││
  │                                              │
  │═══════════ 正常操作階段 ════════════        │
  │                                              │
  │  4. tools/list (請(qǐng)求)                         │
  ├──────────────────────────────────────>│
  │                                              │
  │  5. tools/list (響應(yīng))                         │
  ││
  │     {name: "query", arguments: {...}}        │
  │                                              │
  │  7. notifications/progress (通知)             │
  │

初始化前的限制

在initialized通知發(fā)送前:

客戶端只能發(fā)送:

? initialize請(qǐng)求

? ping請(qǐng)求(用于?;?

? 其他任何請(qǐng)求

服務(wù)器只能發(fā)送:

? initialize響應(yīng)

? ping請(qǐng)求

? logging通知(日志)

? 其他任何消息

違反限制的后果:

// 客戶端在初始化前調(diào)用tools/list
請(qǐng)求: {"method": "tools/list"}
響應(yīng): {
  "error": {
    "code": -32600,
    "message": "會(huì)話未初始化"
  }
}

超時(shí)和重試機(jī)制

請(qǐng)求超時(shí):

import asyncio

# 設(shè)置30秒超時(shí)
try:
    result = await asyncio.wait_for(
        session.call_tool("slow_operation", {}),
        timeout=30.0
    )
except asyncio.TimeoutError:
    # 發(fā)送取消通知
    await session.send_notification(
        "notifications/cancelled",
        {"requestId": "123", "reason": "超時(shí)"}
    )

進(jìn)度通知重置超時(shí):

# 當(dāng)收到進(jìn)度通知時(shí),可以重置超時(shí)計(jì)時(shí)器
timeout = 30  # 基礎(chǔ)超時(shí)
max_timeout = 300  # 最大超時(shí)(5分鐘)

while True:
    try:
        msg = await wait_for_message(timeout)
        if msg.method == "notifications/progress":
            # 收到進(jìn)度,重置超時(shí)
            timeout = 30
    except TimeoutError:
        # 超時(shí)處理
        break

4.4 傳輸方式對(duì)比

stdio傳輸詳解

優(yōu)點(diǎn):

? 簡(jiǎn)單直接,適合本地開(kāi)發(fā)

? 進(jìn)程隔離,安全性好

? 自動(dòng)管理生命周期

? 無(wú)需網(wǎng)絡(luò)配置

缺點(diǎn):

? 只能本地使用

? 不支持多客戶端

? 調(diào)試相對(duì)困難

消息格式:

消息1n
消息2n
消息3n

每個(gè)JSON對(duì)象占一行,以n分隔。

HTTP傳輸詳解

架構(gòu):

┌─────────┐         HTTP POST         ┌─────────┐
│         ├──────────────────────────>│         │
│ 客戶端  │  請(qǐng)求/通知/響應(yīng)(JSON-RPC) │ 服務(wù)器  │
│         │

發(fā)送消息(POST):

POST /mcp HTTP/1.1
Host: localhost:8080
Content-Type: application/json
Accept: application/json, text/event-stream
Mcp-Session-Id: abc123

{"jsonrpc":"2.0","id":1,"method":"tools/list"}

立即響應(yīng)(JSON):

HTTP/1.1 200 OK
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"result":{"tools":[...]}}

流式響應(yīng)(SSE):

HTTP/1.1 200 OK
Content-Type: text/event-stream
Mcp-Session-Id: abc123

id: 1
data: {"jsonrpc":"2.0","method":"notifications/progress","params":{"progress":25}}

id: 2  
data: {"jsonrpc":"2.0","method":"notifications/progress","params":{"progress":50}}

id: 3
data: {"jsonrpc":"2.0","id":1,"result":{"content":[...]}}

接收服務(wù)器消息(GET):

GET /mcp HTTP/1.1
Host: localhost:8080
Accept: text/event-stream
Mcp-Session-Id: abc123
Last-Event-ID: 42

會(huì)話管理:

# 服務(wù)器端設(shè)置會(huì)話ID
@app.post("/mcp")
async def handle_mcp(request):
    if request.method == "initialize":
        session_id = generate_session_id()
        return Response(
            content=json.dumps(result),
            headers={"Mcp-Session-Id": session_id}
        )

# 客戶端后續(xù)請(qǐng)求攜帶會(huì)話ID
@client.request
async def send_request(method, params):
    headers = {}
    if self.session_id:
        headers["Mcp-Session-Id"] = self.session_id
    
    return await http.post(
        "/mcp",
        json={"jsonrpc": "2.0", "method": method, "params": params},
        headers=headers
    )

斷線重連:

async def connect_sse(last_event_id=None):
    headers = {"Accept": "text/event-stream"}
    if last_event_id:
        headers["Last-Event-ID"] = last_event_id
    
    async with httpx.stream("GET", "/mcp", headers=headers) as stream:
        async for line in stream.aiter_lines():
            if line.startswith("id:"):
                last_event_id = line[3:].strip()
            elif line.startswith("data:"):
                data = json.loads(line[5:])
                yield data, last_event_id

4.5 實(shí)際通信示例

讓我們看一個(gè)完整的SQLite查詢場(chǎng)景:

// 1. 列出工具
客戶端 → 服務(wù)器:
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list"
}

服務(wù)器 → 客戶端:
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "query",
        "description": "執(zhí)行SQL查詢",
        "inputSchema": {
          "type": "object",
          "properties": {
            "sql": {"type": "string"}
          },
          "required": ["sql"]
        }
      }
    ]
  }
}

// 2. 調(diào)用查詢工具
客戶端 → 服務(wù)器:
{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "query",
    "arguments": {
      "sql": "SELECT COUNT(*) FROM users WHERE active = 1"
    },
    "_meta": {
      "progressToken": "query-123"  // 請(qǐng)求進(jìn)度通知
    }
  }
}

// 3. 服務(wù)器發(fā)送進(jìn)度(異步通知)
服務(wù)器 → 客戶端:
{
  "jsonrpc": "2.0",
  "method": "notifications/progress",
  "params": {
    "progressToken": "query-123",
    "progress": 50,
    "total": 100,
    "message": "正在掃描users表..."
  }
}

// 4. 返回查詢結(jié)果
服務(wù)器 → 客戶端:
{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "查詢結(jié)果: 1,234個(gè)活躍用戶"
      }
    ],
    "isError": false
  }
}

// 5. 如果查詢出錯(cuò)
服務(wù)器 → 客戶端(錯(cuò)誤情況):
{
  "jsonrpc": "2.0",
  "id": 2,
  "error": {
    "code": -32603,
    "message": "SQL語(yǔ)法錯(cuò)誤",
    "data": {
      "sql": "SELECT COUNT(*) FROM users WHERE active = 1",
      "error": "near "WHERE": syntax error",
      "position": 35
    }
  }
}

這就是MCP通信的完整過(guò)程!通過(guò)JSON-RPC 2.0,客戶端和服務(wù)器可以進(jìn)行結(jié)構(gòu)化、類(lèi)型安全的通信。

五、服務(wù)器能力:三種核心功能

MCP服務(wù)器可以提供三種功能。

5.1 Resources(資源):應(yīng)用決定用什么

資源就是數(shù)據(jù),比如文件內(nèi)容、數(shù)據(jù)庫(kù)記錄、API響應(yīng)。

誰(shuí)控制: 應(yīng)用程序決定把哪些資源提供給AI

如何使用:

// 列出所有可用資源
{"method": "resources/list"}

// 讀取某個(gè)資源
{
  "method": "resources/read",
  "params": {"uri": "file:///project/main.py"}
}

資源URI示例:

file:///project/src/main.py - 文件

db://schema/users - 數(shù)據(jù)庫(kù)表結(jié)構(gòu)

git://commits/main - Git提交歷史

https://api.example.com/data - Web API

訂閱變更: 可以訂閱資源,當(dāng)它變化時(shí)自動(dòng)收到通知。

實(shí)際案例: Filesystem服務(wù)器暴露資源

{
  "uri": "file:///Users/alice/project/src/main.py",  // Python源文件
  "name": "main.py",                                  // 文件名
  "mimeType": "text/x-python",                        // 文件類(lèi)型
  "text": "import osndef main()..."                  // 文件內(nèi)容
}

客戶端AI可以讀取這個(gè)資源,理解代碼結(jié)構(gòu)后提供重構(gòu)建議或生成測(cè)試。

5.2 Prompts(提示模板):用戶選擇用什么

什么是Prompt?

Prompt就像是「對(duì)話模板」或「快捷指令」,把常用的復(fù)雜指令預(yù)設(shè)好,用戶一鍵調(diào)用。用生活中的例子類(lèi)比,就像微信的「快捷回復(fù)」或IDE中的「代碼片段(Snippet)」。

為什么需要Prompt?
場(chǎng)景1:沒(méi)有Prompt時(shí)

用戶每次都要輸入:
"請(qǐng)分析這個(gè)Git倉(cāng)庫(kù)最近一周的提交,統(tǒng)計(jì):
1. 總提交次數(shù)
2. 每個(gè)作者的貢獻(xiàn)
3. 修改的主要文件
4. 是否有破壞性變更
請(qǐng)用表格格式輸出"

場(chǎng)景2:有Prompt后

用戶只需:
1. 點(diǎn)擊 "/analyze-commits" 命令
2. 選擇分支 "main"
3. AI自動(dòng)執(zhí)行完整分析

Prompt的數(shù)據(jù)結(jié)構(gòu)

定義一個(gè)Prompt:

{
  "name": "analyze_commits",              // Prompt的唯一標(biāo)識(shí)
  "title": "提交歷史分析",                  // 用戶界面顯示的名稱(chēng)
  "description": "分析Git提交并生成報(bào)告",    // 功能說(shuō)明
  "arguments": [                          // 需要的參數(shù)列表
    {
      "name": "branch",                   // 參數(shù)名
      "description": "要分析的分支名",      // 參數(shù)說(shuō)明
      "required": true                    // 是否必填
    },
    {
      "name": "since",                    // 時(shí)間范圍
      "description": "起始日期(如:7 days ago)",
      "required": false                   // 可選參數(shù)
    },
    {
      "name": "author",                   // 作者過(guò)濾
      "description": "只看某個(gè)作者的提交",
      "required": false
    }
  ]
}

實(shí)際使用示例

步驟1: 列出所有可用的Prompt

// 客戶端請(qǐng)求
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "prompts/list"
}

// 服務(wù)器響應(yīng)
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "prompts": [
      {
        "name": "analyze_commits",
        "title": "


審核編輯 黃宇

聲明:本文內(nèi)容及配圖由入駐作者撰寫(xiě)或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場(chǎng)。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問(wèn)題,請(qǐng)聯(lián)系本站處理。 舉報(bào)投訴
  • MCP
    MCP
    +關(guān)注

    關(guān)注

    0

    文章

    289

    瀏覽量

    15007
收藏 人收藏
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

    評(píng)論

    相關(guān)推薦
    熱點(diǎn)推薦

    深入剖析MCP1826/MCP1826S:高性能LDO調(diào)節(jié)器的卓越之選

    深入剖析MCP1826/MCP1826S:高性能LDO調(diào)節(jié)器的卓越之選 在電子工程師的日常工作中,電源管理是一個(gè)至關(guān)重要的環(huán)節(jié),而低壓差線性穩(wěn)壓器(LDO)作為其中的關(guān)鍵組件,其性能直接影響著整個(gè)
    的頭像 發(fā)表于 03-03 16:50 ?455次閱讀

    深入剖析MCP1825/MCP1825S:500 mA低功耗LDO穩(wěn)壓器的卓越之選

    深入剖析MCP1825/MCP1825S:500 mA低功耗LDO穩(wěn)壓器的卓越之選 在電子設(shè)計(jì)領(lǐng)域,電源管理始終是關(guān)鍵環(huán)節(jié)。今天,我們聚焦于Microchip的MCP1825/MCP
    的頭像 發(fā)表于 02-05 15:50 ?169次閱讀

    MCP2120紅外編碼器/解碼器:特性、應(yīng)用與設(shè)計(jì)要點(diǎn)

    MCP2120是一款低成本、高性能、全靜態(tài)的紅外編碼器/解碼器,它符合IrDA?物理層規(guī)范(版本1.3),可以在UA
    的頭像 發(fā)表于 02-04 16:05 ?222次閱讀

    MCP】同時(shí)支持stdio,streamableHttpless和sse三種協(xié)議的MCP服務(wù)框架

    項(xiàng)目說(shuō)明 這是一個(gè)同時(shí)支持stdio,streamableHttpless和sse三種協(xié)議的MCP-Server的框架(ts語(yǔ)言)。 為什么我想做這個(gè)框架呢?因?yàn)殡S著AI發(fā)展,現(xiàn)在越來(lái)越多業(yè)務(wù)需要
    的頭像 發(fā)表于 01-21 18:26 ?151次閱讀
    【<b class='flag-5'>MCP</b>】同時(shí)支持stdio,streamableHttpless和sse三種協(xié)議的<b class='flag-5'>MCP</b>服務(wù)框架

    MCP2515:獨(dú)立CAN控制器的深度解析

    和應(yīng)用。 文件下載: MCP2515T-E ST.pdf 一、MCP2515概述 MCP2515是一款獨(dú)立的CAN控制器,它實(shí)現(xiàn)了CAN 2.0B規(guī)范,能夠以1Mb/s的速率
    的頭像 發(fā)表于 01-05 17:15 ?684次閱讀

    Murata DFE2MCPH□□□□JL□□ 片式線圈參考規(guī)范解讀

    Murata DFE2MCPH□□□□JL□□ 片式線圈參考規(guī)范解讀 在電子設(shè)備的設(shè)計(jì)中,片式線圈(片式電感器)是一種常見(jiàn)且關(guān)鍵的元件。今天,我們來(lái)詳細(xì)解讀 Murata 公司的 DFE2MCPH
    的頭像 發(fā)表于 12-16 16:50 ?476次閱讀

    MCP22350 USB Type-C? PD 3.1端口控制器技術(shù)解析

    Type-C?電纜和連接器規(guī)范以及USB PD 3.1規(guī)范。MCP22350高度集成的小尺寸PD端口控制器可為USB Type-C插座提供電纜插頭方向和檢測(cè)。這些控制器通過(guò)集成USB PD 3.1
    的頭像 發(fā)表于 09-30 15:26 ?1006次閱讀
    <b class='flag-5'>MCP</b>22350 USB Type-C? PD 3.1端口控制器技術(shù)解析

    ?MCP22301 USB Type-C? PD 3.1控制器技術(shù)解析與應(yīng)用指南

    Microchip Technology MCP22301 USB Type-C^?^ 供電 (PD) 3.1控制器設(shè)計(jì)用于符合USB Type-C電纜和連接器規(guī)范以及USB PD 3.1規(guī)范。這些
    的頭像 發(fā)表于 09-30 15:21 ?1299次閱讀
    ?<b class='flag-5'>MCP</b>22301 USB Type-C? PD 3.1控制器技術(shù)解析與應(yīng)用指南

    ?MCP16367評(píng)估板用戶指南

    Microchip Technology MCP16367評(píng)估板設(shè)計(jì)用于評(píng)估和演示MCP16367降壓DC-DC轉(zhuǎn)換器的功能。 該評(píng)估板具有2.2MHz的PWM開(kāi)關(guān)頻率、內(nèi)部軟啟動(dòng)、內(nèi)部補(bǔ)償、內(nèi)部電流限制和內(nèi)部自舉二極管。MCP
    的頭像 發(fā)表于 09-28 15:02 ?733次閱讀
    ?<b class='flag-5'>MCP</b>16367評(píng)估板用戶指南

    推薦5個(gè)讓測(cè)試效率翻倍的MCP

    推薦5個(gè)讓測(cè)試效率翻倍的MCP
    的頭像 發(fā)表于 09-19 10:02 ?626次閱讀
    推薦5個(gè)讓測(cè)試效率翻倍的<b class='flag-5'>MCP</b>

    睿遠(yuǎn)研究院丨IO-Link規(guī)范解讀(一):技術(shù)定義與組織規(guī)范

    ? IO-Link 技術(shù)定義與組織規(guī)范 從今日起,小睿將開(kāi)始長(zhǎng)篇連載IO-Link規(guī)范解讀系列文章,幫助大家理解和熟悉IO-Link規(guī)范,并把IO-Link技術(shù)應(yīng)用到自己的產(chǎn)品中去。這
    的頭像 發(fā)表于 09-18 18:17 ?990次閱讀
    睿遠(yuǎn)研究院丨IO-Link<b class='flag-5'>規(guī)范</b><b class='flag-5'>解讀</b>(一):技術(shù)定義與組織<b class='flag-5'>規(guī)范</b>

    技術(shù)解讀MCP協(xié)議以及SmartBear API Hub在MCP開(kāi)發(fā)中的關(guān)鍵作用

    MCP協(xié)議正成為AI集成的“基礎(chǔ)設(shè)施”。本文將帶你認(rèn)識(shí)這一“AI界的USB-C”,并梳理SmartBear API Hub如何通過(guò)契約測(cè)試、雙向驗(yàn)證和代碼生成,真正加速MCP開(kāi)發(fā)。
    的頭像 發(fā)表于 08-21 14:41 ?1277次閱讀
    技術(shù)<b class='flag-5'>解讀</b>:<b class='flag-5'>MCP</b>協(xié)議以及SmartBear API Hub在<b class='flag-5'>MCP</b>開(kāi)發(fā)中的關(guān)鍵作用

    如何用FastMCP快速開(kāi)發(fā)自己的MCP Server?

    作者:算力魔方創(chuàng)始人/英特爾創(chuàng)新大使劉力很多讀者反饋:通過(guò) 《用MCP將百度地圖能力輕松接入DeepSeek》 和 《如何用DeepSeek+MCP實(shí)現(xiàn)AutoGLM沉思的能力?》 的實(shí)戰(zhàn),真真切切
    的頭像 發(fā)表于 05-07 16:07 ?2805次閱讀
    如何用FastMCP快速開(kāi)發(fā)自己的<b class='flag-5'>MCP</b> Server?

    訊飛星辰Agent開(kāi)發(fā)平臺(tái)已全面支持MCP

    MCP全稱(chēng)Model Context Protocol(模型上下文協(xié)議),是由Anthropic公司于2024年11月推出的開(kāi)放協(xié)議,旨在規(guī)范大型語(yǔ)言模型與外部數(shù)據(jù)源及工具之間交互方式的開(kāi)放協(xié)議標(biāo)準(zhǔn)。通過(guò)提供類(lèi)似USB-C的標(biāo)準(zhǔn)化接口,幫助模型發(fā)現(xiàn)、理解并安全調(diào)用各種外部
    的頭像 發(fā)表于 04-15 13:41 ?1704次閱讀

    一文詳解MCP傳輸機(jī)制

    MCP 傳輸機(jī)制(Transport)是 MCP 客戶端與 MCP 服務(wù)器通信的一個(gè)橋梁,定義了客戶端與服務(wù)器通信的細(xì)節(jié),幫助客戶端和服務(wù)器交換消息。
    的頭像 發(fā)表于 04-14 14:03 ?3792次閱讀
    一文詳解<b class='flag-5'>MCP</b>傳輸機(jī)制