Adobe Workfront

Creates a new approval workflow for one document version using an existing template. This is create-only: it does not update an existing approval workflow and returns without changes when one already exists. template_id must be the template GUID. Accepts one document version per call. Approval structures, templates, and caller context vary by instance — pulling both from the available context tools improves accuracy here.

approvals_create_approval_from_template

Create a new reusable approval workflow template. This is create-only and does not update an existing template. This is the dedicated tool for creating approval templates. Use it only when the user explicitly asks to create a reusable template; to set up an approval on a specific document, use create_or_update_approval_workflow. Every stage must declare its prerequisites via `dependsOn` (use [] for the first stage / parallel roots). Most templates are LINEAR: stages[0].dependsOn=[], stages[1].dependsOn=[0], stages[2].dependsOn=[1], and so on. Use a graph only when the workflow genuinely requires parallel branches or fan-in. Resolve every participant to its ID before calling this: use the Insights `search_users` tool for people and the Insights `find_id_by_name` tool for teams (set the participant's participantType to USER or TEAMOB accordingly). Never pass a participant name. Approval structures, templates, and caller context vary by instance — pulling both from the available context tools improves accuracy here.

approvals_create_template

Create a new basic board, optionally inside a workspace. Creates a standard board (no dynamic/kanban/connected-service setup — those are configured in the web UI). Returns the new board id, name, and template.

boards_create_board

Create a new tag in a board’s tag catalog (then use update_card with tags_to_add to apply it). Returns the new tag. Tag names must be unique on the board.

boards_create_board_tag

Create a Planning business rule (formula-based validation) on a record type. The rule's expression is evaluated by the Calculation Engine when the chosen operation fires. A non-blank result is treated as a VIOLATION and blocks the write, surfacing messageKey to the user. CONSTRAINTS (enforced server-side): - operation: only "UPDATE" or "DELETE". - objectType: only "RECORD". - recordTypeId must be a non-global record type in the workspace. - expression is validated by the Calculation Engine; bare $$BEFORE_STATE / $$AFTER_STATE are rejected — use $$BEFORE_STATE.{fieldName}. PREREQUISITE: read docs://formula-syntax — especially its "Business Rule Expressions" section for the violation-return pattern (return a message to block, "" to pass) and the $$BEFORE_STATE/$$AFTER_STATE.{fieldName} syntax — then call get_record_type to confirm the record type and field ids.

planning_create_business_rule

Create a new card on a board in the given column. Returns the created card. To assign members, move, or tag the card afterwards, use update_card. To create it already connected to Workfront in one step (the safe way to connect — an empty card has nothing to lose), pass connect_object_type + connect_project_id + connect_project_name; resolve the project with the Workfront insights tools first.

boards_create_card

Add a checklist item (or subtask) to a parent card. Returns the new item. Use update_checklist_item to rename or mark it done.

boards_create_checklist_item

Add a new plain column to a board. Creates a standard column with the given name (no WIP limits, automation, or intake/dynamic filters — those are configured in the web UI). Returns the board id and its columns so you can find the new column id.

boards_create_column

Create a new comment on an object. Supports rich text, HTML content, tags, and attachments. IMPORTANT: 1) When tagging users or teams, you MUST use the "tags" array with objects shaped as: { id: string, objCode: "USER" | "TEAMOB" }. For users, ALWAYS use the Workfront wfId (32-character hex string). 2) Use dry_run: true first to preview the comment and confirm it is correct before posting. A dry run returns the validated payload and NEVER sends any notifications. RECORD objects (objectCode: "RECORD"): the response will NOT include a `links` field for RECORD objects. Construct the URL client-side using this format: - Updates/details page: {host}/maestro/{workspaceID}/{recordTypeID}/{recordID}/record/details - Specific comment: {host}/maestro/{workspaceID}/{recordTypeID}/{recordID}/record?commentID={commentID} Use the comment's `_id` for {commentID}. Resolve {workspaceID} and {recordTypeID} by calling the maestro lookup tools available in your session (look up by recordID = the comment's `objectID`). {host} matches the host used to invoke this MCP server.

comment-stream_create_comment

Create a brand-new record/object in an external connected system (e.g. create a new Workfront project, portfolio, or program). The record type must be an external record type linked to a supported connection object. Supported Workfront object types: PROJECT, PORTFOLIO, PROGRAM. Optional metadata key/value pairs are spread into the external record payload at creation time. IMPORTANT: Use this ONLY to create a brand-new external object. To LINK or ASSOCIATE an EXISTING Workfront project (or portfolio/program) to a Planning record, do NOT use this tool — instead use bulk_record_actions to set the record's connection/reference field value to the existing object's raw Workfront external ID. Workspace/record-type/field schemas and caller context vary by instance — pulling both from the available context tools improves accuracy here.

planning_create_connection_record

Create an empty Reporting dashboard. Returns the full created dashboard (id, title, description, currency, creatorId, createDate, and an empty widgets/prompt/filter) — do NOT read it back afterward; the dashboard has just been created and a read-back right after create can transiently fail while its access permissions propagate. The returned id is all you need to add widgets via the create_widget tool. Currency defaults from the X-Currency header, then the customer base currency, then USD.

reporting_create_dashboard

Create one or more fields (columns) on a record type. PREREQUISITE: Call get_record_type first to check existing field names (displayName must be unique). Read docs://field-types for available types and options. For formula fields, also read docs://formula-syntax for syntax and available functions. LOOKUP / ROLLUP FIELDS: Use type "lookup" with lookupOptions containing: referenceFieldId (the existing reference field connecting the two record types), sourceFieldId (the field on the linked record type to pull values from), and optionally rollup ("sum", "avg", "min", "max", or "dist"). The displayName for lookup fields is auto-generated. NOTE: The primary (Name) field of the linked record type cannot be used as sourceFieldId. Not atomic — check the hasErrors flag in the response. Per-item results show success/failure with error details. When tool B needs an ID returned by tool A, call them in SEPARATE turns. Wait for A's response, then use the actual returned ID in B. Hierarchy: Workspace → Section → RecordType → Field/View/Record. For reference fields: referenceOptions.recordTypeId MUST differ from the source recordTypeId (the record type you are adding the field to) — self-reference is not supported. Workspace/record-type/field schemas and caller context vary by instance — pulling both from the available context tools improves accuracy here.

planning_create_fields

Queue an asynchronous Workfront import from a complete file. Before building or checking a file, read the import guide with read_workflow_docs (workfront://importer/guide) for the layout and get the field labels from get_export_schema. CREATE adds objects; UPDATE edits existing ones and REPLACES all rates of every parent with rate rows in the file, so confirm UPDATE with the user first. Preserve the original fileName (if you converted the file, use a name whose extension matches the new content) and send the complete file bytes as standard base64 (not base64url, a data URL, or raw JSON or text); the file must be under about 750KB. Never retype file contents into this call: if your client can call tools from code, call create_import from the code that read the file, print its raw result without parsing it, and read the ID yourself. The returned ID means queued, not done: call get_import_status until state is FINISHED. Do not retry an uncertain submission.

workflow_create_import

Create a new Workfront object of the given objectType. Supported types: projects, tasks, issues/requests, project templates and template tasks, portfolios, programs, hour entries, assignments, plus users, teams, roles, and groups (admin only). - The 'data' parameter is REQUIRED on every call and must include the object's 'name' plus any required parent IDs — never invoke this tool with an empty or partial payload. - To attach MULTIPLE custom forms at creation time, use the top-level 'objectCategories' parameter (a sibling of 'data', not nested inside it) — see its own description for the required shape. 'categoryID' inside 'data' remains the single-form shortcut. Never set both. - When the user references a parent or related object by name (project, portfolio, owner, assignee), FIRST call insights_find_id_by_name (entity = the objectType) to obtain its ID, THEN call create_any_object in the same turn — do not stop after the lookup. If the result is ambiguous, ask the user to choose from the returned options instead of guessing. - Use a field's `name` from insights_search_fields as the data key; if `name` is not set, fall back to its `label`. Discover unknown fields with insights_search_fields before adding them. If more than one field matches the label the user used (e.g. a standard and a custom field both labeled "Description"), use the exact key of the one the request points to. If the request doesn't say which, ask the user when you can; otherwise use the standard field and say in your reply which field you used. A bare label that matches more than one field is rejected with each candidate's exact key — retry with one of them. - To submit an issue/request to a request queue, set 'projectID' to the target project — its own default routing, approval process, and category already apply automatically on any create, whether or not the project's queue is published as a public request queue. Only resolve and set 'queueTopicID' (objectType 'queueTopic') when the user names or clearly implies a specific topic — that layers topic-level routing, approval, and category on top, and can even reassign 'projectID' via the topic's routing rule. Do not search for a topic speculatively when none was named. The server does not verify a 'queueTopicID' belongs to the target project's queue, so only resolve one from a topic the user actually named. Do not send entryPoint or isHelpRequest — the server derives those. - A queue submission must file a COMPLETE ("ready") request, not a bare issue: before submitting, gather the fields the queue's request form expects and ASK THE USER for their values — never invent, default, or guess field values (not the Subject, description, priority, dates, or any custom field). Read the queue's standard fields from 'queueDef:visibleOpTaskFields' on the project; always ask for 'name' (request forms label it "Subject") plus the other visible fields (e.g. description, priority, planned dates) and any required custom-form 'DE:<label>' fields — the queue's (or chosen topic's) default form applies automatically. If the user has not supplied a value for a field, ask for it before submitting rather than filling it in yourself; if a required field is rejected on submit, ask and retry. Only call this tool once you have the user's own values. - You MUST call read_workflow_docs with workfront://tools/create-any-object BEFORE this tool whenever the request involves a status/enum value, a filter modifier other than plain equality (_Mod/_Range), a date comparison, a scheduling or date field on a project or task (scheduleMode, taskConstraint, plannedStartDate, plannedCompletionDate, constraintDate), a task dependency field (predecessorExpression), a task duration field (durationExpression), a relation path (a field containing ":"), result ordering (orderBy), a custom form attachment (objectCategories), or a force delete. Skip it only for a pure required-field create with no status/enum, custom field, or related-object ambiguity. - For some accounts, a slow create returns { status: "pending", jobId, message } instead of the created object. If you see that, call check_job_status({ jobId }) again every 5-10 seconds until it reports "completed" or "failed" — do not treat "pending" as an error or retry create_any_object itself. OUT OF SCOPE for these any-object tools — do not attempt, do not imply success: - Uploading or attaching a document - Posting a comment or replying to a comment thread - Creating or advancing an approval/review step - Setting or comparing a project baseline - Logging or approving an expense - Creating a milestone (or milestone path) - Adding a note - Restoring an object from the Recycle Bin For any of these, check whether a dedicated tool for that action is available before falling back to the object's Workfront UI page (the `url` field on a returned object, or https://<host>/<urlSegment>/<objectID>). Object types, custom fields, and caller context vary by instance — pulling both from the available context tools improves accuracy here.

workflow_create_any_object

Use this for any request to set up, add, or change approvers or reviewers on a document — e.g. 'create an approval with X as approver', 'add a review stage'. This is the dedicated tool for document approval workflows. Creates a new approval workflow or updates an existing workflow's stages for a document version; it is not create-only. Every stage must declare its prerequisites via `dependsOn` (use [] for the first stage / parallel roots). Most workflows are LINEAR: stages[0].dependsOn=[], stages[1].dependsOn=[0], stages[2].dependsOn=[1], and so on. Use a graph (parallel branches, fan-in) only when the workflow genuinely requires it. Provide all desired stages — this replaces or extends the existing workflow. WARNING: for a stage matched to an existing one (by stageId or name), the `participants` array you provide REPLACES that stage's entire participant list — anyone you omit is removed, including their recorded decision. Before updating an existing stage (e.g. to add an AI Collaborator bot), call get_approval_info first and include every participant you want to keep, unchanged, alongside any new addition. Add a new participant (human or bot) onto an EXISTING stage — ask which stage if unclear. Only create a new stage if the user explicitly asks for a separate review stage. On clients that support MCP Apps, a visual preview is shown for confirmation. On clients that support elicitation but not apps, the user is asked to confirm inline. Otherwise the change is applied directly. CUSTOM MESSAGES: each stage may carry a per-stage plain-text customMessage shown to that stage's approvers/reviewers in the FIRST-activation notification email (never in reminders). When creating a brand-new approval (no existing stages on this document), ask the user before creating it whether they'd like to add a custom message to any stage — e.g. "Want to add a custom message to any stage, or should I go ahead and create the approval as is?" — do not create it without asking first. Set or replace it by passing the text; remove it by passing null (empty string is rejected); OMIT the field to keep an existing message when you change other fields. Before replacing an existing message, read the current one with get_approval_info and confirm the replacement with the user — the response, and any preview/confirmation shown to the user, includes a before/after diff of the message change, but that is not a substitute for confirming first. If the approval is closed (approved/rejected/withdrawn), tell the user it is no longer active and confirm before proceeding — do not silently block. If no stage is named, default to the currently active stage; if none is active and none is named, ask which stage. If the target stage was already activated, warn that its notification already went out and the message will not be re-sent. Approval structures, templates, and caller context vary by instance — pulling both from the available context tools improves accuracy here.

approvals_create_or_update_approval_workflow

Create one or more record types. A default table view is created automatically for each; do not create another unless the user explicitly wants multiple table views. PREREQUISITE: The workspace must have a section — call update_workspace to add one if needed. Read docs://workspace-setup-guide for best practices on record type design, field configuration, and connection patterns. isGlobal=true requires admin privileges (check is_admin in user_info); default to local record types. Not atomic — check the hasErrors flag in the response. Per-item results show success/failure with error details. When tool B needs an ID returned by tool A, call them in SEPARATE turns. Wait for A's response, then use the actual returned ID in B. Hierarchy: Workspace → Section → RecordType → Field/View/Record. Workspace/record-type/field schemas and caller context vary by instance — pulling both from the available context tools improves accuracy here.

planning_create_record_types

Create a reply to an existing comment. Supports rich text, HTML content, tags, and attachments. IMPORTANT: 1) When tagging users or teams, you MUST use the "tags" array with objects shaped as: { id: string, objCode: "USER" | "TEAMOB" }. For users, ALWAYS use the Workfront wfId (32-character hex string). 2) Use dry_run: true first to preview the reply and confirm it is correct before posting. A dry run returns the validated payload and NEVER sends any notifications. RECORD objects (objectCode: "RECORD"): the response will NOT include a `links` field for RECORD objects. Construct the URL client-side using this format: - Updates/details page: {host}/maestro/{workspaceID}/{recordTypeID}/{recordID}/record/details - Specific comment: {host}/maestro/{workspaceID}/{recordTypeID}/{recordID}/record?commentID={commentID} Use the comment's `_id` for {commentID}. Resolve {workspaceID} and {recordTypeID} by calling the maestro lookup tools available in your session (look up by recordID = the comment's `objectID`). {host} matches the host used to invoke this MCP server.

comment-stream_create_reply

Create a new view for a record type. Views define how records are displayed: table (spreadsheet), timeline (Gantt chart), or calendar. Can configure filters, sorting, grouping, coloring, table columns and column totals, timeline zoom and layout, and (timeline only) a connected record breakdown during creation. Read docs://view-types for the settings each view type uses. For filter configuration, read docs://filter-operators for supported operators by field type. When tool B needs an ID returned by tool A, call them in SEPARATE turns. Wait for A's response, then use the actual returned ID in B. Hierarchy: Workspace → Section → RecordType → Field/View/Record. Workspace/record-type/field schemas and caller context vary by instance — pulling both from the available context tools improves accuracy here.

planning_create_view

Create a widget and its report configuration on a dashboard. One tool for all widget types — set widgetType to "MultiSeries" (a chart), "Kpi", or "Table". Required fields depend on widgetType: MultiSeries needs aggregationFieldId, aggregationType, groupByFields, chartType; Kpi needs fieldId, aggregation; Table needs columns. Each parameter documents the type(s) it applies to; fields for other types are ignored. Never pass a widgetId — this tool only creates. Returns the full created widget in the same flattened shape as read widget mode (shell plus content configuration, field references as { id, label, dataType }), so you normally do not need a follow-up read. If the just-written content cannot be read back immediately, only the shell (id, layout, contentMetadata) is returned — check for the type-specific content (MultiSeries: `aggregationField`; Kpi: `field`; Table: `columns`) and read the widget (id + widgetId) to fetch it if missing. Chart types: BAR, COLUMN, LINE, PIE; BAR/COLUMN support SIMPLE/MULTI_SERIES/STACKED sub-types (LINE and PIE are always SIMPLE); SIMPLE requires exactly 1 group-by field, MULTI_SERIES/STACKED require 2. Filters use kind "condition" or "group". Default stacked widget sizes by type are Kpi 3x4, Table 12x10, MultiSeries 6x8, Calendar 3x4; explicit widget minimum size is 2x3.

reporting_create_widget

Create a new empty workspace. A workspace is a container for organizing related record types, fields, and data. Read docs://workspace-setup-guide for best practices on workspace structure, naming conventions, and section organization. When tool B needs an ID returned by tool A, call them in SEPARATE turns. Wait for A's response, then use the actual returned ID in B. Hierarchy: Workspace → Section → RecordType → Field/View/Record. Workspace/record-type/field schemas and caller context vary by instance — pulling both from the available context tools improves accuracy here.

planning_create_workspace

Create a new workspace from a template. The template provides pre-configured record types, fields, views, and sample data. Use get_template_list to find available templates and get_template for full template details. Optionally override the workspace name, description, icon, and alias after creation from the template.

planning_create_workspace_from_template

Delete a single stage from an approval workflow by name or position (e.g. 'Legal Review', 'stage 2', 'last stage'). Only not-started stages can be deleted. For approvals with parallel paths, use remove_stage_from_path instead — this tool only works on single-path approvals. Approval structures, templates, and caller context vary by instance — pulling both from the available context tools improves accuracy here.

approvals_delete_approval_stage

Permanently delete a board and all its cards and columns. Irreversible. For the common case of hiding a board without losing it, use update_board with is_archived: true instead — that can be undone. Only the board owner or a system admin can delete it.

boards_delete_board

Delete a user business rule by id. Permanent, cannot be undone. System rules are not visible to this API.

planning_delete_business_rule

Delete a checklist item from its parent card. Returns the updated parent card.

boards_delete_checklist_item

Delete a column from a board. If the column still has cards, pass to_column_id to move them to another column — otherwise the delete is rejected so cards are not lost. Returns the board id and its remaining columns.

boards_delete_column

Delete a comment by its ID. Marks the comment as deleted and updates the deleted metadata. Users can only delete their own comments or must have admin privileges. RECORD objects (objectCode: "RECORD"): the response will NOT include a `links` field for RECORD objects. Construct the URL client-side using this format: - Updates/details page: {host}/maestro/{workspaceID}/{recordTypeID}/{recordID}/record/details - Specific comment: {host}/maestro/{workspaceID}/{recordTypeID}/{recordID}/record?commentID={commentID} Use the comment's `_id` for {commentID}. Resolve {workspaceID} and {recordTypeID} by calling the maestro lookup tools available in your session (look up by recordID = the comment's `objectID`). {host} matches the host used to invoke this MCP server.

comment-stream_delete_comment

Delete a Field by ID. This permanently removes the field from its record type, including all data stored in this field across all records. This action cannot be undone. The field must exist and the user must have EDIT permission on the record type. Workspace/record-type/field schemas and caller context vary by instance — pulling both from the available context tools improves accuracy here.

planning_delete_field

Delete a Workfront object by ID. Supported types: projects, tasks, issues/requests, project templates and template tasks, portfolios, programs, hour entries, assignments, plus users, teams, roles, and groups (admin only). - MUST obtain explicit user confirmation (object type, ID, and name) before invoking. If the user's CURRENT message already contains explicit confirmation language ("yes, delete it", "I'm sure, delete X", "confirm delete"), proceed without re-prompting — do NOT ask again. Only ask if the message merely describes the deletion without confirmation. - When the user identifies the target by name, FIRST call insights_find_id_by_name (entity = the objectType) to obtain its ID, THEN call delete_any_object in the same turn — do not stop after the lookup. If the result is ambiguous, ask the user to choose from the returned options instead of guessing. - 'force: true' bypasses the Recycle Bin and is permanent; warn the user and require a second confirmation before passing it. - You MUST call read_workflow_docs with workfront://tools/delete-any-object BEFORE this tool whenever the request involves a status/enum value, a filter modifier other than plain equality (_Mod/_Range), a date comparison, a scheduling or date field on a project or task (scheduleMode, taskConstraint, plannedStartDate, plannedCompletionDate, constraintDate), a task dependency field (predecessorExpression), a task duration field (durationExpression), a relation path (a field containing ":"), result ordering (orderBy), a custom form attachment (objectCategories), or a force delete. Skip it only for a confirmed, non-force delete after a pure identity equality lookup. OUT OF SCOPE for these any-object tools — do not attempt, do not imply success: - Uploading or attaching a document - Posting a comment or replying to a comment thread - Creating or advancing an approval/review step - Setting or comparing a project baseline - Logging or approving an expense - Creating a milestone (or milestone path) - Adding a note - Restoring an object from the Recycle Bin For any of these, check whether a dedicated tool for that action is available before falling back to the object's Workfront UI page (the `url` field on a returned object, or https://<host>/<urlSegment>/<objectID>).

workflow_delete_any_object

Delete a Record Type by ID. This will permanently remove the record type and ALL its data including all records, fields, and views. Requires MANAGE permission. WARNING: This action cannot be undone. All records of this type will be permanently deleted. Workspace/record-type/field schemas and caller context vary by instance — pulling both from the available context tools improves accuracy here.

planning_delete_record_type

Delete a view by ID. This permanently removes the view configuration but does NOT delete records. Requires MANAGE permission. Cannot be undone. The last table view in a record type cannot be deleted. Workspace/record-type/field schemas and caller context vary by instance — pulling both from the available context tools improves accuracy here.

planning_delete_view

Delete a workspace by ID. Permanently removes the workspace and all its data. Requires MANAGE permission. Use workspace ID only (not name/alias); use get_workspace_list to find the ID if needed. Workspace/record-type/field schemas and caller context vary by instance — pulling both from the available context tools improves accuracy here.

planning_delete_workspace

Find and resolve a named Workfront object — project, task, issue, user, portfolio, program, team, document — to its GUID for use in a filter condition.

insights_find_id_by_name

Use this to answer questions like "show me my tasks", "what's due this week", "list open projects", "find tasks assigned to me", "how many issues are overdue", "which projects are behind schedule", "count tasks by status", "show unassigned tasks", "get planned hours for a project", "find issues submitted this month", "what project templates are available". This is the primary read/query tool for all Workfront data retrieval. REQUIRED: call read_docs("mcp-usage") first if you have not already done so this session. Search, list, filter, count, sort, or retrieve Workfront data — projects, tasks, issues, users, portfolios, programs, teams, documents, milestones; returns rows, columns, totalCount. Object types, custom fields, and caller context vary by instance — pulling both from the available context tools improves accuracy here.

insights_find_workfront_data

Get the current approval workflow (stages, participants, status, stage IDs) for a document version. Each participant is listed with its participantId and, for AI Collaborator bots, its participantMetadata — carry both forward unchanged when re-submitting a participant via create_or_update_approval_workflow. To add an AI Collaborator (bot) as a brand-compliance reviewer: use insights_search_users (filtered to bots) to pick one, call this tool to read the target stage's CURRENT participants, then create_or_update_approval_workflow to add the bot alongside every existing participant on that stage unchanged, then check_brand_review_result to check the outcome. REQUIRED before sending reminders or modifying an existing approval — returns the stage IDs that send_approval_reminder and delete_approval_stage need. This is the canonical way to read approval state for a document. When the custom-message feature is enabled for the caller, each stage's customMessage is shown on a Message line when set. If no Message line appears, EITHER no message is set on that stage OR the feature is not enabled for you here — do not assert that none is set. Approval structures, templates, and caller context vary by instance — pulling both from the available context tools improves accuracy here.

approvals_get_approval_info

Fetch board data at varying detail levels. detail=list — discover all boards accessible to the authenticated user (board_ids ignored). detail=snapshot — full board record with all cards and columns (one board_id required). detail=summary — normalized pipeline view: columns, slim cards, aggregates, explicit gaps (one or more board_ids required). detail=candidates — simplified candidate rows (id, name, description, columnId) for connecting Workfront items (one board_id required). Use get_board when the result feeds a Boards write tool (resolved tag/member/status ids, live board aggregates). Use Insights find_workfront_data for ad-hoc reporting across board data. filter (detail=snapshot only) narrows the returned cards by column/status/assignee/tag. Snapshot cards carry commentTarget and connection (see the boards://guide/connected-cards resource).

boards_get_board

Get a single user business rule by id. System rules are not returned. Before diagnosing or editing the returned expression, read docs://formula-syntax. The two silent-failure traps: comparing a single-select/status field to its UI display name instead of the stored internal name (usually lowercase), and using ISBLANK, LEN, or COUNT on a reference/user/multi-select field (those are arrays — use ARRAYLENGTH({Field}) = 0; LEN counts characters and COUNT does not exist). Operators are && || ! and = / !=, not AND/OR/NOT.

planning_get_business_rule

Fetch a single card by board id and card id. Use get_card when the result feeds a Boards write tool (resolved tag/member/status ids). Use Insights find_workfront_data for ad-hoc reporting across board data. Every card carries commentTarget (where to post comments) and connection (null for a standalone card; Workfront status/sync info for a connected one) — see the boards://guide/connected-cards resource.

boards_get_card

Get a single comment by its ID. Returns detailed information about a specific comment. RECORD objects (objectCode: "RECORD"): the response will NOT include a `links` field for RECORD objects. Construct the URL client-side using this format: - Updates/details page: {host}/maestro/{workspaceID}/{recordTypeID}/{recordID}/record/details - Specific comment: {host}/maestro/{workspaceID}/{recordTypeID}/{recordID}/record?commentID={commentID} Use the comment's `_id` for {commentID}. Resolve {workspaceID} and {recordTypeID} by calling the maestro lookup tools available in your session (look up by recordID = the comment's `objectID`). {host} matches the host used to invoke this MCP server.

comment-stream_get_comment

Get the total count of top-level comments for a specific object, matching what `query_comments` would return across all pages. For container objects (e.g. PROJECT), the count includes comments on child objects (e.g. tasks, issues) the same way the listing tool does. Replies are not included in the count; they are nested under their parent comment in `query_comments`. RECORD objects (objectCode: "RECORD"): the response will NOT include a `links` field for RECORD objects. Construct the URL client-side using this format: - Updates/details page: {host}/maestro/{workspaceID}/{recordTypeID}/{recordID}/record/details - Specific comment: {host}/maestro/{workspaceID}/{recordTypeID}/{recordID}/record?commentID={commentID} Use the comment's `_id` for {commentID}. Resolve {workspaceID} and {recordTypeID} by calling the maestro lookup tools available in your session (look up by recordID = the comment's `objectID`). {host} matches the host used to invoke this MCP server.

comment-stream_get_comments_count