Англійська мова для розробників Model Context Protocol (MCP)

Model Context Protocol (MCP) став стандартним способом для застосунків штучного інтелекту для підключення мовних моделей до зовнішніх інструментів, даних і систем. Якщо ви працюєте з MCP у міжнародній команді, вам знадобиться точна англійська мова для опису серверів, можливостей і архітектури клієнт- вузол. Цей підручник містить основні слова для розробників MCP.

Ключовий словник

** MCP- сервер ** — процес, який виставляє інструменти, ресурси або підказки для програми штучного інтелекту за допомогою стандартного протоколу, зазвичай, обгортаючи зовнішню систему або API.

• “Ми створили сервер MCP, який використовує нашу внутрішню систему квитків, тому будь- який помічник, сумісний з MCP, може створювати і запитувати квитки.” *

** MCP- клієнт ** — компонент у програмі вузла, який з’ єднується з одним або декількома серверами MCP і керує протоколом зв’ язку.

• “Клієнт визначає, які інструменти пропонує кожен з’ єднаний сервер, і представляє їх мовній моделі як доступні дії.” *

** Host ** — програма, яка вбудовує клієнта MCP, організовує розмову між користувачем, моделлю і з’ єднаними серверами.

• “Наш внутрішній помічник балачки виконує функції вузла, керуючи з’ єднаннями з серверами MCP для обробки квитків, календаря і бази знань.” *

Instrument — функція, відкрита сервером MCP, яку модель може викликати для виконання дії, наприклад, створення запису або виклику API. “Ми виставили інструмент create_ticket з чітко введеними параметрами, тому модель точно знає, які поля потрібні.”

** Ресурс ** — частина даних, яку сервер MCP надає моделі для читання, наприклад, файл, запис бази даних або документ. “Ми виставляємо недавні звіти про інциденти як ресурси MCP, тому помічник може прочитати їх для контексту без необхідності виклику спеціального інструменту.”

** Запит (примітив MCP) ** — шаблон запиту з параметрами, який можна використовувати багаторазово, сервер MCP може показувати його клієнтам для виклику з певними аргументами. “Сервер виставляє шаблон підказки summarize_incident, який приймає ідентифікатор події і повертає структуровану підказку для моделі.”

** Транспорт ** — основний механізм зв’ язку між клієнтом MCP і сервером, наприклад, stdio або HTTP з подіями, надісланими сервером. “Ми використовуємо stdio для локальних інструментів розробки і HTTP для серверів, які потрібно запускати віддалено.”

** Переговори щодо можливостей** — початкове обговорення, під час якого клієнт і сервер погоджуються щодо того, які з можливостей протоколу (інструменти, ресурси, підказки) підтримуються. “Під час обговорення можливостей наш клієнт дізнається, що цей конкретний сервер підтримує лише інструменти, а не ресурси, тому він відповідно налаштовує інтерфейс користувача.”

** Вибірка ** — функція, яка дозволяє серверу MCP запитати у мовної моделі вузла, щоб вона створила завершення від його імені, змінюючи звичайний напрямок керування. “Ми використовуємо вибірку, щоб сам сервер міг запитати у моделі підсумувати документ, не вимагаючи власної окремої інтеграції LLM.”

Розробка дизайну сервера

• «Ми зберегли поверхню інструментів нашого MCP-сервера малою і фокусованою — п’ять добре задокументованих інструментів, а не двадцять неясних»
• «Опис кожного інструменту написаний для моделі, щоб читати, тому ми вважаємо його документацією, а не просто внутрішнім коментарем»
• «Ми відокремили ресурси тільки для читання від інструментів зміни стану, тому доступ до читання моделі не вимагає такого ж схвалення, як дія запису»

Розмовляли про архітектуру і безпеку

• «Вузол посередничає кожен виклик інструменту, тому ми можемо додати крок схвалення перед будь-якою дією, яка змінює виробничі дані»
• «Переговори про можливості означають, що старі клієнти деградують граціозно, якщо сервер додає нову функцію, яку вони ще не підтримують»
• «Ми обмежуємо обсяг усіх реєстраційних даних сервера, тому навіть якщо модель обманом викликає інструмент несподівано, радіус вибуху обмежений»

Професійні поради

1. ** Написати описи інструментів для аудиторії моделі, а не тільки для людей. ** Неоднозначні описи призведуть до того, що модель викликає неправильний інструмент або надає неправильні параметри.
2. ** Поясніть роль вузла як посередника при обговоренні безпеки. ** Зацікавлені сторони, які хвилюють « ШІ, що виконує дії », часто заспокоюються, дізнавшись, що кожен виклик інструменту проходить через рівень схвалення.
3. ** Зберігайте поверхню інструментів мінімальною і складною. ** Сервер з меншою кількістю, добре визначених інструментів, простіше для моделі і для людей, які переглядають.

Практичні вправи

1. Поясніть колегі у 3- 4 реченнях різницю між інструментом і ресурсом у MCP.
2. Напишіть коротке пояснення (4- 5 речень), чому ваша команда обмежила обсяг реєстраційних даних сервера MCP.
3. Описати простим англійським мовою, яким чином обговорення можливостей дозволяє старішому клієнту працювати з новішим сервером без втрат.

Розвиток мовлення: розвиток мовлення в контексті розвитку мовлення

Ядро розуміння розробки MCP в значній мірі залежить від точного спілкування - не тільки про те, що ви робите, але і про те, як ви це робите. Розробники, що працюють з великими мовними моделями (LLM) і їхніми протоколами, часто опиняються в ситуаціях, що вимагають чіткої, технічно вірної англійської мови. Це не просто про заміну слів; це про прийняття термінології і фразування, що полегшує співпрацю, документацію і, врешті-решт, ефективне вирішення проблем в команді. Ми вже описали ключові слова щодо серверів, підказок, архітектури клієнт/ вузол, але давайте розберемося, як це працює на практиці.

Однією з найпоширеніших проблем є отримання зворотнього зв’язку про зміни коду. У типовому коментарі перегляду коду може бути написано: « У цьому розділі не повністю використано контекстне вікно; розгляньте можливість впровадження більш детальної інженерії підказок, щоб поліпшити якість відповідей ». Зауважте, що у цьому розділі використано точну мову — « не повністю використано », « контекстне вікно », « інженерія підказок ». Такий рівень специфічності не випадковий. Це навмисний вибір, щоб вийти за межі неясних заяв, таких як «потрібне поліпшення», і замість цього визначити *причину * для занепокоєння, направляючи розробника на конкретне рішення. Аналогічно, розмови Slack можуть швидко стати непродуктивними, якщо жаргон використовується без пояснення. Швидке повідомлення на кшталт «Чи можете ви додати обробку помилок навколо виклику API?» Можна було б поліпшити за допомогою «Чи можемо ми реалізувати надійну обробку помилок — зокрема, механізм повторних спроб з експоненційним відступом — щоб забезпечити стійкість, коли зовнішня служба недоступна?»

Інший сценарій виникає під час описів Pull Request (PR). Хороший опис PR не лише говорить про те, * що * було змінено, але і * чому *. « Виправлено помилку у розпізнаванні користувача » недостатньо. Замість цього, більш ефективним описом може бути: “Впроваджено розширену автентифікацію користувача за допомогою OAuth 2.0, щоб вирівняти з найкращими практиками безпеки і зменшити залежність від потоку старих паролів. Це оновлення включає в себе надійну перевірку вхідних даних і обмеження швидкості, щоб зменшити потенційні вразливості. » Знову ж таки, зверніть увагу на стратегічне використання таких термінів, як « OAuth 2. 0 », « перевірка вхідних даних » і « обмеження швидкості » — це демонструє глибше розуміння основної технології. Вміння чітко сформулювати ці технічні рішення є ключовим для залучення нових членів команди або пояснення вашої роботи зацікавленим особам.

Нарешті, важливо пам’ятати, що ясність переважає короткість. Хоча коротке спілкування цінується, жертвуючи точністю заради короткості, це може призвести до непорозумінь і переробки. Намагайтеся досягти балансу - надати достатньо деталей, щоб всі розуміли контекст і наслідки ваших дій.

# Example: Checking API response status codes using curl (illustrative)
curl -s "https://api.example.com/v1/users?limit=10" | jq '.[]'

Ця проста команда демонструє, як розробник може описати ситуацію, що включає виклик API і його відповідь — щось, що можна легко обговорити більш докладно з використанням точного технічного словника.