Wrike

Posts a comment on a Wrike item (task, folder, project, or any custom item type). Use this to reply in an item's comment thread, for example after reading it with get_item_comments. The text is HTML: only links, line breaks (<br>) and quotes (<blockquote>) render; bold/italic do not. Mentions: a person usually writes a mention as "@Name" (e.g. "@Javier"), but bare "@Name" text does NOT notify anyone. To make a real mention you must convert that person into their user id and write @[w:usr:N] inline (e.g. @[w:usr:24175041]); the tool renders it into the actual tag. Resolve the id from context first, such as the comment authors in the thread or the item's assignees, and use only an id you have actually seen. Never invent or guess a user id; if you cannot determine it, or the name is ambiguous (more than one match), ask the user instead of guessing.

create_item_comment

Creates one or more Wrike folders or projects (items of baseType FOLDER or PROJECT), optionally as a custom item type (CIT). A PROJECT is a FOLDER that also has dates, owners (assignees) and a status, so those apply to projects only. Returns each new item's id and permalink; per-item failures are reported individually.

create_project_folder_item

Creates one or more Wrike tasks (items of baseType TASK), each under a parent you specify. Returns each new task's id and permalink; per-item failures are reported individually, so a partial batch still succeeds.

create_task_item

Returns Wrike approvals by exact lookup. Exactly one of two modes per call: - ids: exact id lookup. The API silently omits ids the caller cannot see, so the returned array may be shorter than the input list. - parentId: approvals attached DIRECTLY to that task, folder, or project, such as a task's own approvals or a folder/project's own "Approval by Project". This does NOT recurse: approvals on tasks inside a folder/project are NOT returned. To find approvals across many items, use search_approvals. Each approval carries status (Draft|Pending|Approved|Rejected|Cancelled), type (FilesOnly|Regular), title, description, parentId (w:itm:N), authorId (w:usr:N), finisherId (w:usr:N or null), finished, dueDate, updatedDate, attachmentIds (w:atch:N), and decisions[] ({approverId: w:usr:N, status: Pending|Approved|Rejected, comment, updatedDate}). User ids are returned raw in canonical w:usr:N form (not resolved to names); resolve them with get_users to show names. Decisions are read-only via this API; cast a decision in the Wrike UI. No filters. To filter by status, approver, dueDate, etc., use search_approvals.

get_approvals

Get full detail of Wrike tasks, folders and projects by id: resolved status, filled-in custom fields, people, child/comment/attachment counts, parent, and all attachments (including external Google Drive / link URLs). Only custom fields that have a value are returned; a field absent from the list is not filled in for that item, and an empty attachments list means none. Pass fullDescriptions=true to bypass the 500-char description truncation. Some attachments are Klaxoon whiteboards: type EXTERNAL with a url containing whiteboard_mirror_redirect (the url is a browser-only redirect, don't fetch it; the attachment name is the board's title). To read or edit that board, use the Klaxoon MCP. Find it with list_whiteboards by the attachment name (take the exact-title match; ask if several match), then use its accessCode/boardId. If the Klaxoon MCP isn't connected, see https://developers.klaxoon.com/klaxoon/docs/installation-guide.

get_item_details

Read the comment thread on a Wrike task, folder, or project, newest first, with author and timestamp. Read it before replying with create_item_comment. Returns at most the 200 newest comments; check the `truncated` flag and `totalComments` for the full count.

get_item_comments

List the direct children (one level down) of a Wrike item: a folder, project, task, or space. This is how you see a space's top-level contents and how you walk the hierarchy. Pass a child's id back in to go one level deeper, or to get_item_details for its full detail. It is built for traversing the hierarchy without large responses, so drill down level by level and pull full detail only for the items you care about. When the user wants to know what is under an item, or asks you to explore or look inside it, do not stop at the first level. Follow the branches that look relevant to their request a few levels down (about three is usually enough) so your answer is complete. Stay focused and go deeper only where it helps answer the request, not everywhere.

get_items_children

Look up Wrike users or groups by exact match, using exactly one of ids, emails, or me (each parameter explains its own format below). Each row matches the search_users row shape. The response carries `requested` and `returned`: an id that doesn't exist, isn't visible to you, or is out of range is simply absent from `users` (returned < requested) rather than erroring, so a batch with one such id still returns the good ones. An id with an unrecognized prefix (not w:usr:) is instead rejected as a usage error. For fuzzy / name-fragment discovery, use search_users.

get_users

Read the current user's Wrike inbox notifications, newest first. For triage ("what needs my attention", "summarize my inbox"), use the default (unread only). Pass includeRead=true only when the user asks what they have been working on; it adds recently-read items, which are noise for triage. If you don't already know whose inbox this is, call get_users(me=true) first: you need the user's own name to tell a direct mention from a group one. Each entry has notificationType, the source item (id + permalink), author, ts, and any commentText. Rank by signal, not recency: - Action needed (high): items assigned to the user (notificationType Assign or EntitiesAssigned), and Mention notifications whose commentText @-mentions the user by their own name, especially with a request. - For information (low): Comment notifications that do NOT @-mention the user by name, and Status or field changes on items the user only follows. A Mention addressed to a group (@followers, @assignees, @Product Managers, a team name) rather than to the user by name. notificationType Mention alone cannot tell a group mention from a direct one, so always read commentText to check whether the user's own name is the one mentioned. Cluster by item so each item appears once (one item may carry several notifications, e.g. a Status and a Comment); drop duplicates. Be selective: surface the high-signal items and summarize or omit the rest; many users keep a clean inbox. Show the item's permalink for anything you surface. The payload is a starting point, not the final answer. Status notifications don't say what changed, so call get_item_details for the current status and context before reporting, and read the item when a comment refers to something out of view. Enrich only the items you will actually surface (high-signal or ambiguous status), not the low-signal ones you plan to omit; batch their ids into few get_item_details calls (up to 5 ids each). Don't echo raw commentText verbatim. Reports, dashboards and approvals are surfaced for visibility but carry no w:itm:N id (not addressable by other tools). Paging: pass the oldest returned ts back as `before`. Read notifications persist ~1 month; unread persist longer.

get_my_inbox

Filtered search across approvals visible to the caller. All filters optional; with none, returns every approval shared with you (capped). Each parameter explains its own filter below. Returns at most `limit` approvals plus `truncated: boolean`. When truncated, narrow with a tighter date window, fewer statuses, or a more specific approver list. Results are scoped to what the caller can see; there is no spaceId filter (v4 doesn't offer one). For exact lookup or all approvals on a known task/folder, use get_approvals.

search_approvals