Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Kontrak protokol MCP

Memahami persyaratan untuk menerapkan Model Context Protocol (MCP) sehingga agen dapat memanggil alat dan server agen.

Misalnya kode, lihat Menye barkan server MCP di AgentCore Runtime.

Persyaratan implementasi protokol

Server MCP Anda harus menerapkan persyaratan protokol khusus ini:

Manajemen sesi MCP dan kelengketan microVM

Model Context Protocol (MCP) menggunakan Mcp-Session-Id header untuk mengelola status sesi dan permintaan rute. Untuk spesifikasi MCP, lihat Transportasi HTTP Stream able MCP.

MicroVM Stickiness: Amazon Bedrock AgentCore menggunakan Mcp-Session-Id header untuk merutekan permintaan ke instance microVM yang sama. Klien harus menangkap yang Mcp-Session-Id dikembalikan dalam respons dan memasukkannya ke dalam semua permintaan berikutnya untuk memastikan afinitas sesi. Tanpa ID sesi yang konsisten, setiap permintaan dapat dialihkan ke microVM baru, yang dapat mengakibatkan latensi tambahan karena cold start.

MCP tanpa kewarganegaraan (): stateless_http=True

MCP yang berkeadaan (): stateless_http=False

Untuk detail selengkapnya tentang manajemen sesi MCP stateful, lihat spesifikasi manajemen sesi MCP.

Persyaratan kontainer

Server MCP Anda harus digunakan sebagai aplikasi kontainer yang memenuhi spesifikasi berikut:

Persyaratan jalur

/mcp - POSTING

Tujuan

Menerima pesan MCP RPC dan memprosesnya melalui kemampuan alat agen Anda, menyelesaikan pass-through payload InvokeAgentRuntime API dengan pesan MCP RPC standar

Format tanggapan

JSON-RPC request/response format berbasis, mendukung keduanya application/json dan text/event-stream sebagai tipe konten respons

Kasus penggunaan

T /mcp itik akhir melayani beberapa tujuan utama:

Penanganan kesalahan

Server MCP mengembalikan kesalahan sebagai respons kesalahan JSON-RPC 2.0 standar. Sebagian besar kesalahan dibawa dalam JSON-RPC error objek dengan kode status HTTP 200, seperti yang dipersyaratkan oleh spesifikasi MCP. Hanya kesalahan otentikasi, otorisasi, dan permintaan tingkat protokol yang menggunakan kode status HTTP non-200. Tabel berikut memetakan setiap pengecualian runtime ke kode JSON-RPC kesalahan, kode status HTTP, dan pesan. Beberapa pengecualian berbagi kode JSON-RPC kesalahan tetapi mengembalikan pesan yang berbeda, sehingga mereka terdaftar sebagai baris terpisah.

ConflictExceptiondan RetryableConflictException keduanya menggunakan kode JSON-RPC kesalahan -32005 (HTTP 200) tetapi dibedakan oleh pesan mereka. Layanan mengembalikan RetryableConflictException (Session operation in progress, please retry) ketika operasi kedua menargetkan sesi saat layanan menyediakan atau menghancurkan sesi itu. Karena MCP mengembalikan HTTP 200 dengan kesalahan dalam JSON-RPC tubuh, pemanggil harus memeriksa badan respons dan mencoba lagi dengan backoff eksponensial pendek — klien MCP tidak mencobanya ulang secara otomatis.

Contoh respons kesalahan:

{
  "jsonrpc": "2.0",
  "id": "req-001",
  "error": {
    "code": -32005,
    "message": "Session operation in progress, please retry"
  }
}

Tanggapan otentikasi OAuth

OAuth-configured agen mengikuti standar otentikasi RFC 6749 (OAuth 2.0). Ketika otentikasi hilang, layanan mengembalikan respons 401 Tidak Sah dengan WWW-Authenticate header (per RFC 7235), memungkinkan klien menemukan titik akhir server otorisasi melalui API. GetRuntimeProtectedResourceMetadata

401 Tidak sah

Dikembalikan ketika header Otorisasi hilang atau kosong.

Tanggapan termasuk WWW-Authenticate header:

WWW-Authenticate: Bearer resource_metadata="https://bedrock-agentcore.{region}.amazonaws.com/runtimes/{ESCAPED_ARN}/invocations/.well-known/oauth-protected-resource?qualifier={QUALIFIER}"