Skip to main content

SqlDBM MCP Server

SqlDBM Support
Updated

What the server exposes, how to connect, and what it can do.

The SqlDBM MCP server exposes an organization's SqlDBM data models to AI agents and assistants through the Model Context Protocol (MCP). A connected AI can discover projects, read the full data model as structured data or as DDL, inspect revision history, and generate migration scripts between revisions or environments.

The server is read-only. It works entirely with the data model maintained in SqlDBM, the schema, structure, relationships, and history. It does not access live row data in the warehouse. All access respects the calling user's existing SqlDBM project permissions: an AI sees only the projects that user can already see.

Connection and authentication

Endpoint.  The SqlDBM MCP server is reached at https://mcp.sqldbm.com.

Name: SqlDbm

URL: https://mcp.sqldbm.com

Access to the SqlDBM MCP Server currently requires approval from the SqlDBM team. Customers interested in enabling MCP capabilities should contact SqlDBM to request access and discuss enablement requirements

Connecting.  SqlDBM is available as an MCP server, usable from any MCP-compatible client or AI application. A user adds the SqlDBM connector in their client and signs in with their SqlDBM account through an OAuth 2.0 login. There is no token to generate, copy, or paste; the connection is established by authenticating with SqlDBM and authorizing access.

Authorization.  The OAuth flow grants the access the server needs, including the required modeling scope, as part of sign-in. The user approves the connection once.

Permission model.  Access is tied to the SqlDBM account the user signs in with. The server never widens access; it exposes exactly the projects and revisions that account can already see in SqlDBM.

Developer note.  For clients or custom integrations that configure MCP servers directly rather than through an OAuth connection, authentication uses a SqlDBM OpenAPI bearer token carrying the modeling scope, set in the client configuration.

If you are configuring MCP via an mcp.json file, you'll need to leverage mcp-remote  to allow for the OAuth interaction.  The exact syntax and file location may vary, depending on the tooling you are using, however, most will implementations follow Antropic's original schema. For example, in Cursor, we can use the following, where -y permits the auto-installation of mcp-remote and connects to our MCP server with OAuth:

{
  "mcpServers": {
    "sqldbm": {
      "command": "npx",
      "args": ["-y", "mcp-remote@latest", "https://mcp.sqldbm.com/"]
    }
  }
}

Capabilities

The server exposes twelve tools across five areas.

Discovery

  • get_projects  —  Lists every project the authenticated user can access, with project id, name, and database type. The entry point for every workflow.

Model query — structured, filterable

These tools return the project model as structured JSON, filtered by a query expression so a caller retrieves only the slice it needs. They are the analytical core of the server.

  • get_project_latest_revision  —  Returns the latest revision's full project model, filtered by a JQ expression.
  • get_project_revision  —  The same, for a specified historical revision.
  • get_schema_guide  —  Returns the reference for the model's JSON structure: object shapes, enumerations, and worked query examples. Used to construct precise queries.

DDL retrieval

  • get_project_latest_ddl  —  The full schema DDL for the latest revision.
  • get_project_ddl  —  The full schema DDL for a specified revision.
  • get_project_object_latest_ddl  —  The DDL for a single named object in the latest revision.
  • get_project_object_ddl  —  The DDL for a single named object in a specified revision.

Revision history

  • get_project_revisions  —  Lists every revision of a project, with per-revision metadata: name, number, author, and creation date.

Environments and migration

  • get_project_environments  —  Lists the environments configured for a project.
  • get_project_alter_script  —  Returns the alter script that advances the latest revision to align deployed environments.
  • get_project_compare_alter_script  —  Returns the alter script between any two revisions, any two environments, or a mix of the two.

What the project model contains

The structured model returned by the query tools is the complete SqlDBM model. It includes databases, schemas, tables, views, functions, procedures, sequences, and domains.

For each table the model carries its columns, with data type, nullability, identity, default value, comment, and logical name; its indexes, including primary-key and foreign-key indexes; its relationships, expressed as references with cardinality and explicit column pairs; and its check constraints. Project-level content includes naming conventions, the glossary, and tags.

Every object also carries platform-specific properties for the warehouse it targets: Snowflake, Databricks, BigQuery, Redshift, PostgreSQL, SQL Server, MySQL, Oracle, and others. Snowflake projects additionally expose object and column tags and masking, row-access, and privacy policy assignments.

What the server can answer

Representative questions a connected AI can answer through the tools above:

  • Inventory.  Count and list every table, view, function, and other object in a model.
  • Relationships.  List every foreign-key relationship, with its column pairs and cardinality.
  • Sensitive data.  Identify columns whose names or comments match common PII patterns, and list Snowflake masking and privacy policies. Note that this is pattern-matching and policy visibility, not a formal classification field.
  • Object detail.  Retrieve the full structure or the DDL of a single named table or view.
  • Change and migration.  List the revision history of a model, and generate the alter script between two revisions or two environments.
  • Schema as code.  Return the complete, runnable DDL for an entire model or any single object.

Constraints and limits

  • Read-only.  The server cannot create, modify, or delete anything in SqlDBM or in the warehouse.
  • Model only, no row data.  The server exposes the data model. It never reads the contents of warehouse tables.
  • Permission-scoped.  A caller sees only the projects and revisions its SqlDBM user account can access.
  • Filtered model queries.  The model-query tools require a query expression. The full model can be very large, so an unfiltered request is not permitted; responses are also capped per call and a short execution timeout bounds each query.

Related articles