Skip to main content
Glama
Teamwork

Teamwork

Official
by Teamwork
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Remote

twprojects-create_allocation

Commit a user's planned time to a project over a date range, setting a fixed daily rate in seconds and optional linked tasks. Creates a scheduler allocation while handling capacity collisions.

Instructions

Commit a user's time to a project over a date range (a scheduler allocation). This is planned time, a separate plane from task estimates and logged time.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
colorYesThe allocation's colour as six hexadecimal digits, with or without a leading '#'.
titleYesThe name of the allocation, at most 100 characters.
end_dateYesThe last day of the allocation (format: YYYY-MM-DD). Must not precede start_date. Extending it ADDS committed time rather than spreading the existing total: the per-day rate is what is held constant, so the total is the working days in the range times that rate.
project_idYesThe ID of the project to commit the time to.
start_dateYesThe first day of the allocation (format: YYYY-MM-DD).
descriptionNoAn optional description of the allocation, at most 255 characters.
is_billableNoWhether the allocated time can be charged to a client.
linked_task_idsNoThe tasks to associate with the allocation. This REPLACES the whole set of linked tasks, so send every task that should stay linked. To add or remove one task without touching the rest, use twprojects-link_task_to_allocation or twprojects-unlink_task_from_allocation instead.
seconds_per_dayYesThe time committed on each working day of the range, in SECONDS — 4 hours a day is 14400. Must be between 60 (one minute) and 86400 (24 hours). Seconds rather than hours because the hours form is a float and rounds. This rate is what is held constant: the total is the working days in the range times this, so widening the range adds committed time.
assigned_user_idYesThe ID of the user whose time is committed. Accepts a real person or a placeholder user — a stand-in used to plan work before the person who will do it is known. Nothing in the response distinguishes the two, so confirm which one an ID refers to before reporting who is booked.
ignore_collisionsNoSkip the capacity check altogether. Prefer inform_of_over_allocation: this one also lets the change through, but suppresses the over-allocation report with it, so nobody is told the person is over-booked. It takes precedence when both are set.
inform_of_over_allocationNoAccept a change that puts the user over their capacity and report it, rather than rejecting it. Defaults to true, and the result says so when it happens. Turning it off means an over-allocating change is refused outright.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed12 schema fields changedv1.39.3
    • removedInput schema / properties / description / anyOf
      Removed value: -[
-  {
-    "maxLength": 255,
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
    • addedInput schema / properties / description / maxLength
      Added value: +255
    • addedInput schema / properties / description / type
      Added value: +"string"
    • removedInput schema / properties / ignore_collisions / anyOf
      Removed value: -[
-  {
-    "type": "boolean"
-  },
-  {
-    "type": "null"
-  }
-]
    • addedInput schema / properties / ignore_collisions / type
      Added value: +"boolean"
    • removedInput schema / properties / inform_of_over_allocation / anyOf
      Removed value: -[
-  {
-    "type": "boolean"
-  },
-  {
-    "type": "null"
-  }
-]
    • addedInput schema / properties / inform_of_over_allocation / type
      Added value: +"boolean"
    • removedInput schema / properties / is_billable / anyOf
      Removed value: -[
-  {
-    "type": "boolean"
-  },
-  {
-    "type": "null"
-  }
-]
    • addedInput schema / properties / is_billable / type
      Added value: +"boolean"
    • removedInput schema / properties / linked_task_ids / anyOf
      Removed value: -[
-  {
-    "items": {
-      "type": "integer"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]
    • addedInput schema / properties / linked_task_ids / items
      Added value: +{
+  "type": "integer"
+}
    • addedInput schema / properties / linked_task_ids / type
      Added value: +"array"
  2. Addedv1.33.1

TDQS

A4/5.0
Behavior3/5

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

Annotations only provide basic false booleans, so the description carries some burden. It adds meaningful context by clarifying this is planned time, separate from actual logged time, but it does not disclose side effects like capacity checks, linked-task replacement, or that extending the date range adds committed time. Those behaviors are documented in the schema, not the description itself.

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?

The description is two sentences with no wasted words. The core action is front-loaded, and the clarifying distinction about planned time is concise and valuable.

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

Completeness4/5

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

The schema is rich enough to compensate for the brief description, explaining the important nuances of end_date, seconds_per_day, linked_task_ids, and collision flags. The main gap is the lack of an output schema and no explicit statement of what the response contains, but the parameter descriptions provide strong situational completeness.

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

Parameters3/5

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

Schema description coverage is 100%, and the parameter descriptions are unusually detailed, covering units, date semantics, collision behavior, and linked-task replacement. The tool description itself adds no parameter-level meaning, so the baseline of 3 is appropriate.

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?

The description states a specific action ('Commit a user's time to a project over a date range') and clearly identifies the resource as a scheduler allocation. It also distinguishes this from task estimates and logged time, which helps differentiate it from siblings like twprojects-create_timelog.

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

Usage Guidelines4/5

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

The description gives clear context that this tool is for planned/scheduler time rather than logged time or task estimates, implying when to choose it over time-logging tools. It does not explicitly name alternatives for modifications or linking tasks, but the schema parameter descriptions fill much of that gap.

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

Deploy Server

Other Tools