Adobe Workfront

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.

planning_create_connection_record

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.

planning_create_fields

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>).

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.

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.

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.

planning_create_view

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.

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.

approvals_delete_approval_stage

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 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.

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.

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.

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.

planning_delete_workspace

[DEPRECATED] Do not use. This tool will be removed on 2026-09-30. Use the Insights `find_workfront_data` tool instead to look up documents (call `read_docs("mcp-usage")` first to get its playbook). Look up a document by filename OR by document version ID (DOCV) — provide exactly one. Use document_name when the user names a file ("winter-campaign.pdf"); use document_version_id when you have a DOCV from a Workfront URL or another tool. Returns document name, current version ID, and a Workfront document link per match (for name search) or full metadata (for version ID lookup). Matching by name is word-order-tolerant: 'pink whale' matches 'Whale-pink'. Behavior: single match → use it; multiple matches → return all and ask the user to pick; zero matches → tell the user the file was not found. For a document the user just uploaded this session, prefer the document_version_id delivered by the upload (workfront_document_upload_batch model context) rather than searching here; only fall back to this name lookup if that document_version_id isn't available.

approvals_find_document

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.

insights_find_workfront_data

[DEPRECATED] Do not use. This tool will be removed on 2026-09-30. Use the Insights `find_workfront_data` tool instead to look up projects (call `read_docs("mcp-usage")` first to get its playbook). Look up Workfront projects, optionally filtered by name and/or restricted to projects the calling user owns. Use a name fragment when the user names a project ("Winter Campaign", "Q4 Launch"); set owned_by_me when the user says "my projects", "projects I own", or "what am I working on". Behavior: owned_by_me alone → projects the user owns; name alone → matching projects across the system; both → owned projects whose name matches. Returns project name, ID, and status for each match — feed a project ID to get_documents_by_scope, then approval tools on the documents. Multiple matches → return a numbered list and ask the user to disambiguate; zero matches → tell the user.

approvals_find_projects

[DEPRECATED] Do not use. This tool will be removed on 2026-09-30. Use the Insights `find_id_by_name` tool with entity "team" instead to look up teams. Look up a Workfront team's ID by name (fuzzy/partial match). Call this whenever the user wants a whole team — not a single person — as an approver or reviewer ("send to the Design team", "Legal team should approve"). Approval and template tools accept teams as participants with participantType: "TEAMOB" and the ID this tool returns. Behavior: single match → use it; multiple matches → return a numbered list and ask the user to pick; zero matches → tell the user no team was found. The word "team" is stripped from the query automatically.

approvals_find_team_by_name

[DEPRECATED] Do not use. This tool will be removed on 2026-09-30. Use the Insights `search_users` tool instead to search for users. Call it with `query` (required user name), `bot_filter: "exclude"` (the default for human-only results), and `limit` (defaults to 25; maximum 25). Results expose identity fields at the top level: `wf_id`, `name`, `email`, `is_active`, and `is_bot`. Use `wf_id` as `participantId` with `participantType: "USER"` when calling `create_or_update_approval_workflow`. To find AI Collaborator bots instead, call `search_users` with `bot_filter: "only"`.

approvals_find_user_by_name

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.

approvals_get_approval_info

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

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

Find and retrieve the current user's Workfront identity (name, ID, URL) for personalizing a response. When to call: when the response should address the user by name or include a direct link to a Workfront object that needs the user's workfront URL as a base. Do NOT call this just because the question mentions "me" / "my" / "mine" — use the `$$USER.ID` sentinel directly inside conditions instead. This tool is for rendering a response, not for filtering. Returns: ok with {user_id, user_name, wf_url}.

insights_get_current_user

[DEPRECATED] Do not use. This tool will be removed on 2026-09-30. Use the Insights `find_workfront_data` tool instead to list documents in a project or folder (call `read_docs("mcp-usage")` first to get its playbook). List documents (with name and current version ID) inside a project or folder. Call this when the user wants to act on documents in a project or folder ("start approval on every file in the Winter Campaign project", "what's in the Final folder"). Pick the scope_type that matches the user's intent: - "project" → scope_id = project ID. Returns all documents in that project. - "folder" → scope_id = folder ID directly. Returns documents in that specific folder. - "folder_name" → scope_id = project ID, plus folder_name. Resolves the named folder within the project, then returns its documents. Returns a numbered list of documents with name and document version ID (DOCV). Feed the version IDs to approval / AEM / reminder tools. When scope_type=folder_name resolves to a single folder, the resolved folder ID is included in the response — pass it as folder_id to upload tools to target that folder. If folder_name matches multiple folders, the tool returns the folder options instead — re-call with scope_type=folder and the specific folder ID.

approvals_get_documents_by_scope

Find which Maestro workspaces and record types are connected to a specific external object. Use this to check whether an external record (e.g. a Workfront project) is already linked to a Maestro record, or to discover which workspaces/record types can accept a connection for that object type. Returns a list of entries, each containing the Maestro record linked to the external object and the workspace it lives in. See docs://connections for available connections and their supported object types.

planning_get_external_record_workspaces

Get Field details by ID. Returns field configuration and a fieldValueSchema describing how to format values for this field when creating or updating records. TIP: To see all fields on a record type at once, prefer get_record_type with attributes=['id','displayName','fields'].

planning_get_field

Get the sharing a field inherits from its record type (and, transitively, the workspace) — the grantees who can already see the field without an explicit field-level grant. Useful for showing inherited access alongside direct field grants in a sharing dialog. Requires MANAGE permission on the record type. Only available when field-level permissions are enabled. Operates on Planning/Maestro objects (workspace, view, record type, record) via the ReBAC AuthZ model. For classic Workfront objects (PROJ, TASK, OPTASK, DOCU, PORT), use the access-control_* tools instead.

planning_get_field_inherited_sharing

Resolve and retrieve dot-notation field paths for Workfront entities — projects, tasks, issues, users, portfolios, programs, teams — required by find_workfront_data(). Returns the single best root entity and, per field, all candidate paths.

insights_get_field_paths

Get field-level sharing: who may View or Edit a specific field's values. Returns a wildcard access level (EVERYONE_IN_WORKSPACE or SELECTED_USERS_ONLY) and the list of explicit grantees (users/groups/teams) with their field relation (viewer = View values, editor = Edit values). Requires MANAGE permission on the record type that owns the field. Only available when field-level permissions are enabled. For dynamic (global) record types, use scopeWorkspaceId. Operates on Planning/Maestro objects (workspace, view, record type, record) via the ReBAC AuthZ model. For classic Workfront objects (PROJ, TASK, OPTASK, DOCU, PORT), use the access-control_* tools instead.

planning_get_field_sharing

Get Record details by ID. Returns all attributes.

planning_get_record

Get field change history for a record. Returns chronological list of field value changes (most recent first) showing what changed, when, and by whom. Includes both before/after values for each change. Useful for audit trails and tracking record modifications. Excludes system field changes. Supports pagination via offset/limit.

planning_get_record_change_log

Get record sharing. Retrieves sharing/permissions information for a specific record, including who has access and their permission levels. Returns a wildcard access level (EVERYONE_IN_WORKSPACE or SELECTED_USERS_ONLY) and a list of sharing entries. Requires MANAGE permission on the record type containing the record. Operates on Planning/Maestro objects (workspace, view, record type, record) via the ReBAC AuthZ model. For classic Workfront objects (PROJ, TASK, OPTASK, DOCU, PORT), use the access-control_* tools instead.

planning_get_record_sharing

Get Record Type details by ID. Retrieves complete information about a specific record type including its configuration, fields, permissions, metadata, and a summary of all views (table/timeline/calendar). For global record types (isGlobal=true), also includes global settings such as which workspaces use it and authorization config (requires MANAGE permission). Unlike workspaces (which have a distinct ownerId), record types have no separate ownership field — createdBy (who originally created the record type) is the closest available owner signal. For per-field value schemas (field IDs, types, formats), read the schema://record-type/{recordTypeId} resource.

planning_get_record_type

Get record type sharing. Retrieves sharing/permissions information for a record type, including who has access and their permission levels. Returns list of objects containing users, groups, teams, roles, and companies with their assigned permissions. Requires MANAGE permission on the workspace containing the record type. For dynamic (global) record types, use scopeWorkspaceId to get workspace-specific sharing. Operates on Planning/Maestro objects (workspace, view, record type, record) via the ReBAC AuthZ model. For classic Workfront objects (PROJ, TASK, OPTASK, DOCU, PORT), use the access-control_* tools instead.

planning_get_record_type_sharing