kwork-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| KWORK_SITE | No | Kwork site: ru (kwork.ru) or com (kwork.com); kwork.com has no project exchange | ru |
| KWORK_WRITES | No | Sending to Kwork: confirm sends only after the user's yes in chat, auto lets the agent send, off is read-only | confirm |
| KWORK_TIMEOUT | No | Kwork request timeout in seconds (1-120) | 30 |
| KWORK_LOG_LEVEL | No | Server log level (stderr) | INFO |
| KWORK_STATE_DIR | No | Absolute private directory with the account store written by kwork-mcp login | |
| KWORK_EXPECTED_USER_ID | No | Kwork user ID to serve; needed only when kwork-mcp login stored several accounts |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| account_statusA | Проверить фактический аккаунт, ожидаемую привязку и готовность writes. Используйте первым после запуска и перед безопасным write-flow. Возвращает стабильные user_id/username и полную внешнюю запись профиля. Данные Kwork помечены как недоверенный внешний ввод. |
| get_connectsA | Получить активные и общие коннекты без изменения аккаунта. |
| get_user_infoA | Получить полный публичный профиль ровно по одному user_id или username. |
| search_usersB | Искать пользователей Kwork с сохранением полных полей и paging metadata. |
| discover_projectsA | Получить страницу проектов с явным discovery-режимом и opaque cursor.
|
| get_projectB | Получить проект по стабильному project_id с полным описанием и raw fields. |
| get_exchange_infoB | Получить полный стандартный exchangeInfo response через pinned API client. |
| list_my_offersB | Список собственных офферов; каждый элемент гарантирует offer_id и project_id. |
| get_offerC | Получить собственный оффер по offer_id, включая обязательный project_id. |
| list_worker_ordersC | Список заказов продавца через реальный generic workerOrders page contract. |
| get_order_detailsB | Получить полную структуру details/stages/tracks заказа без обрезки. |
| list_dialogsB | Получить страницу диалогов с полными последними сообщениями. |
| get_dialogA | Получить полные сообщения диалога по username. Без page возвращается последняя страница с самыми свежими сообщениями. Страницы нумеруются от начала переписки: более ранние сообщения лежат на page на единицу меньше, page=1 — самое начало. |
| list_my_kworksB | Получить все собственные кворки с status group и полными raw fields. |
| get_kwork_detailsC | Получить полный getKworkDetailsExtra response без ложных полей. |
| list_categoriesA | Получить полное трёхуровневое дерево категорий и их ID. |
| list_favorite_categoriesB | Получить полный ответ избранных категорий текущего аккаунта. |
| list_notificationsB | Получить полные notification groups и вложенные notifications. |
| prepare_writeA | Проверить и сохранить точный Kwork write payload без remote side effect. Поддерживаемые actions: submit_offer, delete_offer, send_message, edit_message, delete_message, mark_dialog_read, submit_order_approval и set_kwork_state. Перед подготовкой выполняются свежая account binding check и action-specific preflight. Результат содержит payload_hash, TTL и HMAC-derived confirmation_token; в ledger хранится только его hash. Exact replay того же idempotency_key/request возвращает тот же token, пока запись prepared. Другой request с тем же key запрещён. |
| commit_writeA | Выполнить ровно подготовленный payload в режиме shared one-writer. Commit повторяем только с теми же write_id/payload_hash/token: shared ledger вернёт сохранённый результат и не вызовет Kwork повторно. Remote writes никогда автоматически не retry. Timeout, proxy loss, 5xx или неподтверждённый offer_id дают submission_unknown/isError; после этого commit повторять нельзя — вызовите reconcile_write. При KWORK_WRITES=confirm вызывайте commit_write только после явного «да» пользователя на точный текст, цену и получателя. |
| get_write_statusB | Прочитать durable state и сохранённый результат без remote write. |
| reconcile_writeA | Read back Kwork state for submission_unknown without resubmitting payload. Возвращает reconciled_succeeded при найденном точном side effect. Reconciled_absent требует нескольких полных отрицательных наблюдений через visibility interval; до этого остаётся submission_unknown. Remote write не выполняется. Неизвестные состояния (модерация, исчезнувший объект, чужой текст) не считаются доказательством; если сверка не сходится, оператор фиксирует исход через kwork-mcp resolve-write. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 22 tools
Most tools target distinct resources and actions, and the list/get pairs (dialogs, offers, kworks, projects) are differentiated by scope and description. Minor potential confusion remains around account_status vs. get_user_info and between several read-oriented list/get pairs, but descriptions generally resolve this.
The set is predominantly consistent snake_case verb_noun naming: list_*, get_*, prepare_write, commit_write, reconcile_write. account_status is the main exception, and a few names like discover_projects and search_users use different verbs for similar retrieval patterns, but overall readability is high.
With 22 tools, the surface is on the heavy side for a single MCP server, even accounting for Kwork's broad domain. The tools mostly earn their place, but there is room to consolidate or hide lower-level read operations.
Read coverage is broad across orders, dialogs, users, projects, offers, kworks, categories, and notifications, and the write lifecycle is carefully modeled. However, core lifecycle gaps remain, such as creating/editing kwork listings and broader order/payment/review operations.