This server lets you manage Megaplan (tasks, deals, projects, employees, comments) through AI assistants using MCP.
Tasks: list tasks with filters (status, responsible, search) and create tasks with name, description, responsible, deadline, and parent task.
Deals: list deals with filters and create deals with pipeline, amount, contact, responsible, and description.
Projects: list projects with filters by status and search.
Employees: list employees with search and department filter.
Comments: get and add comments to tasks, deals, or projects (HTML supported).
Skills/prompts: “my tasks today” to view active tasks by urgency and a step-by-step deal creation wizard.
Deployment: supports stdio and Streamable HTTP transport (optionally on a custom port) for local or remote/cloud use.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@megaplan-mcp List my tasks for today"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Если вы искали, как подключить Мегаплан к нейросети, ставить задачи и вести сделки не открывая интерфейс — это оно. 8 инструментов поверх API v3: задачи, сделки, проекты, сотрудники и комментарии, плюс 2 навыка — «мои задачи на сегодня» и мастер создания сделки. Пишете «создай сделку на 300 тысяч по этому контакту» — сделка появляется в Мегаплане.
MCP-сервер для системы управления проектами Мегаплан. Задачи, сделки, проекты, сотрудники и комментарии через API v3.
Инструмент | Описание |
| Список задач с фильтрами по статусу, ответственному и поиском |
| Создать задачу с названием, описанием и дедлайном |
| Список сделок с фильтрами |
| Создать сделку с воронкой, суммой и контактом |
| Список проектов с фильтрами |
| Список сотрудников с поиском и фильтром по отделу |
| Комментарии к задаче, сделке или проекту |
| Добавить комментарий к задаче, сделке или проекту |
Related MCP server: plane-mcp-server
Навык | Описание |
| «Мои задачи на сегодня» — активные задачи по срочности |
| «Создай сделку» — пошаговое создание сделки |
В Мегаплане откройте Настройки → Интеграции → API
Сгенерируйте access-токен
Используйте свои учётные данные Мегаплана (e-mail + пароль).
{
"mcpServers": {
"megaplan": {
"command": "npx",
"args": ["-y", "@theyahia/megaplan-mcp"],
"env": {
"MEGAPLAN_DOMAIN": "yourcompany",
"MEGAPLAN_TOKEN": "your-access-token"
}
}
}
}Либо через логин и пароль:
{
"mcpServers": {
"megaplan": {
"command": "npx",
"args": ["-y", "@theyahia/megaplan-mcp"],
"env": {
"MEGAPLAN_DOMAIN": "yourcompany",
"MEGAPLAN_LOGIN": "user@example.com",
"MEGAPLAN_PASSWORD": "your-password"
}
}
}
}Запуск с флагом --http включает транспорт поверх HTTP (удобно для удалённых и облачных развёртываний):
MEGAPLAN_DOMAIN=yourcompany MEGAPLAN_TOKEN=xxx npx @theyahia/megaplan-mcp --http
# Слушает http://localhost:3000/mcpСвой порт задаётся переменной окружения PORT.
Переменная | Обяз. | Описание |
| да | Поддомен Мегаплана (например, |
| одно из | Bearer access-токен |
| одно из | E-mail для входа (если нет токена) |
| одно из | Пароль (если нет токена) |
| нет | HTTP-порт для режима |
Реферальное вознаграждение за приведённых клиентов Мегаплана — 20-50% на регулярной основе:
Зарегистрируйтесь партнёром и получите реферальную ссылку
Каждый приведённый клиент — регулярная доля от его платежей
npm install
npm run build
npm test
npm run dev # режим stdio через tsx
npm run start:http # режим HTTPMIT
Add a comment to a task, deal, or project in Megaplan.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Comment text (supports HTML) | |
| subject_id | Yes | Entity ID to comment on | |
| subject_type | Yes | Entity type to comment on |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the burden. It discloses the core behavior (adding a comment) but omits details like required permissions, side effects, or error behavior. Adequate for a simple creation action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the essential purpose with no extra words. Structure is optimal for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not mention return values, error handling, or any post-creation behavior. For a creation tool, this is a notable gap that reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter documented. The description adds no extra meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a comment') and the resource ('task, deal, or project'). It distinguishes from sibling tools like create_deal and create_task, which create entities rather than comments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or alternatives is provided. The context from sibling names implies this tool is for commenting, but the description lacks when-not or prerequisite information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new deal in Megaplan with name, pipeline, responsible user, and amount.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Deal name/title | |
| amount | No | Deal amount | |
| contact_id | No | Contact/client ID | |
| program_id | Yes | Deal program (pipeline) ID | |
| description | No | Deal description | |
| responsible_id | No | Responsible employee ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states 'Create a new deal' implying mutation, but lacks details on side effects (e.g., triggers, audit logs), authorization needed, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with 14 words, concise and front-loaded. It efficiently states the core purpose without waste, though it could sacrifice some brevity for completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description omits what the tool returns (e.g., created deal object). It also does not mention that name and program_id are required, which is only in schema. For a creation tool with 6 parameters and no annotations, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description lists some parameters (name, pipeline, responsible user, amount) but does not add meaning beyond what's in the schema (e.g., format constraints, dependencies).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'deal in Megaplan', and lists key fields (name, pipeline, responsible user, amount). This distinguishes it from sibling create_* tools like create_comment and create_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs. alternatives. The description does not mention prerequisites, when not to use it, or trade-offs compared to other tools like create_task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new task in Megaplan with name, description, responsible user, and deadline.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Task name/title | |
| deadline | No | Deadline in ISO format (e.g. 2025-12-31T23:59:59+03:00) | |
| parent_id | No | Parent task ID (for subtasks) | |
| description | No | Task description | |
| responsible_id | Yes | Responsible employee ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description should fully disclose behavioral traits. It only states 'create a new task' without mentioning side effects, permissions, or return values, leaving significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is efficient but could be slightly more structured (e.g., bullet points) without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite moderate complexity (5 parameters, no output schema), the description omits important context like what happens on successful creation (e.g., returns task ID), how parent_id works, or any constraints. It feels incomplete for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, meaning all parameters are already documented in the schema. The description lists a few parameters (name, description, responsible user, deadline) but adds no additional meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'task', and lists specific fields (name, description, responsible user, deadline). It distinguishes from sibling tools like create_comment and create_deal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., create_deal) or when not to use it. Pre-requisites or context about task creation are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List comments for a task, deal, or project in Megaplan.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results per page | |
| offset | No | Offset for pagination | |
| subject_id | Yes | Entity ID to get comments for | |
| subject_type | Yes | Entity type to get comments for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It describes a read operation ('List') but does not disclose additional behavioral traits such as sorting order, inclusion of deleted comments, or rate limits. The pagination parameters in the schema are present, but the description adds no extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundancy. It effectively communicates the tool's purpose without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, the description is fairly complete in stating the action and entity types. However, it does not hint at the response format or any default ordering, which would be helpful for an agent. Given the complexity and presence of pagination parameters, additional context about the output would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all four parameters. The tool description does not add any supplementary meaning beyond what is already in the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('comments'), and specifies the entity types it applies to (task, deal, project). It effectively distinguishes from sibling tools like 'create_comment' (write operation) and other get tools (different entities).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implicitly clear (when you need to list comments for a specific entity), but the description does not explicitly state when to use this tool versus alternatives, nor does it provide any exclusions or comparisons with sibling tools like 'get_tasks'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List deals from Megaplan with filters by status, responsible user, and search.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results per page | |
| offset | No | Offset for pagination | |
| search | No | Search by deal name | |
| filter_status | No | Filter by deal status | |
| filter_responsible_id | No | Filter by responsible employee ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description is too brief, lacking details on read-only nature, rate limits, performance, or what is returned beyond deals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with main purpose, no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks explanation of return value, pagination handling, and fails to differentiate from sibling list tools like get_tasks; incomplete for a 5-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and description adds value by naming filter categories (status, responsible user, search), but does not elaborate on limit/offset behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'List' and resource 'deals', and specifies filters, distinguishing it from sibling tools like create_deal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for listing deals with filters, but does not provide explicit when-to-use or alternatives, nor discusses pagination or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List employees from Megaplan with search and department filter.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results per page | |
| offset | No | Offset for pagination | |
| search | No | Search by employee name or email | |
| filter_department_id | No | Filter by department ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It does not mention authentication, rate limits, pagination behavior, or what the response contains. Only states it lists employees with filters, which is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 10 words, front-loaded with the core action. Every word earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description must explain return values. It does not mention what is returned (e.g., list of employee objects, pagination info). Lacks context on defaults, ordering, or response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description adds little beyond grouping search and department filter, but does not explain limit/offset or provide additional semantics beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists employees from Megaplan, with specific verbs 'List' and resources 'employees'. It mentions two filtering capabilities (search and department filter), distinguishing it from siblings that handle different resources (comments, deals, tasks).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No mention of prerequisites, context, or when not to use it. The description is purely declarative without usage hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List projects from Megaplan with filters by status and search.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results per page | |
| offset | No | Offset for pagination | |
| search | No | Search by project name | |
| filter_status | No | Filter by status (active, completed, etc.) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It indicates a read-only operation ('List projects'), but it does not mention authentication needs, rate limits, or what happens with empty results. The behavior is straightforward but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core purpose and key filters. Every word is necessary; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description should provide more context about the return format, pagination behavior (offset/limit), and potential errors. It only covers basic filtering, leaving users uncertain about what data they will receive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all 4 parameters (100% coverage), so the description adds minimal value beyond confirming the filter and search capabilities mentioned in the description. It does not provide additional context like format or allowed values beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List projects from Megaplan' using a specific verb and resource, and it mentions filters by status and search. It distinguishes itself from sibling tools like get_deals and get_tasks by targeting a different entity type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing projects with optional filter parameters, but it offers no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. Sibling tools are for different entities, so differentiation is inherent but not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tasks from Megaplan with filters by status, responsible user, and search.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results per page | |
| offset | No | Offset for pagination | |
| search | No | Search by task name | |
| filter_status | No | Filter by status (e.g. active, completed, delayed) | |
| filter_responsible_id | No | Filter by responsible employee ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose pagination behavior, rate limits, or any side effects beyond listing with filters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, efficiently front-loaded with the action. It could be slightly more structured, but it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 5 parameters and no output schema, the description is adequate for a simple list tool but lacks details on pagination behavior and return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description reiterates three filter parameters but adds no new meaning beyond the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List tasks' and the resource 'from Megaplan', and mentions specific filters (status, responsible user, search), which distinguishes it from sibling tools like get_comments or get_deals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_comments or get_deals, nor does it specify exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.1.0create_commentcreate_dealcreate_taskget_commentsget_dealsget_employeesget_projectsget_tasksScored across 8 tools
Each tool targets a distinct entity and action (create vs get). There is no ambiguity between tasks, deals, projects, comments, or employees.
All tools follow a consistent verb_noun pattern (create_* or get_*) with underscores, making them predictable and easy to remember.
With 8 tools, the server is well-scoped for a basic project management API, covering core create and read operations across key entities.
Significant gaps exist: there are no update or delete tools for any entity, and no create_employee. This leaves agents unable to modify or remove items, which is a major limitation.
Create and manage MeisterTask projects, tasks, and notes from your AI assistant.
Remote MCP for Kanban AI boards—manage projects, tasks, and comments from AI tools.
Task manager your agent can fully operate: boards, tasks, sprints, roles, worklogs, day planner.
Manage projects, tasks, time tracking, and team collaboration through natural language.
