Skip to main content
Glama

Onplana

by io.github.Onplana
OverviewDiscussionsAdmin

create_project

Create a new, EMPTY project in the user's Onplana workspace: a named container with an optional start and end date and no tasks yet. Fits "start a project called X" or "set up a project for our office move" when there is no work to put in it yet. When the request includes the work itself ("plan a website launch", "set up a project with the tasks for X"), instantiate_plan creates the project and its whole plan in one call; calling this tool first and then instantiate_plan without a projectId produces two projects and leaves this empty one behind. An id from this tool passed to instantiate_plan as projectId fills this project with a plan instead. Tasks can also go in with create_task or bulk_create_tasks. The caller becomes the project owner. If start/end are omitted, the project runs from today to about 90 days out, adjustable later with update_project. In an organization that classifies its projects, type STRATEGIC is refused: a strategic project there starts as a proposal and is created when the proposal passes its gate. list_projects with search shows whether a similarly named project already exists. The result carries nextSteps: the follow-on calls with this project id already filled in. A project left at "created" is an empty project the user then has to fill by hand. The result includes url, a direct link to the project in Onplana. ALWAYS show that link in your reply: the user is working inside another app and has no other way to find what was just created.

Input Schema

NameRequiredDescriptionDefault
nameYesProject name, 2–255 chars.
typeNoSTRATEGIC or OPERATIONAL. STRATEGIC is refused in an organization that classifies its projects, where a strategic project starts as a proposal.
colorNoOptional hex color for UI display.
budgetNoOptional numeric budget in the project currency.
statusNoDefault PLANNING.
endDateNoOptional ISO 8601 end date (YYYY-MM-DD). Defaults to ~90 days after the start when omitted; when both are given it must be after startDate.
currencyNoISO 4217 currency code, 3 letters. Default USD.
startDateNoOptional ISO 8601 start date (YYYY-MM-DD). Defaults to today when omitted.
descriptionNoOptional description, up to 10000 chars.
idempotencyKeyNoOptional idempotency key. Pass a stable unique value (e.g. a UUID) to make this create safe to retry: calling again with the same key within 24h - even from a new session after a reconnect - replays the original result and creates no duplicate. Org-scoped; works across conversations.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / endDate / description
      Previous value: -"ISO 8601 end date (required, must be after startDate)."New value: +"Optional ISO 8601 end date (YYYY-MM-DD). Defaults to ~90 days after the start when omitted; when both are given it must be after startDate."
    • changedInput schema / properties / startDate / description
      Previous value: -"ISO 8601 start date (required)."New value: +"Optional ISO 8601 start date (YYYY-MM-DD). Defaults to today when omitted."
    • changedInput schema / properties / type / description
      Previous value: -"STRATEGIC or OPERATIONAL."New value: +"STRATEGIC or OPERATIONAL. STRATEGIC is refused in an organization that classifies its projects, where a strategic project starts as a proposal."
    • changedInput schema / required
      Previous value: -[
-  "name",
-  "startDate",
-  "endDate"
-]New value: +[
+  "name"
+]
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare the safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=false). The description adds non-obvious behavior: the caller becomes owner, default date range of today to ~90 days, STRATEGIC being refused in classifying orgs, and that the result carries nextSteps and a url. That is substantial disclosure beyond what the annotations provide.

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

Conciseness4/5

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

Front-loads purpose and the key routing rule in the first two sentences, then layers prerequisites, side effects, and return-value handling. It is long, and a few clauses (e.g. restating the date default) echo the schema, but almost every sentence carries 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?

With no output schema, the description correctly describes the returned artifacts (`nextSteps`, `url`) and instructs the agent to surface the link. For a 10-parameter mutation tool it covers ownership, defaults, refusal cases, idempotency, and follow-on calls, leaving no critical gap.

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 description coverage is 100%, so the baseline is 3 and the schema already documents defaults for startDate/endDate and the STRATEGIC enum. The description reinforces the date-default behavior ('adjustable later with update_project') and the STRATEGIC refusal, but does not add much syntax the schema lacks.

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 ('Create a new, EMPTY project') and immediately qualifies scope ('a named container with an optional start and end date and no tasks yet'). The EMPTY emphasis plus explicit contrast with instantiate_plan lets an agent distinguish it from the sibling that also creates projects.

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?

Gives concrete user phrasings for when to use it ('start a project called X') and when not to ('plan a website launch'), naming instantiate_plan as the alternative. It also warns about the specific failure mode (two projects, empty one left behind) and points to list_projects with `search` for duplicate checking.

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