Loading ToolBench
MCP Server providing tools for Android Gradle build management, code generation context for Clean Architecture layers, and task planning with Compose Desktop UI
This Kotlin MCP server registers 6 tools but exhibits critical quality gaps across naming, descriptions, and schema definition. Four tools have non-English names (transliterated Russian), which breaks LLM tool discovery conventions. Input schemas are present and properly structured with JSON Schema, but descriptions vary widely in quality and actionability. The server maintains session state in `GradleBuildSession` for the first tool, which violates stateless request handling principles introduced in the current MCP spec. Error handling is present but generic. Overall, this is a C-grade server with significant structural issues that would require refactoring before production use.
Создает новый план с задачами и сохраняет его в MD файл. План будет создан в директории .cursor/plans/ с именем файла вида: plan-{название}-{timestamp}-{id}.md Используй эту функцию когда: - Нужно создать новый план работы - Требуется структурировать задачи для проекта - Необходимо задокументировать этапы реализации Аргументы: - plan_name: название плана (обязательно) - description: описание плана и его целей (обязательно) - tasks: массив названий задач (обязательно, минимум 1 задача) Возвращает: - Информацию о созданном плане включая ID, путь к файлу и список задач
Получает информацию о текущем активном плане. Возвращает подробную информацию о плане, включая: - Основные данные (ID, название, описание, статус) - Список всех задач с их статусами - Прогресс выполнения - Путь к MD файлу Используй эту функцию когда: - Нужно узнать текущее состояние плана - Требуется получить список задач и их статусы - Необходимо проверить прогресс выполнения - Нужно получить ID задач для обновления статусов Примечание: - Если нет активного плана, вернется сообщение об этом - Активный план определяется по статусу "В работе" или самый новый по дате Аргументы: - include_details: (необязательный) boolean, включать ли расширенную информацию о задачах (по умолчанию true) Возвращает: - Полную информацию о текущем плане или сообщение об отсутствии активных планов
Используй эту функцию для получения контекста и правил генерации Data и Domain слоёв в Clean Architecture и тестов для них. Функция возвращает полный контекст с примерами существующих классов (DTO, Repository, UseCase, Mappers) и правилами их создания для нового сервиса. Применяй эту функцию когда: - Нужно создать новый сервис по API-контракту, JSON-схеме или документации - Требуется сгенерировать Data/Domain слои для новой фичи - Необходимо понять структуру и паттерны организации кода в проекте - Необходимо тесты для данных слоёв Аргументы: - service_name: название сервиса/фичи (опционально). Используется для подстановки в именования классов и пакетов вместо переменной 'x' из правил.
Non-English tool name breaks LLM discovery. 'Запросить параметры Gradle сборки' (Russian transliteration) violates the convention that tool names use English action verbs (get_, create_, update_, etc.). LLMs are trained on English codebases and will struggle to recognize this as a callable tool. Rename to 'ask_for_gradle_build_params' or 'get_gradle_build_params'.
Stateful session object (GradleBuildSession) persists state between requests, violating current MCP spec's stateless request handling principle. The server stores 'currentParams' in a singleton, making it impossible for concurrent requests or multi-user deployments. Each request must be self-contained. Remove GradleBuildSession and pass all state through tool parameters or return values.
Input schema for 'get_data_domain_context' lacks a 'required' array definition in the visible source. The parameter 'service_name' has no type constraint (should be 'type': 'string') and no indication of whether it is required or optional. Per the rubric, parameters without explicit type definitions cap the schema score at 30.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 30 | - | v1 |
Используй данную функцию, когда тебя просят передать привет. Функция принимает аргумент name_arg в виде строки String. name_arg - имя человека, которому нужно передать привет.
Обновляет статус задачи в текущем активном плане. Изменения автоматически сохраняются в MD файл плана. Используй эту функцию когда: - Нужно отметить задачу как выполненную - Требуется изменить статус задачи (начата, отменена и т.д.) - Необходимо обновить прогресс выполнения плана Аргументы: - task_id: идентификатор задачи (обязательно) - status: новый статус задачи (обязательно) Возможные значения: * "pending" - ожидает выполнения * "in_progress" - в процессе выполнения * "completed" - выполнена * "cancelled" - отменена Примечание: - Если активного плана нет, будет возвращена ошибка - Task ID можно получить из вывода create_plan или get_current_plan Возвращает: - Информацию об обновленном плане с новым статусом задачи
Запрашивает у пользователя параметры для сборки Gradle-модуля. **Что нужно запросить:** 1. Название Gradle-модуля (например: PfmCalendarLibImpl, feature-auth, app) 2. Тип сборки (только один из трех вариантов): - :assembleRelease - релизная сборка - :assembleDebug - отладочная сборка - :testDebugUnitTest - unit-тесты 3. Используй эту функцию когда: - Нужно получить у пользователя данные для сборки Аргументы: - module_response: название модуля - type_builder_response: тип сборки - absolute_core_path: определи сам корневой путь проекта (Абсолютный путь к корневой папке проекта)
Descriptions for 'get_data_domain_context', 'hello', and 'create_plan' lack clarity on WHEN to call each tool and what it returns. The rubric requires descriptions to answer: What does it do? When should the LLM call it? What does it return? Current descriptions are narrative but lack structured guidance. Rewrite as: [ACTION] [WHEN/USE CASE] [INPUT] [OUTPUT].
Tool 'hello' is a trivial greeting tool with no clear integration into the server's domain (Gradle builds, Android architecture, task planning). Its purpose is unclear and it adds no value to the toolset. Remove it or combine into a more substantial initialization/context tool.
Error responses for 'Запросить параметры Gradle сборки' return unstructured text instead of categorizing errors as retryable, user-fixable, or fatal. E.g., 'Путь не существует или не является директорией' (path does not exist) is user-fixable, but the response does not suggest next steps like 'Try: verify_project_path(absolute_core_path)' or 'Available paths: [...]'. Per the rubric, errors must guide recovery.
Parameter 'absolute_core_path' in the first tool requires users to know the exact absolute path. Per the rubric, tools should accept human-friendly identifiers and resolve them internally. Rename to 'project_name' and let the tool search for the project, or provide a 'discover_project()' helper tool.
Output schema not documented for any tool. The rubric requires that 'Tools returning lists should accept page/offset and limit parameters and return a total count or next_cursor.' Tool 'get_data_domain_context' presumably returns a large context object, but there is no visible schema describing what fields the LLM should expect. Document return types for all tools.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present in the code. The current MCP spec rewards these per-tool hints for production readiness. Tools like 'create_plan' (WRITE) and 'update_task_status' (WRITE) should be marked as destructive/idempotent to help agents reason about side effects.