Skip to main content
Glama
ziamalik

Bay Street MCP

by ziamalik

Bay Street MCP

A regulatory backstop for Canadian fintech architects: validate designs, vendor selections, and incident responses against OSFI, PIPEDA, FINTRAC, and Quebec Law 25 without leaving your editor.

Architecture review at design time. Regulatory text at query time. Built for senior architects working with LLMs at Canadian financial institutions.

CI License: MIT Python 3.13+ Status: Early Development

Status

🚧 Early development. Project scaffolding and v0.1 roadmap landed in the initial commit. First working release (v0.1.0) targeted for roughly 6 weeks out, built incrementally. Watch the commit history for weekly progress.

Component

State

Project scaffolding, CI, license, dependencies, MCP server stub

✅ Shipped

OSFI Guideline E-21 ingestion working

🚧 Up next

compliance_lookup MCP tool returning real cited passages

⬜ Planned

End-to-end smoke test against an MCP client (Claude Desktop, Cursor, Cline)

⬜ Planned

PIPEDA full text

⬜ Planned

FINTRAC AML/ATF guidance

⬜ Planned

Quebec Law 25

⬜ Planned

Demo recording + first public release (v0.1.0 tag)

⬜ Planned

If you want this for your Canadian fintech AI tooling, watch or star the repo. Substantive feedback on the roadmap is welcome via Issues.

Related MCP server: india-reg-mcp

Demo

Demo lands with the v0.1.0 release: a 90-second screen recording showing an MCP client (Claude Desktop in the demo) calling compliance_lookup and answering a regulatory question with a citation back to the source document.

Why I built this

I have spent 20 years architecting platforms in Canadian financial services. The regulatory review of new designs has always been a slow, expensive, late-stage step. By the time legal or compliance surfaces an issue, the architecture is locked, the build is in progress, and the rework is painful.

Bay Street MCP puts the regulatory backstop where it belongs: at design time, in the architect's editor, alongside your LLM of choice. The server exposes Canadian financial regulation as queryable context. Your LLM reads your architecture, queries the relevant provisions, and surfaces the implications before they become rework.

How architects use this

Bay Street MCP shines at the four moments where architects need regulatory context without leaving their editor:

  1. Pre-design check. "I'm building a real-time fraud detection system that uses customer transaction data. What regulatory considerations should shape the design?" Your LLM queries Bay Street MCP and returns OSFI E-21 (operational risk) plus PIPEDA (data handling) considerations grounded in the source text.

  2. Architecture review augmentation. Paste your design (Mermaid diagram, ADR, RFC, system diagram). Your LLM reads it, queries the relevant provisions, and surfaces a structured regulatory review: "Your design includes [X]. OSFI [section Y] requires [Z]. Recommendation: [W]."

  3. Vendor and third-party evaluation. "We're considering [SaaS vendor]. They process PII for our customers. What PIPEDA and Quebec Law 25 considerations apply to this contract?" Get cited passages on consent, retention, cross-border transfer, and breach notification.

  4. Incident response. "We had a 6-hour outage of our funds-transfer service. What are our regulatory reporting obligations?" Get the specific E-21 incident reporting requirements with citations.

The MCP server is the knowledge backstop. Your LLM is the reasoning engine. You stay the human-in-the-loop deciding what to ship.

Quick start (planned for v0.1, not yet functional)

The instructions below describe how the server will work once v0.1.0 ships. They do not work against the current commit. Tracking progress is in the Status table above.

The example uses Claude Desktop because it is the most widely deployed MCP client. Bay Street MCP works with any MCP client (Cursor, Cline, Claude Code, Continue, Goose, etc.); the install step varies by client but the underlying server invocation is the same.

  1. Clone and install:

    git clone https://github.com/ziamalik/bay-street-mcp.git
    cd bay-street-mcp
    uv sync
  2. Download a regulation PDF. For the v0.1 example, grab OSFI Guideline E-21 (Operational Risk Management and Resilience) from https://www.osfi-bsif.gc.ca/.

  3. Ingest it:

    uv run bay-street-ingest data/osfi-e21.pdf \
      --regulation "OSFI Guideline E-21" \
      --jurisdiction CA \
      --source-url "https://www.osfi-bsif.gc.ca/en/guidance/guidance-library/operational-risk-management-resilience"
  4. Add to your claude_desktop_config.json (typically at ~/Library/Application Support/Claude/claude_desktop_config.json on macOS or %APPDATA%\Claude\claude_desktop_config.json on Windows):

    {
      "mcpServers": {
        "bay-street": {
          "command": "uv",
          "args": ["--directory", "/absolute/path/to/bay-street-mcp", "run", "bay-street-mcp"]
        }
      }
    }

    See claude_desktop_config.example.json for an alternative invocation if you have installed the package globally.

  5. Restart Claude Desktop (or your MCP client of choice). Ask:

    What does OSFI E-21 say about AI risk management?

    The LLM will call compliance_lookup and answer with citations.

What v0.1 will deliver (when shipped)

  • One MCP tool: compliance_lookup(query, top_k) returning passages with {regulation, jurisdiction, page, source_url} citation metadata

  • One regulation supported out of the box: OSFI Guideline E-21 (you load the PDF)

  • Chroma vector store, persistent on disk

  • Stdio transport (works with Claude Desktop, Claude Code, Cursor, any MCP client)

  • About 400 lines of Python

Subsequent versions add PIPEDA, FINTRAC, Quebec Law 25, then expand to OSFI E-23 (model risk) and B-13 (technology and cyber risk). See Roadmap below.

Roadmap

v0.1 (in progress, ETA ~6 weeks):

  • Project scaffolding, CI, license, dependencies, MCP server stub

  • OSFI Guideline E-21 ingestion working end-to-end

  • compliance_lookup MCP tool returning real cited passages

  • End-to-end demo against an MCP client (Loom)

  • First public release (v0.1.0 tag)

v0.2 and beyond:

  • PIPEDA full text + summary

  • FINTRAC AML/ATF guidance

  • Quebec Law 25

  • OSFI E-23 (model risk management)

  • OSFI B-13 (technology and cyber risk)

  • Auto-refresh from regulator sites with diff detection

  • Resource endpoints for whole-document retrieval

  • Citation formatting (APA, plain-text)

  • Pre-built Docker image

How it works

User question  →  LLM  →  MCP tool call  →  Chroma similarity search
       →  top-k passages with metadata  →  LLM synthesizes answer with citations

The ingestion script chunks each regulation by ~800 words with 100-word overlap, stores in Chroma with metadata {regulation, jurisdiction, page, source_url}. The MCP tool returns passages with full citation metadata, so the LLM can cite page numbers and source URLs in its response.

Why MCP

MCP (Model Context Protocol) is becoming the standard interface for connecting LLMs to external context. Exposing this as an MCP server means the same compliance knowledge is usable from any MCP-compatible client (Claude Desktop, Cursor, Cline, Claude Code, Continue, Goose, and others) and any underlying model the client supports, without building a custom integration each time.

Because MCP separates the knowledge layer from the model layer, the same Bay Street MCP install works with any model the client supports: Claude, Mistral, OpenAI (including their open-weight gpt-oss models), Llama, or any local model via Ollama or vLLM. Useful for on-prem deployments, data-residency-sensitive workflows where cloud LLMs are not allowed, and cost-sensitive batch use cases. The knowledge layer (Canadian regulatory text) and the reasoning layer (whichever LLM you choose) are deliberately decoupled.

Development

uv sync --all-extras
uv run pytest
uv run ruff check .

License

MIT. Use it, fork it, ship it.

About

Built by Zia Malik — 20 years Canadian financial services, currently building AppVet (AI-powered web app security audits) and writing about fintech-grade AI engineering.

If you are at a Canadian fintech and want this extended for your specific regulatory surface, open an issue or reach out.

Available Tools

1 tool
compliance_lookupA

Search Canadian financial-services regulations (OSFI, PIPEDA, FINTRAC, Quebec Law 25) and return the most relevant passages with citation metadata. Use this tool whenever the user asks about Canadian financial regulation, compliance, AI/data governance for Canadian financial institutions, AML/ATF, operational risk, model risk, or related topics.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesNatural-language question about Canadian financial-services compliance.
top_kNoNumber of passages to return. Default 5, max 10.

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It implies a read-only operation by stating 'search and return', but does not explicitly confirm non-destructive behavior or disclose any side effects, rate limits, or auth requirements. It adds some value by mentioning citation metadata but lacks full transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, each adding value. The first sentence states functionality, the second provides usage guidance. No unnecessary words or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description briefly mentions returning 'most relevant passages with citation metadata', but does not detail the output structure (e.g., fields, format, pagination). For a search tool, more specificity on the return value would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with both 'query' and 'top_k' having descriptions. The description does not add any additional meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches Canadian financial-services regulations, listing specific sources (OSFI, PIPEDA, FINTRAC, Quebec Law 25), and returns relevant passages with citation metadata. The verb 'search' and resource 'Canadian financial-services regulations' are specific, and there are no sibling tools to distinguish from.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use this tool whenever the user asks about Canadian financial regulation, compliance, AI/data governance for Canadian financial institutions, AML/ATF, operational risk, model risk, or related topics.' This provides clear guidance on when to use, even though no alternatives exist.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

TDQS

A4/5.0
Disambiguation5/5

With only one tool, there is no possibility of confusion or overlap with other tools.

Naming Consistency5/5

The single tool name 'compliance_lookup' follows a clear verb_noun convention, which is consistent by default.

Tool Count3/5

A single tool for a broad domain like Canadian financial regulations feels slightly thin, but it may be acceptable for a focused lookup utility.

Completeness2/5

The tool only supports lookup operations, lacking capabilities like listing categories, comparing regulations, or retrieving updates, which leaves significant gaps for comprehensive compliance work.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    B
    maintenance
    An MCP server that gives Claude searchable, cited access to RBI and SEBI regulatory documents — circulars, master directions, notifications, and regulations.
    49
    1
    MIT
  • A
    license
    A
    quality
    D
    maintenance
    MCP server to fetch Japanese financial laws and regulations from the e-Gov API, preventing hallucinations in Claude's responses. Supports 9 domains including Financial Instruments and Exchange Act, Banking Act, etc.
    5
    MIT
  • A
    license
    A
    quality
    B
    maintenance
    MCP server for token-efficient access to Open Finance Brasil rules, enabling coding agents to search and retrieve specific regulations, OpenAPI specs, and business rules through progressive disclosure.
    4
    25
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ziamalik/bay-street-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server