MCP Tools Reference

Die formale integrierte Tool-Oberfläche von 2.0.2, die durch MCP-Schlüssel verwaltet wird, enthält genau fünf Tool-Namen:

Veröffentlichte Custom Tools können die Tool-Sammlung einer gebundenen Datenbank erweitern, sind aber keine zusätzlichen integrierten Tools.

Empfohlener Discovery-Ablauf

Verwenden Sie die Metadaten-Ermittlung, wenn der Client die Datenbankstruktur nicht bereits zuverlässig kennt. Schema-Tools laufen im Datenbankkontext des authentifizierten Schlüssels und akzeptieren keinen vom Client gelieferten Connection String.

get_schemas

Liefert die Schemas, die die Provider-Metadatenlaufzeit für die an den MCP-Schlüssel gebundene Datenbank meldet.

Parameter: keine.

Erfolgsresultat: Schema-Namen als kommagetrennter String.

Autorisierung und Grenzen:

• Bei expliziter Tool-Allowlist muss der Schlüssel get_schemas verwenden dürfen.
• Datenbank-Provider und Verbindung müssen aus dem authentifizierten Schlüssel aufgelöst worden sein.
• Die Operation belegt den gemeinsamen SQL-Concurrency-Limiter.
• Erfolg und Fehler werden im Audit-Pfad als mcp.get_schemas erfasst.

Das Tool akzeptiert weder eine Datenbank-ID noch einen Connection String vom Modell.

get_tables

get_tables(schemaName: string)

Liefert die vom Provider gemeldeten Tabellen im angeforderten Schema und filtert sie anhand der Tabellen-Whitelist des MCP-Schlüssels, sofern eine konfiguriert ist.

Existieren semantische Metadaten für den gebundenen Database-Management-Eintrag, kann jede sichtbare Tabelle zusätzlich enthalten:

• Anzeigename;
• Beschreibung;
• Synonyme;
• Metrikbeschreibungen dieser Tabelle.

Erfolgsresultat: ein kommagetrennter String. Einträge können daher mehr Informationen als nur physische Tabellennamen enthalten.

Audit-Action: mcp.get_tables.

get_columns

get_columns(schemaName: string, tableName: string)

Der Server prüft zuerst, ob die angeforderte qualifizierte Tabelle durch den MCP-Schlüssel erlaubt ist. Danach liest er Provider-Spaltenmetadaten und serialisiert ein JSON-Array.

Jedes ColumnInfo-Objekt in 2.0.2 enthält:

Semantische Anreicherung kann Anzeigenamen, Beschreibungen, Synonyme und Beziehungsbeschreibungen in Description ergänzen. Beziehungskontext wird nur aufgenommen, wenn beide beteiligten Tabellen durch die Tabellen-Whitelist des Schlüssels erlaubt sind.

Audit-Action: mcp.get_columns.

execute_query_sql

execute_query_sql(sql: string)

Akzeptiert genau eine SELECT-SQL-Anweisung. Die öffentliche Beschreibung in 2.0.2 nennt ausdrücklich häufige Formen wie JOIN, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT/OFFSET, DISTINCT, CTEs, Subqueries sowie UNION/INTERSECT/EXCEPT.

Die Anfrage läuft durch die typisierte F#-Query-Laufzeit. Je nach Laufzeit-Capabilities werden dabei Fakten wie referenzierte Tabellen, CTE-Nutzung und Subquery-Nutzung auf demselben kontrollierten Pfad gesammelt und als Audit-Nachweis verwendet.

Erfolgsresultat: JSON-Serialisierung der Ergebniszeilen.

Fehlerresultat: Text beginnend mit Execution failed: gefolgt von der Fehlermeldung. Vom Aufrufer angeforderte Cancellation wird weitergereicht und nicht in einen normalen Ergebnisstring umgewandelt.

Laufzeitgrenzen:

• MCP-Tool-Allowlist;
• Datenbankbindung des MCP-Schlüssels;
• Tabellen-Whitelist;
• aktuelle Security-/Query-Policy;
• SQL-Concurrency-Limiter;
• Source-/Target-SQL-Capability-Prüfungen;
• Audit-Ereignis mcp.query.executed mit Operation, Dauer, zurückgegebenen Zeilen und vom Compiler abgeleiteten Definitionsfakten.

Eine lesbare Capability-Zusammenfassung steht in der SQL-Support-Referenz.

execute_dml_sql

execute_dml_sql(sql: string)

Die öffentliche MCP-Eingabe ist SQL. Der McpServer und der Cancellation Token der .NET-Methode werden von der Laufzeit injiziert und sind keine Felder, die ein Agent mitsendet.

Unterstützte Statement-Klassen im MCP-DML-Pfad von 2.0.2:

Bei UPDATE und DELETE wird die Freigabe an die exakte Primary-Key-Zeilenmenge gebunden; vor dem Commit werden die Zeilenidentitäten innerhalb der Transaktion erneut geprüft. Bei INSERT VALUES bindet die Freigabe an den unveränderlichen Literal-Payload und das exakte kompilierte Kommando; beim Commit wird die freigegebene Payload-Zeilenanzahl verifiziert.

Lehnt der Mensch ab oder kann die Validierung nicht abgeschlossen werden, findet kein Commit statt. Audit-Ereignisse verwenden mcp.dml.executed und speichern Operation, Verarbeitungsdauer, betroffene Zeilen, Freigabestatus und gegebenenfalls Fehlerkategorie.

Das vollständige Protokoll steht unter Safe DML.

Gemeinsame Fehler der integrierten Tools

Typische Fehler sind:

• MCP-Autorisierungskontext fehlt;
• explizite Tool-Allowlist enthält das Tool nicht;
• Datenbank-Provider oder Verbindungskonfiguration ist ungültig;
• SQL-Concurrency-Limit kann keinen Lease vergeben (Server busy);
• angeforderte Tabelle liegt außerhalb der Schlüssel-Whitelist;
• SQL ist leer, nicht unterstützt, von der Policy abgelehnt oder scheitert an einer Capability-Grenze;
• Provider-Ausführung schlägt fehl.

Die Tools liefern bewusst begrenzte Fehlerinformationen, statt auf uneingeschränkte Provider-Ausführung zurückzufallen.

Custom Tools

Veröffentlichte Custom Tools werden für den gebundenen Database-Management-Eintrag des MCP-Schlüssels geladen und können in derselben AllowedTools-Menge nach Namen ausgewählt werden. Auch ihre Ausführung durchläuft Datenbankbindung, Tabellen-Whitelist, Sicherheitsrichtlinie, Concurrency-Steuerung und Audit; DML-Custom-Tools laufen zusätzlich durch den Freigabeprozess.

Siehe Custom Tools.

Semantische Metadaten sind kein sechstes integriertes Tool

Das Repository 2.0.2 enthält Implementierungsdetails zur Semantikverwaltung, doch der formale MCP-Key-Registry- und Admin-Key-Management-Pfad kennt die fünf auf dieser Seite aufgeführten Tools. Die offizielle Dokumentation behandelt semantische Metadaten daher als Admin-/Control-Plane-Capability, die von Schema Discovery konsumiert wird, nicht als zusätzlichen integrierten MCP-Vertrag.

Siehe Semantische Metadaten.