Beschreiben Sie das Problem/den Fehler/die Frage
Ich habe einen AI Agent-Knoten mit einem Microsoft SQL-Knoten, der als Tool angebunden ist.
Der SQL-Knoten verwendet $fromAI() im Feld “Query”, damit der Agent
Abfragen dynamisch erstellen kann. Jedes Mal, wenn der Agent versucht, dieses Tool aufzurufen,
schlägt es mit einem Bad-Request-Fehler fehl. Welche Fehlermeldung wird angezeigt (falls vorhanden)?
Problem im Knoten “EXPERTO SQL”: Bad request - bitte überprüfen Sie Ihre Parameter.
Ungültiges Schema für Funktion “AnalisisAgentes”: Das Schema muss ein JSON Schema
vom Typ “object” sein, erhalten wurde “type: "None"”. Setup
Knoten: Microsoft SQL (Query ausführen), verwendet als Tool in einem AI Agent
LLM: Azure OpenAI Chat Model
Wert des Query-Felds: {{ $fromAI('description') }}
Tool-Beschreibung: Manuell festgelegt Was ich bereits versucht habe
$fromAI-Parameternamen geändert: {{ $fromAI('sqlQuery', 'SQL to execute', 'string') }}
Überprüft, dass das Feld “Tool-Beschreibung” Text enthält
Workflow neu gestartet und neu gespeichert
Nichts davon hat den Fehler behoben. Das Schema wird immer noch als type: "None"
generiert, statt als type: "object", was Azure OpenAI ablehnt. Frage
Gibt es eine bekannte Lösung oder einen Workaround, um den MS SQL-Tool-Knoten zu zwingen,
ein gültiges JSON-Schema (type: "object") zu generieren, wenn er in einem AI Agent verwendet wird?
Willkommen @jnscb in unserer Community! Ich bin Jay und bin ein von n8n verifizierter Creator.
Der Fehler tritt auf, weil $fromAI() ohne Type-Argument ein Schema mit "type": null statt einem gültigen JSON Schema-Typ generiert. Die Lösung: Geben Sie den Typ immer explizit in Ihrem $fromAI()-Aufruf an. Für eine SQL-Query-String sollte es sein: $fromAI('query', 'The SQL query to execute', 'string'). Ohne das dritte Argument kann n8n den Typ nicht ableiten und die Schema-Validierung schlägt fehl. Stelle auch sicher, dass du $fromAI() nicht in doppelte geschweifte Klammern verpackst - es sollte direkt im Feld ohne {{ }}-Syntax verwendet werden.
Ich habe beide Änderungen angewendet, die du erwähnt hast — die {{ }} entfernt und den Typ explizit auf 'string' gesetzt. Ich habe auch versucht, die Tool-Beschreibung von Set Manually zu Set Automatically zu wechseln und zurück. Der Fehler ist in allen Fällen genau derselbe:
Invalid schema for function ‘Microsoft_SQL’: schema must be a JSON Schema of ‘type: “object”’, got ‘type: “None”’.
Das ist das, was ich jetzt im Query-Feld habe:
$fromAI('sqlQuery', 'The SQL query to execute against [CMS].[dbo].[VW_HAGLOG]', 'string')
Setup:
n8n-Version: 2.20.6 (selbstgehostet, npm, Windows Server 2019)
LLM: Azure OpenAI Chat Model
Node: Microsoft SQL (Execute Query), verbunden als Tool zum AI Agent
Das Schema erreicht das Modell immer noch als type: "None", unabhängig von der Konfiguration. Hast du einen anderen Workaround, den du empfehlen würdest?
Vielen Dank, dass du das alles getestet hast und die Details geteilt hast.
Da du bereits:
{{ }} entfernt und $fromAI(...) direkt im Query-Feld aufgerufen hast
den Typ explizit auf 'string' gesetzt hast
mit den Tool Description-Modi experimentiert hast
und das Schema immer noch als type: "None" durchkommt, sieht das wirklich nach einer Einschränkung/einem Bug aus, wie der Microsoft SQL-Node sein Tool-Schema im AI Agent bereitstellt – nicht nach einem Konfigurationsproblem auf deiner Seite.
An diesem Punkt würde ich zwei Optionen in Betracht ziehen:
Versuchen Sie eine minimale $fromAI
Zuerst würde ich schnell eine sehr einfache Version testen wie:
text
{{$fromAI("query")}}
Falls dies immer noch type: "None" ergibt, können wir ziemlich sicher sein, dass es node-spezifisch ist und nicht um die $fromAI-Signatur geht.
Wechsel zu Sub-Workflow + Call n8n Workflow Tool
Für etwas, das du in der Produktion nutzen möchtest, würde ich empfehlen:
Haupt-Workflow: AI Agent → Call n8n Workflow Tool (fungiert als dein “SQL-Executor”)
Sub-Workflow: Workflow Input Trigger → Microsoft SQL (Execute Query)
Im Sub-Workflow:
definiere eine Input wie sqlQuery und ordne sie dem MS SQL Query-Feld zu
setze Workflow Inputs auf Defined automatically by the model, damit der Agent sie basierend auf der Tool-Beschreibung ausfüllen kann.
Auf diese Weise:
kontrollierst du das Schema über Workflow Inputs, anstatt vom Tool-Schema des MS SQL-Nodes abhängig zu sein
bekommst du bessere Fehlerbehandlung und kannst sauberere Meldungen zurückgeben, wenn das Modell ungültiges SQL generiert
kannst du diesen “SQL-Executor” einfach in anderen Agenten/Workflows wiederverwenden.
Von meiner Seite: Deine $fromAI-Nutzung ist bereits gültig, und das verbleibende Problem liegt wahrscheinlich auf Node-/Schema-Ebene. Bis n8n einen Fix bereitstellt, ist das Sub-Workflow + Call Workflow Tool-Muster der Ansatz, dem ich in echten Projekten am meisten vertraue.
Ich habe das Query-Feld durch die einfachstmögliche Form ersetzt:
$fromAI("query")
Selber Fehler:
Invalid schema for function ‘Microsoft_SQL’: schema must be a JSON Schema of ‘type: “object”’, got ‘type: “None”’.
Option 2 — Subworkflow + Call n8n Workflow Tool
Ich habe das Muster, das du vorgeschlagen hast, umgesetzt:
Subworkflow: Execute Workflow Trigger (mit sqlQuery input als string definiert) → Microsoft SQL (Execute Query) mit {{ $json.sqlQuery }} im Query-Feld.
Hauptworkflow: AI Agent + Azure OpenAI Chat Model + Call n8n Workflow Tool, das auf den Subworkflow verweist, mit $fromAI('sqlQuery', '...', 'string') auf den Workflow-Input abgebildet.
Der Fehler ist identisch, nur der Funktionsname ändert sich:
Invalid schema for function ‘executeSQL’: schema must be a JSON Schema of ‘type: “object”’, got ‘type: “None”’.
Das gleiche type: "None" Schema-Problem reproduziert sich auf einem völlig anderen Tool-Node (Call n8n Workflow Tool statt Microsoft SQL). Das schließt den MS SQL-Node als Grundursache aus und deutet auf etwas Tiefergehendes hin — entweder darauf, wie n8n 2.20.6 JSON-Schemas für Tools mit $fromAI()-Parametern generiert, oder darauf, wie diese Schemas an Azure OpenAI gesendet werden (das sie strenger validiert als Standard-OpenAI).
Da zwei verschiedene Tool-Nodes das exakt gleiche fehlerhaft geformte Schema erzeugen, bin ich der Meinung, dass es sich um einen komplexeren Bug in der Schema-Generierungsebene handelt, anstatt um ein Konfigurationsproblem. Ich habe ein GitHub Issue mit allen Details und Reproduktionsschritten eröffnet.
Danke, dass du beide Optionen so gründlich getestet hast — das sind wirklich wertvollen Daten.
Die Tatsache, dass der Fehler auf beiden Knoten (MS SQL und Call n8n Workflow Tool) auftritt, bestätigt, dass dies nicht knotenspezifisch ist. Der String type: "None" ist ein Python-artiger Null-Wert, der in die JSON-Schema-Serialisierung durchsickert — das ist ein bekanntes Problem in n8n <= 2.20.x in Kombination mit Azure OpenAI, das eine strengere Schema-Validierung durchführt als Standard-OpenAI-Endpunkte.
Grundursache: Der $fromAI()-Schema-Generator von n8n erzeugt in einigen Grenzfällen type: null, aber Azure OpenAI lehnt alles ab, das keine gültige JSON-Schema-Typzeichenfolge ist. Standard-OpenAI ist nachsichtiger und ignoriert es oft.
Definitiver Workaround — verwende stattdessen einen Code-Knoten als Tool:
Auf einer direkten Verbindung von MS SQL als Tool kannst du einen Code-Knoten verwenden, der:
Die SQL-Abfrage als hart codierte String-Eingabe vom Agent empfängt
Die Abfrage über den MS-SQL-Knoten in einen Sub-Workflow ausführt (wie du bereits hast)
Ergebnisse zurückgibt
Bei dem “Call n8n Workflow Tool” ist der Schlüsselbehebung, die Workflow-Eingaben → Typ im Knoten “Execute Workflow Trigger” explizit auf string zu setzen, dann im Tool-Knoten die Eingabebeschreibung deutlich festzulegen. Stelle sicher, dass du nicht$fromAI() im Sub-Workflow-Trigger selbst verwendest — dieses Feld sollte einfach {{ $json.sqlQuery }} verwenden.
Alternativ der schnellste Weg: Upgrade auf n8n 2.21+, wo dieser Schema-Serialisierungsfehler behoben wurde.
Wenn ein Upgrade im Moment nicht möglich ist, teile mir einen Screenshot deiner Execute Workflow Trigger-Eingabedefinition und ich kann genau lokalisieren, wo die None durchsickert.
Danke für die Analyse, sie hat mir geholfen zu wissen, wo ich nachschauen sollte.
Wichtige Aktualisierung: Ich habe die neueste Version von n8n installiert und der Fehler ist genau derselbe. Ich habe den offiziellen Fehlerbericht gefunden (Issue #25276 im n8n-Repository) und es ist klar, dass dies durch eine Aktualisierung NICHT behoben wird — es ist in aktuellen Versionen bestätigt und bleibt nach der Aktualisierung bestehen. Es ist auch nicht exklusiv für Azure: der gleiche type: "None"-Fehler wird auch von Standard-OpenAI und Anthropic abgelehnt. Die Grundursache ist, dass n8n ein ungültiges Schema mit type: "None" am Root des input_schema des Tools generiert, anstatt "object".
Also hat die Aktualisierung auf 2.21+ es nicht gelöst, wie du vorgeschlagen hast — und soweit ich sehen kann, stimmt diese Versionsnummer nicht mit der tatsächlichen n8n-Versionierung überein, in der dieser Bug vorhanden ist (v2.6.3).
Was ich jetzt brauche, und es ist dringend: Kennst du eine Möglichkeit, das Tool-Schema so zu erzwingen, dass type: "object" am Root herauskommt (ein Patch, eine Einstellung oder ein Zwischenknoten)? Ich brauche die Tools jetzt funktionsfähig und ein Downgrade ist keine Option. Ich kann dir einen Screenshot des Execute Workflow Trigger schicken, wenn das dir hilft, genau zu bestimmen, wo die None durchsickert.
Danke, dass du dich in den Fehlerbericht eingegraben hast – das bestätigt, dass es sich um ein tiefergehendes Schema-Serialisierungsproblem im Core handelt, nicht um etwas, das allein ein Version-Bump jetzt behebt.
Der zuverlässigste Workaround ist der Code-Node-als-Tool-Ansatz, den ich vorhin erwähnt habe. Da der Code-Node nicht durch den $fromAI()-Schema-Generator läuft, gibt es kein type: None, das durchsickert. Richte den Code-Node mit einer klaren Eingabebeschreibung ein, schreib die SQL-Abfrage in den Code, und rufe dann den MS-SQL-Node aus einem Sub-Workflow auf. Der Agent übergibt die Abfrage als einfachen String und das Schema bleibt sauber.
Für den Weg über das Call n8n Workflow Tool speziell – stelle sicher, dass der Execute Workflow Trigger im Sub-Workflow seine Eingabe als Typ String definiert hat (nicht leer gelassen). Leere Eingaben erzeugen type: None im Schema-Root. Gehe zum Trigger-Node, füge manuell ein Feld mit Typ String hinzu, und das sollte die Schema-Ablehnung beheben, auch ohne einen Bug-Fix von der n8n-Seite.
Es wurde ein Pull Request verlinkt, der die Grundursache behebt: PR #31681 — fix(Microsoft SQL Node): Allow expressions in the query field (geöffnet am 3. Juni 2026, eingereicht von einem Community-Mitglied). Er ist mit dem gemeldeten Issue verknüpft und wird es schließen, sobald er zusammengeführt und in einem Release ausgeliefert wird.
Eine Vorwarnung, damit niemand überrascht wird: Derzeit ist der PR verlinkt/offen, aber noch nicht in einem stabilen Release zusammengeführt – daher wird ein einfaches Update das Problem noch nicht beheben. Behalte den PR und das n8n-Changelog im Auge und aktualisiere, sobald die Version mit dem Fix verfügbar ist.
Workaround, der einstweilen funktioniert (zum Verwenden des MS SQL Nodes als Tool von einem AI Agent):
Schreibe im Query-Feld $fromAI()direkt, ohne den {{ }}-Wrapper:
$fromAI('sqlQuery', 'SELECT query to run against [DB].[schema].[table]', 'string')
Wenn der Node als Tool fungiert, muss n8n die $fromAI()-Expression so parsen, wie sie ist, um das JSON Schema zu erstellen. Sie in {{ }} einzuwickeln führt dazu, dass das Schema statt "object" als type: "None" angezeigt wird.
Setze Tool Description auf Set Automatically, damit n8n das Schema aus den deklarierten $fromAI-Argumenten ableitet.
Stelle sicher, dass du gerade Anführungszeichen (') verwendest, nicht typografische/schöne – auch die unterbrechen das Parsing.
Diese Kombination erzwingt ein valides type: "object"-Root-Schema. Sobald #31681 in einem Release verfügbar ist, sollte das Query-Feld Expressions sauber akzeptieren und dieser Workaround ist nicht mehr notwendig.
