feat(tools): add Strale — 290+ quality-tested data capabilities for agents

[petterlindstrom79]

Summary

Adds a Strale tool node that gives Flowise agents access to 290+ quality-tested data capabilities: company verification across 20 countries, sanctions screening, VAT validation, invoice extraction, and more.

Two modes:

• Search and execute — agent describes what it needs in natural language, Strale finds and runs the best matching capability
• Execute a specific capability — call a pre-configured capability by slug (e.g. vat-validate, sanctions-check)

Every response includes a quality score (SQS) and transaction ID for audit trails. 5 free capabilities work without an API key (email-validate, dns-lookup, json-repair, url-to-markdown, iban-validate).

Files added

• packages/components/nodes/tools/Strale/Strale.ts — Node class with 4 inputs (API key, mode, slug, base URL)
• packages/components/nodes/tools/Strale/core.ts — Two StructuredTool subclasses (search+execute, execute-specific)
• packages/components/nodes/tools/Strale/strale.svg — Node icon

Links

• Homepage: https://strale.dev
• API docs: https://strale.dev/docs
• npm: https://www.npmjs.com/package/strale-mcp
• GitHub: https://github.com/strale-io/strale

[gemini-code-assist]

Code Review

This pull request introduces the Strale tool integration, which provides access to over 290 data capabilities such as company verification and sanctions screening through a search-and-execute tool and a specific capability executor. The review feedback focuses on improving the robustness of the API interaction by handling non-JSON error responses more gracefully and ensuring consistent validation of tool inputs to prevent potential runtime errors when arguments are omitted.

[gemini-code-assist]

The current implementation calls res.json() before checking res.ok. If the API returns a non-JSON error response (e.g., a 500 error from a proxy or a timeout), res.json() will throw a SyntaxError, masking the actual HTTP error status. It is safer to read the response as text first and handle potential parsing errors gracefully to provide a more descriptive error message, as per the repository guideline to provide better error messages.

Suggested change

	const data = await res.json()
	if (!res.ok) {
	const errorMessage = data?.error || data?.message || `HTTP ${res.status}: ${res.statusText}`
	throw new Error(errorMessage)
	}
	const text = await res.text()
	let data
	try {
	data = JSON.parse(text)
	} catch (e) {
	if (!res.ok) throw new Error("HTTP " + res.status + ": " + res.statusText)
	throw e
	}
	if (!res.ok) {
	throw new Error(data?.error || data?.message || "HTTP " + res.status + ": " + res.statusText)
	}

References

1. Use a default (fallback) implementation unless the specific implementation has meaningfully different behavior or provides better error messages.

[gemini-code-assist]

JSON.parse(arg.inputs) is called without checking if arg.inputs is defined. If the LLM omits the inputs argument in its tool call, this will throw an error. For consistency with the implementation in StraleSearchAndExecuteTool (line 115), you should check for the existence of arg.inputs before attempting to parse it. This validation approach aligns with the preference for early returns.

            let inputs: Record<string, any> = {}
            if (arg.inputs) {
                try {
                    inputs = JSON.parse(arg.inputs)
                } catch {
                    return JSON.stringify({
                        error: "invalid_inputs",
                        message: "Could not parse inputs as JSON: " + arg.inputs
                    })
                }
            }

References

1. Multiple early returns for validation can be preferable to a single error-aggregating block if the latter is considered more confusing or less readable.