Connect Claude AI to Canadian property data

This guide walks through connecting an AI agent — Claude, ChatGPT, a custom agent stack, anything that speaks the Model Context Protocol — to the Canadian residential and commercial property pipeline operated by BrightCat Data. The target reader is a data engineer or AI builder who needs to move from “we should integrate property data” to “the agent is answering live queries” in a single working day.

BrightCat exposes the same underlying data through two shapes. A Snowflake Marketplace share delivers SQL-driven analytics. An MCP endpoint layered on top of that share delivers agentic AI workflows. Most enterprise deployments use both. The Snowflake share is the durable data surface. The MCP endpoint is the conversational surface layered on top of it.

What follows assumes you already have a Snowflake account, an AI client that supports MCP (Claude Desktop is the reference implementation; Claude in Chrome, Cursor, and custom agent stacks all work), and basic familiarity with OAuth 2.0. The setup pattern follows Snowflake’s standard Marketplace-plus-OAuth flow, which means anything you build here is portable across MCP-compatible clients.

What MCP is, and why it matters here

The Model Context Protocol is an open protocol that lets an AI agent call external data and tools mid-conversation. Introduced by Anthropic in late 2024 and now supported by most major AI stacks, MCP turns a data warehouse into something the agent can query directly. No embeddings pipeline, no retrieval pre-processing, no stale snapshots loaded into context.

For property data specifically, MCP closes a gap that retrieval-augmented generation never closed cleanly. The agent gets the live weekly data as of today, not a static embedding of last quarter. It can issue exact SQL-equivalent queries instead of fuzzy vector retrieval. And because the data stays inside the buyer’s Snowflake environment, it never crosses a third-party boundary.

The practical effect is that an agent can answer something like “which active listings in Burlington crossed $1.2M this week and sat more than 30 days?” by issuing a real query, not by guessing from pre-loaded context.

What’s in the BrightCat data surface

BrightCat ships five product families, each exposed as a separate Snowflake database with a SAMPLE and PRODUCT schema. The sample schema is the public-facing evaluation slice. The product schema is the licensed production data. MCP access is scoped to whichever databases the client has licensed.

Most integrations start with Listings and Core. Rentals and Commercial are added when the use case matures past the initial retention or acquisition workflow.

What you need before starting

• A Snowflake account. Any edition (Standard or higher). The account region does not need to match BrightCat’s region — Snowflake handles cross-region share replication automatically, though there may be a small replication fee.
• An AI client with MCP support. Claude Desktop or Claude in Chrome for interactive use. A custom agent stack (built on the MCP SDK, LangChain, or LlamaIndex) for programmatic use.
• ACCOUNTADMIN or equivalent access on your Snowflake account long enough to accept the share and configure the OAuth integration. Day-to-day use runs under a read-only service role.
• One or more outbound IP ranges for your AI client. BrightCat maintains a trusted-IP allowlist as a network-layer control in front of OAuth.
• Signed BrightCat Master Data License Agreement (MDLA v3). Standard procurement, three-tier term structure, clear AI/ML use clauses.

None of these are heavy. The bottleneck in practice is the MDLA review inside the buyer’s procurement team, which typically takes five to ten business days in a regulated enterprise and under three in a startup.

Step 1 — Request access

Access is gated by an explicit request, not a self-service signup. This is intentional. It lets BrightCat scope the Snowflake share, the MCP endpoint, and the network allowlist to your environment before any credentials exist.

Submit a request with the following:

• Company legal name and the intended Snowflake account identifier
• The product families you want access to (Listings, Sold, Rentals, Commercial, Core)
• Intended use case and integration pattern (Snowflake SQL only, MCP only, or both)
• Outbound IP ranges for allowlisting
• Signed or in-progress MDLA

BrightCat responds with a share provisioning confirmation, an OAuth integration ID, and the MCP endpoint URL scoped to your account. Typical turnaround is one to three business days from receipt of the signed MDLA.

Step 2 — Accept the Snowflake share

Once provisioning completes, the BrightCat data appears as a pending Snowflake Marketplace share inside your Snowflake account. Accept the share under an ACCOUNTADMIN session. Each licensed product family appears as a separate database.

-- Run as ACCOUNTADMIN. Replace placeholder database names with
-- the provider-supplied identifiers from your provisioning email.

USE ROLE ACCOUNTADMIN;

CREATE DATABASE BRIGHTCAT_LISTINGS
  FROM SHARE <provider-share-id>.BRIGHTCAT_LISTINGS;

CREATE DATABASE BRIGHTCAT_CORE
  FROM SHARE <provider-share-id>.BRIGHTCAT_CORE;

-- Grant read access to the role your team will query under.
GRANT IMPORTED PRIVILEGES ON DATABASE BRIGHTCAT_LISTINGS
  TO ROLE DATA_ANALYST;

After this step, your data team can query BrightCat tables inside Snowflake exactly as they would any other Snowflake table. A quick validation:

-- Abstract example. Exact column names provided with access.
SELECT province, COUNT(*) AS active_listings
FROM BRIGHTCAT_LISTINGS.PRODUCT.listings_weekly
WHERE listing_status = 'active'
  AND file_date = (
    SELECT MAX(file_date)
    FROM BRIGHTCAT_LISTINGS.PRODUCT.listings_weekly
  )
GROUP BY province
ORDER BY active_listings DESC;

If this returns a row per province with counts adding to roughly the expected Canadian active-market size, the share is live and the data is current. If it returns empty, the most common cause is that the share was granted to a different role — check SHOW SHARES as ACCOUNTADMIN.

Step 3 — Configure OAuth for MCP

The MCP endpoint uses Snowflake OAuth for authentication. This keeps the AI client’s access aligned with Snowflake’s existing role-based security. The agent can only see what the read-only role can see, regardless of what the agent is asked to do.

Two things have to exist inside your Snowflake account for MCP to work:

• A dedicated read-only role the AI client authenticates as
• An OAuth security integration that ties the role to the MCP endpoint

-- Dedicated read-only role for MCP access.
CREATE ROLE CLAUDE_MCP_READONLY;

GRANT IMPORTED PRIVILEGES ON DATABASE BRIGHTCAT_LISTINGS
  TO ROLE CLAUDE_MCP_READONLY;
GRANT IMPORTED PRIVILEGES ON DATABASE BRIGHTCAT_CORE
  TO ROLE CLAUDE_MCP_READONLY;

GRANT ROLE CLAUDE_MCP_READONLY TO USER <service-user>;

-- OAuth security integration.
CREATE SECURITY INTEGRATION CLAUDE_MCP_INTEGRATION
  TYPE = OAUTH
  ENABLED = TRUE
  OAUTH_CLIENT = CUSTOM
  OAUTH_CLIENT_TYPE = 'CONFIDENTIAL'
  OAUTH_REDIRECT_URI = 'https://claude.ai/api/mcp/auth_callback'
  OAUTH_ISSUE_REFRESH_TOKENS = TRUE
  OAUTH_REFRESH_TOKEN_VALIDITY = 7776000
  OAUTH_USE_SECONDARY_ROLES = IMPLICIT;

-- Pre-OAuth: set the default role so the handshake
-- lands on the correct scope.
ALTER USER <service-user>
  SET DEFAULT_ROLE = 'CLAUDE_MCP_READONLY';

Retrieve the OAuth client ID and client secret:

SELECT SYSTEM$SHOW_OAUTH_CLIENT_SECRETS('CLAUDE_MCP_INTEGRATION');

Copy the OAUTH_CLIENT_ID and either OAUTH_CLIENT_SECRET value. You’ll need both in Step 4.

Step 4 — Register the MCP server with Claude

Register BrightCat as an MCP server inside your AI client. For Claude, this is done either through the Claude Desktop settings panel (for interactive use) or through a programmatic config file (for custom agent stacks).

Interactive setup (Claude Desktop)

In Claude Desktop → Settings → Connectors → Add custom connector, enter the following:

• Server name: BrightCat
• Server URL: https://<your-account>.snowflakecomputing.com/api/v2/databases/BRIGHTCAT_LISTINGS/schemas/PUBLIC/mcp-servers/BRIGHTCAT
• Authentication: OAuth 2.0
• Client ID: from Step 3
• Client secret: from Step 3

Claude performs the OAuth handshake, asks for confirmation of the requested Snowflake role, and establishes the connection. The first request can take 30–60 seconds as Snowflake cold-starts the virtual warehouse. Subsequent requests are fast.

Programmatic setup (agent stacks)

Register the MCP server in your agent config. The shape varies by stack — below is the standard MCP client config block.

{
  "mcpServers": {
    "brightcat": {
      "url": "https://<your-account>.snowflakecomputing.com/api/v2/databases/BRIGHTCAT_LISTINGS/schemas/PUBLIC/mcp-servers/BRIGHTCAT",
      "auth": {
        "type": "oauth2",
        "clientId": "${SNOWFLAKE_OAUTH_CLIENT_ID}",
        "clientSecret": "${SNOWFLAKE_OAUTH_CLIENT_SECRET}"
      }
    }
  }
}

Load your credentials from environment variables or a secret manager. Never commit them to source control. Snowflake OAuth refresh tokens are long-lived (90 days by default) so expiry handling should be automatic for the first few months of operation.

Step 5 — First query and validation

Once the MCP server is registered, the agent can issue natural-language queries that translate to SQL under the hood. The agent chooses the right product database, constructs the query, executes it through the MCP tool call, and returns a structured answer.

A good first query is scoped tight. The goal is to confirm the pipe is open, not to stress-test the model.

If the connector is wired correctly, Claude will produce a tool call against the BrightCat MCP endpoint, issue a SQL query along the lines of the Listings validation example shown in Step 2, and return the result as a structured table in the conversation.

Common validation failures and their causes:

• Empty result: the share was accepted but the MCP role wasn’t granted IMPORTED PRIVILEGES. Re-run the grants from Step 3.
• Authentication error: the default role wasn’t set to CLAUDE_MCP_READONLY before the first OAuth handshake. Reset the default role, disconnect the connector, reconnect.
• Slow first query: normal. Snowflake is cold-starting the virtual warehouse. Keep the warehouse on a short auto-suspend (60 seconds) for interactive use, longer for production agents.
• Tool call not triggered: the agent didn’t recognize the MCP server as relevant to the query. Reference BrightCat explicitly by name in the prompt.

Agent patterns worth copying

Once the connector is live, the useful question becomes what to do with it. Three patterns come up repeatedly in early-production BrightCat deployments.

Weekly retention trigger

An agent runs every Sunday after the BrightCat refresh. It queries the Listings product for newly-active listings and joins the output to the bank or telecom’s customer table on postal code. Matched customers are flagged for the retention team’s Monday queue. The agent handles the query, the join, the threshold filtering, and the delivery — typically into a Slack channel or a Salesforce task queue.

Conversational territory analysis

A sales ops lead or analyst asks natural-language questions: “How has inventory in Mississauga changed over the last six weeks?” “What’s the median sold price trend in L6L this quarter vs last?” The agent issues the SQL, returns the numbers, and can also produce a written summary in the same turn. Replaces the static weekly dashboard with an interactive one.

Next-best-offer for telecom churn

The agent combines the pre-mover signal (household-level, derived from the BrightCat Listings feed) with the telecom’s own usage and billing data to score each flagged household for the right retention offer. Pricing hold for high-value customers, plan-downgrade protection for price-sensitive ones, product upgrade for upwardly mobile households. The MCP call is one input; the decision logic is entirely inside the buyer’s stack.

Frequently asked questions

Related