Skip to main content
Glama

twprojects-list_allocations

Read-only

List scheduler allocations — who is committed to which project, and when. ALWAYS pass start_date and end_date: with neither set the endpoint returns only today through 30 days from today, and says nothing about having narrowed the range, so an unbounded call silently answers a question about a wider period with one month of data. Allocations are planned time and a separate plane from task estimates and logged time; the two are not summed. linkedTaskEstimatedTime counts each linked task whole and must not be summed across allocations.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number for pagination of results (1-based).
fieldsNoThe attributes to return for each allocation, from the listed names.
verboseNoIf false, returns id + name only — useful when scanning many results.
end_dateNoReturn allocations overlapping up to and including this day (format: YYYY-MM-DD). Defaults to 30 days from today when omitted.
order_byNoThe field to sort the allocations by. Omit to keep the ordering the API applies by default.
page_sizeNoNumber of results per page for pagination (1-500).
count_onlyNoIf true, return only {"count": N}: the exact number of matching allocations, no rows — use for "how many". Ignores page, page_size, verbose, fields.
order_modeNoThe direction to sort the results in.
start_dateNoReturn allocations overlapping this day onwards (format: YYYY-MM-DD). Defaults to today when omitted.
project_idsNoOnly return allocations on these projects.
search_termNoA search term to filter allocations by title.
show_deletedNoReturn ONLY deleted allocations instead of the active ones — this replaces the result set rather than adding to it, so a call with this set says nothing about what is currently scheduled. Deleting an allocation is a soft delete, and this is how a deleted one is found again.
deleted_afterNoOnly return allocations deleted at or after this moment; the boundary itself matches, unlike updated_after. Pair it with show_deleted, which is what switches the results to deleted allocations. Accepts an RFC 3339 timestamp (2026-08-03T14:30:00Z) or a plain YYYY-MM-DD date (2026-08-03), which covers that whole day in UTC.
updated_afterNoOnly return allocations updated strictly after this moment; the boundary itself does not match. Accepts an RFC 3339 timestamp (2026-08-03T14:30:00Z) or a plain YYYY-MM-DD date (2026-08-03), which covers that whole day in UTC.
project_statusNoOnly return allocations on projects with this status.
project_tag_idsNoOnly return allocations on projects carrying these tags.
assigned_user_idsNoOnly return allocations assigned to these users. Accepts real people and placeholder users alike.
project_owner_idsNoOnly return allocations on projects owned by these users.
project_company_idsNoOnly return allocations on projects belonging to these companies.
project_category_idsNoOnly return allocations on projects in these categories.
assigned_user_team_idsNoOnly return allocations whose assigned user belongs to one of these teams.
match_all_project_tagsNoRequire a project to carry every tag in project_tag_ids rather than any of them.
include_financial_detailsNoInclude forecasted revenue and cost for the allocated time. Requires the scheduler rates entitlement and financial permission on the project; without either, the request still succeeds but the figures are withheld. Read canViewFinancialDetails on each row to tell a withheld figure from a zero one.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
metaNo
countNoExact number of matches across every page. Returned instead of the rows when count_only.
includedNo
allocationsNo

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavior beyond both annotations and schema: the endpoint silently narrows an unbounded range to today+30 days, allocations live on a separate semantic plane from logged/estimated time, and linkedTaskEstimatedTime must not be summed across allocations. These are exactly the traps an agent cannot infer and could easily get wrong.

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 sentences with zero waste: purpose first, the most critical operational warning second, then the two semantic clarifications. The highest-stakes information is front-loaded before any secondary detail. Every sentence earns its place.

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?

For a 23-parameter tool, this is complete. The rich schema documents every filter, the output schema covers return shape, and annotations carry the read-only safety profile. The description fills precisely the gaps structured data cannot: default-behavior traps, the planned-vs-logged semantic model, and a data-interpretation pitfall. Nothing needed for correct invocation is missing.

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% with individually well-documented parameters, so the baseline is 3. The description elevates this by adding meaning the schema cannot express: the interaction between start_date/end_date omission and result completeness, plus the aggregation semantics of linkedTaskEstimatedTime carried in the fields enum. The schema handles the remaining 21 parameters adequately on its own.

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?

"List scheduler allocations — who is committed to which project, and when" is a specific verb+resource statement that conveys both the operation and the returned content. It distinguishes this from the many sibling tools (get_allocation, create_allocation, update_allocation) and from related-but-different resources like timelogs and tasks.

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 explicit, high-stakes usage guidance: ALWAYS pass start_date and end_date, with a concrete explanation of the silent one-month default and why an unbounded call misanswers broader questions. It also separates allocations from task estimates and logged time, telling the agent when this tool is the wrong model. It does not explicitly name sibling alternatives (e.g., get_allocation for a single allocation), but the contextual cues are strong enough for correct routing.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3/5.0
Disambiguation4/5

Tools are organized into clear namespaced subdomains (twchat, twdesk, twprojects, twspaces) with distinct actions per resource. However, the twprojects domain has many tools for custom items that share repetitive descriptions, and a few tools like `twprojects-search` could overlap with list tools, but overall boundaries are clear.

Naming Consistency4/5

Naming follows a consistent `{prefix}-{verb}_{noun}` pattern across all tools, with prefixes indicating the subdomain. The only minor inconsistency is the use of singular and plural in nouns (e.g., `get_company` vs `list_companies`) and some verbs like `link_project_to_workflow` vs `move_tasks`, but the pattern is predictable.

Tool Count3/5

With 200 tools, this server is extremely large, covering multiple Teamwork products (Chat, Desk, Projects, Spaces). While each subdomain is well-scoped individually, the sheer number makes it unwieldy for an agent to navigate, and many tools could be pruned or combined (e.g., many custom item variants). It's on the high end of acceptable.

Completeness4/5

The surface is comprehensive, covering CRUD operations for most entities, specialized queries (search, count, summarize), and cross-entity linking (link_task_to_ticket). Minor gaps include lack of delete tools for most entities and some missing lifecycle operations (e.g., archiving), but core workflows are well-covered.