Wrike

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

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). Confirmation is a separate step after mapping fields. A user message that asks you to submit/create/file a request (even if it says "submit" and includes field values) is intent to start, not confirmation. Before asking for confirmation, show every field value you plan to submit in a regular assistant message as a markdown table with columns Field | Value | Source. Use human-readable field titles and option / user names, not ids. Source must state where each value came from, such as the user's message, a user selection, or an inference from context; clearly mark inferred or uncertain values. Do not put this preview into the host's native choice UI or compress it into prose. Invite the user to edit any value, and call out Date, budget, finance, and due-date fields. Name the optional fields you left empty in that same message so the user can add them before confirming. Then wait for an affirmative reply in a later message (e.g. "yes", "confirm", "go ahead", "submit it"). Do not call submit_requestform in the same turn as the initial request or the preview. 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 about a wrong value shape or range (e.g. Incorrect submit type, end_date_is_before_date, or wording that a field value is invalid) mean fix that field's value and resubmit — do not treat them as a missing mandatory field. Messages that say a mandatory field is missing mean add that field and resubmit. On COMPLETED call get_item_details with the returned itemId and give the user [title](permalink) from that response. If the form had any Attachment field (mandatory or optional), follow with a separate callout heading (not a buried one-liner), for example: ## Attach files in Wrike Attachments can't be added through this channel. Open the item and attach there: [title](permalink) On non-actionable errors, offer prefill_requestform only if the user wants to continue in the 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