Loading ToolBench
MCP server for Bitrix24 — CRM, deals, contacts, tasks (Russia)
Bitrix24-MCP has 12 tools with complete input schemas (Zod-based) and descriptions. However, descriptions are generic and lack LLM-optimized guidance. Most parameters are documented but lack constraints (enums, ranges, patterns). Output schemas are not documented, responses are plain text, not structured. Error handling is minimal. Tool names follow verb_noun convention well. No tool annotations (readOnlyHint/destructiveHint) despite clear read/write distinction. Composition is sound (one tool per action), but parameter design could accept human-friendly identifiers (e.g., user names alongside IDs).
Mark a Bitrix24 task as completed by task ID.
Create a new CRM contact with name, last name, phone, and email.
Create a new CRM deal in Bitrix24 with title, amount, stage, and linked contact/company.
Create a new task in Bitrix24 with title, description, responsible user, and deadline.
Get a single CRM deal by ID with all fields.
List CRM contacts from Bitrix24 with optional filters by name, phone, or email.
No output schema documentation. All tools return plain text responses. LLMs cannot predict response structure, forcing unstructured parsing and wasting tokens.
Missing tool annotations. Tools like create_deal, update_deal, create_contact, create_task, complete_task, upload_file, send_message are destructive/write operations but lack destructiveHint annotation. Read-only tools lack readOnlyHint.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
List CRM deals from Bitrix24 with optional filters by stage, responsible user, and sort order.
List tasks from Bitrix24 with optional filters by status, responsible user, and group.
List Bitrix24 users with optional filters by active status and department.
Send an instant message via Bitrix24 IM to a user or chat.
Update an existing CRM deal fields: title, stage, amount, contacts, etc.
Upload a file to Bitrix24 disk folder (base64-encoded content).
Parameter descriptions lack constraints. 'stage_id' accepts free-form strings (e.g., 'NEW', 'WON', 'LOSE') but no enum is declared. 'priority' in create_task has enum ['0','1','2'] but description is vague. LLMs cannot validate inputs without explicit constraints.
No error recovery guidance. Error handling in client.ts returns raw HTTP status codes and API responses. LLMs receive no actionable next steps (e.g., 'User not found. Try search_users() first.').
Parameters require opaque IDs (user_id, contact_id, company_id, deal_id). No support for human-friendly identifiers (names, emails). Agents must call lookup tools first, wasting round-trips.