sql-database

SQL Database Bridge

Use the MCP tools provided by this plugin for direct database work:

• The plugin defaults to local desktop SQL execution. Call login_platform first; local SQL still uses Lovable's OAuth and entitlement decision before any database operation.
• Hosted Lovable mode is advanced-only and must be explicitly enabled with SQL_BRIDGE_MODE=remote or SQL_BRIDGE_MODE=hosted. It proxies the hosted MCP tools and uses Lovable's OAuth/RLS/ entitlement decisions.
• Explicit local_* tools are available when hosted mode is enabled so advanced clients can still reach desktop SQL Server/LocalDB, Windows authentication, SQLite, MySQL, or local PostgreSQL. Neither path bypasses Lovable account authentication or active-subscription checks.
• Always call login_platform before local or hosted SQL work (login_lovable remains a legacy alias). Describe this to the user as signing in to the SQL Database Bridge platform account, not “logging in to Lovable.” If the account is unauthenticated or lacks an active entitlement, stop and report the platform account-access reason. login_platform is idempotent: reuse the locally persisted account session and refresh its access token when possible; do not open a new browser approval flow for every SQL request.
• In hosted mode, use the hosted connection IDs from list_connections; do not send raw database passwords or connection strings through chat.
• The hosted app currently supports PostgreSQL only. If a hosted tool reports MySQL, MSSQL, or SQLite as unsupported, do not retry through the hosted MCP; use the default local tools.
• Use connect_database when the desktop bridge supplies a session connection. The session name defaults to main; a supplied server infers MSSQL. For MSSQL, use authentication: "sql" with username/password or authentication: "windows" to use the current Windows user.
• If the user provides a server, database, and authentication details in text or an authorized screenshot, configure the connection immediately with connect_database; do not ask for another password when Windows authentication is selected. A request such as “table eMeditDb” should be interpreted as the database name when the surrounding context is configuring a connection.
• For (localdb)\\MSSQLLocalDB, omit encryption unless the user explicitly requires it. The bridge defaults LocalDB to Encrypt=no and can retry a certificate/encryption failure once locally.
• In hosted mode, start with list_connections to obtain a connection UUID, then use test_connection, list_schemas, list_tables, and describe_table before writing unfamiliar queries.
• For a desktop SQL Server or LocalDB request, use connect_local_database with authentication: "windows" for the current Windows user, then use list_local_tables, describe_local_table, and query_local_sql. Do not route a LocalDB request to hosted PostgreSQL tools.
• In local mode, call sync_connections or list_connections before working. Local connect_database automatically pushes metadata through upsert_connection; never include a password in that metadata call. A remote-only connection needs local credentials before use.
• Use local delete_connection to remove both the desktop connection and its synced metadata. close_connection only closes the session and does not delete the metadata row.
• In hosted mode, use run_query with connection_id, sql, optional params, and optional row_limit. It is read-only, rejects multi-statement SQL, applies a timeout, and returns bounded structured results.
• In local mode, use query_sql for one statement at a time.
• Treat returned data as sensitive and avoid printing credentials or unnecessary personal data.
• Do not put connection passwords into files, environment snapshots, or ordinary assistant text.
• Runtime connection profiles are in-memory only, but the host app controls whether tool arguments are logged or redacted.
• Write operations are disabled unless the user explicitly enables SQL_ALLOW_WRITE=true.