loopengine 0.1.97 → 0.1.99

package/dist/core/system-agents/templates.js

@@ -1,7 +1,7 @@
 import { nextTimeOfDay, parseTimeOfDay, workspaceTimeZone } from '../time-zone.js';
 const GMAIL_KEYS = ['GMAIL_CLIENT_ID', 'GMAIL_CLIENT_SECRET', 'GMAIL_REFRESH_TOKEN'];
 const SHOPIFY_KEYS = ['SHOPIFY_STORE_DOMAIN', 'SHOPIFY_ADMIN_TOKEN'];
-const GITHUB_KEYS = ['GITHUB_TOKEN', 'GITHUB_DEFAULT_REPO'];
+const GITHUB_APP = 'io.github.github/github-mcp-server';
 const SLACK_KEYS = ['SLACK_BOT_TOKEN', 'SLACK_DEFAULT_CHANNEL'];
 const WEB_SEARCH_KEYS = [['TAVILY_API_KEY', 'BRAVE_API_KEY', 'FIRECRAWL_API_KEY']];
 const DOCS_NOTE = 'Put your policies and help articles in the project\'s docs folder, as Markdown or text files (or point DOCS_SEARCH_PATH at another folder)';
@@ -128,20 +128,22 @@ Rules:
             risk: 'medium',
             asksFirst: ['opening or commenting on issues'],
             needs: [
-                { kind: 'ability', name: 'lp-github', description: 'your repository\'s commits, deploys and issues' },
+                { kind: 'app', name: 'GitHub', description: 'your repository\'s commits, deploys and issues' },
                 { kind: 'ability', name: 'lp-slack-notifier', description: 'posting the summary to Slack' },
             ],
             agent: {
                 name: 'incident-triage',
                 systemPrompt: `You help the on-call engineer triage incidents.
 
+Our repository on GitHub: [owner/name] (edit this). Pass its owner and repo to every GitHub tool.
+
 When you get an alert, error or bug report:
 1. Summarise it in two sentences: what is failing and who is affected.
 2. Rate the severity: SEV1 (customers can't use the product), SEV2 (a major feature is broken), SEV3 (degraded or a workaround exists), SEV4 (minor).
-3. Find what changed shortly before it started: github_list_workflow_runs for recent deploys and failed builds, github_list_pull_requests for recently merged changes, and github_list_commits (narrowed with since_hours and path) for detail. Match times carefully.
-4. Check whether it's already known with github_search_issues; read a match with github_get_issue.
+3. Find what changed shortly before it started: github_actions_list (method list_workflow_runs) for recent deploys and failed builds, github_list_pull_requests (state closed) for recently merged changes, and github_list_commits (narrowed with since and path) for detail. Match times carefully.
+4. Check whether it's already known with github_search_issues; read a match with github_issue_read (method get).
 5. Post a short summary to Slack with post_to_slack: what's broken, severity, the most likely cause with links, and one next step (who should look, what to check, or whether to roll back).
-6. If an issue already tracks it, add your findings with github_comment_issue; otherwise, for SEV1 or SEV2, open one with github_create_issue. Both ask a person first.
+6. If an issue already tracks it, add your findings with github_add_issue_comment; otherwise, for SEV1 or SEV2, open one with github_issue_write (method create). Both ask a person first.
 
 Rules:
 - Only read on your own; never roll anything back yourself.
@@ -151,12 +153,13 @@ Rules:
             },
         },
         setup: {
-            abilities: ['lp-github', 'lp-slack-notifier'],
-            keys: [...GITHUB_KEYS, ...SLACK_KEYS],
+            abilities: ['lp-slack-notifier'],
+            apps: [{ id: GITHUB_APP, title: 'GitHub', tools: ['list_commits', 'list_pull_requests', 'actions_list', 'search_issues', 'issue_read', 'issue_write', 'add_issue_comment'] }],
+            keys: [...SLACK_KEYS],
             rules: [
                 { name: 'template-slack-summary-allowed', tool: 'post_to_slack', decision: 'allow' },
-                { name: 'template-new-issues-need-approval', tool: 'github_create_issue', decision: 'ask' },
-                { name: 'template-comments-need-approval', tool: 'github_comment_issue', decision: 'ask' },
+                { name: 'template-new-issues-need-approval', tool: 'github_issue_write', decision: 'ask' },
+                { name: 'template-comments-need-approval', tool: 'github_add_issue_comment', decision: 'ask' },
             ],
             needsApprovals: true,
             notes: ['Send it alerts: paste one into Chat, have your alerting tool call it over HTTP, or reply to it in Slack'],
@@ -280,12 +283,14 @@ Rules:
             asksFirst: ['replying to the sender'],
             needs: [
                 { kind: 'ability', name: 'lp-gmail', description: 'the shared inbox' },
-                { kind: 'ability', name: 'lp-github', description: 'tasks, as GitHub issues' },
+                { kind: 'app', name: 'GitHub', description: 'tasks, as GitHub issues' },
             ],
             agent: {
                 name: 'inbox-to-tasks',
                 systemPrompt: `You turn requests in our shared inbox into tasks, kept as GitHub issues.
 
+Tasks live in this GitHub repository: [owner/name] (edit this). Pass its owner and repo to every GitHub tool.
+
 Who handles what (edit this; GitHub usernames):
 - Billing and invoices: [username]
 - Technical problems: [username]
@@ -294,8 +299,8 @@ Who handles what (edit this; GitHub usernames):
 When asked to handle new emails:
 1. Find them with gmail_search, query "is:unread in:inbox". Read each with gmail_get_thread.
 2. Decide whether it's a request someone needs to act on. Newsletters, receipts, out-of-office replies and spam are not: mark them read and move on.
-3. Check whether a task already exists with github_search_issues (the sender and subject). If so, add the new details with github_comment_issue instead.
-4. Otherwise open one with github_create_issue: a short title starting with a verb, a two-line summary, the sender, the due date (the date they asked for, or 2 working days if they didn't say), and the owner from the list above as the assignee.
+3. Check whether a task already exists with github_search_issues (the sender and subject). If so, add the new details with github_add_issue_comment instead.
+4. Otherwise open one with github_issue_write (method create): a short title starting with a verb, a two-line summary, the sender, the due date (the date they asked for, or 2 working days if they didn't say), and the owner from the list above as the assignee.
 5. Reply to the sender with gmail_send (reply_to_message_id set): who is handling it and by when. A person approves it first.
 6. Mark the email read with gmail_modify_labels.
 
@@ -307,14 +312,15 @@ Rules:
             },
         },
         setup: {
-            abilities: ['lp-gmail', 'lp-github'],
-            keys: [...GMAIL_KEYS, ...GITHUB_KEYS],
+            abilities: ['lp-gmail'],
+            apps: [{ id: GITHUB_APP, title: 'GitHub', tools: ['search_issues', 'issue_write', 'add_issue_comment'] }],
+            keys: [...GMAIL_KEYS],
             rules: [
                 { name: 'template-read-mail-allowed', tool: 'gmail_search', decision: 'allow' },
                 { name: 'template-read-thread-allowed', tool: 'gmail_get_thread', decision: 'allow' },
                 { name: 'template-labels-allowed', tool: 'gmail_modify_labels', decision: 'allow' },
-                { name: 'template-tasks-allowed', tool: 'github_create_issue', decision: 'allow' },
-                { name: 'template-task-updates-allowed', tool: 'github_comment_issue', decision: 'allow' },
+                { name: 'template-tasks-allowed', tool: 'github_issue_write', decision: 'allow' },
+                { name: 'template-task-updates-allowed', tool: 'github_add_issue_comment', decision: 'allow' },
                 { name: 'template-replies-need-approval', tool: 'gmail_send', decision: 'ask' },
             ],
             schedule: { every: '10m', name: 'Check the shared inbox', message: 'Turn the new emails in the shared inbox into tasks.' },

package/dist/core/system-agents/workflow-planner.d.ts

@@ -1,6 +1,6 @@
 import type { ToolSchema } from '#core/agent-config.js';
 import type { ModelCall } from '#core/run-agent.js';
-import type { StarterTemplate } from './templates.js';
+import type { StarterTemplate, TemplateApp } from './templates.js';
 export type Decision = 'allow' | 'ask' | 'deny';
 export interface WorkflowStep {
     title: string;
@@ -18,6 +18,30 @@ export interface WorkflowStep {
      * an ability): the source's name. It's copied to the agent that runs the
      * workflow, not installed. */
     connection?: string;
+    /** For a step done by an MCP server's tool, when no ability has it: the
+     * server's id (search_mcp_servers). `tool` is then the server's own
+     * tool name, if the planner could see them. On Create the server
+     * becomes a private ability (core/mcp-ability-generator.ts) and the
+     * step points at its tool instead. */
+    mcp?: string;
+}
+/** An MCP server a plan would set up as a private ability. */
+export interface PlannedMcpServer {
+    id: string;
+    title: string;
+    url: string;
+    description: string;
+    /** Saved by the workspace, or on its publisher's verified domain. */
+    verified: boolean;
+    source: 'saved' | 'registry';
+    /** The private ability it becomes, e.g. mcp-linear. */
+    ability: string;
+    /** The setting its key is saved as, when it takes one. */
+    keyEnv: string;
+    /** Whether that setting already has a value. */
+    keySet: boolean;
+    /** The workspace already has an ability made from this server. */
+    existing?: string;
 }
 export interface WorkflowPlan {
     name: string;
@@ -64,6 +88,11 @@ export interface WorkflowPlan {
     };
     /** What the workspace can't do yet, in plain words. */
     gaps: string[];
+    /** MCP servers its steps use, set up on Create (filled in after planning). */
+    mcpServers?: PlannedMcpServer[];
+    /** Connected apps it adds to the agent, with just the tools its steps
+     * use (filled in on Create, from mcpServers). */
+    apps?: TemplateApp[];
 }
 export interface WorkflowPlannerTools {
     /** Every agent: its tools, installed abilities, rules and messaging. */
@@ -81,9 +110,13 @@ export interface WorkflowPlannerTools {
     /** An ability's tools (with the decision each ships with) and settings. */
     abilityDetails(spec: string): Promise<unknown>;
     listConnections(): Promise<Record<string, unknown>>;
+    /** MCP servers matching a query (core/mcp-directory.ts). Optional: without it the planner only plans with abilities. */
+    searchMcpServers?(query: string): Promise<unknown>;
+    /** A server's tools, when it can be listed without a key (or with one already set). */
+    mcpServerTools?(id: string): Promise<unknown>;
 }
-export declare const WORKFLOW_PLANNER_PROMPT = "You turn a workflow a person describes into a plan for a LoopEngine agent.\n\nLoopEngine agents call tools. Tools come from abilities (installable packages: public ones on npm, or the workspace's own private ones) or are built in. Each tool has a permission: allow (runs on its own), ask (waits for a person to approve, edit or deny it) or deny. When nobody is in Chat, questions and approvals go to the agent's messaging app (Slack, Telegram, Lark or email) and the run waits, for days if needed, then carries on.\n\nHow to plan:\n1. Look before you plan: list_agents (what exists, and what each agent's tools and rules are), list_workspace_abilities, search_public_abilities for each kind of step (even when an agent already has a connected tool for it), ability_details for any ability you might use (its exact tool names and the settings it needs), and list_connections.\n2. Split the workflow into steps, in order. For each step:\n   - something to fetch or do: kind \"tool\", with the exact tool name and where it comes from. Pick the source in this order:\n     a. A tool the target agent already has (from list_agents): use it, nothing to install.\n     b. An ability: a workspace ability (list_workspace_abilities) or a public one (search_public_abilities, e.g. \"firecrawl\" or \"web search\" for searching and reading the web). Set \"ability\" to its install spec (the npm name, or a workspace ability's spec) and use the exact tool name from ability_details.\n     c. Only when no ability does it: a tool in some agent's connectedTools (a connected service, usually one that needs a person to sign in, like Gmail or HubSpot). Give its exact tool name, set \"connection\" to that source's name and leave \"ability\" empty (it's copied to the agent that runs the workflow). Never put a connection's name in abilities.\n     An ability beats a connected tool even when another agent already has the connected one: it's faster, needs only a key, and travels with the agent. If you chose a connected tool, say why in gaps.\n   - the person chooses or answers (\"ask me which\", \"let me pick\"): kind \"ask\", tool \"system_ask_user\" (built in, no ability). Say what options are offered. It reaches them through the agent's messaging app by itself, so don't add a separate step to post to Slack or another chat first, and don't install a chat ability just to ask.\n   - the person reviews or approves before something happens (\"let me review it\", \"before it's sent\"): kind \"approval\", on the tool that does that thing; its rule becomes \"ask\".\n   - the agent's own work (writing, summarising, choosing): kind \"other\".\n   - nothing found can do it: set \"missing\" to what's needed, and add it to gaps.\n3. Rules: every tool the workflow uses gets one. Reading and searching: allow. Anything a person should see first (sending, publishing, paying, creating something others see): ask. Never set deny unless asked.\n4. Skill: the steps in order, as numbered instructions the agent follows, naming the tools and saying exactly when to stop and ask. Write it so the agent keeps going after each answer or decision.\n5. Trigger: a schedule (\"every Monday at 9\" is every \"7d\", at \"09:00\", weekday 1) or on_request (started from Chat or a message). startMessage is what the agent receives when it starts.\n6. Target: an existing agent only when it already has (or can install) the tools, none of the workflow's rules would change a decision it already has, and the same people would approve. Otherwise a new agent, with a short lowercase-hyphenated name and a system prompt saying who it is and what it's for. Give the reason either way.\n7. keys: the setting names its abilities need that list_connections or the agents don't show as set (from ability_details settings).\n\nThen call save_plan once, with the whole plan. Don't ask the person questions: if something is unclear, plan the most reasonable version and note the assumption in gaps.";
-export declare function workflowPlannerTools(): ToolSchema[];
+export declare const WORKFLOW_PLANNER_PROMPT = "You turn a workflow a person describes into a plan for a LoopEngine agent.\n\nLoopEngine agents call tools. Tools come from abilities (installable packages: public ones on npm, or the workspace's own private ones) or are built in. Each tool has a permission: allow (runs on its own), ask (waits for a person to approve, edit or deny it) or deny. When nobody is in Chat, questions and approvals go to the agent's messaging app (Slack, Telegram, Lark or email) and the run waits, for days if needed, then carries on.\n\nHow to plan:\n1. Look before you plan: list_agents (what exists, and what each agent's tools and rules are), list_workspace_abilities, search_public_abilities for each kind of step, ability_details for any ability you might use (its exact tool names and the settings it needs), and list_connections.\n2. Split the workflow into steps, in order. For each step:\n   - something to fetch or do: kind \"tool\", with the exact tool name and where it comes from. Pick the source in this order:\n     a. A tool the target agent already has (from list_agents): use it, nothing to install.\n     b. An ability: a workspace ability (list_workspace_abilities) or a public one (search_public_abilities, e.g. \"firecrawl\" or \"web search\" for searching and reading the web). Set \"ability\" to its install spec (the npm name, or a workspace ability's spec) and use the exact tool name from ability_details.\n     c. Only when no ability can do it, and search_mcp_servers is available: an app's MCP server. Search for the app (e.g. \"linear\", \"stripe\"), pick the app's own server (official), else a saved or verified one, then call mcp_server_tools. Set \"mcp\" to the server's id, and \"tool\" to its exact tool name when mcp_server_tools lists them (leave \"tool\" empty when it needs a key first, and say in \"detail\" what the step does). It's set up as a private ability when the workflow is created, which picks its tools and their permissions, so add no rules for MCP tools.\n   - the person chooses or answers (\"ask me which\", \"let me pick\"): kind \"ask\", tool \"system_ask_user\" (built in, no ability). Say what options are offered. It reaches them through the agent's messaging app by itself, so don't add a separate step to post to Slack or another chat first, and don't install a chat ability just to ask.\n   - the person reviews or approves before something happens (\"let me review it\", \"before it's sent\"): kind \"approval\", on the tool that does that thing; its rule becomes \"ask\".\n   - the agent's own work (writing, summarising, choosing): kind \"other\".\n   - nothing found can do it: set \"missing\" to what's needed, and add it to gaps.\n3. Rules: every tool the workflow uses gets one. Reading and searching: allow. Anything a person should see first (sending, publishing, paying, creating something others see): ask. Never set deny unless asked.\n4. Skill: the steps in order, as numbered instructions the agent follows, naming the tools and saying exactly when to stop and ask. Write it so the agent keeps going after each answer or decision.\n5. Trigger: a schedule (\"every Monday at 9\" is every \"7d\", at \"09:00\", weekday 1) or on_request (started from Chat or a message). startMessage is what the agent receives when it starts.\n6. Target: an existing agent only when it already has (or can install) the tools, none of the workflow's rules would change a decision it already has, and the same people would approve. Otherwise a new agent, with a short lowercase-hyphenated name and a system prompt saying who it is and what it's for. Give the reason either way.\n7. keys: the setting names its abilities need that list_connections or the agents don't show as set (from ability_details settings). Not for MCP servers: their keys are asked for on the plan.\n\nThen call save_plan once, with the whole plan. Don't ask the person questions: if something is unclear, plan the most reasonable version and note the assumption in gaps.";
+export declare function workflowPlannerTools(withMcp?: boolean): ToolSchema[];
 /** lowercase-hyphenated, 2–40 characters. */
 export declare function slugify(value: string, fallback?: string): string;
 /** A plan from the model's save_plan input, or undefined when it lacks a

package/dist/core/system-agents/workflow-planner.js

@@ -4,13 +4,12 @@ export const WORKFLOW_PLANNER_PROMPT = `You turn a workflow a person describes i
 LoopEngine agents call tools. Tools come from abilities (installable packages: public ones on npm, or the workspace's own private ones) or are built in. Each tool has a permission: allow (runs on its own), ask (waits for a person to approve, edit or deny it) or deny. When nobody is in Chat, questions and approvals go to the agent's messaging app (Slack, Telegram, Lark or email) and the run waits, for days if needed, then carries on.
 
 How to plan:
-1. Look before you plan: list_agents (what exists, and what each agent's tools and rules are), list_workspace_abilities, search_public_abilities for each kind of step (even when an agent already has a connected tool for it), ability_details for any ability you might use (its exact tool names and the settings it needs), and list_connections.
+1. Look before you plan: list_agents (what exists, and what each agent's tools and rules are), list_workspace_abilities, search_public_abilities for each kind of step, ability_details for any ability you might use (its exact tool names and the settings it needs), and list_connections.
 2. Split the workflow into steps, in order. For each step:
    - something to fetch or do: kind "tool", with the exact tool name and where it comes from. Pick the source in this order:
      a. A tool the target agent already has (from list_agents): use it, nothing to install.
      b. An ability: a workspace ability (list_workspace_abilities) or a public one (search_public_abilities, e.g. "firecrawl" or "web search" for searching and reading the web). Set "ability" to its install spec (the npm name, or a workspace ability's spec) and use the exact tool name from ability_details.
-     c. Only when no ability does it: a tool in some agent's connectedTools (a connected service, usually one that needs a person to sign in, like Gmail or HubSpot). Give its exact tool name, set "connection" to that source's name and leave "ability" empty (it's copied to the agent that runs the workflow). Never put a connection's name in abilities.
-     An ability beats a connected tool even when another agent already has the connected one: it's faster, needs only a key, and travels with the agent. If you chose a connected tool, say why in gaps.
+     c. Only when no ability can do it, and search_mcp_servers is available: an app's MCP server. Search for the app (e.g. "linear", "stripe"), pick the app's own server (official), else a saved or verified one, then call mcp_server_tools. Set "mcp" to the server's id, and "tool" to its exact tool name when mcp_server_tools lists them (leave "tool" empty when it needs a key first, and say in "detail" what the step does). It's set up as a private ability when the workflow is created, which picks its tools and their permissions, so add no rules for MCP tools.
    - the person chooses or answers ("ask me which", "let me pick"): kind "ask", tool "system_ask_user" (built in, no ability). Say what options are offered. It reaches them through the agent's messaging app by itself, so don't add a separate step to post to Slack or another chat first, and don't install a chat ability just to ask.
    - the person reviews or approves before something happens ("let me review it", "before it's sent"): kind "approval", on the tool that does that thing; its rule becomes "ask".
    - the agent's own work (writing, summarising, choosing): kind "other".
@@ -19,10 +18,10 @@ How to plan:
 4. Skill: the steps in order, as numbered instructions the agent follows, naming the tools and saying exactly when to stop and ask. Write it so the agent keeps going after each answer or decision.
 5. Trigger: a schedule ("every Monday at 9" is every "7d", at "09:00", weekday 1) or on_request (started from Chat or a message). startMessage is what the agent receives when it starts.
 6. Target: an existing agent only when it already has (or can install) the tools, none of the workflow's rules would change a decision it already has, and the same people would approve. Otherwise a new agent, with a short lowercase-hyphenated name and a system prompt saying who it is and what it's for. Give the reason either way.
-7. keys: the setting names its abilities need that list_connections or the agents don't show as set (from ability_details settings).
+7. keys: the setting names its abilities need that list_connections or the agents don't show as set (from ability_details settings). Not for MCP servers: their keys are asked for on the plan.
 
 Then call save_plan once, with the whole plan. Don't ask the person questions: if something is unclear, plan the most reasonable version and note the assumption in gaps.`;
-export function workflowPlannerTools() {
+export function workflowPlannerTools(withMcp = false) {
     const step = {
         type: 'object',
         properties: {
@@ -30,9 +29,9 @@ export function workflowPlannerTools() {
             kind: { type: 'string', enum: ['tool', 'ask', 'approval', 'other'] },
             tool: { type: 'string' },
             ability: { type: 'string' },
+            mcp: { type: 'string', description: "an MCP server's id, for a step no ability can do" },
             detail: { type: 'string' },
             missing: { type: 'string' },
-            connection: { type: 'string' },
         },
         required: ['title', 'kind'],
     };
@@ -42,6 +41,10 @@ export function workflowPlannerTools() {
         { name: 'search_public_abilities', description: 'Search public LoopEngine abilities on npm, e.g. "web search", "wordpress", "slack".', input_schema: { type: 'object', properties: { query: { type: 'string' } }, required: ['query'] } },
         { name: 'ability_details', description: "An ability's exact tool names, what each does, the permission each ships with, and the settings it needs. spec: its npm name or workspace spec.", input_schema: { type: 'object', properties: { spec: { type: 'string' } }, required: ['spec'] } },
         { name: 'list_connections', description: 'What is set up: model providers with keys, messaging apps per agent.', input_schema: { type: 'object', properties: {} } },
+        ...(withMcp ? [
+            { name: 'search_mcp_servers', description: "Search apps' MCP servers (the workspace's saved ones, then the public MCP Registry), for a step no ability can do. query: the app's name, e.g. \"linear\".", input_schema: { type: 'object', properties: { query: { type: 'string' } }, required: ['query'] } },
+            { name: 'mcp_server_tools', description: "An MCP server's tools (name, description, read-only or not), or a note that it needs a key before they can be seen. id: from search_mcp_servers.", input_schema: { type: 'object', properties: { id: { type: 'string' } }, required: ['id'] } },
+        ] : []),
         {
             name: 'save_plan',
             description: 'Save the workflow plan. Call once, at the end.',
@@ -113,6 +116,7 @@ export function validateWorkflowPlan(raw) {
                 ...(str(step.detail, 600) ? { detail: str(step.detail, 600) } : {}),
                 ...(str(step.missing, 300) ? { missing: str(step.missing, 300) } : {}),
                 ...(str(step.connection, 120) ? { connection: str(step.connection, 120) } : {}),
+                ...(str(step.mcp, 200) && !str(step.ability, 300) ? { mcp: str(step.mcp, 200) } : {}),
             }];
     });
     if (!steps.length)
@@ -128,14 +132,17 @@ export function validateWorkflowPlan(raw) {
             ...(typeof triggerRaw.weekday === 'number' && triggerRaw.weekday >= 0 && triggerRaw.weekday <= 7 ? { weekday: triggerRaw.weekday } : {}),
         }
         : { kind: 'on_request', description: str(triggerRaw.description, 200) ?? 'when asked' };
+    // An MCP step's permissions are set when its server becomes an ability.
+    const mcpTools = new Set(steps.flatMap((s) => (s.mcp && s.tool ? [s.tool] : [])));
     const rules = (Array.isArray(r.rules) ? r.rules : []).flatMap((x) => {
         const rule = (x ?? {});
         const tool = str(rule.tool, 120);
         return tool && isDecision(rule.decision) && tool !== 'system_ask_user' ? [{ tool, decision: rule.decision }] : [];
-    });
-    // An approval step's tool always asks first.
+    }).filter((rule) => !mcpTools.has(rule.tool));
+    // An approval step's tool always asks first (an MCP step's tool gets
+    // that when its ability is made).
     for (const step of steps) {
-        if (step.kind !== 'approval' || !step.tool)
+        if (step.kind !== 'approval' || !step.tool || step.mcp)
             continue;
         const rule = rules.find((x) => x.tool === step.tool);
         if (rule)
@@ -178,7 +185,7 @@ export async function planWorkflowWithModel(modelCall, description, tools) {
     for (let round = 0; round <= MAX_TOOL_ROUNDS; round++) {
         let response;
         try {
-            response = await modelCall(messages, WORKFLOW_PLANNER_PROMPT, workflowPlannerTools());
+            response = await modelCall(messages, WORKFLOW_PLANNER_PROMPT, workflowPlannerTools(Boolean(tools.searchMcpServers)));
         }
         catch (err) {
             // A reply cut off part-way (its tool arguments end mid-JSON) usually
@@ -229,6 +236,12 @@ export async function planWorkflowWithModel(modelCall, description, tools) {
                     case 'list_connections':
                         output = await tools.listConnections();
                         break;
+                    case 'search_mcp_servers':
+                        output = tools.searchMcpServers ? await tools.searchMcpServers(String(input.query ?? '')) : 'not available';
+                        break;
+                    case 'mcp_server_tools':
+                        output = tools.mcpServerTools ? await tools.mcpServerTools(String(input.id ?? '')) : 'not available';
+                        break;
                     case 'save_plan':
                         plan = validateWorkflowPlan(input);
                         output = plan ? 'saved' : 'that plan needs a name, summary, at least one step, a skill body and newAgent.systemPrompt; fix and call again';
@@ -266,6 +279,7 @@ export function workflowTemplate(plan) {
         },
         setup: {
             abilities: plan.abilities,
+            ...(plan.apps?.length ? { apps: plan.apps } : {}),
             keys: plan.keys,
             skills: [{ id: plan.id, description: plan.skill.description, body: plan.skill.body }],
             rules: plan.rules.map((r) => ({ name: slugify(`${plan.id}-${r.tool}`, `${plan.id}-rule`), tool: r.tool, decision: r.decision })),

package/dist/core/workspace-abilities.js

@@ -1,6 +1,6 @@
 // The workspace's own copies of private abilities: installed once from a
 // private source (core/ability-sources.ts) on the console's Abilities
-// page, then added to any agent from its Abilities tab. Each copy is a
+// page, then added to any agent from its Apps tab. Each copy is a
 // folder under abilities/ in the project root (or the folder
 // LOOPENGINE_ABILITIES_DIR names), and abilities/workspace.json says
 // where each came from:

package/dist/index.d.ts

@@ -99,6 +99,9 @@ export type { PublicAbilitySearchResult } from './web/abilities-admin.js';
 export { AbilitySourceError, abilityOrigin, readAbilitySources, saveAbilitySource, removeAbilitySource, listSourceAbilities, sourceTokenVar, type AbilitySource, type SourceAbility, type AbilityOrigin } from './core/ability-sources.js';
 export { describeAbilitySources, listPrivateAbilities, saveAbilitySourceFromConsole, removeAbilitySourceFromConsole } from './web/ability-sources-admin.js';
 export { readAbilityDetails, readToolDefinitions, type AbilityDetails } from './core/ability-details.js';
+export { loadMcpAbilityTools, mcpAbilityLoadError, closeMcpConnections, resolveMcpManifest, listMcpServerTools, isMcpAuthError, type McpServerManifest, type McpAuth, type InstalledMcpRecord, type McpToolInfo } from './core/mcp-abilities.js';
+export { searchMcpServers, getMcpServer, savedMcpServers, type McpDirectoryServer } from './core/mcp-directory.js';
+export { generateMcpAbility, mcpAbilityNames, McpAbilityGenerationError, type GeneratedMcpAbility, type McpAbilityRequest } from './core/mcp-ability-generator.js';
 export { abilityDetails } from './web/ability-details-admin.js';
 export { WorkspaceAbilityError, listWorkspaceAbilities, addWorkspaceAbility, removeWorkspaceAbility, workspaceAbilitiesDir, type WorkspaceAbility } from './core/workspace-abilities.js';
 export { installWorkspaceAbility, installUploadedAbility, MAX_UPLOAD_BYTES, type AbilityUpload } from './web/workspace-abilities-admin.js';

package/dist/index.js

@@ -89,6 +89,9 @@ export { searchPublicAbilities, fetchLatestAbilityVersion } from './web/abilitie
 export { AbilitySourceError, abilityOrigin, readAbilitySources, saveAbilitySource, removeAbilitySource, listSourceAbilities, sourceTokenVar } from './core/ability-sources.js';
 export { describeAbilitySources, listPrivateAbilities, saveAbilitySourceFromConsole, removeAbilitySourceFromConsole } from './web/ability-sources-admin.js';
 export { readAbilityDetails, readToolDefinitions } from './core/ability-details.js';
+export { loadMcpAbilityTools, mcpAbilityLoadError, closeMcpConnections, resolveMcpManifest, listMcpServerTools, isMcpAuthError } from './core/mcp-abilities.js';
+export { searchMcpServers, getMcpServer, savedMcpServers } from './core/mcp-directory.js';
+export { generateMcpAbility, mcpAbilityNames, McpAbilityGenerationError } from './core/mcp-ability-generator.js';
 export { abilityDetails } from './web/ability-details-admin.js';
 export { WorkspaceAbilityError, listWorkspaceAbilities, addWorkspaceAbility, removeWorkspaceAbility, workspaceAbilitiesDir } from './core/workspace-abilities.js';
 export { installWorkspaceAbility, installUploadedAbility, MAX_UPLOAD_BYTES } from './web/workspace-abilities-admin.js';

package/dist/web/abilities-admin.d.ts

@@ -8,7 +8,7 @@ export declare function searchPublicAbilities(query?: string): Promise<PublicAbi
  * `packageName`, or null if it can't be determined — not published
  * there at all (a private/file:/git-installed ability, the common case
  * during local development), a network hiccup, or a timeout. Best-effort
- * only: the Abilities tab uses this to decide whether an installed
+ * only: the Apps tab uses this to decide whether an installed
  * ability's own "Upgrade" button is worth showing, not to block
  * anything, so a failure here surfaces as "can't tell, show the button
  * anyway" rather than an error the operator has to deal with. */

package/dist/web/abilities-admin.js

@@ -43,7 +43,7 @@ const NPM_LATEST_VERSION_TIMEOUT_MS = 5000;
  * `packageName`, or null if it can't be determined — not published
  * there at all (a private/file:/git-installed ability, the common case
  * during local development), a network hiccup, or a timeout. Best-effort
- * only: the Abilities tab uses this to decide whether an installed
+ * only: the Apps tab uses this to decide whether an installed
  * ability's own "Upgrade" button is worth showing, not to block
  * anything, so a failure here surfaces as "can't tell, show the button
  * anyway" rather than an error the operator has to deal with. */