The field validation is the detail worth noticing: Bitrix24 portals are customised heavily, and get_task_fields lets a write be shaped against what this portal defines rather than rejected by it. Authentication is an inbound webhook URL rather than OAuth, which makes setup a copy-and-paste but also means that one string is the whole credential.
A Bitrix24 server covering tasks, workgroups and users. Task writes are validated before they go out — if you pass custom fields, the keys are checked against what the instance says a task holds — and every call is a JSON-RPC exchange over stdio against your own Bitrix24 webhook.
- Tasks created with title, description, responsible person, group and custom fields
- Tasks updated, closed and reopened by id
- Tasks listed by responsible person or group, with paging
- The field definitions a task on your instance actually holds, used to validate what you send
- A task's history returned as entries with date, field, value and the user who changed it
- Workgroups created and listed
- Users listed with Bitrix24's own filter syntax, and the current user resolved
- The user field definitions available
Node.js 18 or newer, and an inbound webhook URL from your portal set in the environment. That webhook's own scope is the ceiling on what any of these tools can reach.
One command plus a key — npx mcp-bitrix24, then supply credentials