modelcontextprotocol/python-sdk
Watch
1
0
Fork
You've already forked python-sdk
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs: refresh translations for recent English changes (#3379)

Browse source
This commit is contained in:
Max 2026-08-24 19:29:54 +01:00 • committed by GitHub
commit c5d7d0b6d0
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
1 changed files with 3149 additions and 1047 deletions
Download patch file Download diff file Expand all files Collapse all files

18
i18n/uk/pages/advanced/middleware.md
View file

@ -1,6 +1,6 @@
---
translation:
sections: [6048b4f308edbb8c, 068bda0f21ee9c1b, c3e565b61acd75c5, c62422b159c6ed09, 47204fab253cc45c]
sections: [6048b4f308edbb8c, 46056f318ef205e4, c3e565b61acd75c5, c62422b159c6ed09, 420968f514138f43]
tool: 1
---
# Middleware {#middleware}
@ -33,8 +33,8 @@ translation:
рядок методу; `ctx.params` — сирі параметри, **до** будь-якої валідації.
* `call_next(ctx)` запускає решту ланцюжка: валідацію, пошук обробника, сам обробник.
Поверніть те, що він повернув, — і відповідь залишиться недоторканою.
* `try`/`finally` тут навмисно: обробник, що викидає виняток, однаково буде заміряно, бо збій
доходить до middleware як виняток із `call_next`.
* `try`/`finally` тут навмисно: для обробника, що викидає виняток, час однаково буде заміряно,
бо збій доходить до middleware як виняток із `call_next`.
* `server.middleware.append(...)` реєструє її. Список виконується від зовнішнього до
внутрішнього, тож `middleware[0]` — найближча до мережі.
@ -55,8 +55,11 @@ tools/call took 0.1 ms
* Установлення з'єднання: `server/discover`, або `initialize` і `notifications/initialized`
у сесії старого покоління.
* Кожен запит і кожне сповіщення. Для сповіщення `ctx.request_id is None`,
`call_next(ctx)` повертає `None`, а все, що повернете ви, відкидається.
* Кожен запит і кожне сповіщення, що доходить до сервера. Для сповіщення
`ctx.request_id is None`, `call_next(ctx)` повертає `None`, а все, що повернете ви,
відкидається. (На шляху Streamable HTTP версії `2026-07-28` POST зі сповіщенням від клієнта
транспорт підтверджує кодом `202` і ніколи не передає далі, тож до middleware воно теж не
доходить; ця ревізія не визначає жодних сповіщень від клієнта до сервера через HTTP.)
* Навіть метод, для якого сервер не має обробника: `call_next` викидає
`MCPError(-32601, "Method not found")` *крізь* ваш middleware на шляху до клієнта.
@ -115,8 +118,9 @@ SDK постачає рівно один шар middleware, і він уже є
* Middleware — це `async (ctx, call_next) -> result`; його передають як
`MCPServer(middleware=[...])` (або додають до `mcp.middleware`), а в низькорівневому `Server`
додають до `server.middleware`.
* Він огортає **кожне** вхідне повідомлення (`server/discover`, `initialize`, запити,
сповіщення, невідомі методи) і виконується від зовнішнього до внутрішнього.
* Він огортає **кожне** вхідне повідомлення, що доходить до сервера (`server/discover`,
`initialize`, запити, сповіщення, невідомі методи), і виконується від зовнішнього до
внутрішнього.
* `ctx.request_id is None` — так відрізняють сповіщення від запиту.
* Викиньте виняток замість виклику `call_next`, щоб відхилити одне повідомлення; з'єднання
вціліє.