Skip to main content
Glama

Onplana

by io.github.Onplana
OverviewDiscussionsAdmin

gantt_optimize

Destructive

Ask the AI to propose a new schedule for a project that fits all tasks before a target deadline while respecting dependencies. Returns an array of {taskId, startDate, dueDate} proposals (YYYY-MM-DD strings), any warnings, and feasibility status. Use mode="preview" (default) to inspect the proposal first; use mode="apply" to capture a baseline and commit the dates immediately (requires project Owner or Manager role). Cap: 100 tasks per project. Use when the user asks "can we finish by [date]?" or "reschedule this project to meet the deadline".

Input Schema

NameRequiredDescriptionDefault
modeNopreview (default): return proposals without writing. apply: capture a baseline then commit all proposed dates. Requires project Owner or Manager role.preview
deadlineYesTarget end date in YYYY-MM-DD format. All tasks will be proposed to finish on or before this date.
previewIdNoThe previewId a preview of this project returned. When a preview returns one, apply mode writes exactly that stored preview instead of proposing again, and refuses without it or when the plan changed since.
projectIdYesID of the project to optimize the schedule for.
levelResourcesNoWhen true (default: false), the AI avoids overallocating any user beyond their ResourceCapacity.hoursAvail for the week.
allowOverallocationNoWhen true, overallocation warnings are surfaced but not treated as failures. Default false (overallocation causes a retry).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / mode
      Added value: +{
+  "default": "preview",
+  "description": "preview (default): return proposals without writing. apply: capture a baseline then commit all proposed dates. Requires project Owner or Manager role.",
+  "enum": [
+    "preview",
+    "apply"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / previewId
      Added value: +{
+  "description": "The previewId a preview of this project returned. When a preview returns one, apply mode writes exactly that stored preview instead of proposing again, and refuses without it or when the plan changed since.",
+  "type": "string"
+}
  2. Added

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and idempotentHint=false; the description adds substantial context beyond them: apply captures a baseline then commits immediately, requires elevated role, refuses when a previewId is missing or the plan changed, and warns on overallocation. That is exactly the mutation-safety detail the annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four compact sentences with no filler, front-loaded with purpose, then returns, then mode guidance, then cap and trigger conditions. Every sentence carries distinct decision-relevant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description takes on that burden by naming the return shape ({taskId, startDate, dueDate} with YYYY-MM-DD, warnings, feasibility status). Combined with the role, cap, and mode caveats, an agent has everything needed to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; however the description adds meaning not present in the schema, notably the 100-task-per-project cap and the overallocation retry behavior, plus a readable restatement of preview/apply tradeoffs. It does not fully compensate where schema already documents previewId and deadline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('propose a new schedule for a project') with the objective (fit all tasks before a target deadline) and constraint (respecting dependencies). It also previews the return payload, so an agent knows exactly what the tool produces.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly separates preview vs apply, states the authorization requirement for apply (Owner or Manager), the 100-task cap, and gives literal trigger phrases ('can we finish by [date]?', 'reschedule this project to meet the deadline'). This routes the agent unambiguously, including against the adjacent auto_schedule_proposal.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Onplana toolsInspect
Try in Browser
Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources