improvement(tools): retire direct execution

Author: icecrasher321

.agents/skills/add-block/SKILL.md

@@ -19,6 +19,10 @@ When the user asks you to create a block:
 
 Blocks depend on tool outputs. If the underlying tool response schema is not documented or live-verified, you MUST tell the user instead of guessing block outputs.
 
+When block work changes tool execution, same-process work must use a registered
+`InternalToolConfig.operation`. Never add a Sim `/api/...` self-hop or the retired
+`directExecution` property.
+
 - Do NOT invent block outputs for undocumented tool responses
 - Do NOT describe unknown JSON shapes as if they were confirmed
 - Do NOT wire fields into the block just because they seem likely to exist

.agents/skills/add-integration/SKILL.md

@@ -68,7 +68,7 @@ Choose the tool boundary before writing the declaration:
 - Use `ToolConfig.request` only for an absolute external HTTP(S) provider endpoint.
 
 Never point a tool at `/api/...`, construct an absolute URL back to Sim, declare
-`request.internal`, or add an API route merely to reuse code, normalize files, or authorize
+`request.internal`, add the retired `directExecution` property, or add an API route merely to reuse code, normalize files, or authorize
 resources. A real external/browser route and an in-process tool may share the same operation, but
 neither calls the other. Follow the full transport and handler rules in the `add-tools` skill.
 
@@ -171,7 +171,7 @@ Hard rules:
 - Never substitute secret plaintext into source or serialize plaintext provenance.
 - Never hand-roll private provenance headers/envelopes; the shared `executeTool` boundary owns
   transport and strips private metadata from functional results.
-- Never attach private provenance to an external URL or to `directExecution`. Project proven
+- Never attach private provenance to an external URL. Project proven
   model-visible external fields with `request.modelInput`; otherwise preserve ordinary request
   semantics. Use a registered in-process operation when encrypted provenance must cross the
   boundary.
@@ -607,7 +607,7 @@ If creating V2 versions (API-aligned outputs):
 - [ ] Chose exactly one boundary per tool: registered `InternalToolConfig.operation` or absolute
       external HTTP(S) `ToolConfig.request`
 - [ ] No tool points to `/api/...`, constructs a URL back to Sim, declares `request.internal`, or
-      has an HTTP fallback for an in-process operation
+      `directExecution`, or has an HTTP fallback for an in-process operation
 - [ ] All params have correct visibility
 - [ ] All nullable fields use `?? null`
 - [ ] All optional outputs have `optional: true`

.agents/skills/add-tools/SKILL.md

@@ -54,7 +54,7 @@ Every tool must use exactly one of these configurations:
   HTTP(S) provider endpoint.
 
 Never set a tool URL to `/api/...`, construct an absolute URL back to Sim, declare
-`request.internal`, import a route module, or create an API route merely to normalize files,
+`request.internal`, add the retired `directExecution` property, import a route module, or create an API route merely to normalize files,
 authorize access, or reuse server code. A real browser/API route may remain as a thin adapter, but
 the route and the tool must call the same operation directly. A true cross-process/capability
 boundary uses an explicit server client and is not disguised as a tool self-hop.
@@ -524,6 +524,7 @@ All tool IDs MUST use `snake_case`: `{service}_{action}` (e.g., `x_create_tweet`
       HTTP(S) `ToolConfig.request`
 - [ ] No tool request points to `/api/...`, constructs a URL back to Sim, or declares
       `request.internal`
+- [ ] No tool declares `directExecution`; in-process work uses a registered operation
 - [ ] All params have explicit `required: true` or `required: false`
 - [ ] All params have appropriate `visibility`
 - [ ] All nullable response fields use `?? null`

.agents/skills/add-trigger/SKILL.md

@@ -508,7 +508,8 @@ Two rules the checks enforce:
 Webhook and polling routes are legitimate external ingress boundaries. They must not call this
 Sim app's own API routes to reuse provider or business logic. Extract the shared provider operation
 or authorized application use case and call it directly from the trigger handler and any other
-server adapter. HTTP is reserved for an actual cross-process/capability boundary.
+server adapter. HTTP is reserved for an actual cross-process/capability boundary. Tool work uses a
+registered `InternalToolConfig.operation`; the retired `directExecution` property must not return.
 
 ### Trigger Definition
 - [ ] Created `utils.ts` with options, instructions, extra fields, and output builders

.agents/skills/tool-registry-boundary/SKILL.md

@@ -11,7 +11,12 @@ You keep the 4,300-tool executable registry out of module graphs that don't exec
 
 > Client-reachable code reads tool **metadata**. Only code that actually executes a tool imports the **registry**.
 
-`@/tools/registry` is a ~9,000-line barrel importing every tool. Each `ToolConfig` mixes plain data (`params`, `outputs`, `name`) with closures — `request.url`, `request.headers`, `transformResponse`, `directExecution`, `postProcess`. Those closures reach the SDK clients, API helpers and parsers each integration needs, and that is what makes the barrel expensive: reaching it costs ~4,700 additional modules.
+`@/tools/registry` is a ~9,000-line barrel importing every tool. External `ToolConfig` entries mix
+plain data (`params`, `outputs`, `name`) with request/response closures, while
+`InternalToolConfig` entries contain semantic input projection and load their server implementation
+through `lib/internal/tool-operations/registry.server.ts`. Request closures can still reach SDK
+clients, API helpers, and parsers, which is what makes the executable barrel expensive: reaching it
+costs ~4,700 additional modules.
 
 `getTool()` returns the whole `ToolConfig`, so a single `getTool` import anywhere in a client-reachable file drags all of it in.
 
@@ -95,4 +100,5 @@ The canvas route reached the registry through **four** redundant edges — `prov
 
 Ask what the caller does with the config. If it reads `params`, `outputs`, `name`, `description` or just checks existence, it belongs on `@/tools/metadata` — no exceptions, even on a path you believe is server-only today, because a future client import will silently re-attach the registry to the graph.
 
-If it genuinely executes — builds a request, transforms a response, runs `directExecution` — use `getTool`, and keep that file off client-reachable paths.
+If it genuinely executes — builds an external request, transforms a response, or dispatches a
+registered internal operation — use `getTool`, and keep that file off client-reachable paths.

.agents/skills/validate-integration/SKILL.md

@@ -159,8 +159,9 @@ search, extraction, or "AI-powered" marketing terminology.
 - [ ] Sim-owned durable writes and internal execution handoffs that can enter workflows/models use
       field-scoped `request.secretProvenance`; authenticated receivers validate the exact selection
       and scope, strip private metadata, and persist, import, or propagate it at the owning boundary
-- [ ] Private provenance is never attached to external URLs or `directExecution`; proven
-      model-visible external fields use projection, while other external inputs remain unchanged
+- [ ] Private provenance is never attached to external URLs; registered in-process operations
+      preserve it through `operation.modelInput` / `operation.secretProvenance`, while proven
+      model-visible external fields use request projection and other external inputs remain unchanged
 - [ ] No tool performs raw secret plaintext/source substitution or serializes plaintext provenance
 - [ ] No `transformResponse` or tool-local helper blanket-sanitizes ordinary third-party results;
       only execution-scoped, activated Sim provenance is projected at shared model/log boundaries

apps/sim/app/api/tools/netsuite/objects/route.test.ts

@@ -31,11 +31,11 @@ vi.mock('@/lib/oauth/credential-service', () => ({
   resolveCredentialAccessToken: mockResolveCredentialAccessToken,
   resolveOAuthAccountId: mockResolveOAuthAccountId,
 }))
-vi.mock('@/tools/netsuite/get_async_status', () => ({
-  netsuiteGetAsyncStatusTool: { directExecution: mockGetAsyncStatus },
+vi.mock('@/lib/internal/netsuite/operations/get-async-status', () => ({
+  executeNetsuiteGetAsyncStatusOperation: mockGetAsyncStatus,
 }))
-vi.mock('@/tools/netsuite/list_record_types', () => ({
-  netsuiteListRecordTypesTool: { directExecution: mockListRecordTypes },
+vi.mock('@/lib/internal/netsuite/operations/list-record-types', () => ({
+  executeNetsuiteListRecordTypesOperation: mockListRecordTypes,
 }))
 
 import { POST } from '@/app/api/tools/netsuite/objects/route'

apps/sim/app/api/tools/netsuite/objects/route.ts

@@ -12,9 +12,9 @@ import { generateRequestId } from '@/lib/core/utils/request'
 import { withRouteHandler } from '@/lib/core/utils/with-route-handler'
 import { NETSUITE_SERVICE_ACCOUNT_PROVIDER_ID } from '@/lib/credentials/client-credential-accounts/descriptors'
 import { TokenServiceAccountValidationError } from '@/lib/credentials/token-service-accounts/errors'
+import { executeNetsuiteGetAsyncStatusOperation } from '@/lib/internal/netsuite/operations/get-async-status'
+import { executeNetsuiteListRecordTypesOperation } from '@/lib/internal/netsuite/operations/list-record-types'
 import { resolveCredentialAccessToken, resolveOAuthAccountId } from '@/lib/oauth/credential-service'
-import { netsuiteGetAsyncStatusTool } from '@/tools/netsuite/get_async_status'
-import { netsuiteListRecordTypesTool } from '@/tools/netsuite/list_record_types'
 import type { NetSuiteAuthParams } from '@/tools/netsuite/types'
 import { normalizeSuiteTalkUrl } from '@/tools/netsuite/utils'
 import type { ToolResponse } from '@/tools/types'
@@ -180,14 +180,13 @@ async function executeDiscoveryTool(
   throwIfAborted(signal)
   switch (body.kind) {
     case 'record_types': {
-      const execute = netsuiteListRecordTypesTool.directExecution
-      if (!execute) throw new Error('NetSuite record-type tool is not executable')
-      return execute(auth, signal)
+      return executeNetsuiteListRecordTypesOperation(auth, signal)
     }
     case 'async_tasks': {
-      const execute = netsuiteGetAsyncStatusTool.directExecution
-      if (!execute) throw new Error('NetSuite asynchronous-status tool is not executable')
-      return execute({ ...auth, jobId: body.jobId, view: 'tasks' }, signal)
+      return executeNetsuiteGetAsyncStatusOperation(
+        { ...auth, jobId: body.jobId, view: 'tasks' },
+        signal
+      )
     }
   }
 }

apps/sim/app/workspace/[workspaceId]/w/components/preview/components/preview-workflow/preview-workflow.tsx

@@ -416,12 +416,12 @@ export function PreviewWorkflow({
 
         // Check for direct error on the subflow block itself (e.g., loop resolution errors)
         // before falling back to children-derived status
-        const directExecution = blockExecutionMap.get(blockId)
+        const blockExecution = blockExecutionMap.get(blockId)
         const subflowExecutionStatus: ExecutionStatus | undefined =
-          directExecution?.status === 'error'
+          blockExecution?.status === 'error'
             ? 'error'
             : (getSubflowExecutionStatus(blockId) ??
-              (directExecution ? (directExecution.status as ExecutionStatus) : undefined))
+              (blockExecution ? (blockExecution.status as ExecutionStatus) : undefined))
 
         nodeArray.push({
           id: blockId,

apps/sim/lib/internal/bitbucket/execute-tool.ts

@@ -0,0 +1,35 @@
+import {
+  executeBitbucketGetFileOperation,
+  executeBitbucketGetPipelineStepLogOperation,
+  executeBitbucketGetPullRequestDiffOperation,
+  executeBitbucketGetPullRequestDiffstatOperation,
+} from '@/lib/internal/bitbucket/operations'
+import { executeToolOperationImplementation } from '@/lib/internal/tool-operations/execute'
+import type { InternalToolOperationHandler } from '@/lib/internal/tool-operations/types'
+
+export const executeBitbucketTool: InternalToolOperationHandler = async (request) => {
+  switch (request.toolId) {
+    case 'bitbucket_get_file':
+      return executeToolOperationImplementation(executeBitbucketGetFileOperation, request)
+    case 'bitbucket_get_pipeline_step_log':
+      return executeToolOperationImplementation(
+        executeBitbucketGetPipelineStepLogOperation,
+        request
+      )
+    case 'bitbucket_get_pull_request_diff':
+      return executeToolOperationImplementation(
+        executeBitbucketGetPullRequestDiffOperation,
+        request
+      )
+    case 'bitbucket_get_pull_request_diffstat':
+      return executeToolOperationImplementation(
+        executeBitbucketGetPullRequestDiffstatOperation,
+        request
+      )
+    default:
+      return Response.json(
+        { success: false, error: `Unsupported bitbucket tool: ${request.toolId}` },
+        { status: 500 }
+      )
+  }
+}