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., "@@loopgantt/mcp-server Make a Gantt chart for a 6-week website relaunch"
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.
MCP (Model Context Protocol) server for LoopGantt. Turn a plain-language plan into a real Gantt chart from Claude Desktop, Cursor, or any MCP client — no account, no API key.
Point your MCP client at https://loopgantt.com/api/mcp (Streamable HTTP). Nothing to install, no account, no key.
Claude (claude.ai / Claude Desktop): Settings → Connectors → Add custom connector → URL https://loopgantt.com/api/mcp.
ChatGPT: Settings → Connectors → Create → MCP server URL https://loopgantt.com/api/mcp, authentication None.
Cursor and other clients (mcp.json):
{
"mcpServers": {
"loopgantt": {
"url": "https://loopgantt.com/api/mcp"
}
}
}The remote server exposes the keyless tools, resources and prompt below. The account tools (create_project, list_projects) need an API key and are only available on the local server for now.
Related MCP server: Blossom
npm install -g @loopgantt/mcp-serverAdd to your MCP client config (Claude Desktop: claude_desktop_config.json):
{
"mcpServers": {
"loopgantt": {
"command": "loopgantt-mcp"
}
}
}Restart the client and ask:
"Make a Gantt chart for a 6-week website relaunch"
"Plan a kitchen renovation with realistic durations and dependencies"
"Schedule the launch of our mobile app starting September 1"
Your assistant drafts the tasks, durations and dependencies; LoopGantt schedules them with its critical-path engine and replies with a picture of the chart, the dates, the critical path and a link where you can view the chart, export it (PNG / PDF) and save it to a free account.
Unclaimed charts expire after 7 days (30 days once the link is opened). Saving to an account keeps them forever.
create_gantt — no key neededParameter | Description |
| Project name |
| Optional one-liner |
|
|
| Working weekdays as ISO numbers |
| Non-working dates, |
| In execution order: |
Limits: 300 tasks, 20 dependencies per task, 10 charts per hour and 30 per day per network (the hosted server at loopgantt.com/api/mcp allows 60 per hour and 300 per day per network, because hosted assistants share a few addresses). Dates in replies are the first and last working day of each task.
schedule_project — no key neededSame input as create_gantt (name optional). Returns dates, critical path, float and the project end without storing anything — for "what's my critical path?" / "when would this finish?" questions. Limit: 60 calls per hour per network.
list_templates / get_template — no key neededThe industry templates (software, construction, marketing, events, IT, HR, finance) with their task lists, ready to adapt and pass to create_gantt. Also exposed as MCP resources (loopgantt://templates/<slug>).
plan_projectA guided flow — arguments goal, deadline?, team_size? — that drafts a work breakdown, creates the chart and presents the picture, the critical path and the link.
Get a key at https://loopgantt.com/settings/api-keys and pass it as an environment variable:
{
"mcpServers": {
"loopgantt": {
"command": "loopgantt-mcp",
"env": { "LOOPGANTT_API_KEY": "sk_live_…" }
}
}
}This enables create_project (creates the project directly in your account) and list_projects.
Variable | Description | Required |
| Enables the account tools | No |
| API base URL (default | No |
The server is a thin client over LoopGantt's public API — see the OpenAPI spec at https://loopgantt.com/openapi.json.
MIT
Create a Gantt chart from a task list — no account or API key needed. YOU author the plan: list the tasks in execution order with realistic working-day durations and dependencies (0-based positions of earlier tasks; use { task, type, lag } for start-to-start/finish-to-finish links or lag). Milestones have duration 0. LoopGantt schedules it with its critical-path engine and returns a picture of the chart, the dates, the critical path and a link where the user can view, export (PNG/PDF) and save the chart. Always show the user the link.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Project name | |
| tasks | Yes | ||
| holidays | No | Non-working dates, YYYY-MM-DD | |
| workDays | No | Working weekdays as ISO numbers 1 (Mon) … 7 (Sun). Default Mon–Fri. | |
| startDate | No | YYYY-MM-DD (defaults to today) | |
| description | No | Optional one-line description |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It covers the no-auth requirement, the scheduling behavior ('LoopGantt schedules it with its critical-path engine'), the outputs (picture, dates, critical path, link), and an explicit instruction to show the link. It does not mention error behavior or rate limits, but it is substantially transparent for this 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 dense paragraph with no filler; key facts are front-loaded ('no account or API key needed') and each sentence contributes either usage context, authoring instructions, or output behavior. It is slightly long, but every clause adds value.
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 tool with no output schema, the description does explain the return value: a picture of the chart, dates, critical path, and a view/export/save link. It also covers the key task-authoring rules. It could be more complete by describing the returned image format or handling of invalid dependency references, but overall an agent has enough to call the tool correctly.
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 83%, so the schema already documents most parameters. The description adds meaningful authoring guidance: list tasks in execution order, use realistic working-day durations, use 0-based predecessor positions, and use { task, type, lag } for typed links or lag. This reinforces and extends the schema by explaining the expected mental model for creating a valid task list.
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 names a specific verb and resource: 'Create a Gantt chart from a task list.' It also clarifies the tool's scope (no account/API key, author a plan, critical-path scheduling). It does not explicitly contrast with siblings like schedule_project, so it falls short of full differentiation.
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 gives clear context on when to use the tool: when the user wants a Gantt chart, needs no authentication, and expects the agent to author a task plan. However, it never states when to prefer an alternative tool or exclude schedule_project/list_templates/get_template, leaving comparison to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one industry template by slug: its task list with durations, ready to adapt and pass to create_gantt.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Template slug from list_templates |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It clearly states that the operation retrieves a read-only template and what the result contains. It does not describe edge-case behavior like invalid slugs, but for a simple getter this is adequate.
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, front-loaded sentence with no filler. It communicates the target, scope, return content, and downstream use in an efficient and readable way.
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 one-parameter retrieval tool, the description covers the main operational need: what is returned and how the result is used. Since no output schema exists, more detail about the exact structure of 'task list with durations' could help, but the description is still sufficient for selection and invocation.
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 schema fully documents the slug parameter. The description repeats 'by slug' but does not add substantive semantic detail beyond the schema's own reference to list_templates.
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 uses a specific verb and resource: 'Get one industry template by slug', and clarifies the content returned ('task list with durations'). It also distinguishes itself from list_templates by emphasizing retrieval of a single template.
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 clearly implies when to use this tool: when you need a specific industry template to adapt before passing it to create_gantt. It does not explicitly mention when not to use it or name alternatives, but the workflow context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List LoopGantt's industry project templates with task counts and typical durations. Pick one, fetch it with get_template, adapt it, then create_gantt.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It communicates a read-only listing behavior and the content returned, which is sufficient for a zero-parameter list operation; it does not claim side effects or require caveats like pagination.
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?
Two sentences with no fluff: the first defines the listing behavior, the second gives the follow-on workflow. Useful information is front-loaded.
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 zero-parameter list tool, the description covers what is returned (templates with task counts and typical durations) and what to do next. It does not spell out the exact return shape, but with no output schema that is a minor gap.
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 tool has zero parameters and the schema fully reflects that, so the baseline 4 applies. There is nothing for the description to add about parameters.
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 uses a specific verb ('List') and a specific resource ('LoopGantt's industry project templates') while adding output details (task counts and typical durations). The workflow reference to get_template and create_gantt immediately distinguishes this discovery action from the sibling creation/fetch tools.
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 clearly places list_templates at the start of a workflow: pick a template, fetch with get_template, adapt, then create_gantt. It does not explicitly state when not to use it or contrast it with schedule_project, so it misses the full 'alternatives' bar, but the intended context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute a schedule without storing anything: dates, critical path, float and project end for a task list (same input shape as create_gantt; name optional). Use it to answer "what is the critical path?", "when would this finish?", "how much slack does X have?". Use create_gantt when the user wants a chart they can open.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Project name | |
| tasks | Yes | ||
| holidays | No | Non-working dates, YYYY-MM-DD | |
| workDays | No | Working weekdays as ISO numbers 1 (Mon) … 7 (Sun). Default Mon–Fri. | |
| startDate | No | YYYY-MM-DD (defaults to today) | |
| description | No | Optional one-line description |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden of behavioral disclosure. It explicitly states the operation has no persistent side effect ("without storing anything"), which is valuable context. It does not describe return format or failure behavior, but for a pure computation tool the core behavioral fact is disclosed.
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 three focused sentences: what the tool computes, example user questions it answers, and the sibling alternative. There is no filler or repetition of schema content, and the most important fact (non-persistent computation) is front-loaded.
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 fairly complex scheduling tool with no output schema and no annotations, the description still covers the key facts: what it does, what values it produces, and which sibling to choose instead. It does not document the exact return structure, but the listed outputs and schema together are sufficient for correct selection and invocation.
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 high (83%), so the schema already documents parameter meanings such as tasks, holidays, workDays, and startDate. The description adds only a useful hint that the input shape matches create_gantt and that name is optional, which is already implied by the schema; no major parameter burden is added.
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 opens with a specific verb and resource: "Compute a schedule without storing anything" and names the concrete outputs: "dates, critical path, float and project end." It also distinguishes itself from create_gantt by contrasting a computed schedule with a chart an agent can open, so an agent can tell siblings apart.
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?
Usage is explicit: the description provides exact user intents that map to this tool ("what is the critical path?", "when would this finish?", "how much slack does X have?"). It also names the alternative condition: "Use create_gantt when the user wants a chart they can open." This is clear when-to-use and when-not-to-use guidance.
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.3.0create_ganttget_templatelist_templatesschedule_projectScored across 4 tools
list_templates and get_template are clearly a list/detail pair, while create_gantt and schedule_project share the same input shape and both surface dates and critical path. The descriptions clearly distinguish them by output and intent—create_gantt for a viewable chart, schedule_project for pure computation—so an agent can disambiguate with careful reading.
All four tools follow a consistent verb_noun snake_case pattern: list_templates, get_template, create_gantt, schedule_project. There are no mixed conventions or stylistic deviations.
Four tools form a tight, well-scoped set: template discovery, template retrieval, chart creation, and schedule computation each have exactly one tool. Nothing feels redundant or missing at the current scope.
The stated template-to-Gantt workflow is fully covered: list templates, fetch one, create a chart, or compute a schedule. There is no management layer for updating or deleting previously created charts, but the returned link handles viewing/exporting/saving, making this a minor gap rather than a critical one.
Create scheduled Gantt charts with critical path from a plain-language plan — no account or key.
MCP server for generating rough-draft project plans from natural-language prompts.
Task management your AI agents can actually run. One line becomes a context-ready task over MCP.
Gantt chart SaaS with server-side critical path and dependency-aware shift-impact tools, plus CRUD.
