Loading ToolBench
MCP server for Megaplan — tasks, deals, project management (Russia)
Server has 8 tools with consistent naming (verb_noun pattern) and descriptions present for all. Schemas are visible and use Zod validation. However, descriptions are generic (avg ~80 chars, below 194-char baseline), lack actionable context, and parameter descriptions are minimal. Output schemas are not documented. Error handling is absent from visible code. No tool annotations (readOnlyHint/destructiveHint). Composition is sound, tools are single-responsibility and chainable via IDs. Security: credentials injected via env (MEGAPLAN_DOMAIN, MEGAPLAN_TOKEN, MEGAPLAN_LOGIN/PASSWORD), which is correct.
Add a comment to a task, deal, or project in Megaplan.
Create a new deal in Megaplan with name, pipeline, responsible user, and amount.
Create a new task in Megaplan with name, description, responsible user, and deadline.
List comments for a task, deal, or project in Megaplan.
List deals from Megaplan with filters by status, responsible user, and search.
List employees from Megaplan with search and department filter.
Descriptions lack actionable context. E.g., 'List tasks from Megaplan with filters by status, responsible user, and search' does not explain WHEN to use this tool vs. alternatives, what the response structure is, or how to chain results to other tools. Descriptions should be 50 - 200 chars and answer: What? When? What's returned?
Output schemas are not documented. Tools return text responses (via handleGetTasks, etc.) but the structure of that text (JSON, CSV, table format) is not specified. LLMs cannot plan downstream calls without knowing what fields are returned.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | <=2025-11-25 | v2 |
List projects from Megaplan with filters by status and search.
List tasks from Megaplan with filters by status, responsible user, and search.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). The server correctly identifies read-only vs. write tools in the risk field, but does not expose this via MCP tool annotations. This prevents clients from applying safety policies (e.g., requiring confirmation before destructive ops).
Error handling is not visible in tool implementations. No recovery guidance, error classification, or actionable messages. If a task creation fails, the LLM receives a raw error with no hint on whether to retry, ask the user, or try a different approach.
Parameter descriptions are minimal. E.g., 'Filter by status (e.g. active, completed, delayed)' uses example values instead of enums. LLMs may hallucinate invalid statuses. Replace with enum constraint or explicit list of valid values.