Find projects by name, status, type, or date range. Returns id, name, status, progress, dates, managers. Filterable fields: name, statusLabel, customTypeLabel, startDate, endDate.

Get project details by ID with subcomponent counts. Budget can be included via include: ["budget"]. For tasks, risks, issues, purchases, and revenues use the dedicated tools: list_project_tasks, get_project_risks, get_project_issues, get_project_purchases, get_project_revenues.

Find services by name, status, type, or date range. Same query shape as search_projects but for services.

Get service details by ID with subcomponent counts. Budget can be included via include: ["budget"]. For activities, purchases, and revenues use the dedicated tools: list_service_activities, get_service_purchases, get_service_revenues.

List activities for a service with pagination. Returns { items, total, limit, skip, hasMore }. Default limit: 50, max: 200.

Get purchase orders for a service with pagination. Returns { items, total, limit, skip, hasMore }. Default limit: 50, max: 200.

Get revenue items for a service with pagination. Returns { items, total, limit, skip, hasMore }. Default limit: 50, max: 200.

List tasks for a project with pagination. Returns { items, total, limit, skip, hasMore }. Default limit: 50, max: 200.

Get full detail of a single task from v2 REST (source of truth, not affected by DataMart sync delay). Returns dates, status, type, priority, kind, parent task, sprint, and has-subcomponent flags. Use list_project_tasks or search_tasks first to discover task IDs.

Search tasks across all projects in the account (DataMart). Filters combine with AND. Returns { items, total, limit, skip, hasMore } where each item is { projectId, projectName, task }. Results may lag writes by up to 60 seconds (DataMart eventual consistency); use get_task for the confirmed state of one task. Default limit: 50, max: 200.

Get budget summary for a project. Returns four budget objects: budgetTopDown (planned), budgetBottomUp (estimated), budgetPeriodEndClose (forecast), budgetActual (spent).

Get purchase orders for a project with pagination. Returns { items, total, limit, skip, hasMore }. Default limit: 50, max: 200.

Get revenue items for a project with pagination. Returns { items, total, limit, skip, hasMore }. Default limit: 50, max: 200.

Get risks for a project with pagination. Returns { items, total, limit, skip, hasMore }. Default limit: 50, max: 200.

Get full detail of a single risk from v2 REST (source of truth). Includes mitigation and contingency plans, probability, impact, level, occurrence cost, and manager. Use get_project_risks first to discover risk IDs.

Get full detail of a single issue from v2 REST (source of truth). Includes type, status, manager, management cost/hours, project impact, final resolution, and custom fields. Use get_project_issues first to discover issue IDs.

Get issues for a project with pagination. Returns { items, total, limit, skip, hasMore }. Default limit: 50, max: 200.

List the progress (seguimiento/follow-up) history for a task, newest first. Task progress is a time-series of entries, not a single task field; this is why update_task rejects PercentComplete.

Get the project progress report: expected curve, baseline curve, and follow-up history (date + percentage). includeEntries true adds the full Seguimiento entries (ProjectProgressId, assessment, descriptions) for update_project_progress.

Report progress on a task by creating a new progress (seguimiento/follow-up) entry. This is the correct way to set a task's completion percentage: it triggers task status transitions (100% completes the task, dropping below 100% reopens it), parent task rollups, automatic project progress, events, and notifications. Discover assessmentId values with get_reference_data entity "assessments".

Update an existing task progress (seguimiento/follow-up) entry via PATCH; send only the fields to change. Find the progressId with list_task_progress.

Create a project-level progress (Seguimiento) entry: the project status report with report date, completion percentage, assessment rating, and status description. Independent from per-task progress. WARNING: percentage 100 automatically CLOSES the project, which blocks further time entry; log hours first (reopen with update_project if needed). Assessment IDs: get_reference_data entity "assessments".

Update an existing project-level progress (Seguimiento) entry; send only the fields to change. Find the progressId with get_project_progress includeEntries true.

Read task effort by assigned user and professional category: planned estimates, accepted actual effort, and worked time. teamMembers lists assignees (UserId, name, email); TaskUserId is the assignment key. Estimates are written with update_task_effort.

Set planned effort for assigned users; never logs worked time or changes accepted effort or billing. Find assignees with get_task_effort and assign missing users with update_task first. Unlisted users stay unchanged. Unless taskTotalEstimate is supplied, the total is recomputed from user and unassigned-category estimates. Regular tasks only.

Log actual worked hours on a task for one user and date. ITM Platform stores ONE total per user+task+date: mode "add" adds to it, "set" replaces it (0:00 clears). The response echoes the previous and new totals. The user must be assigned to the task (TaskMembers on update_task) and the project status must allow time entry (closed projects block it). userId defaults to the session user; another user requires a Company Admin or Full Access license and the hours are attributed to that user.

Portfolio-level analytics: group projects by any field and compute metrics (count, avgProgress, totalBudget, totalActual). Uses DataMart aggregation -- no REST equivalent. Available groupBy fields: statusLabel, priorityLabel, methodology, customTypeLabel, isClosed, managers.name.

Run a custom query against ITM DataMart (MongoDB-backed). For advanced analysis beyond typed tools.

Operations:

• "components": list with filters. Params: where, project, sort, limit (max 200), skip

• "component": single by ID. Params: id, project

• "aggregateComponents": aggregation pipeline. Params: pipeline (must end with $limit, max 1000)

Allowed filter operators: $eq, $ne, $in, $nin, $gt, $gte, $lt, $lte, $regex, $options, $exists, $not, $and, $or, $nor Allowed pipeline stages: $match, $project, $group, $sort, $limit, $skip, $unwind, $addFields, $set, $unset Banned: $lookup, $merge, $out, $function, $accumulator, $where, $facet

Key fields: id, name, code, componentType, statusLabel, priorityLabel, percentComplete, startDate, endDate, methodology, managers, budgetTopDown, budgetActual, customFields (object keyed by field display name; see get_custom_fields).

Projecting full embedded arrays (tasks: 1, risks: 1, etc.) is rejected as too large; use dot notation (e.g. "tasks.name": 1) or the subcomponent tools with limit/skip.

This account defines custom fields. In DataMart documents they live under "customFields", an object keyed by the field's display name. Keys present (with component counts):

• project: "Exposure" (13), "Invoice paid" (13), "Client acceptance date" (13), "Area" (13), "ERP Code" (13) Query them via query_datamart: project {"customFields": 1} to read all values, or where {"customFields.": ...} to filter. Keys are case- and accent-sensitive and may contain trailing spaces. Keys with lower counts than their siblings are usually language variants of the same field on multilingual accounts; cover both variants with $or when totals matter. Field types and dropdown values: get_custom_fields and get_custom_field_options.

Find team members by name or email. Returns user ID, display name, email (the username) and IsNonLoginUser. Non-login users have an empty EmailAddress: address them by UserId in TaskManagers/TaskMembers. Uses projected v2 REST search (not DataMart).

Get details for a single user by ID. Returns full user profile including roles, categories, and contact info.

Get reference IDs for statuses, types, priorities, risks, issues, purchases, revenues, and assessments. Use assessments for task progress; activitystatuses/servicetypes for service writes; and riskstatuses, risktypes, riskimpacts, riskprobabilities, or risklevels for risks. Where BaseId exists, write tools accept either localized Id or BaseId and normalize as needed.

Get the account's custom field definitions for an entity type: project, task, risk, issue, service, activity, purchase, or revenue. Returns Id, BaseId, Name, TypeId, TypeName (Text, Number, Percentage, Date, HTML, RYGList, DropDownList, List), Description, Required.

VALUES live in DataMart under "customFields", keyed by the display Name exactly as returned here (case- and accent-sensitive, may contain trailing spaces). Query via query_datamart, e.g. project {"customFields": 1} or where {"customFields.": ...}. On multilingual accounts the key follows each component's language; fetch definitions per languageId to learn the variant names of the same BaseId. Dropdown values: get_custom_field_options.

Get the selectable options of a dropdown custom field (RYGList, DropDownList, or List types), using the BaseId returned by get_custom_fields. Returns Id, BaseId, Text, Color (RYG lists), SortOrder, IsDefault. The option Text is the value stored in DataMart "customFields" for the component.

Create a new project. Name and TypeId are required (entity "getprojecttypes"). ProjectMethodTypeId selects the methodology: 1=Waterfall (default when omitted), 2=Kanban (created with default board columns). Status cannot be set at creation (the account default status applies); change it with update_project. The caller becomes project manager when their license allows it.

Create a regular task, milestone, or summary task. KindId: 1=Milestone, 2=Summary, 3/default=Task (not the TypeId). Waterfall regular tasks require StatusId, StartDate, and EndDate; milestones require EndDate; summaries require StatusId. Kanban supports regular tasks only and uses board defaults. ParentId creates Waterfall hierarchy. AutomaticProgress statuses create 100% progress; a later lower report needs a later ReportDate. Use get_reference_data for valid IDs.

Update task fields via PATCH; send only the fields to change. KindId changes the task kind (1=Milestone, 2=Summary, 3=Task; not TypeId) and ParentId moves the task under a summary task; both are Waterfall-only. Converting to a milestone requires equal StartDate and EndDate in the same call. A status with AutomaticProgress (such as Completed) creates a 100% progress entry; a later lower report only takes effect with a later ReportDate (percentComplete tracks the latest entry by ReportDate).

Log a new risk in a project. TypeId, StatusId, ImpactId, ProbabilityId, and LevelId are all required. Discover IDs with get_reference_data (entities "riskstatuses", "risktypes", "riskimpacts", "riskprobabilities", "risklevels"); localized Ids are normalized automatically.

Log a new issue in a project. Discover IDs with get_reference_data (entities "issuestatuses", "issuetypes"); localized Ids are normalized automatically.

Update project fields via PATCH; send only the fields to change.

Update risk fields; send only the fields to change. Discover IDs with get_reference_data (entities "riskstatuses", "risktypes", "riskimpacts", "riskprobabilities", "risklevels"); localized Ids are normalized automatically.

Update issue fields via PATCH; send only the fields to change. Discover IDs with get_reference_data (entities "issuestatuses", "issuetypes"); localized Ids are normalized automatically.

Create a new service. Name and TypeId are required; use get_reference_data with entity "servicetypes" to discover valid service type IDs. The service is always created with the account default status; call update_service afterwards to change it.

Update service fields via PATCH; send only the fields to change. Status IDs come from get_reference_data entity "projectstatuses".

Create a new activity in a service. Activities form a flat list (no milestones, summaries, or hierarchy). Name, StatusId, StartDate, and EndDate are required. Activity statuses differ from task statuses; use get_reference_data with entity "activitystatuses" to discover valid IDs.

Update activity fields via PATCH; send only the fields to change. Activity statuses differ from task statuses (entity "activitystatuses").

Apply one status to many tasks of a project in one call (faster than looping update_task). Collect task IDs via list_project_tasks or search_tasks; chunk into calls of at most 100 IDs. Resolve valid status IDs via get_reference_data (entity "gettaskstatuses"): statuses differ between Waterfall and Kanban projects, and Kanban projects interpret statusId as the Kanban column ID, so pass projectMethodTypeId (1=Waterfall, 2=Kanban) or use statusName instead. Always check the failed array; retrying a failed chunk is safe.

Apply one status to many activities of a service in a single call. Collect activity IDs first via list_service_activities, then chunk into calls of at most 100 IDs. Resolve valid activity status IDs via get_reference_data with entity "activitystatuses" (activity statuses differ from task statuses), or pass statusName. Always check the failed array; retrying a failed chunk is safe.