Wrike

Returns field-change history for Wrike tasks, folders, and projects: what changed, when, and who changed it. Use it to build timelines, audit changes, and investigate how an item evolved. Use get_item_details for the current state and get_item_comments for discussion and reasons behind changes. Choose requestedChanges based on the user's request and include every relevant change type. For broad or unspecified history requests, include all available types. For multi-item investigations, put the most relevant items first and start with the change types needed for the question. If one item needs deeper analysis, start a new call for that item with additional requestedChanges or a wider changedDate range. Each page returns at most pageSize events, newest first within each item. Results are grouped by item, and items are processed in scope.itemIds order. Each event includes its timestamp, author, change type, action, and a typed payload containing old/new or added/removed values, depending on the change type. Only items with matching events are returned. When truncated=true, call again with the returned nextPageToken and the same arguments as in the initial call. The token alone determines the next page; repeated arguments do not affect it. Continue until truncated=false.

get_item_history

Returns one request form: title, description, optional pageIndex, and pages of fields. Index first: omit pageIds to get pageIndex only (pages empty). Then call again with pageIds for the ENTRY page and each next page. Use pageIndex.visibility, afterPages, and visibleWhenAny to follow the graph. Set includePageIndex=false on later calls once you have the index. Do not load every page up front. pageIndex (when included): id, title, visibility (ENTRY | ORPHAN | AFTER_PAGE | ON_CONDITION), hasMandatoryAttachment (unconditional mandatory Attachment on the page — prefer prefill when true on the path). A mandatory Attachment gated by visibleWhenAny does not set this flag; prefer prefill only if that parent option is selected (see the field on the loaded page). ENTRY — form start (first page). ORPHAN — no inbound edges and not the start; do not offer to the user. AFTER_PAGE — default next after afterPages (page→page). ON_CONDITION — option branch via visibleWhenAny (field/option/parent titles); afterPages may also be present. Each field: id (w:rffld:S), title, type, mandatory, optional helperText, options for CHECK_BOX / COMBO_BOX / IMPORTANCE (w:rfopt:S). Send option ids for those types, w:usr:N for USER, ISO YYYY-MM-DD for DATE, a plain number for NUMBER, plain text otherwise. ATTACHMENT cannot be sent through MCP — leave those fields out. Field-level visibleWhenAny: fill only when a listed parent option is selected; until then mandatory does not apply. If the response exceeds the size limit, the tool errors. When the message says to retry, call again with fewer pageIds and includePageIndex=false — the form may still be fillable page by page. Only if a single page (or the index alone) still exceeds the limit, this form cannot be filled through MCP and has to be opened in Wrike (name it by the title from search_requestforms). Do not offer prefill_requestform without page fields. Treat cut-off JSON the same way. Attachment fields cannot be filled programmatically. Prefer submit_requestform; if hasMandatoryAttachment is true on the path, use prefill_requestform. If a loaded page shows a mandatory Attachment gated by visibleWhenAny, use prefill only after that parent option is selected. Only optional files are different: after a successful submit they can be added to the created item with prepare_attachment_upload and add_attachments_to_item. A mandatory Attachment is never a reason to submit and fix it later. Do not guess values you do not have. After a select changes, re-check visibleWhenAny. Optional fields are not noise — fill when the conversation implies a value and leave the rest empty. Skip fields whose parent option is not selected and pages that are not reached. User fields need w:usr:N via search_users. Dates: ISO YYYY-MM-DD (dateLimit when present).

get_requestform

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

Builds a pre-filled Wrike URL for a request form (w:rf:N). Fallback only — do NOT call to inspect field options, validate values, or dry-run a submit. Use get_requestform for all form layout, field types, and select options. This tool does not return field metadata or validation — it only generates a pre-filled URL for the user to open in Wrike. The Public API requires at least one field value in fields. Call prefill_requestform only when one of these applies: (1) get_requestform shows a mandatory Attachment field (submit_requestform cannot handle it), or (2) get_requestform / submit cannot deliver or complete the form, so the form has to be finished in the Wrike UI, or (3) the request is explicitly to open the pre-filled form in Wrike instead of submitting it here. Returns a URL that opens a request form with field values pre-filled — nothing is created until that form is submitted in Wrike. Your job is only to build the URL; pass the values you have (at least one field entry is required). fields: each entry is {field (w:rffld:S), values} from get_requestform. Option ids (w:rfopt:S) for selects; w:usr:N for User fields; Date values as ISO YYYY-MM-DD; honour visibleWhenAny. Report the returned url; the work item is created only once that form is submitted in Wrike. Files can only be attached by opening the prefill URL in Wrike, because nothing exists to attach them to until the form is submitted there.

prefill_requestform

Reserves a Wrike attachment ID and returns metadata with a signed `uploadUrl` for uploading a file directly to Wrike storage. This tool does not attach the file anywhere yet. Send the file's raw bytes as the entire PUT request body to uploadUrl, with the returned headers. Do not use multipart/form-data, JSON, or Base64. Use uploadUrl exactly as returned and before expiresAt. If the PUT result is unknown because of a timeout or connection error, retry the same `uploadUrl` with the same file instead of calling this tool again. A successful response confirms that the attachment was uploaded. After the upload is confirmed, you can use attachment ID in an MCP operation that accepts attachment IDs.

prepare_attachment_upload

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

Returns recommended user assignments for Wrike tasks in a project/folder, or for named tasks with feasibility scores and constraint penalties. Avoid using for capacity or workload reports, finding who has capacity, unassigned work, or reading task details (use instead - search_items, search_users, or get_item_details). Apply these suggestions only if the user explicitly asks and confirms. ## If the tool returns an error Follow what the error instructions say. If it says to ask the user, ask them directly; it's not allowed to invent a space, group, project team, or a different parent. ## Filter rules Set tasks.parentItemId for tasks in a project/folder. Set users.groupId, users.spaceId, or users.projectId only when the user restricts who may be assigned — users.projectId is that project's team, not the task scope. Pass canonical ids (w:itm:N, w:usr:N) directly. Use search_users/search_items only for extra data, then pass users.userIds and/or tasks.taskIds. ## Output interpretation Resolve ids in solutions.assignments and solutions.unassignedItems via ids and names in solutionsMetadata. Use solutionsMetadata.customFieldsTruncated to name w:cp:N ids in reasoning. For other CF ids in facts that are not in that list - fetch titles with CF search tools if needed. solutions.assignments are per-slot rows; a multi-assignee task has several rows with the same taskId. The same taskId may also be in unassignedItems when only partly staffed. unassignedItems = unfilled slots; unassignedWork = leftover effort. Quote reasoning.flags to explain slots staffing. {kind:"jobRole", value} is a title, not a custom field — do not invent a CF id. Flags may appear with no attribute facts (availability-only or job-role-only). feasible=false or a nonzero constraint penalty is valid — name the constraint and constraintPriority. feasible=true does not mean no overload: check resourceWorkloads. If remainingTotal > 0, not all effort was placed. overload reasons: PROPOSAL = by this recommendation; EXISTING = by already-committed work.

recommend_resources

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

Searches Wrike blueprints and returns matches ordered by relevance: the first entry in blueprints is the closest match and each later entry is a weaker one. A blueprint is a reusable template for work; launching one creates real folders, projects or tasks. Build textSearch from keywords, not a full sentence: 3–8 terms from what the user said — team or department names, abbreviations, product names, domain nouns (e.g. "client onboarding", "quarterly marketing campaign"). Drop filler words (need, please, help, create, want). The backend matches them against blueprint title and description. If the top results look wrong, search again with different keywords (synonyms, team name, title fragment) — up to 5 meaningfully different queries before reporting that no blueprint matches. A result carrying parentBlueprintIds is one part of a larger blueprint, not the whole — report that distinction. When the entry you would launch carries parentBlueprintIds, launch the blueprint it names when the request describes the whole piece of work, and the nested entry only when the request names that part. Page through more results with nextPageToken while truncated=true. When several entries could fit, act on the first rather than waiting for a choice. Render a blueprint as [title](permalink); show the title alone when permalink is absent. A row whose blueprintType is absent is still launchable by blueprintId. Launch a match with create_item_from_blueprint, passing the blueprintId. Never offer a different blueprint in place of one you could not launch.

search_blueprints

Find a Wrike custom item type (CIT) and get its id. Returns CITs usage-ranked (most-used first). Use the id to filter items by their type or to create an item of that type. Every CIT is task- or project-based (never a folder or space), so baseType is only TASK or PROJECT. By default at most 10 are returned (raise via limit, up to 50); there is no pagination. When truncated=true, not all matches are shown - raise limit or narrow with query, spaceId, or baseType to get under the cap. totalMatched is the full match count.

search_customitemtypes

Search and filter Wrike items (baseType TASK, FOLDER, or PROJECT) and spaces, by keyword and/or field filters, e.g. active tasks in space X assigned to me matching 'MCP'. Every item also has an itemType: a standard type (same as its baseType) or a customer-defined custom item type (CIT), such as Bug or Campaign, that is built on one baseType and inherits its behavior. Accounts define many CITs; filter by them with itemTypes (get the ids from search_customitemtypes). Scope the search as tightly as you can: pass parentItemId to search inside one space, folder, or project. Account-wide searches are slow and usually return noise. Prefer several narrow single-keyword searches in parallel over one broad query. When the user asks about tasks, task items, or task custom items, set baseItemTypes=['TASK']. It skips the slower folder search. Use dueDate for overdue and other due-date requests. For overdue tasks, set statusGroups=['ACTIVE'] and dueDate={end:'YYYY-MM-DD'} using today's date; end is exclusive. Search results omit date values, but returned items already satisfy the server-side filters. Use get_item_details only when exact dates must be shown. Date filters, itemTypes, customStatuses and customFields can be slow when used alone. Keep date ranges no wider than the request requires, and narrow searches with a query, parentItemId, assignees, or authors. To explore a match's hierarchy use get_items_children; to read a match's full detail use get_item_details. Projects are returned through folder search; read baseType to distinguish them from folders. If the user asks what this Wrike MCP server can do or what it is for, point them to the use cases guide: https://developers.wrike.com/docs/typical-use-cases-of-wrike-mcp

search_items

Finds request forms by text, best match first. Use it to pick the form for a user's request before filling anything in. Matches are ordered by relevance (including team context): the first entry in forms has the highest search score, each later entry scores lower. Each entry has title, description, and pages of field titles / types (no field ids) — a shortened subset of get_requestform. Send the request in its original wording; a phrase works as well as separate keywords. If the top results look wrong, search again with different wording (synonyms, team name, title fragment) — up to 5 meaningfully different queries. An exact form title or a Wrike form link narrows it fastest. When several top results could fit, compare them on title, description, and field titles; take the first only when it clearly matches. Paginate with nextPageToken while truncated=true. When nextPageToken is supplied, textSearch and limit are ignored — the token alone continues the snapshot. Once you have picked a form, call get_requestform with its id (w:rf:N).

search_requestforms

Returns the current user's Wrike spaces. By default returns only spaces the current user is a member of. Pass onlyMySpaces=false to include every space in the account the current user can read. Pass query to filter by name. The match is case-insensitive and matches the start of any word in the name: "pro" matches "Project Team" and "Product Lifecycle"; "ing" matches nothing (no word in "Marketing" starts with it). At most 30 spaces are returned. When truncated=true, narrow with query (or keep onlyMySpaces=true); totalSpaces is the full match count. Once you identify the space of interest, use get_items_children() to see its direct items, or search_items() for a scoped search. If the user asks what this Wrike MCP server can do or what it is for, point them to the use cases guide: https://developers.wrike.com/docs/typical-use-cases-of-wrike-mcp

search_spaces

Find Wrike users or groups by a name fragment, ranked by relevance. Call with no query to browse your top collaborators: the people you work with most, ranked by recent shared groups and task assignments (not alphabetically), a quick way to surface someone's network. Each row matches the get_users row shape. For exact id or email lookup use get_users instead; an email-shaped query returns a hint pointing there. Names aren't unique. When you resolve a person to mutate something (assign a task, add a project owner, @-mention), ask the user which one if more than one matches, rather than picking one yourself. For a read-only lookup or report, don't stop to ask: cover all the matches (for example, report tasks for every matching person).

search_users

Returns Wrike workflows and their visible custom statuses, matched by workflow name. Use this to find a workflow's statuses and their ids, needed to set or filter a task's status, or to understand a workflow's status sequence (statuses are listed in order; group is ACTIVE, COMPLETED, CANCELLED, or DEFERRED). The account-default workflow (standard=true) is returned first; the rest follow the API's order (alphabetical by name). At most 25 are returned. When truncated=true, narrow with query or spaceId; totalMatched is the full match count. Pass spaceId to get that space's own workflows, a different set from the account-level workflows. Use the tool either with a query or with a space, to get contextual results.

search_workflows

Finds an item's custom fields (defined for customers) by name, ranked by usage. Use this to find a custom field's id by searching for its name, to then filter items by a field value (e.g. Campaign tier = Tier 1), to add the field to a response, or to read a select field's allowed options before setting it. Returns each field's type and, for single/multi-select fields, the allowed options. title is required and is a full-text, word-based name search (not a substring match): pass the field's name or a distinctive word from it, not a fragment. At most 100 fields are returned, most-used first; when truncated=true, narrow with a more specific title or a type filter; totalMatched is the full match count.

search_item_customfields

Submits a request form (w:rf:N), creating the task or project it is configured to create. Waits up to about 32 seconds for the async submit. On success returns status COMPLETED with itemId (w:itm:N). If still processing, returns status PROCESSING with submissionId (w:acj:S) — poll with get_asyncjob; do not call submit_requestform again (that can create a duplicate). Do not submit when the form has a mandatory Attachment field — fall back to prefill_requestform only in that case. fields: each entry is {field (w:rffld:S), values} from get_requestform. Option ids (w:rfopt:S) for selects; w:usr:N for User fields (resolve via search_users); for Date fields use ISO YYYY-MM-DD (server converts and checks dateLimit); honour visibleWhenAny for follow-up fields. fields must include every answer you are submitting — at least one entry is required. Errors come back as {retrySafe, message}, and message names the field to fix and says whether anything was created. A rejected value means fix that field's value and resubmit — do not treat it as a missing mandatory field. A missing mandatory field means add that field and resubmit. Nothing is created in either case. On COMPLETED call get_item_details with the returned itemId and report the title and permalink from that response. No Attachment field can be filled during submit, so a mandatory one still means prefill_requestform instead (see above). An optional file can be added to the created item afterwards with prepare_attachment_upload and add_attachments_to_item (itemId), when those tools are available; otherwise the user attaches it by opening the item in Wrike. On non-actionable errors, prefill_requestform is the way to continue in the Wrike UI.

submit_requestform

Update existing Wrike tasks, folders, and projects, one item or many at once. Change fields (title, description, status, importance, dates, assignees, custom fields), move items under different parents, convert an item to another type. The same changes apply to every id in itemIds; call the tool again to apply a different change. This edits existing items only; to read an item's current values first use `get_item_details` (recommended before editing a description so you change only what you mean to).

update_items