create_markdown_image_upload
ChatGPTStart uploading a local image (e.g. a screenshot) so it can be embedded in a Port markdown property or markdown widget. Workflow: 1. Call this tool with the file's path, MIME type and exact size in bytes (wc -c < <file>). 2. Run the returned curlCommand on the machine that has the file. It uploads straight to storage, so the image never passes through this conversation. The upload link expires after expiresInSeconds. 3. Call finalize_markdown_image_upload with the returned key and name to get the markdown snippet. Without a shell, send a multipart/form-data POST to uploadUrl with every entry of fields, followed by the file as the last form field, named file. Limits: PNG, JPEG, GIF, WebP, APNG or AVIF, up to 10 MB. Video isn't supported; use an animated GIF or WebP instead.
delete_entity
ChatGPTPermanently delete one entity. This cannot be undone. Confirm with the user before calling. This tool does not cascade (delete_dependents is always false). The delete fails only when other entities point at this one through a required relation — optional relations do not block it. Remove those required dependents first, or read the error if the call fails because of them. Do not delete every related entity; optional relations can stay. blueprintIdentifier is the blueprint (the data model) this entity belongs to. entityIdentifier is the record to delete.
delete_page
ChatGPTDelete a page by its identifier. This will permanently remove the page from the sidebar.
delete_widget
ChatGPTDelete a widget from a dashboard, home, or entity page by its ID.
describe_user_details
ChatGPTDescribe the user, which organization he is connected to and what teams he is a member of and more information regarding the user. Call this FIRST when the user asks to create a dashboard, catalog page, or page with tables — before ask_user_questions, planning, upsert_dashboard_page, or upsert_catalog_page. Read pagePermissions.guidance.workflow and follow it exactly. If pagePermissions.canCreatePages is false, stop and tell the user to contact their admin — do not ask questions and do not suggest entity page updates or other workarounds unless pagePermissions.canUpdatePages is true and the user explicitly asks to customize an existing entity page. If pagePermissions.shouldAskVisibility is false, use pagePermissions.defaultVisibility and do not ask visibility questions. When the request is an ambiguous "page with a table", resolve catalog vs dashboard first (catalog = full-page blueprint table; dashboard = layout that contains a table) — ask once if unclear; do not default to dashboard. When explaining permission issues, relay pagePermissions.guidance in plain language; do not quote internal field names.
duplicate_page
ChatGPTDuplicate a dashboard page. Creates an identical copy with the same widgets, layout, page filters, icon, and description. The new page is placed immediately after the source page in the sidebar (or in the private pages section for private dashboards). The title is "{original title} (copy)" and the identifier is "{original}_copy" (with numeric suffix if needed). Always use this tool to duplicate a dashboard — do not rebuild the page with get_page + upsert_dashboard_page. Manual recreation can change widget order, drop page filters, or use a different icon. Only dashboard pages (type "dashboard") are supported. Entity pages cannot be duplicated.
finalize_markdown_image_upload
ChatGPTFinish an image upload started with create_markdown_image_upload, once its curlCommand has succeeded. Returns the image url and a ready markdown snippet (). Put the snippet into a markdown property with upsert_entity, or into a markdown widget. The image is validated and stripped of metadata, so this fails if the file wasn't uploaded, isn't a valid image or is too large. The URL only renders inside Port, for members of this organization; use get_markdown_image to look at the image yourself.
get_blueprint_permissions
ChatGPTGet entity RBAC permissions for a blueprint: read, register, update, unregister, updateProperties, and updateRelations policies.
get_markdown_image
ChatGPTView an image that was uploaded to Port and embedded in markdown, such as a screenshot on a work item. These URLs look like https://<asset-domain>/organizations/<orgId>/markdown_image/<file>. Port asset URLs are private, so they can't be fetched directly; this tool returns the image itself. Only this organization's images can be read, and only PNG, JPEG, GIF or WebP files up to 3.75 MB (5 MB once base64-encoded).
get_page
ChatGPTGet a specific page by identifier. Returns full page details including widgets configuration. For dashboard and home pages, returns flat widgets and layout from the root dashboard-widget. For entity pages (type "entity"), returns a "tabs" array with each tab's title, widgets, layout, and reserved flag. Tabs are returned in display order.
get_port_knowledge_documents
ChatGPTFetch full documents from the documentation and other knowledge sources of Port by their source URL, as search results return them. Returns a markdown representation of the full content of each matched document; results may be empty if none of the requested URLs match. Long documents are truncated; increase max_chars_per_document to fetch more of a single document. The results are paginated. Use this tool when you simply want to look up the content of one or more specific documents.
get_run
ChatGPTGet the full details and current status of any run by its ID. Automatically routes to the correct backend based on the ID format: - IDs starting with wfr_ → workflow run (returns status, result, nodeRuns per-node details) - All other IDs → action run (returns status, statusLabel, summary, response, approval info) Common use cases: - Polling for completion after triggering a workflow or action run - Inspecting a specific run from list_runs results - Checking approval status or node-level execution details - Reading what a pending workflow INPUT node asks for: its node run's output.evaluatedConfig holds the evaluated description, userInputs form and userInputs.buttons to use with submit_input_node_response Use list_runs first to discover run IDs. > Note: track_action_run is a legacy per-type tool; prefer get_run for all run status lookups.
get_workflow
ChatGPTGet the full definition of a single workflow by identifier. Returns the complete workflow including all nodes, connections, and configurations. Prefer this over list_workflows when you need details for one workflow; it is easier for tools and models to discover and use.
give_port_feedback
ChatGPTReport a problem you hit while working with Port so the Port team can fix it. Use this when the Port documentation is missing, unclear, outdated, wrong, or contradicts itself; when Port itself has a bug, a limitation, or a missing feature; when a tool from Port's own MCP server fails or behaves unexpectedly; or when the search or document tools on this server fail or misbehave. Say what you were doing, what you expected and what happened, and name the pages, endpoints, or tools involved. Only call this for a concrete problem: not to test the tool, not to say there is nothing to report, and not for problems with tools or services unrelated to Port. Include identifiers from Port that would help reproduce the problem, such as request IDs, error codes, or object IDs, but leave out credentials, personal data, and details of your own organization such as people, customers, or internal ticket references.
list_actions
ChatGPTList actions and automations in your organization. Without identifiers: Returns summary list (identifier, title, description, trigger type). With identifiers: Returns full details including complete input schemas. Use this when you need the full schema before triggering an action or automation. This tool only covers actions and automations. Self-service workflow triggers are a separate concept — list them with list_self_service_triggers. An empty result here does not mean there are no triggers. > Prefer `list_workflows` when discovering all available workflows, actions, and automations in a single call. Use this tool when you need full action or automation details by identifier.
list_blueprints
ChatGPTList blueprints in the organization. When to use: you need to discover which blueprints exist, or you need one blueprint's property types, enum values, or relation targets before filtering entities, calling upsert_entity, or editing a blueprint. To create or change a blueprint, use upsert_blueprint. Without identifiers: summary (identifier, title, description, property/relation names). With identifiers: full details including property definitions, schemas, relations, and enum values. Use full details when you need: - Property types for constructing filters - Enum values for properties - Relation target blueprints
list_entities
ChatGPTQuery entities from a blueprint. All parameters are composable. FILTERING: - identifiers: Pre-select specific entities by ID - query: Apply filter rules (can combine with identifiers). Max one nested level; nested groups contain only leaf rules, e.g. { combinator: "and", rules: [ruleA, { combinator: "or", rules: [ruleB, ruleC] }] }. OUTPUT OPTIONS (composable): - groupBy: Get value distribution grouped by property/relation - countOnly: Include total count in response - Can request multiple: e.g., groupBy + countOnly returns both groups and total count RESPONSE includes: - entities + hasMoreEntities: when listing (no groupBy) - groups + hasMoreGroups: when groupBy is set - count: when countOnly is true ⚠️ Ensure you have the blueprint schema before filtering or using include. Call list_blueprints if you don't already have it from this session. Required for: 1. FILTERING: property types, enum values, relation targets 2. INCLUDE: use only exact property KEY names from schema.properties / relations — never guess, never use title/label fields (e.g. "affected_service" not "Affected Service") ❌ COMMON FAILURES: - Wrong enum value casing (e.g., "open" instead of "Open") - Wrong relation target (using service ID for a _user relation) - Wrong operator for type (e.g., "contains" on non-array) - Guessed or invented include names — any identifier not in the schema fails the entire call with a 422 INCLUDE PARAMETER: - Copy exact KEYS from schema.properties, relations, and scorecards in the list_blueprints response - NOT categories: "properties", "relations", "scorecards" SEARCHING BY NAME: - Use "contains" on BOTH $identifier AND $title with "or" combinator - Use single words (e.g., "payment" not "payment gateway") DATE FILTERING: - Range: { "property": "created_at", "operator": "between", "value": { "from": "ISO_DATE", "to": "ISO_DATE" } } - Comparison: { "property": "created_at", "operator": ">=", "value": "ISO_DATE" } USER IDENTIFIERS: - _user blueprint uses EMAIL as identifier - Filter by user: { "relation": "creator", "operator": "=", "value": "john@company.com" } FILTERING BY RELATIONS: - Use "relation" key, NOT "property": { "relation": "assignee", "operator": "=", "value": "..." } - Single relations: use "=" - Array relations: use "contains" or "containsAny" SORTING: - Use "order": "asc" or "desc" (NOT "direction")
list_runs
ChatGPTList recent runs across all types (workflows and actions). Returns a unified flat list sorted by creation time (newest first). Each item includes a type field: WORKFLOW or ACTION. Common use cases: - "List my runs" → call with no filters - "What is waiting for my approval" → call with waitingForApproval: true - "Show recent workflow runs" → call with types: ["WORKFLOW"] - "Track progress of my action runs" → call with types: ["ACTION"] Approval filtering note: - Action runs: waitingForApproval matches WAITING_FOR_APPROVAL status exactly. - Workflow runs: waitingForApproval matches WAITING_FOR_INPUT status exactly — the run is blocked on an input node. Getting full details of a specific run: use get_run with the run's id.
list_scorecards
ChatGPTList scorecards in your organization. Without identifiers: Returns summary list (identifier, title, blueprint, levels, compacted rules). With identifiers: Returns full scorecard details including complete rule configurations.
list_self_service_triggers
ChatGPTList the self-service workflow triggers you are allowed to run, with their input schemas. Use this tool whenever the user wants to perform a task that Port may already support. If the user says "triage bug X", "rotate credentials for service Y", or "onboard a new developer" — search here first. There may already be a workflow configured for exactly that. Returns one item per triggerable workflow: the workflowIdentifier to pass to trigger_run, and the userInputs schema describing what that workflow expects. Use this as the discovery step before `trigger_run` for workflows. It replaces calling list_workflows and then get_workflow for each result — one call returns both the identifier and the inputs, without the full node graph. Results are already scoped to what you can execute, so an empty list means there is nothing you are permitted to run. Pass includeNonExecutable: true to also see triggers you cannot run, each marked with permitted. Filtering: - Pass query to keyword-search across workflow identifier, title, and description (e.g., query: "jira" to find all Jira-related triggers). - Pass blueprintIdentifier (optionally with entityIdentifier) to narrow to triggers that act on a specific entity. Only self-service triggers are returned. Event and schedule triggers fire automatically and cannot be invoked manually.
list_workflows
ChatGPTList workflows, actions, and automations in your organization. Returns a flat list where each item includes a type field: WORKFLOW, ACTION, or AUTOMATION. Filtering: - Pass query to keyword-search across identifier, title, and description (e.g., query: "jira" to find all Jira-related items). - Pass types to narrow by type (e.g., ["WORKFLOW"] for workflows only, ["ACTION", "AUTOMATION"] for actions/automations only). Getting full details: This tool returns lean summaries. Use get_workflow with a workflow identifier or list_actions with identifiers to retrieve full definitions.
load_skill
ChatGPTLoad specialized guidance for a domain-specific task. Skills provide step-by-step instructions for common workflows. Load a skill BEFORE starting a specialized task to ensure consistent, thorough handling. Available Skills: - action-permissions-helper: Help users configure permissions for classic self-service actions, with focus on dynamic permission policies. Does not apply when the org sets settings.disableClassicActions to true, since the classic action tools are unavailable there. Use when users need help with execute/approve permissions, JQ conditions, or catalog queries for access control. - annotate_on_doit: Create, update, or look up DoiT Cloud Intelligence annotations - the dated markers that explain cost spikes/drops in DoiT reports. Use when the user says "annotate", "mark this in DoiT", "add a cost annotation", or describes an infra change that will move the bill (instance resize, new cluster, storage tier change, account closure, commitment purchase). - bug-triage-file: Use this skill to file a Port Jira issue after gather. Real bugs go through jiraIssue_report_a_bug; documentation issues go through report_a_documentation_issue. Always confirms with the user before filing, waits for the run to complete, confirms to the reporter on success, updates the bug_triage_agent_run metrics entity (jira_bug vs jira_issue relation), and (when triage ran outside C0BJZ6S3GBF) posts a short summary + next steps to that channel. - bug-triage-gather: Used by the Bug Triage Agent (Platform Beaver) for Phases 1–2. Collects context from the reporter, searches Port for similar open jira_bug entities, classifies the issue (real bug / config / feature request / duplicate / documentation issue), and when it is a real bug collects Jira filing fields then investigates the Port monorepo via GitHub MCP (port-labs/Port only). For documentation issues, collects report_a_documentation_issue fields and skips codebase analysis. Creates/updates a bug_triage_agent_run metrics entity. Load this skill at the start of a triage conversation. - catalog-page-helper: Guide for creating and updating catalog pages (type blueprint-entities) with a single table-entities-explorer. Use when creating a catalog page, listing blueprint entities in the sidebar, or filtering/grouping/sorting/columns on a catalog table. For dashboards use dashboard-page-helper; for entity pages (type entity) use entity-page-helper. - core-to-connect-escalations-report: Generates an HTML report of Zendesk EXTERNAL INTEGRATIONS tickets (product_area = external_integrations) escalated from Core Support directly to R&D Connect — skipping Integrations Support — broken down per account, with monthly volume trend, by-integration breakdown, and current-assignee / who-escalated analysis. Excludes Zendesk follow-up tickets (title begins with Re:/RE:, or tags follow_up/follow-up). Window defaults to tickets opened from 2026-06-01 to date (created_at). These are the tickets Integrations Support is meant to handle before Connect. Triggers on: 'core to connect escalations', 'integrations core to connect report', 'direct Connect escalations by account', 'Core → Connect escalation report', 'integrations tickets escalated directly to Connect', 'core-to-connect report'. Do NOT use for the Integrations Support monthly digest (use integrations-support-monthly-digest) or the all-up Support weekly digest (use support-weekly-digest). Do NOT include non-integrations product areas, tickets that also carried integration_support_needed, or follow-up tickets. - customer-status: Generate comprehensive customer health reports from Port data. Use when preparing QBRs, customer health checks, escalation reviews, churn risk assessments, data quality audits, CSM onboarding to accounts, product roadmap reviews (HubSpot commitments, Canny feature requests), or bug buffer allocation planning. Synthesizes Zendesk tickets, HubSpot commitments, Canny feature requests, usage metrics, ownership data, and data completeness into actionable markdown reports. - dashboard-page-helper: Guide for creating dashboard pages w…
load_widget_schema
ChatGPTGet the JSON schema for a dashboard widget type. Call this before upsert_dashboard_page, upsert_widget, or update_entity_page. Custom-widget schema requires org admin permissions and is rejected at call time for members.
move_page
ChatGPTMove a page to a different location in the sidebar. Use "parent" to move the page into a folder (or set to null for sidebar root). Use "after" to position the page after another item (or set to null for the beginning).
run_action
ChatGPT> Prefer `trigger_run` which works across both workflow runs and action runs in a single tool. Run an action by its identifier. DISCOVERY WORKFLOW: 1. Use list_actions tool to discover all available actions and their identifiers 2. Use list_actions tool with the specific action identifier to get: - The exact action definition - Required input properties and their schemas - Whether entityIdentifier is needed (check if trigger.blueprintIdentifier exists AND trigger.operation is "DAY-2" or "DELETE") - Property types, formats, constraints, and required fields 3. Format the properties object according to the action's trigger.userInputs.properties schema 4. Call run_action with the actionIdentifier, properties, and optionally entityIdentifier ENTITY IDENTIFIER REQUIREMENTS: - entityIdentifier is ONLY required when trigger.blueprintIdentifier exists AND trigger.operation is "DAY-2" or "DELETE" - If trigger.blueprintIdentifier is undefined/missing, do NOT provide entityIdentifier regardless of the operation type (including DAY-2 and DELETE) - Many DAY-2 and DELETE actions do NOT have a blueprintIdentifier and do NOT need an entityIdentifier - When entityIdentifier IS required, use list_entities tool with the blueprint identifier from trigger.blueprintIdentifier to find valid values - Do NOT refuse to run an action just because it is DAY-2 or DELETE - check trigger.blueprintIdentifier first PROPERTY FORMATTING: - Always check list_actions (with identifiers) response for the exact property schema - Match property types, formats, and constraints exactly as defined - Include all required properties as specified in trigger.userInputs.required
search_audit_logs
ChatGPTSearch entity audit logs with flexible filters. FILTER FIELDS: - status: SUCCESS or FAILURE (=, !=, in, notIn) - operation: audit action such as CREATE, UPDATE, DELETE (=, !=, in, notIn) - type: trigger origin such as UI, API, WEBHOOK (=, !=, in, notIn) - date: timestamp range using between with { "from": "<ISO timestamp>", "to": "<ISO timestamp>" } - error: text search on failure message - runId, installationId, webhookId: exact token match - entity, blueprint: filter by entity or blueprint (use identifiers when historicalData is true) PAGINATION: - Use limit and offset. TIP: Set historicalData to true (default) when filtering by blueprint or entity identifier.
search_port_knowledge_sources
ChatGPTPerform semantic retrieval over the documentation and other knowledge sources of Port and return the most relevant chunks for a given query. A "chunk" is a short, self-contained snippet of text taken from a single page or item within these sources (for example, part of a documentation page) and includes its source URL and markdown content. Chunks are returned in descending order of relevance to the query, and the tool always returns a fixed number of chunks (top-k). If the knowledge sources do not contain information relevant to the query, the returned chunks may be only weakly related or entirely unrelated. Use this tool anytime you need information about Port.
simulate_blueprint_permissions
ChatGPTSimulate blueprint entity permissions for a user. Use list mode to discover all accessible entities for an operation, or detail mode (with entityIdentifier) to inspect decision checks for a specific entity.
submit_input_node_response
ChatGPTSubmit a response to a workflow INPUT node run that is waiting for input, on behalf of the current user. The available buttons and the form to fill come from the INPUT node's configuration, evaluated for this run. Follow this flow: 1. Get the workflow run identifier (wfr_...) and the node run identifier (wfnr_...) from the user (e.g. from the input notification or a run link). 2. Call get_run with the workflow run identifier and find the INPUT node run in nodeRuns. 3. Read its output.evaluatedConfig: description explains what is being asked, userInputs is the form (properties, required) and userInputs.buttons lists the buttons you can submit. 4. Confirm the chosen button and inputs with the user, then call this tool. Only users configured as responders on the node can submit, and each responder can respond once. The node completes only after the configured number of responders chose the same button.
track_action_run
ChatGPTTrack action execution status by run ID. > Prefer `get_run` which works across both action runs and workflow runs in a single tool.
trigger_auto_discovery
ChatGPTStart an auto-discovery process to find and suggest entities for a blueprint. Use this tool when the user wants to discover, create, import, or add entities to their catalog. Do NOT create entities manually — always use this tool instead. You MUST call list_blueprints first to get the exact blueprint identifier before calling this tool. Ask the user for context before triggering.
trigger_run
ChatGPTTrigger a workflow run or an action run. Only WORKFLOW and ACTION items can be triggered. AUTOMATION items returned by list_workflows are event-driven and fire automatically — they cannot be manually invoked. DISCOVERY FIRST: Before triggering, find the identifier and required inputs: - For workflows: use list_self_service_triggers — it returns the workflowIdentifier, the nodeIdentifier, and the userInputs in one call, scoped to what you can execute. Pass both identifier (the workflowIdentifier) and nodeIdentifier back here verbatim. A workflow can expose several self-service triggers with different inputs, so omitting nodeIdentifier is rejected as ambiguous unless there is exactly one. - For actions: use list_actions with the identifier to read trigger.userInputs.properties and learn required inputs. Entity inputs (actions): entityIdentifier is only required when trigger.blueprintIdentifier exists AND trigger.operation is "DAY-2" or "DELETE". Use list_entities to find valid identifiers. After triggering: - Workflow runs are asynchronous — use get_run with the returned run ID to poll for completion. - Action runs may complete immediately or require approval — check the returned status and requiredApproval fields.
update_entity_page
ChatGPTUpdate an existing entity page's tabs, tab names, tab order, page metadata, or page filters. Entity pages are auto-generated per blueprint — they cannot be created manually. When to use this tool: - Add a new custom tab to an entity page - Rename a tab (provide previousTitle + title, no widgets/layout) - Delete a custom tab (omit it from tabOrder; reserved tabs cannot be deleted) - Reorder tabs (provide tabOrder with every remaining tab title in the desired display order) - Update page metadata (title, description, icon) - Add or update multiple widgets/layout on a tab at once - Create, update, or remove page-level filters (pageFilters) When NOT to use this tool: - Updating a single widget → use upsert_widget with tabTitle instead - Dashboard or home pages → use upsert_dashboard_page / upsert_widget - Catalog pages (type "blueprint-entities") → use upsert_catalog_page - Never use upsert_dashboard_page on entity pages Load the entity-page-helper skill for full guidance. Entity page identifier is "{blueprintIdentifier}Entity" (e.g. "serviceEntity"). If the user's current context mentions a page identifier or blueprint, use it — do not ask the user which page to modify. First call get_page to see tabs. Only call load_widget_schema when the user explicitly asked for widgets. Custom widgets require org admin permissions and are rejected at call time for members. Rules: - Only change what the user asked for — do not add placeholder widgets, icons, or layout unless requested - To add an empty tab, provide only { title: "Tab Name" } — widgets and layout are optional - Tabs omitted from input are preserved (including Overview and reserved tabs) - Runs, Audit Log, and Related Entities cannot be provided or renamed — they are preserved automatically - Overview widgets may be updated via this tool or upsert_widget; Overview cannot be renamed or removed - Reserved tab names (Overview, Runs, Audit Log, Related Entities) cannot be used as rename targets - For renames: { previousTitle: "Old Name", title: "New Name" } — do not include widgets or layout - pageFilters replaces the entire filter list when provided; omit to leave filters unchanged; pass an empty array to clear all filters Available widget types for entity page dashboards: - table-entities-explorer: Display entities in a table with filtering, sorting, and grouping - board: Kanban/board view of entities grouped into columns by one property or relation (aliases: kanban, kanban board, board view). Requires blueprint and exactly one groupBy field. - entity-details: Show details of a specific entity (for dashboard pages) - action-card-widget: Display action buttons in a card - workflow-card-widget: Display workflow self-service triggers in a card - action-runs-table-widget: Display action run history in a table - links-widget: Display a collection of links - ai-agent: Embed an AI agent chat interface - markdown: Render markdown content - iframe-widget: Embed an external URL in an iframe - entities-number-chart: Display a numeric metric (count, sum, average, etc.) - entities-pie-chart: Display entity distribution as a pie chart - bar-chart: Display entity distribution as a bar chart - multi-line-chart: Display trends over time as a multi-line chart - custom-widget: Display a custom view using a port plugin to see your data when native widgets are not enough
upsert_catalog_page
ChatGPTCreate or update a catalog page (type "blueprint-entities") by applying agent-built Pages API JSON. MUST load_skill catalog-page-helper before calling — that skill defines defaults, filters/operators, create vs update, sidebar placement, and the exact widget JSON to send. Do not invent page/widget shape here. Do NOT use for dashboards (upsert_dashboard_page), entity pages (update_entity_page / upsert_widget), or home. Before calling, call describe_user_details and follow pagePermissions.guidance.workflow. If pagePermissions.canCreatePages is false, do not call this tool. If pagePermissions.shouldAskVisibility is false, use pagePermissions.defaultVisibility. Pass a complete page-shaped payload (identifier, blueprint, title, icon, widgets with one table-entities-explorer that includes id, blueprint, displayMode "single", and dataset). On create, set icon to the blueprint icon from list_blueprints (not "Apps", not omitted). The tool validates and create/patches; it sets type/sidebar/section only. On update, get_page first, edit the explorer widget, and send the full payload; omit visibility only when leaving it unchanged. After success, link with the returned absolute url: [<title>](<url>).
upsert_dashboard_page
ChatGPTCreate or update a dashboard or home page. Do NOT use on entity pages (type "entity") — use update_entity_page or upsert_widget instead. Do NOT use on catalog pages (type "blueprint-entities") — use upsert_catalog_page instead. For ambiguous "page with a table" requests, resolve catalog vs dashboard first (catalog = full-page blueprint table; dashboard = layout that contains a table) — ask once if unclear; do not default to dashboard. Before calling this tool, call describe_user_details and follow pagePermissions.guidance.workflow. If pagePermissions.canCreatePages is false, do not call this tool. If pagePermissions.shouldAskVisibility is false, use pagePermissions.defaultVisibility. Only ask about private vs organization visibility when pagePermissions.shouldAskVisibility is true — never offer entity pages as a creation option. Do not call this tool if the user lacks permission for the requested visibility. Custom-widget widgets require org admin permissions and are rejected at call time for members. Decide create vs update from the conversation first. For updates you MUST pass the exact page identifier (private pages get an owner suffix on create — use the identifier returned by create/get_page/get_sidebar). If updating and the identifier is unknown, ask the user which page (or look it up via get_sidebar / get_page) — do not invent a base identifier or create a duplicate. After a successful create or update, always include a markdown link using the returned absolute url: [<title>](<url>). On create of a non-private page, call get_sidebar and set after to the last top-level (non-private) sidebar item so the page is appended at the end; omit after/parent for private pages. On create, if the user did not specify an icon, pass icon "Apps" (do not ask). Load dashboard-page-helper for full guidance. The dashboard-widget container is auto-generated; just provide widgets and layout. To create a private page, set visibility to "private"; private pages cannot be nested with parent or positioned with after, and the API may append an owner-specific suffix to the identifier. To add or update page filters without changing widgets, pass only identifier and pageFilters (call get_page first to see existing filters). pageFilters replaces the entire filter list; pass an empty array to clear all filters. Each widget needs an "id" (referenced in layout) and "type". Call load_widget_schema to get the schema for a widget type. Available widget types: - table-entities-explorer: Display entities in a table with filtering, sorting, and grouping - board: Kanban/board view of entities grouped into columns by one property or relation (aliases: kanban, kanban board, board view). Requires blueprint and exactly one groupBy field. - entity-details: Show details of a specific entity (for dashboard pages) - action-card-widget: Display action buttons in a card - workflow-card-widget: Display workflow self-service triggers in a card - action-runs-table-widget: Display action run history in a table - links-widget: Display a collection of links - ai-agent: Embed an AI agent chat interface - markdown: Render markdown content - iframe-widget: Embed an external URL in an iframe - entities-number-chart: Display a numeric metric (count, sum, average, etc.) - entities-pie-chart: Display entity distribution as a pie chart - bar-chart: Display entity distribution as a bar chart - multi-line-chart: Display trends over time as a multi-line chart - custom-widget: Display a custom view using a port plugin to see your data when native widgets are not enough
upsert_entity
ChatGPTCreate or update an entity (one catalog record). Updates if it exists, creates if it does not. A blueprint is the data model for a kind of record: it defines that record's properties and relations. blueprintIdentifier names which blueprint this entity belongs to. Call list_blueprints with that identifier first if you do not already have its schema. entity.identifier selects which entity to update or create. If omitted on create, the API generates one. Uses upsert with merge by default — only provided fields are updated, existing fields are preserved.
upsert_widget
ChatGPTCreate or update a single widget on a dashboard, home, or entity page. Preferred tool for updating one widget — use this instead of update_entity_page when changing a single widget's configuration. If the widget with the given ID exists, it will be updated. Otherwise, a new widget will be created. For entity pages (type "entity"), tabTitle is required — call get_page first to see available tabs. If the user's current context mentions a page identifier or blueprint, use it — do not ask the user which page. For dashboard/home pages, tabTitle is not needed. Custom widgets require org admin permissions and are rejected at call time for members. Available widget types: - table-entities-explorer: Display entities in a table with filtering, sorting, and grouping - board: Kanban/board view of entities grouped into columns by one property or relation (aliases: kanban, kanban board, board view). Requires blueprint and exactly one groupBy field. - entity-details: Show details of a specific entity (for dashboard pages) - action-card-widget: Display action buttons in a card - workflow-card-widget: Display workflow self-service triggers in a card - action-runs-table-widget: Display action run history in a table - links-widget: Display a collection of links - ai-agent: Embed an AI agent chat interface - markdown: Render markdown content - iframe-widget: Embed an external URL in an iframe - entities-number-chart: Display a numeric metric (count, sum, average, etc.) - entities-pie-chart: Display entity distribution as a pie chart - bar-chart: Display entity distribution as a bar chart - multi-line-chart: Display trends over time as a multi-line chart - custom-widget: Display a custom view using a port plugin to see your data when native widgets are not enough Call load_widget_schema to get the detailed schema for a specific widget type. Chart widget property fields use kebab-case prefixes (e.g. mirror-property#name, calculation-property#name).
upsert_workflow
ChatGPTCreate or update a workflow. Updates if exists, creates if not. The workflow.identifier determines which workflow to update or create. Build decision: Use this tool by default for any flow, automation, or multi-step process — unless the user explicitly asks for an "action" or "automation", in which case use upsert_action instead. > Use list_workflows to discover existing workflows, actions, and automations before building new ones.
validate_page
ChatGPTValidate page JSON for dashboard, home, entity, or blueprint-entities pages (Zod schema + guardrails). READ-ONLY — call when the user asks to show, list, or diagnose page validation issues, or when fixing/repairing/producing valid page JSON. Call instead of get_page for validation errors — get_page does not return them. MUST load_skill fix-pages-api-validation when fixing or providing valid page JSON. identifier = diagnose a stored page and return errors plus full PUT-shaped pageBody when invalid (use pageIdentifier from Current User View, or "{blueprint}Entity" when context has blueprint but no pageIdentifier). page = call after every edit and loop validate_page({ page }) until valid:true before delivering JSON — load fix-pages-api-validation for the full workflow. Responses include nextStep when actionable: present_errors, fix_and_revalidate, output_page_body — follow fix-pages-api-validation for each. Never infer extra errors, suggest deleting the page, or use page write tools.
