Wrike MCP — conversation tools over a live project API

Context

In a multi-site hospitality IT/PMO environment, project truth lived in Wrike, but keeping it current was a human bottleneck: PMs chased updates across chat and spreadsheets, then re-typed status into the system of record. Stakeholders (support, ops, vendors, finance-facing programs) needed trustworthy live status without adding headcount. Constraint: agents could help only if writes were governed—no unbounded mutations in production Wrike.

Intervention

Shipped conversation-driven Wrike MCP servers so an agent loads and updates items through a few tools, with item types and workflows generated from the API into YAML.

Phase 1 — Tool shape

One tool per file. get_wrike_item accepts a permalink or id and returns title, description, custom item type, task status, and surface custom fields. convert_wrike_link translates a browser URL to an API id. list_folder_contents and get_custom_item_types cover navigation. Creation prefers add_item_to_parent, which picks the child type from the hierarchy, including natural-language aliases.

Phase 2 — Registry, not a hand-maintained ID list

wrike:bootstrap writes item types from the API; wrike:bootstrap-workflows writes workflows and custom statuses. An overlay YAML holds hierarchy and aliases and is validated on its own. The server merges generated config and overlay. Mutations are narrow: rename, description, status or customStatusId (not both), folder parents.

Phase 3 — Two transports, one space lock

The same tool idea ships as stdio and as streamable HTTP. A sibling server is locked to a single Wrike space so item types, workflows, and custom fields cannot drift onto another account. Agents draft and flag; a person still accepts the change in Wrike.

Risks & how they were handled

• Wrong writes in production Wrike → mitigated with allow-lists, dry-run/review habits, and audit logs.
• PM distrust of “AI status” → kept humans accountable; agents draft/flag, PMs accept.
• API rate limits / outages → retries and fail-closed behaviour when Wrike was unavailable.

What I'd do differently

• Start with an even thinner tool surface (read + flag only) before allowing drafts.
• Codify eval fixtures earlier from real anonymized task samples.

Outcome

Before: PMs acted as status relays—typically on the order of ~15–30 min per covered project just to chase and paste updates into Wrike (est.). After: production MCP lets agents read/update live tasks, draft Definition of Done, and flag blockers under governance—so the PM pass is mostly review in the system of record (roughly a few minutes per agent batch when the project is covered, est.). Status no longer depends on chat archaeology.

System map

What shipped

← AI_devs Next: LocalOutbound →