Skip to main content
Glama
213,524 tools. Last updated 2026-06-19 18:25

"How to connect and execute queries on a private SQL database" matching MCP tools:

  • Execute a SQL query on a site's database. Supports SELECT, INSERT, UPDATE, DELETE, and DDL statements. Results are limited to 1000 rows for SELECT queries. Requires: API key with write scope. Args: slug: Site identifier database: Database name query: SQL query string Returns: {"columns": ["id", "title"], "rows": [[1, "Hello"], ...], "affected_rows": 0, "query_time_ms": 12}
    Connector
  • Browse enacted public and private laws from Congress.gov by congress and law type ('pub' for public laws, 'priv' for private). 'list' filters by enactment status and law type — the discovery path 'bill_lookup' does not offer. 'get' returns the origin bill record (sponsor, actions, summaries, text), with the public/private law citation on the bill's 'laws' array (e.g. {"number":"118-2","type":"Public Law"}).
    Connector
  • Run Disco on tabular data to find novel, statistically validated patterns. This is NOT another data analyst — it's a discovery pipeline that systematically searches for feature interactions, subgroup effects, and conditional relationships nobody thought to look for, then validates each on hold-out data with FDR-corrected p-values and checks novelty against academic literature. This is a long-running operation. Returns a run_id immediately. Use discovery_status to poll and discovery_get_results to fetch completed results. Use this when you need to go beyond answering questions about data and start finding things nobody thought to ask. Do NOT use this for summary statistics, visualization, or SQL queries. Public runs are free but results are published. Private runs cost credits. Call discovery_estimate first to check cost. Private report URLs require sign-in — tell the user to sign in at the dashboard with the same email address used to create the account (email code, no password needed). Call discovery_upload first to upload your file, then pass the returned file_ref here. Args: target_column: The column to analyze — what drives it, beyond what's obvious. file_ref: The file reference returned by discovery_upload. analysis_depth: Search depth (1=fast, higher=deeper). Default 1. visibility: "public" (free) or "private" (costs credits). Default "public". title: Optional title for the analysis. description: Optional description of the dataset. excluded_columns: Optional JSON array of column names to exclude from analysis. column_descriptions: Optional JSON object mapping column names to descriptions. Significantly improves pattern explanations — always provide if column names are non-obvious (e.g. {"col_7": "patient age", "feat_a": "blood pressure"}). author: Optional author name for the report. source_url: Optional source URL for the dataset. use_llms: Slower and more expensive, but you get smarter pre-processing, summary page, literature context and pattern novelty assessment. Only applies to private runs — public runs always use LLMs. Default false. api_key: Disco API key (disco_...). Optional if DISCOVERY_API_KEY env var is set.
    Connector
  • REQUIRED before stock_data_query, 20 SQL patterns prevent timeouts/wrong results Must be called once per session immediately after get_database_schema. Contains query patterns for time-series selection, return calculations, screening joins, window functions, backtesting, and performance optimization. Time-series queries will timeout or return wrong results without these patterns. After this tool returns, call stock_data_query to execute SQL.
    Connector
  • Search National Flood Insurance Program (NFIP) claims data by state, county, ZIP code, and year range. Returns claim counts, amounts paid on building and contents, flood zones, and loss years. state is required — the full NFIP dataset is 2.7 million rows; unfiltered access is prohibited. When DataCanvas is enabled (CANVAS_PROVIDER_TYPE=duckdb) and results exceed the inline preview, the full result set is staged on a canvas for SQL aggregation via fema_dataframe_query. Use fema_dataframe_describe to inspect the staged table schema before writing SQL. Without canvas, results are returned inline up to the limit.
    Connector
  • Answer questions using knowledge base (uploaded documents, handbooks, files). Use for QUESTIONS that need an answer synthesized from documents or messages. Returns an evidence pack with source citations, KG entities, and extracted numbers. Modes: - 'auto' (default): Smart routing — works for most questions - 'rag': Semantic search across documents & messages - 'entity': Entity-centric queries (e.g., 'Tell me about [entity]') - 'relationship': Two-entity queries (e.g., 'How is [entity A] related to [entity B]?') Examples: - 'What did we discuss about the budget?' → knowledge.query - 'Tell me about [entity]' → knowledge.query mode=entity - 'How is [A] related to [B]?' → knowledge.query mode=relationship NOT for finding/listing files, threads, or links — use search.files / search.threads / search.links for that.
    Connector

Matching MCP Servers

Matching MCP Connectors

  • Intent execution engine for autonomous agent task routing

  • Governed personal world model and memory for your AI agent. Pair once, connect over MCP.

  • Fetches data from a leaf route with optional facet filters, date range, frequency, and column selection. Use eia_describe_route first to discover valid facet IDs, facet values, column IDs, and frequency codes. Data values are strings in the response (EIA API returns all numeric values as strings, e.g. "9.13"); cast to DOUBLE in SQL when arithmetic is needed. Returns a preview inline; large result sets (total > length) spill to a DataCanvas table when canvas is enabled — use the returned canvas_id and dataset name with eia_dataframe_query for SQL analysis. Pass the same canvas_id on subsequent eia_query_route calls to accumulate multiple route results into one canvas for cross-route joins.
    Connector
  • Execute a SQL query on Baselight and wait for results (up to 1 minute). The query executes and returns the first 100 rows upon completion, or info about a pending query that needs more time. Use DuckDB syntax only, table format "@username.dataset.table" (double-quoted), SELECT queries only (no DDL/DML), no semicolon terminators, use LIMIT not TOP. If query is still PENDING, use `sdk-get-results` to continue polling. If totalResults > returned rows, use `sdk-get-results` with offset to paginate.
    Connector
  • Run a read-only SQL query in the project and return the result. Prefer this tool over `execute_sql` if possible. This tool is restricted to only `SELECT` statements. `INSERT`, `UPDATE`, and `DELETE` statements and stored procedures aren't allowed. If the query doesn't include a `SELECT` statement, an error is returned. For information on creating queries, see the [GoogleSQL documentation](https://cloud.google.com/bigquery/docs/reference/standard-sql/query-syntax). Example Queries: -- Count the number of penguins in each island. SELECT island, COUNT(*) AS population FROM bigquery-public-data.ml_datasets.penguins GROUP BY island -- Evaluate a bigquery ML Model. SELECT * FROM ML.EVALUATE(MODEL `my_dataset.my_model`) -- Evaluate BigQuery ML model on custom data SELECT * FROM ML.EVALUATE(MODEL `my_dataset.my_model`, (SELECT * FROM `my_dataset.my_table`)) -- Predict using BigQuery ML model: SELECT * FROM ML.PREDICT(MODEL `my_dataset.my_model`, (SELECT * FROM `my_dataset.my_table`)) -- Forecast data using AI.FORECAST SELECT * FROM AI.FORECAST(TABLE `project.dataset.my_table`, data_col => 'num_trips', timestamp_col => 'date', id_cols => ['usertype'], horizon => 30) Queries executed using the `execute_sql_readonly` tool will have the job label `goog-mcp-server: true` automatically set. Queries are charged to the project specified in the `project_id` field.
    Connector
  • Scan text or code for leaked secrets: API keys (AWS, GCP, Azure, OpenAI, Anthropic, Stripe, GitHub, GitLab, Slack, Twilio, SendGrid, HuggingFace), private keys (RSA/EC/PGP), JWTs, database connection strings, Bearer tokens, and Basic auth headers. Returns a list of findings with type, severity, line number, and a redacted preview. Use before committing code, sharing logs, or sending text to an LLM. 100% regex-based, zero network calls.
    Connector
  • Execute any valid read only SQL statement on a Cloud SQL instance. To support the `execute_sql_readonly` tool, a Cloud SQL instance must meet the following requirements: * The value of `data_api_access` must be set to `ALLOW_DATA_API`. * For a MySQL instance, the database flag `cloudsql_iam_authentication` must be set to `on`. For a PostgreSQL instance, the database flag `cloudsql.iam_authentication` must be set to `on`. * An IAM user account or IAM service account (`CLOUD_IAM_USER` or `CLOUD_IAM_SERVICE_ACCOUNT`) is required to call the `execute_sql_readonly` tool. The tool executes the SQL statements using the privileges of the database user logged with IAM database authentication. After you use the `create_instance` tool to create an instance, you can use the `create_user` tool to create an IAM user account for the user currently logged in to the project. The `execute_sql_readonly` tool has the following limitations: * If a SQL statement returns a response larger than 10 MB, then the response will be truncated. * The tool has a default timeout of 30 seconds. If a query runs longer than 30 seconds, then the tool returns a `DEADLINE_EXCEEDED` error. * The tool isn't supported for SQL Server. If you receive errors similar to "IAM authentication is not enabled for the instance", then you can use the `get_instance` tool to check the value of the IAM database authentication flag for the instance. If you receive errors like "The instance doesn't allow using executeSql to access this instance", then you can use `get_instance` tool to check the `data_api_access` setting. When you receive authentication errors: 1. Check if the currently logged-in user account exists as an IAM user on the instance using the `list_users` tool. 2. If the IAM user account doesn't exist, then use the `create_user` tool to create the IAM user account for the logged-in user. 3. If the currently logged in user doesn't have the proper database user roles, then you can use `update_user` tool to grant database roles to the user. For example, `cloudsqlsuperuser` role can provide an IAM user with many required permissions. 4. Check if the currently logged in user has the correct IAM permissions assigned for the project. You can use `gcloud projects get-iam-policy [PROJECT_ID]` command to check if the user has the proper IAM roles or permissions assigned for the project. * The user must have `cloudsql.instance.login` permission to do automatic IAM database authentication. * The user must have `cloudsql.instances.executeSql` permission to execute SQL statements using the `execute_sql_readonly` tool or `executeSql` API. * Common IAM roles that contain the required permissions: Cloud SQL Instance User (`roles/cloudsql.instanceUser`) or Cloud SQL Admin (`roles/cloudsql.admin`) When receiving an `ExecuteSqlResponse`, always check the `message` and `status` fields within the response body. A successful HTTP status code doesn't guarantee full success of all SQL statements. The `message` and `status` fields will indicate if there were any partial errors or warnings during SQL statement execution.
    Connector
  • Capture a Texas homeowner's interest in rooftop solar and route to a licensed installer — use when the user owns (or is buying) a Texas home and mentions solar panels, solar quotes, solar savings, or reducing their bill through solar. Use when the user says 'I just bought a house in Austin and want solar quotes', 'how much could solar save on my Houston electric bill', or 'connect me with a solar installer for my new home'. Returns a lead ID and confirms next steps; Utilify routes the lead to installer partners (SunPower, Sunrun, Palmetto, and independent TX installers). Caveats: (1) only call when the user has explicitly opted in and confirmed homeownership — this is not for renters, and Utilify may earn a referral fee. (2) Texas-only — for non-TX addresses, decline and explain. (3) Don't double-call for the same address in one conversation; one lead per opt-in. If the user has only expressed mild curiosity ('I'm thinking about solar someday'), answer the question first and only call this tool once they confirm 'yes, connect me'.
    Connector
  • Returns the complete setup and usage guide for SwapWizard. Call this FIRST before using any other tool. Covers: required configuration (API key, Alchemy RPC URL, private key), how to use poolId correctly, step-by-step operational flows for swap/zap in/zap out/analyze, transaction execution details, and approval rules.
    Connector
  • Step 1 of schema discovery: returns the catalog of tables relevant to the user's question. Each table comes with its dataset, business name, dw_table_name and a short description — but NOT the field-level details (no columns, no types, no semantic codes). Use the catalog to identify the most promising candidate(s), then call **get_table_schema** to fetch the full structure of a specific table before writing SQL. **IMPORTANT for SQL queries**: Use ONLY the `dataset.table` format (e.g., `prod_google_ads_v2.campaign_stats`). NEVER prefix with a project_id.
    Connector
  • Returns runnable code that creates a Solana keypair. Solentic cannot generate the keypair for you and never sees the private key — generation must happen wherever you run code (the agent process, a code-interpreter tool, a Python/Node sandbox, the user's shell). The response includes the snippet ready to execute. After running it, fund the resulting publicKey and call the `stake` tool with {walletAddress, secretKey, amountSol} to stake in one call.
    Connector
  • Returns runnable code that creates a Solana keypair. Solentic cannot generate the keypair for you and never sees the private key — generation must happen wherever you run code (the agent process, a code-interpreter tool, a Python/Node sandbox, the user's shell). The response includes the snippet ready to execute. After running it, fund the resulting publicKey and call the `stake` tool with {walletAddress, secretKey, amountSol} to stake in one call.
    Connector
  • Provisions a managed PostgreSQL database on a dedicated VM on your private network. It is PRIVATE — reachable only from another instance on the same private network, via the DB's internal/private IP (not a public address). Get the ids from list_flavors, list_private_networks, list_keypairs. Provisioning takes ~5 min; poll list_databases until status='ready', then the connection details (private_ip, port 5432, db_name, db_user) are populated.
    Connector
  • Provisions a managed MySQL (or MariaDB) database on a dedicated VM on your private network — the relational-database resource (use this instead of create_database when the app needs MySQL/MariaDB, e.g. WordPress, NextCloud, Matomo, many PHP/LAMP apps). It is PRIVATE — reachable only from another instance on the same private network, via the DB's internal/private IP (port 3306), not a public address. Get the ids from list_flavors, list_private_networks, list_keypairs. Provisioning takes ~5 min; poll list_relational_databases until status='ready', then the connection details (private_ip, port 3306, db_name, db_user) are populated. MySQL is created with mysql_native_password auth so older clients/apps connect cleanly. (ClickHouse is a separate resource — use create_clickhouse / list_clickhouse_databases.)
    Connector
  • Deploys an app to a VM and exposes it at a public https://<name>-<id>.redu.cloud URL (a random 8-char suffix is appended to <name> for uniqueness — a BARE custom `dname` like `myapp.redu.cloud` ALSO gets a suffix, so to PIN a known URL pass a dname that already includes an 8-char suffix like `myapp-7k2m9x4p.redu.cloud` and wire the app's own URL env to it; single-surface apps can instead just read the injected PUBLIC_URL/APP_URL). The container is built ON the VM — no local Docker/podman needed. PREREQS — run check_deploy_prerequisites first: it auto-selects your network_id + keypair_name (and returns a recipe to mint a keypair if you have none). Pass those two ids here. PORT: pass the port the app actually listens on (plan_deploy detects it / Dockerfile EXPOSE) — redu health-probes that exact port, so a wrong/omitted port (defaults to 3000) fails a non-3000 app (e.g. a static nginx app listens on 80 → pass 80). TWO source modes: (1) GIT — pass `repo` (public; private repos also need git_token). (2) UPLOAD — call prepare_upload first to tar + POST your LOCAL working dir, then pass the returned `source_token` (no git, no PAT; use this for uncommitted code, a fixed clone of a repo you don't own, or private code). The source needs a Containerfile/Dockerfile; redu auto-finds one in common subfolders (Docker/, scripts/, packaging/…) and builds with the repo root as context — for a repo with MULTIPLE Dockerfiles pass `dockerfile`+`context` to pick the right one. If it has NONE, pass dockerfile_content (the one plan_deploy generated) or include a Dockerfile in the uploaded tarball. To wire a DB, pass `database` (auto-injects the connection env + DATABASE_URL — zero setup): `database:'single_vm'` puts Postgres ON the app VM (cheapest; data dies if the VM is replaced); `database:'managed'` provisions a SEPARATE managed-DB VM on the same private network and wires it automatically (data PERSISTS across redeploys; reused on a same-name redeploy) — you do NOT call create_database/create_relational_database for this. Choose the engine with `db_engine` ('postgres' default → PG* env; 'mysql'/'mariadb' → MYSQL_* env + mysql:// URL, for WordPress/Matomo/LAMP apps; mysql/mariadb require database:'managed'). redu also injects APP_URL/PUBLIC_URL (= the app's public URL) into its env, so apps that need their own URL get it (map an app-specific var like BASE_URL to PUBLIC_URL if needed). Build+provision takes ~3-6 min (a bit longer for managed, which also brings up the DB VM); poll list_deployments or get_deployment until status='ready'. On 'build_failed'/'error', call get_deployment(id) to read build_log. ALWAYS run plan_deploy first and confirm the plan + cost with the user before deploying.
    Connector
  • Provisions a managed ClickHouse database (OLAP / columnar analytics engine, Apache-2.0) on a dedicated VM on your private network — its OWN resource, NOT a relational database. Use it for analytics / observability workloads that need a column store (PostHog, Langfuse, event analytics, time-series). It is PRIVATE — reachable only from another instance on the same private network, via the DB's internal/private IP on the ClickHouse HTTP port 8123 (CLICKHOUSE_HOST/PORT/USER/PASSWORD/DB env, http://host:8123). Get the ids from list_flavors (use m1.small+ — ClickHouse needs >=2GB RAM), list_private_networks, list_keypairs. Provisioning takes ~5 min; poll list_clickhouse_databases until status='ready'.
    Connector