mcp-server

Activate an agent, changing its status from draft or paused to active. Active agents respond to chat messages; active agents with routines will run those routines on schedule. Requires write access when connected with OAuth.

Add a new step to a workflow. **This is the recommended path for agent-authored workflows** — call `create_workflow({ name, goal })` first, then `add_step` one step at a time, then `validate_workflow` + `publish_workflow`. Each call returns per-step validation errors immediately, so a bad step type / prompt template / missing required field is caught before the next step is built on top of it. ## KG-First — before writing prompt content into a step Before writing an AI-step prompt that contains workspace-specific content (thesis, ICP criteria, scoring rubric, sector list, geo focus, brand voice, seed lists), check whether that content already lives in the workspace KG: call `list_memories` / `list_knowledge_lists` / `get_knowledge_text`. If it doesn't exist yet, seed it first (`store_memory` / `upsert_knowledge_text`) before adding this step. Then reference it at runtime in the prompt template via `{{steps.read-kg.content}}` rather than pasting the text inline. **Boundary: strategy → KG; execution wiring → workflow context; workflow structure → workflow.** ## Required `step` fields (all types) - `id`: stable string unique within the workflow. - `type`: one of the closed list — `trigger`, `appAction`, `aiAction`, `aiActionWithTools`, `toolAction`, `code`, `knowledgeSync`, `return`, `milestone`, `share`, `wait`, `branch`, `parallel`, `loop`, `end_if`, `agentOrchestrator`. Any other string is silently stripped by the runtime. - `name`: human-readable label. Non-terminal steps also need `next: { stepId }` pointing to the next step. Terminal steps (`milestone`, `return`) omit `next`. ## Minimal shape by type ```json // trigger (manual) { "id": "start", "type": "trigger", "name": "Manual Start", "pipelineStepStartConditions": { "trigger": { "type": "manual" } }, "next": { "stepId": "next-step" } } // aiAction — LLM prompt → structured JSON { "id": "analyze", "type": "aiAction", "name": "Analyze", "pipelineStepPrompt": { "template": "Analyze {{input.company_url}}", "responseStructure": { "summary": "string", "score": "number (0-100)" } }, "creditCost": 10, "next": { "stepId": "next-step" } } // appAction — call an app/integration action { "id": "enrich", "type": "appAction", "name": "Enrich Company", "app": { "id": "agentled", "actionId": "agentled.get-linkedin-company-from-url", "source": "native" }, "stepInputData": { "profileUrls": "{{input.company_url}}" }, "next": { "stepId": "next-step" } } // → call `get_app_actions({ appId })` FIRST to get valid actionId + input field names for this app. // aiActionWithTools — LLM agent invoking runtime tools { "id": "research", "type": "aiActionWithTools", "name": "Research", "tools": [{ "type": "builtin", "name": "web_search", "builtinType": "web_search" }], "pipelineStepPrompt": { "template": "Research {{input.topic}}", "responseStructure": { "summary": "string" } }, "creditCost": 10, "next": { "stepId": "next-step" } } // → call `list_models` for valid builtinType values (web_search, workspace_memory, kg_search, …). // knowledgeSync — persist prior step output to a KG list { "id": "save", "type": "knowledgeSync", "name": "Save to KG", "knowledgeSync": { "source": { "stepId": "analyze", "resultsPath": "items" }, "listKey": "scored_companies", "fieldMapping": { "name": "name", "score": "score" } }, "next": { "stepId": "done" } } // milestone — terminal step for top-level workflows { "id": "done", "type": "milestone", "name": "Done" } ``` ## Variable references - `{{input.fieldName}}` — input page field (defined in `context.executionInputConfig.fields` or `context.inputPages[].configuration.fields`). - `{{steps.stepId.fieldName}}` — output of a prior step. - `{{currentItem.field}}` — current item inside a `loopConfig` iteration. Trigger step inputs are referenced as `{{input.X}}`, **not** `{{steps.trigger-id.X}}` — common agent mistake. ## Composable step blocks When building multi-step workflows, apply these reusable patterns: - **Search & Extract**: aiAction (generate queries) → appAction (search) → aiAction (extract). Never pass raw input to search APIs. - **Enrich & Score**: appAction (fetch data) → aiAction (score). Always enrich before scoring. - **Draft & Send**: aiAction email → approval with onApproval.action="schedule-email". Use HTML bodies for open/click tracking. Do not use Gmail/Outlook send appActions unless explicitly requested. - **Report & Notify**: aiAction report with Config renderer → share step → aiAction notification email. Include `{{steps.<shareStepId>.shareUrl}}` in the email template and keep the body to an HTML overview + report link. - **Scrape & Summarize**: appAction (scrape) → aiAction (summarize). - **Loop Enrich & Filter**: loopConfig on first step only → appAction (enrich each) → aiAction (score/filter). Post-loop: aiAction to rank with `entryConditions.criteria[{ type: "loop_completion" }]` and `onCriteriaFail: "wait"`. Do not use `scope` as the runtime wait/fan-in mechanism; it only declares explicit container membership. - **Multi-phase KG pipeline**: each phase reads its input status, processes rows, then advances them (kg.upsert-rows with initial status → kg.read-list by status → kg.update-rows to next status). Status values are user-defined per pipeline. Status is DB-indexed — always filter by a single equality value, never scan. Mark the next status BEFORE side-effects (email, share, Slack). (Source of truth: COMPOSABLE_STEP_BLOCKS in workflowPatternExamples.ts) ## Positioning Use `insertAfter` to place the step after an existing step ID. When `rewireNext` is true (default), the insertAfter step's `next` is updated to the new step, and the new step's `next` is set to what insertAfter previously pointed to — maintaining the chain. Validates step ID uniqueness. Respects draft snapshot routing for live workflows. Requires write access when connected with OAuth.

Builder-only activity append. Use this when the authenticated external builder is reporting progress, links, test notes, or questions; the server records the registered builder identity. Requires write access when connected with OAuth.

Business-agent-only activity append. Use this for source-agent follow-up, review, or routing notes; builders should use append_builder_work_activity instead. Requires write access when connected with OAuth.

Append one item to a step array path without accidentally replacing the whole array with a single-element list. Preferred for `tools`, `integrations`, and similar arrays. Internally: `get_step` → append → safe `update_step` replace. Returns the same shape as `update_step`. Requires write access when connected with OAuth.

Apply one exact reviewed workspace package preview. Requires workspace:packages:apply plus workspace owner or ADMIN authority. Installation creates only paused/draft workspace assets. It never runs workflows, activates routines or SignalKit, calls providers, spends credits, sends, writes CRM/calendar/integrations, or imports customer data. Requires write access when connected with OAuth.

Archive a WorkspaceUseCase product record without deleting linked workflows, agents, routines, AgentFiles, or knowledge. Requires write access when connected with OAuth.

Archive a workspace-created skill without deleting its backing AgentFile content. Requires write access when connected with OAuth.

Archive a WorkspaceView manifest without deleting linked KG rows, workflows, executions, approvals, agents, routines, or external data. Requires write access when connected with OAuth.

Add one typed live-enforcement pointer on an onboarding-goal approval requirement. This updates the requirement binding only. It does not change the referenced workflow, agent, channel, or routine; run providers; spend credits; make approval decisions; or execute external writes. Removing a path from a send, write, or delete safeguard requires confirm=true. The server reuses the UI validator and writes an actor-attributed audit row. Requires write access when connected with OAuth.

Bind one skill reference to a linked use-case agent and business role. This changes goal configuration only. It does not assign the skill to the agent, grant tools or app permissions, run providers, spend credits, or perform external writes. The server reuses the UI validator and writes an actor-attributed audit row. Requires write access when connected with OAuth.

Send a message to the AgentLed AI agent and get a response. The agent can reason, plan, and build workflows through natural language conversation — no need to construct pipeline JSON manually. Use this tool when you want to: - Build a workflow from a high-level description ("Create a lead enrichment workflow for SaaS companies") - Get recommendations on how to structure a workflow - Ask questions about available integrations or capabilities - Iterate on workflow design through conversation The agent has access to the same planning tools, workflow builder, and workspace context as the in-app chat. For multi-turn conversations, pass the session_id returned from the first message to maintain context across messages. Example: chat("Build me a workflow that takes a LinkedIn company URL, enriches the data, and scores it by ICP fit") Requires write access when connected with OAuth.

Send a message to an agent. Defaults to the active workspace assistant (assistant@...) when no id or agent_slug is provided. Use list_agents first when you want to choose a different agent. The agent's instructions are used as the system prompt. Supports multi-turn conversations via session_id. Requires write access when connected with OAuth.

Claim a queued or needs_changes builder work item for this authenticated builder and append activity. Requires write access when connected with OAuth.

Clear the current fit assessment only after an explicit user instruction. This returns the record to Unreviewed while retaining bounded attributed change evidence. It does not run workflows, trigger routines, call providers, change approvals, write CRM data, mutate the source record, or spend credits. Requires write access when connected with OAuth.

Update non-secret channel configuration — enable/disable, default agent, allowed senders, outbound policy, etc. Allowed fields per channel: - email: enabled, allowedSenders (string[]), inboundAddress, allowOutboundEmail, allowedOutboundRecipients, requireOutboundApproval. defaultAgentId is legacy and ignored by email routing. - slack: enabled, defaultAgentId, defaultChannelId (Slack channel ID used to route inbound mentions when one Slack team is shared) - whatsapp: enabled, defaultAgentId - signal: enabled, defaultAgentId - telegram: enabled, defaultAgentId, botUsername, allowedChatIds Secret fields (botToken, signingSecret, accessToken, webhookSecret) are REJECTED by the external API — connect those via the Settings → Channels UI (OAuth flows encrypt at rest). Requires write access when connected with OAuth.

Configure the display-only Recent tab shown inside the existing workspace Home tab/table region, and choose which Home tab opens by default. Set config.defaultTabId to "recent" or to a use-case tab id listed by inspect_home_recent_tab to change the default tab; omit it to keep the legacy defaultSelected behavior. Requires the exact workspace revision returned by inspect_home_recent_tab and a full config object, or null to reset defaults. This only changes Home navigation and presentation: it does not run workflows, call providers, spend credits, change approvals, or mutate workflow/customer records. Requires write access when connected with OAuth.

Create a new agent with name, instructions, tools, workflows, and optional config files. The response includes channels for currently reachable inbound channels. Email is automatic per agent when the workspace email channel is enabled; use the returned email channel address rather than assigning a defaultAgentId for email. Agents are conversational AI Agents by default. For scheduled/autonomous work, create the agent first, then attach routines to it via create_routine (e.g. daily deal-sourcer, weekly digest). Key fields: - name: Agent display name - agentType: Preset template — 'personal-assistant', 'competitive-researcher', 'social-media-marketer', 'customer-support', 'content-marketer', 'lead-qualifier', 'deal-sourcer', 'custom' (default) - instructions: System prompt / core AGENTS.md content - enabledApps: App IDs this agent can use — get IDs from list_apps (e.g. ['web-scraping', 'kg', 'gmail']) - appPermissions: Optional per-app permissions keyed by app ID. Use { access: 'read' } for read-only or { access: 'write', writeApprovalRequired: true } for mutating access with approval. For per-action overrides, add actionApprovals with canonical action keys, e.g. { linkedin: { access: 'write', writeApprovalRequired: true, actionApprovals: { 'linkedin.create-comment': false } } }. Read access is implicit and never requires approval. The internal 'agentled' app is not configurable here. - skillIds: Skill IDs from list_agent_skills. Stored internally as enabledSkills; user-facing label is Skills. Use list_agent_skills({ includeRuntime: true }) only when configuring advanced runtime bundles such as workflow-operator, template-runner, or inline-execution. - assignedWorkflowIds: Workflow IDs this agent can trigger — get IDs from list_workflows - goals: Natural-language description of what the agent should achieve - configFiles: Override generated config files — keys are 'SOUL.md' (persona), 'TOOLS.md' (tool routing). If omitted, files are auto-generated from agentType template. Reflection context files ('JOURNAL.md', 'OBJECTIVES.md', 'PEOPLE.md') are linked AgentFiles, not configFiles. Active AI Agents auto-seed placeholders for those files. The agent decides what durable signal belongs there; do not write raw transcript logs or update them just because a chat turn happened. - avatar_icon_name: Lucide icon name for the agent avatar (e.g. 'Bot', 'Radar', 'Target', 'Sparkles') - avatar_color: Hex color for the avatar (e.g. '#6366f1', '#7C3AED', '#EA580C') - linkedFileIds: Workspace-level AgentFile IDs to attach as knowledge (from list_agent_files — workspace scope) - chatModel: Override the chat model (e.g. 'anthropic:claude-4-6-sonnet', 'openai:gpt-4o-mini') - activate: Set true to activate immediately (default false = draft) To add scheduled routines after creating the agent, use create_routine. Requires write access when connected with OAuth.

Create a durable work handoff from a business agent to an external AI builder. Use sourceAgentEntityId to preserve the business-agent owner for review/email/UI. Requires write access when connected with OAuth.

Create a new knowledge list with a typed schema. Idempotent on key collision — returns the existing list with a warning instead of erroring, so AI agents can safely re-run setup steps. Use this before inserting rows to ensure the list schema exists. Returns: { listKey, fieldCount, kgSyncEnabled, alreadyExisted? }. Requires write access when connected with OAuth.

Create and enable a public form link for a workflow so anyone can submit the workflow input form without an account. Requires write access when connected with OAuth.

Create a new routine for an agent. Routines are paid autonomous features; free-tier workspaces cannot create or resume them. Interval values: By schedule: weekday-morning (Mon–Fri 08:00 UTC), weekday-evening (Mon–Fri 18:00 UTC), weekly-monday (Mon 08:00 UTC), weekly-tuesday-evening (Tue 18:00 UTC), weekly-friday-evening (Fri 18:00 UTC), daily (every day 08:00 UTC), monthly (1st of month 08:00 UTC) By interval: 6h, 48h Model format: "provider:modelId" e.g. "openai:gpt-5.4-mini" (default). Use skillIds from list_agent_skills for routine-level skill overrides. Use list_agent_skills({ includeRuntime: true }) for advanced routine runtime bundles such as routine-core. Requires write access when connected with OAuth.

Create a manual config snapshot of a workflow's current state. Use this to save a checkpoint before making changes, so you can restore later if needed. Enforces plan-based limits (Pro=2, Teams=10, Custom=50). Returns an error with limit info if the snapshot limit is reached — delete old snapshots first to free up space. Requires write access when connected with OAuth.

Create a WorkspaceUseCase product record for a multi-workflow business goal. Use this before creating or attaching workflows for use cases such as sourcing, intake, front desk, or business intros. For config.useCasePage.body.columns, arbitrary badges can use case-insensitive valueRoles and numeric scores can use ordered minimum thresholds. Allowed semantic roles are neutral, accent, warning, success, and danger; never store CSS classes in config. This creates the product-layer object and linked references only; it does not create workflows, write KG rows, run providers, spend credits, trigger routines, or send messages. After creating it, create/update workflows with the returned workflowGraphId and keep linked refs on the use case current. Requires write access when connected with OAuth.

Create a new workflow. ## KG-First — before you write any prompt content If the workflow you're building contains workspace-specific content (investment thesis, ICP criteria, scoring rubrics, target sectors, brand voice, geo focus, seed lists), run this preflight before generating AI-step prompt strings: 1. **Inspect** — call `list_memories`, `list_knowledge_lists`, `get_knowledge_text` to see what already exists in the workspace KG. 2. **Seed** — if the content isn't in the KG yet, write it there first (`store_memory`, `upsert_knowledge_text`, `upsert_knowledge_rows`). Confirm with the user before seeding new content. 3. **Reference** — pull KG content at runtime in the step (`kg.read-text`, `kg.read-list`, `recall_memory`). Never paste workspace-specific paragraphs into prompt template strings. **Boundary: strategy → KG; execution wiring → workflow context; workflow structure → workflow.** ## Recommended flow for agent-authored workflows `create_workflow({ name, goal })` → `add_step` per step → `validate_workflow` → `publish_workflow`. Call this with **only** `name` + `goal` — leave `steps` empty. Then `add_step` one step at a time. The incremental path catches errors immediately and surfaces `{{input.X}}` / `{{steps.Y.Z}}` bindings per-step. Internal testing: 0 errors incremental vs 13 errors bulk. `pipeline.steps` is supported for imports/templates/round-trips only. Agents authoring from scratch should not use it. ## Pipeline object fields - `name` (required), `goal`, `description`, `context`, `metadata`, `style` - `steps`: Closed `type` values (others silently stripped): `trigger`, `appAction`, `aiAction`, `aiActionWithTools`, `toolAction`, `code`, `knowledgeSync`, `return`, `milestone`, `share`, `wait`, `branch`, `parallel`, `loop`, `end_if`, `agentOrchestrator`. Prefer `schedule` triggers for email intake and non-real-time use — idempotent, no webhook infra. Use `app_event`/`webhook` only for "as soon as" / "real-time" requirements. For child / sub-workflows that end in a `return` step and are only invoked via `agentled.call-workflow`, set `context.executionInputConfig.internal: true` to hide the Run button in the UI (see `update_workflow` for details). ## Step shape reference Call `get_step_schema({ stepType, shape? })` for the authoritative field schema AND minimal JSON examples of every common step shape. The highest-friction shapes are: - **Report step** (aiAction with Config renderer) — `get_step_schema({ stepType: "aiAction", shape: "report" })`. - **Composed email with approval** — `get_step_schema({ stepType: "aiAction", shape: "email" })`. Use this with `schedule-email`; do not add Gmail/Outlook send appActions unless explicitly requested. - **Agentic research** (web_search + workspace_memory) — `get_step_schema({ stepType: "aiActionWithTools", shape: "agentic-search" })`. - **Agent Team** (agentOrchestrator) — `get_step_schema({ stepType: "agentOrchestrator", shape: "supervisor" })`. - **Public share URL for a report** — `get_step_schema({ stepType: "share", shape: "public" })`. - **KG field mapping** — `get_step_schema({ stepType: "knowledgeSync", shape: "standard" })`. - **Code step** (JavaScript transformation) — `get_step_schema({ stepType: "code", shape: "standard" })`. JavaScript only — Python is not supported. For app actions, call `get_app_actions({ appId })` for input/output schemas. For models, call `list_models`. ## Composable Step Blocks **Search & Extract**: `aiAction (queries) → appAction (search) → aiAction (extract)` ⚠️ NEVER pass raw user input (job titles, topics) directly to a search API — always generate optimized boolean/keyword queries first. **Enrich & Score**: `appAction (fetch) → aiAction (score)` **Draft & Send**: `aiAction email → approval + schedule-email`. Use HTML bodies for open/click tracking. **Write app action with approval**: put the approval directly on the write `appAction` (`preExecuteApproval: true`, `onApproval.action: "execute-approved-action"`, `onApproval.target.type: "current-step"`). Do not add a separate "Approve X" milestone/wait step before the write action, and do not add a separate "Mark X sent/published" step unless it records the real post-send result. **Report & Notify**: `aiAction report with Config renderer → share step → aiAction notification email with concise HTML overview + shareUrl` **Loop Enrich & Filter**: `loopConfig on first step → appAction (enrich) → aiAction (score)` ## Available Apps & Data Sources **Before proposing data sources or sourcing channels to the user, you MUST know what is actually reachable.** The catalog has two billing models — don't conflate them, and don't invent connectors that don't exist. Always call `list_apps` and `get_app_actions({ appId })` to verify before finalizing a plan. ### Billed via Agentled credits (no user setup needed) - **agentled native LinkedIn / email**: `get-linkedin-profile-from-url`, `get-linkedin-company-from-url`, `find-email-person-domain`, `get-emails-from-company-domain`. - **agentled native LinkedIn search & content**: `linkedin-post-search` (keyword post search — primary LinkedIn discovery surface), `linkedin-jobs`, `linkedin-profile-posts`, `linkedin-company-posts`. - **email finder**: `hunter`. - **web fetch / scrape**: `web-scraping.scrape` (any URL → markdown), `http-request.request`, `page-index`. - **browser automation**: `browser-use.run-task` / `extract-data`, `anthropic-computer-use`, `openai-computer-use`. - **AI / image gen**: `openai`, `google-gemini`, `mistral`, `bytedance`, `kling`. - **public data feeds**: `french-gouv`, `google-maps`, `realtor`, `seloger`, `amazon`, `ad-intelligence`, `upwork`, `instagram`, `facebook`. - **knowledge graph**: `kg.*` (read-list, upsert-rows, update-rows, traverse-edges, etc.) — 1 credit per call. - **comms**: `gmail`, `google-calendar`, `webhook` (Slack/Discord), `notion`. ### Bring-your-own-key (NOT billed via Agentled credits) These require the user to connect their own account / paste their own API key. Treat them as available only if the user has the integration connected. - `crunchbase` (user's Crunchbase API key) - `specter` (user's Specter API key) - `affinity-crm` (user's Affinity API key) - `phantombuster` (user's PhantomBuster account — runs LinkedIn search agents, Sales Navigator scrapers, etc.) When proposing one of these, ask "do you already have a <service> account connected?" before assuming you can use it. ### Built-in tools (for `aiActionWithTools` steps, not standalone apps) `web_search`, `file_search`, `code_interpreter`, `fetch_website_content`, `kg_search`, `kg_traverse`, `kg_nodes`, `kg_write`, `workspace_memory`. Attach via the step's `tools` array; the AI decides at runtime whether to call them. ### Common gotchas - Want LinkedIn keyword/post search? Use the native `linkedin-post-search` (Agentled credits) — see `deal-sourcing-linkedin-founder-signals.ts` for a reference workflow. - Want LinkedIn Sales Navigator search / lead lists / company employees? `phantombuster` (BYOK) — see `deal-sourcing-linkedin.ts`. - No native ProductHunt / EU-Startups / X-Twitter connector — use `web-scraping.scrape` on a known URL or `web_search` via `aiActionWithTools`. - LinkedIn profile / company *enrichment* is URL-only (`get-linkedin-profile-from-url`). For discovery, pair it with `linkedin-post-search` or `phantombuster`. ## Multi-Workflow Architecture (Source → KG → Process) Before building a multi-workflow goal, call `list_use_cases` or `get_use_case`; reuse matching `workflowGraphId`, KG refs, agents, and workflows. Tag new bundles with `metadata.workflowGraph.id`. For a new multi-source/shared-tail goal, call `preview_use_case_kit` first and review its dry-run operations with the user. If the ask fits Source -> KG -> Process, **do not hand-roll** N disconnected `create_workflow` calls from scratch. When the user wants to "find leads", "source startups", "build a list to act on later", or run anything on a recurring cadence that produces entities to act on, **do not build one monolithic workflow**. Build several: 1. **One sourcing workflow per channel/theme** (e.g. "LinkedIn cybersecurity startups", "YC W25 batch", "ProductHunt this week"). Each runs on its own schedule and writes to a **shared KG list** via `kg.upsert-rows` with: `userKey` = stable id (URL/domain/LinkedIn URL) for O(1) dedup across runs; `status: "new"` to mark rows for downstream processing; `mergeStrategy: "merge"` so fields added later (scores, outreach status) survive re-upserts. 2. **One orchestrator/qualifier workflow** that runs on its own cadence (e.g. weekly), reads `kg.read-list({ filters: { status: "new" } })`, qualifies/scores each row against the current theme, then either dispatches to outreach or marks `status: "qualified" / "rejected"`. 3. **One outreach workflow** (often a child workflow called via `agentled.call-workflow`) that the orchestrator invokes for qualified rows. Why split: sourcing cadences, qualification criteria, and approval-gated outreach evolve independently. Multiple sourcing workflows converging on one `listKey` is the canonical pattern. Suggest the split explicitly ("N sourcing workflows + 1 qualifier + 1 outreach") instead of a mega-workflow. ## Build incrementally — two first, then refactor, then the rest When the plan calls for many sourcing workflows (or any N near-identical workflows), **do not build all N upfront**. Build two first, ship them end-to-end, then extract what is actually shared — most often the *tail*: normalize → kg.upsert-rows (with userKey + status: "new" + mergeStrategy: "merge") → milestone. Once the shared shape is clear: 1. Extract the common tail into a **child workflow** (terminal `return` step, `context.executionInputConfig.internal: true`) and have the two existing sourcing workflows call it via `agentled.call-workflow`. 2. Validate + run the two pilots end-to-end on the shared tail. 3. *Then* build the remaining sourcing workflows on top of that …

Create a workspace only when the caller has operator workspace-create scope; otherwise the request is rejected without mutation. Call resolve_workspace first. Trusted operators preparing a client workspace without changing plans, trials, or credits must set billingMode to planless. This setup primitive does not provision use-case kits, run workflows, insert candidate rows, send messages to customers, write CRM/calendar, call SignalKit receive, trigger routines, or spend provider credits. Requires write access when connected with OAuth.

Create a draft workspace skill backed by an existing AgentFile. The AgentFile content should contain the skill instructions/body. The WorkspaceSkill record stores lifecycle, risk, relevance, recommended apps/actions, and approval metadata. The allowedApps/allowedActions fields are recommendations for runtime guidance; actual availability still comes from the assigned agent app/action scope, runtime bundles, workspace connections, and approval gates. Prefer import_workspace_skill for Markdown/SKILL.md/JSON imports; use this low-level tool when you already have a reviewed AgentFile ID. Requires write access when connected with OAuth.

Create a saved WorkspaceView manifest over live workspace data. Workspace Views are general operating surfaces, not KG-only reports. Data sources can include KG lists/text, workflow executions/output pages/timelines, pending approvals, agent approvals, action queues, routine runs, external APIs, and custom sources. Creating the view writes only the manifest; it does not read sources, run workflows, insert KG rows, send messages, call providers, make approval decisions, or spend credits. Requires write access when connected with OAuth.

Permanently delete an agent and all its files. Attached routines are also removed by the API. Requires write access when connected with OAuth.

Permanently delete a file attached to an agent. Requires write access when connected with OAuth.

Delete a stopped workflow execution and its related timeline/chat records. EXCEPTION-ONLY admin maintenance tool. Requires an API key with admin:patch scope. Required operator flow: 1. Call stop_execution with a human-readable reason. 2. Wait until get_execution shows status "stopped". 3. Call delete_execution with reason and confirmExecutionId exactly matching executionId. The API rejects non-stopped executions and mismatched confirmation. This is destructive and should only be used for stopped test runs or incident cleanup. Requires write access when connected with OAuth.

Permanently delete a knowledge list and ALL its rows. This action is irreversible. Pass the listKey of the list to delete. The API requires confirm: true — this tool sends it automatically. Returns: { success, listKey }. Requires write access when connected with OAuth.

Delete specific rows from a knowledge list by their IDs. This action is irreversible. For more than 10 rows the API requires confirm: true — this tool sends it automatically. Returns: { deleted, errors[] } where each error includes a structured code field: - foreign_key_constraint: row is referenced by KG edges (scoring predictions, outcomes, relations) and cannot be hard-deleted - not_found: row ID does not exist - permission_denied: insufficient workspace permissions - delete_failed: unclassified failure IMPORTANT: Rows referenced by KG edges cannot be hard-deleted. If you receive foreign_key_constraint errors, use soft-delete instead: call upsert_knowledge_rows with mergeStrategy "merge" and rowData { _dropped: true, _dropReason: "..." }. Workflow readers typically filter on _dropped or status != "noise", so soft-deleted rows are excluded from downstream reads. Requires write access when connected with OAuth.

Delete a text-based knowledge entry by key. This action is irreversible. Returns: { success, key }. Requires write access when connected with OAuth.

Delete a specific memory by key. Requires write access when connected with OAuth.

Delete a public form link by token/id. Currently unsupported by External API (returns 501). Requires write access when connected with OAuth.

Permanently delete a routine. This cannot be undone. Requires write access when connected with OAuth.

Delete a specific config snapshot. Use list_snapshots to find snapshot IDs. Useful for freeing up space when the snapshot limit is reached. Requires write access when connected with OAuth.

Permanently delete a workflow by ID. This cannot be undone. **Two-phase flow (required):** 1. Call with just `workflowId` to get a deletion preview. Response: `{ pendingDelete: true, id, name, status, relatedEntities: { executions, leads, timelines }, relatedEntitiesTruncated, confirmToken, expiresIn: 300, expiresAt, message }` Nothing is deleted in phase 1. Token is valid for 5 minutes. 2. Call again with both `workflowId` AND `confirmToken` to perform the cascade delete. Response: `{ deleted: true, id }`. **Server error responses (always structured JSON):** - `404 { error: "Workflow not found" }` — wrong ID or wrong workspace. - `403 { error: "Invalid or expired confirmation token. Request a new deletion preview first." }` — token typo, expired, or workspace/workflow mismatch. - `500 { error: "Failed to delete workflow" }` — cascade failure (rare; safe to retry phase 2 with a fresh token). **If you see a bare "Denied." with no detail, that is your MCP host (Claude Desktop / Cursor / etc.) denying the destructive call at the approval-policy layer, not this server.** Agentled never returns "Denied." — every error from this tool includes a JSON body. Check the host's tool-permission settings and re-approve, then retry. Requires write access when connected with OAuth.

Discard the draft snapshot for a live workflow. The live pipeline config stays unchanged. Use this to abandon draft changes and go back to the current live version. Requires write access when connected with OAuth.

Semantic intent router — describe what you want to accomplish in plain English and Agentled will find the best matching live workflow in your workspace. Optionally auto-executes the matched workflow. Examples: - "find the CEO's email for stripe.com" - "research acme corp and score them against our ICP" - "scrape https://example.com and summarize it" Returns the best match with confidence score, extracted inputs, and alternatives. Set execute=true to also start the matched workflow immediately. Requires write access when connected with OAuth.

Export a workflow as portable JSON for cross-environment transfer. Returns a self-contained WorkflowExport object with all steps, context, metadata, and pages. Workspace-specific identifiers (workspaceId, agentIds) are stripped so the export can be imported into any workspace. Use this together with import_workflow to move workflows between environments (e.g. sandbox → prod).

Get full details of an agent including its config, files, attached routines, and assigned inbound channels.

Get the content of a specific file attached to an agent.

Get detailed action schemas for a specific app. Returns input parameters, output fields, and credit costs. Use this to understand exactly what inputs an action needs when building workflow steps.

Get the workspace's whitelabel branding configuration. Returns the current branding settings: displayName, logoUrl, tagline, primaryColor, primaryColorDark, faviconUrl, and hideBadge. Use this to inspect the current client portal branding before making changes.

Get full builder work item context, outputs, activity, metadata, and review state.

Get the status or final result for a durable external chat turn returned by chat or chat_with_agent. Use this after a chat tool response returns status "running" and a turn_id. Polling this tool is idempotent and does not rerun the original prompt, model call, app actions, approvals, credits, or external sends.

Get the draft snapshot for a live workflow. When you update a live workflow, changes go to a draft instead of modifying the live pipeline. Use this to inspect the current draft state. Returns hasDraft: true/false and the draft config if it exists.

Get full execution details including results from each completed step. The executionContent field maps stepId -> step output data. Use this to inspect what a workflow produced, debug failures, or check intermediate results. executionId must be the PipelineExecution id, not executionInputId. If start_workflow returned only executionInputId, first call list_executions and match pipelineExecutionInputId to find the execution id. When sharing a step-specific run with a human, use /runs?runId=<executionId>&step=<workflowStepId>. Do not send a run-only URL and ask the human to open an approval/output/failure/current step manually.