Stirling-Tools/Stirling-PDF · error · Error

Tool operation not supported: ${operationName}

Error message

Tool operation not supported: ${operationName}

What it means

Thrown by executeToolOperationWithPrefix when toolRegistry[operationName] has no operationConfig (or the ToolId key is absent entirely). Unlike errors 61/62 (tool exists but endpoint missing), here the tool is not registered for direct execution at all. The operationName is interpolated so the caller can see exactly which id failed.

Source

Thrown at frontend/editor/src/core/utils/automationExecutor.ts:176

    files,
    toolRegistry,
    AUTOMATION_CONSTANTS.FILE_PREFIX,
  );
};

/**
 * Execute a tool operation with custom prefix
 */
export const executeToolOperationWithPrefix = async (
  operationName: string,
  parameters: ErasedToolParams,
  files: File[],
  toolRegistry: ToolRegistry,
  filePrefix: string = AUTOMATION_CONSTANTS.FILE_PREFIX,
): Promise<File[]> => {
  const config = toolRegistry[operationName as ToolId]?.operationConfig;
  if (!config) {
    throw new Error(`Tool operation not supported: ${operationName}`);
  }

  // Merge with default parameters to ensure all required fields are present
  const mergedParameters = { ...config.defaultParameters, ...parameters };

  try {
    // Check if tool uses custom processor (like Convert tool)
    if (config.customProcessor) {
      const result = await config.customProcessor(mergedParameters, files);
      return result.files;
    }

    // Execute based on tool type
    if (config.toolType === ToolType.multiFile) {
      return await executeMultiFileOperation(
        config,
        mergedParameters,
        files,

View on GitHub (pinned to 9ef20dcab8)

Solutions

1. Log or surface the exact operationName from the error and check it against the keys of toolsTaxonomy (the ToolRegistry).
2. Correct the typo or update the automation JSON to use the current canonical tool id.
3. If the tool was removed, replace that step with an equivalent supported tool or remove the step.
4. Validate the automation JSON against the registry before execution — parseAutomationFile already collects unresolvedOperations for this purpose; surface those to the user first.

Example fix

// before — JSON has "operation": "splitt" (typo)
// after  — "operation": "split"

const KNOWN_OPS = new Set(Object.keys(toolRegistry).filter(id => toolRegistry[id]?.operationConfig));

if (!KNOWN_OPS.has(operationName)) {
  throw new Error(`Unknown operation '${operationName}'. Supported: ${[...KNOWN_OPS].join(', ')}`);
}

function isSupportedOperation(name: string, registry: ToolRegistry): boolean {
  return !!(registry[name as ToolId]?.operationConfig);
}

try {
  await executeToolOperationWithPrefix(op, params, files, registry);
} catch (e) {
  if (e instanceof Error && e.message.startsWith('Tool operation not supported')) {
    showUser(`Operation '${op}' is not available in this build.`);
  } else { throw e; }
}

When it happens

Trigger: Calling executeToolOperationWithPrefix(op, params, files, registry) where op is not a key in registry, or is a key whose value lacks .operationConfig. This includes typos, stale ids from an imported automation JSON, or tool ids that are valid ToolIds but were stripped from a partial/custom registry.

Common situations: An imported automation JSON references a tool id that was renamed or removed in a newer build. The user hand-typed an operation name with a typo. A custom/partial ToolRegistry was passed that only contains a subset of tools. The operation id in the JSON is a display id, not the canonical ToolId.

Related errors

• This operation has no backend endpoint and cannot be execute
• No automation configuration provided
• Invalid folder scanning config: expected JSON object
• Invalid folder scanning config: missing 'pipeline' array
• Invalid folder scanning config: pipeline[${index}] is not an

AI-assisted analysis of Stirling-Tools/Stirling-PDF@9ef20dcab8 (2026-08-13). Data as JSON: /api/errors/e8bd09886bd0fa85. Report an issue: GitHub.