Loading ToolBench
FastAPI-based MCP server for integrating with AmoCRM API. Provides HTTP endpoints for managing leads, contacts, companies, tasks, and chat messages. Supports webhook integration and chat storage via SQLite.
This server has fundamental definition quality issues across multiple dimensions. Tool naming is inconsistent and sometimes ambiguous (e.g., 'amocrm_request' is a generic catch-all). Most tool descriptions are in Russian and lack sufficient detail about WHEN to use each tool, what data they return, or error conditions. Parameter descriptions are sparse, many parameters have minimal or no description text. The input schemas are technically present but incomplete: several parameters lack 'type' declarations (nullable booleans without type, properties without constraints). Output schemas are not documented anywhere. The server exposes a concerning 'amocrm_request' tool that allows arbitrary HTTP calls to the AmoCRM backend (GET/POST/PATCH/DELETE), which is a security red flag and violates the single-responsibility principle. No error handling guidance is present, tools will fail but provide no recovery hints to an LLM. This is below median quality for community MCP servers.
Универсальный HTTP запрос к AmoCRM серверу. Позволяет вызвать любой endpoint нашего бэкенда.
Создать новую сделку в AmoCRM
Быстро создать сделку (алиас). Берёт дефолты из окружения при отсутствии параметров
Удалить сделку по ID
Получить статус AmoCRM сервера
Получить список сделок из AmoCRM
Получить сделки за период с фильтрами (удобный алиас)
amocrm_request tool permits arbitrary HTTP requests (GET/POST/PATCH/DELETE) to any endpoint without validation or guardrails. LLM can invoke DELETE on sensitive endpoints without safeguards.
Multiple tools perform similar operations: create_lead and create_simple_lead both create leads. LLM must reason about which to use, wasting tokens. Per pattern:composition, each tool should have one clear responsibility.
Delete tool (delete_lead) has no description text flagging it as destructive. Per pattern:command-tool, destructive operations must explicitly state 'This will permanently delete X.' No confirmation mechanism.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 20 | - | v1 |
Input schemas lack proper type declarations. get_leads_by_date has 'date_from' with description but no 'type' field; same for 'date_to' marked nullable without type.
No output schemas documented for any tool. LLMs cannot know what fields to expect in responses, making it impossible to chain tools (e.g., does get_leads return lead_id? what is the field name?). Per pattern:tool, outputs must be documented.
Tool descriptions are too short and lack WHEN/WHY context. Most here are 20-50 chars, providing minimal guidance for tool selection.
Environment variable fallback behavior (e.g., create_lead uses AMO_PIPELINE_ID if pipeline_id omitted) is documented in descriptions but not in parameter schema. This creates ambiguity, is pipeline_id truly optional, or does it fail if env var is missing?
No error handling or recovery guidance. Tools will fail (e.g., 'lead not found', 'invalid pipeline_id') but responses do not tell LLM what to do next (retry, ask user, suggest alternatives). Per pattern:recovery-guide, all errors must include actionable next steps.
Numeric parameters lack constraints (min/max). 'limit' defaults to 10 or 50 with no stated bounds. LLM could request 1,000,000 leads, causing API overload or timeout.
No pagination mechanism documented. get_leads accepts 'limit' but no offset/cursor or indication of total count. If AmoCRM has 1000+ leads, returning only 10 without a way to fetch more forces agent to call the tool repeatedly. Per pattern:paginated-result, tools returning lists must support pagination.