Skip to main content
Server path: /pinkfish-sidekick | Type: Embedded | PCID required: No

Tools


capabilities_discover

Discover available capabilities for a task. Returns lightweight recommendations for tools, agent skills, connections, and/or resources. Call capability_details to get full details for selected items. Use the “types” parameter to filter by capability type. Parameters:

capability_details

Get full details for selected capabilities. For tools: returns inputSchema (full JSON Schema with nested objects, arrays, enums, and required fields), outputSchema, isDynamic (true for dynamic MCP servers), and any matching agent skill content. For agent skills: returns full knowledge content. For connections: returns connection metadata. For resources: returns collection details. Use the “types” parameter to filter by capability type. For custom integrations, when capabilities_discover returns a tool name like “myintegration_c_request”, pass ONLY that exact tool name to capability_details (not the integration name or skill name). The response automatically includes all associated content including skill instructions. Parameters:

mcp_discover

Find MCP servers and tools for any task. Covers external integrations (gmail, slack, zendesk, salesforce) AND embedded capabilities (datastore, llm, ocr, web-application, summarization, translation, web scraping). Returns tool specifications along with IDs needed to use them when relevant. Parameters:

workflow_agents

Create, read, update, list, and invoke agents for use in workflows. Agents can be bound to workflows via workflow_bind_resources and called via pf.agents.get() and pf.agents.call(). ACTIONS: create (new agent), read (get details), update (modify), list (all agents), invoke (call agent). FOR CREATE/UPDATE WITH SERVERS: Call mcp_discover first to see available MCP servers and tools. Parameters:

workflow_bind_resources

Apply resource bindings for an existing workflow. Use this after workflow_update whenever you add, repair, or change WORKFLOW_RESOURCES bindings. Supported binding types include connection, collection, trigger, and agent. After binding, verify with workflow_read({ automationId, checkResources: true }) before the first workflow_run. Example: workflow_bind_resources({ automationId: ”…”, bindings: { salesConn: { id: “pcid_123”, resourceType: “connection” } } }). The bindings parameter is REQUIRED — you must provide at least one binding. Parameters:

workflow_create

Create a new workflow automation. Returns automationId and starterCode. Use only when no automationId exists in context (headless/API scenarios). If automationId already exists, use workflow_update directly instead. Parameters:

workflow_delete

Delete a workflow by ID. This is permanent — the automation, its steps, releases, and bindings are removed. Confirm with the user before calling. Use workflow_list to find the ID. Parameters:

workflow_duplicate

Duplicate (clone) a workflow within the current org. Returns the new automation’s ID, name, and description. Optionally provide a name for the copy; otherwise the backend picks a default (typically the source name with a suffix). Parameters:

workflow_invoke

Invoke/call/execute another workflow (sub-workflow) using its webhook trigger URL. Use this when a workflow needs to call or trigger another workflow. Automatically executes async and polls for results (up to 14 minutes). Get the webhookEndpoint URL from the trigger sub-agent or workflow_trigger_* tools. Parameters:

workflow_invoke_by_id

Invoke another workflow by its automation ID and return its results. Runs the workflow’s latest PUBLISHED release (the same version its triggers run) under your identity — you can only invoke workflows you already have access to. Use the automationId returned by capabilities_discover. This is the id-based way to call a workflow, analogous to invoking an agent by id; for calling a workflow via its trigger webhook URL use workflow_invoke instead. Long-running workflows are handled by the async execution system. Parameters:

workflow_list

List all workflows accessible to the user. Returns workflows that have API triggers configured, including their automation ID, name, and trigger details. Use this to discover existing workflows that can be invoked as sub-workflows. Parameters:

workflow_manual_edit

FOR FRONTEND USE ONLY - Agents should use workflow_update instead. LLM-powered workflow edits for frontend UI operations:
  • Accepts structured operations (addNodes, removeNodes, updateNodes, addEdges, removeEdges)
  • Uses an LLM to generate targeted code edits with FastApply merge
  • Avoids fragile code parsing/regeneration
For MCP tool nodes: adds node + edge + generates function automatically. For code-block nodes: generates placeholder function automatically. Uses optimistic locking (expectedVersion) to detect conflicts when multiple users edit simultaneously. Parameters:

workflow_pin

Pin or unpin node outputs to reuse across workflow runs. Pinned nodes skip execution and use stored output from a previous run. Use this to avoid re-running expensive operations (LLM calls, API requests) during development. Parameters:

workflow_promote

Promote a workflow to the next stage in its promotion path. Copies the automation to the target org defined by the path. Returns the target automation ID, target org ID, and whether a new automation was created. Parameters:

workflow_promotion_paths_get

Get a single promotion path by ID, including its stages. Parameters:

workflow_promotion_paths_list

List all promotion paths visible to the current organization. Each path defines a sequence of stages (orgs) that a workflow moves through during promotion. Parameters: None

workflow_publish

Publish a new release of a workflow — the same operation as the web editor’s Publish button. Returns the created releaseId, automationVersion (the draft version snapshotted at publish time), and publishedAt. Each call creates a new release even if the code has not changed. Does NOT share the workflow with the org; call workflow_share separately to make a published workflow runnable from Coworker chat. Parameters:

workflow_read

Get workflow structure and optionally focused details for a specific node. IMPORTANT: Only include parameters you actually need. Do NOT pass empty strings, empty arrays, or false for optional parameters — omit them entirely. For example, to check resources, send ONLY: { automationId: ”…”, checkResources: true } Choose one primary read mode:
  • Use only automationId for a lightweight structure read
  • Add exactly one focused mode (nodeId, nodeIds, search, addBetween, or includeCode) when you need targeted details
  • Add checkResources: true only when verifying bindings or resource health
Default response (lightweight):
  • nodes: List of {id, name, type} for all nodes
  • edges: Connection graph
  • resources: List of declared resource names
With nodeId (focused read for modifying a node):
  • focus.node: Node details (see below for what’s returned based on node type)
  • focus.neighbors: Before/after nodes with their schemas
  • focus.availableData: All upstream node outputs (field names)
  • focus.globals: Inputs, resources, context variables (@workflow., @user., etc.)
Node types in focused read:
  • code-block/mcp-tool nodes: Returns code, inputSchema, outputSchema
  • Control flow nodes (router, merge, for-each, if-else, loop, while, parallel, delay, sub-workflow, hitl): Returns full node properties (expression, routes, sources, body, preamble, expirationDuration, approvalUrl, etc.) - NO code since these are runtime primitives
  • trigger nodes: Returns full node properties including outputSchema
With nodeIds (multi-node read):
  • focusedNodes: Map of nodeId to {code, inputSchema, outputSchema} for each requested node
With search (grep across code):
  • matches: Array of {nodeId, line, match, context} for each matching line
  • totalMatches: Total count
With addBetween (for inserting a new node):
  • insertionPoint: Context for where to add the node
With includeCode (full dump — prefer search or nodeIds for targeted reads):
  • code: Full workflow code (WARNING: can be very large for complex workflows)
With checkResources (for binding):
  • resources: Detailed binding status for each resource
With version (read a past revision):
  • Pass version to read a historical step version instead of the current one. Every response already includes stepVersion at the top level, so you can decrement from there to walk back through history. On a version miss, the error lists available versions. checkResources and addBetween reflect current state and are ignored when version is set.
Parameters:

workflow_release_diff

Compare current draft code against the latest published release. Returns a unified diff showing what changed, per-step breakdown, and summary statistics (lines added/removed/changed). Use this to understand what code was running in production vs what has been modified since. Parameters:

workflow_results

Deep inspection of workflow run output files. Use after workflow_run to verify output correctness or inspect data. Operations: “list” (artifact summaries with structure/preview/tips — use first to see which files exist, including HTML/UI artifacts), “search” (regex across files), “read” (extract data with path/sample/pagination/fields), “getUrl” (get signed URL for a specific file to download or pass to another tool). For full execution logs (pf.log.* output), use read with filename: “stdout.txt” — returns JSON with a log field. Parameters:

workflow_run

Execute workflow and return results. Runs entire workflow by default. Use runUntilNode to stop after a specific node completes. Long-running workflows are automatically handled by the async execution system. Parameters:

workflow_run_status

Check the status of a workflow run and wait for completion. Automatically polls until the workflow completes or the async execution system handles long-running operations. Returns full results when complete. Parameters:

workflow_share

Share (or unshare) a workflow. Default scope is “org” — grants the caller’s selected organization READ on the workflow. Publishing alone does not make a workflow runnable from Coworker chat; the workflow must also be shared with the org. This tool only toggles the ACL; it does not publish. Call workflow_publish separately when you want the full “publish and make available in Coworker” flow. Parameters:

workflow_trigger_api

Create, manage, and list API (webhook) triggers that provide an HTTP endpoint to start workflows. Actions: create, get, update, delete, list, enable, disable. Pass resourceName to auto-bind on create. For API and Interface triggers, use inputSchema to define form fields (see workflow-trigger-schema skill for details). VERSION CONTROL: useDraft=true for development (default); useDraft=false + release=0 (default) to track the latest published release in production, or release=N to pin to a specific published version. Parameters:

workflow_trigger_application

Create, manage, and list application triggers (GitHub, Shopify, etc.) that start workflows on app events. Actions: create, get, update, delete, list, enable, disable. Pass resourceName to auto-bind on create. VERSION CONTROL: useDraft=true for development (default); useDraft=false + release=0 (default) to track the latest published release in production, or release=N to pin to a specific published version. Parameters:

workflow_trigger_cleanup

Delete unused triggers for an automation. Unused = trigger exists but is not bound to any resource in WORKFLOW_RESOURCES. Call this after creating replacement triggers to clean up orphaned triggers. Returns list of deleted triggers, kept triggers, and failed triggers (with error details if any could not be deleted). Parameters:

workflow_trigger_email

Create, manage, and list email triggers that start workflows when emails are received. Actions: create, get, update, delete, list, enable, disable. Pass resourceName to auto-bind on create. VERSION CONTROL: useDraft=true for development (default); useDraft=false + release=0 (default) to track the latest published release in production, or release=N to pin to a specific published version. Parameters:

workflow_trigger_interface

Create, manage, and list interface triggers (user-facing forms generated from a workflow’s inputSchema). Actions: create, get, update, delete, list, enable, disable. Pass resourceName to auto-bind on create. VERSION CONTROL: useDraft=true for development (default); useDraft=false + release=0 (default) to track the latest published release in production, or release=N to pin to a specific published version. Parameters:

workflow_trigger_list_all

List triggers across all trigger types. When automationId is provided, returns only triggers for that workflow. When omitted, returns all triggers across all workflows. Parameters:

workflow_trigger_replace

Replace an existing trigger in one call: reads old trigger, creates replacement with carried-forward fields, then deletes old trigger. Use this for switch/replace operations to avoid dropping required properties. Pass resourceName to auto-bind the new trigger after creation. Parameters:

workflow_trigger_schedule

Create, manage, and list schedule triggers that automatically start workflows on a cron schedule. Actions: create, get, update, delete, list, enable, disable. Pass resourceName to auto-bind on create. VERSION CONTROL: useDraft=true for development (default); useDraft=false + release=0 (default) to track the latest published release in production, or release=N to pin to a specific published version. Parameters:

workflow_update

Update workflow code only. Use code-edit format showing ONLY the sections being changed. Include 2-3 lines of actual unchanged code BEFORE and AFTER your changes for context, then use // … existing code … as placeholder to skip larger unchanged sections. If you added or changed WORKFLOW_RESOURCES, call workflow_bind_resources next, then verify with workflow_read({ automationId, checkResources: true }) before the first workflow_run. APPROVAL NODE: Type “approval” — control flow node (NO function registration). 3 output handles replace if-else: “notify” (runs before pause, send email with @node_approval.approvalUrl), “approved” (on approve), “denied” (on deny). Properties: “preamble” (reviewer message), “expirationDuration” (minutes, default 60). See approval skill for full examples. Parameters: