Skip to main content
Glama
JuliaTechnologies

mcp-saas-connector

Official

mcp-saas-connector

One MCP server for the SaaS back office. Stripe, HubSpot, and Google Sheets exposed as typed, read-only-by-default tools for Claude and any MCP client.

Most teams that connect an agent to their business systems end up running three separate servers with three different auth stories and three different ideas of what a safe default looks like. This server takes the opposite approach: one process, one configuration surface, one security model, and a tool catalog designed for how agents actually consume data.

Design principles

  • Read-only by default. Tools that create or modify data exist, but they register only when you set CONNECTOR_ALLOW_WRITES=true. There are no destructive tools at all: nothing deletes, refunds, or overwrites.

  • Token-disciplined responses. Provider APIs return large payloads. Every tool maps them to the compact set of fields an agent acts on, so a customer lookup costs a few hundred tokens instead of a few thousand.

  • Secrets never reach the model. Error messages pass through a redaction layer that strips API keys, bearer tokens, and private key material before anything is surfaced.

  • Two dependencies. The MCP SDK and zod. Google auth is a hand-built RS256 service-account JWT, not the full googleapis client.

Related MCP server: saas-brain-mcp

Quickstart

Requires Node 18 or newer.

Claude Code

claude mcp add saas \
  --env STRIPE_API_KEY=rk_live_... \
  --env HUBSPOT_ACCESS_TOKEN=pat-... \
  -- npx -y @juliatechnologies/mcp-saas-connector

Claude Desktop

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "saas": {
      "command": "npx",
      "args": ["-y", "@juliatechnologies/mcp-saas-connector"],
      "env": {
        "STRIPE_API_KEY": "rk_live_...",
        "HUBSPOT_ACCESS_TOKEN": "pat-..."
      }
    }
  }
}

From source

git clone https://github.com/JuliaTechnologies/mcp-saas-connector.git
cd mcp-saas-connector
npm install
npm test
node dist/index.js

Providers turn on individually: set a credential and its tools register, leave it unset and they stay off. With no credentials at all the server still starts and exposes connector_status, which explains its own setup state.

Configuration

Variable

Enables

Notes

STRIPE_API_KEY

Stripe tools

Use a restricted key (rk_...) with read permissions

HUBSPOT_ACCESS_TOKEN

HubSpot tools

Private app token scoped to contacts and deals

GOOGLE_SERVICE_ACCOUNT_JSON

Google Sheets tools

Inline JSON or a path to the key file. Share target sheets with the service account email

CONNECTOR_ALLOW_WRITES

Write tools

true registers the three write tools below. Anything else keeps them off

Tool catalog

Tool

Provider

Mode

What it does

connector_status

core

read

Reports enabled providers and write state

stripe_list_customers

Stripe

read

List customers, optional exact-email filter

stripe_get_customer

Stripe

read

One customer with balance and metadata

stripe_list_subscriptions

Stripe

read

Subscriptions by customer and status

stripe_list_invoices

Stripe

read

Invoices with totals and hosted links

stripe_list_payment_intents

Stripe

read

Recent payments with status

hubspot_search_contacts

HubSpot

read

Full-text contact search

hubspot_get_contact

HubSpot

read

One contact with associated deal ids

hubspot_list_deals

HubSpot

read

Deals with stage, amount, cursor paging

hubspot_get_deal

HubSpot

read

One deal by id

sheets_list_tabs

Sheets

read

Tabs and grid sizes of a spreadsheet

sheets_read_range

Sheets

read

Cell values from an A1 range

hubspot_create_contact

HubSpot

write

Create a contact

hubspot_create_note

HubSpot

write

Attach a timestamped note to a contact

sheets_append_row

Sheets

write

Append one row to a tab

Security model

The full policy lives in SECURITY.md. The short version: least-privilege credentials are assumed, write tools are an explicit opt-in, secrets are redacted from all output, stdout is reserved for the MCP protocol, and the server sends nothing anywhere except the provider APIs you configure. No telemetry.

Roadmap

  • Streamable HTTP transport for remote deployment behind OAuth

  • Per-tool allowlists so operators can expose a subset of a provider

  • More providers: Salesforce, Notion, Slack

  • An eval harness for tool-call correctness

Issues and pull requests are welcome.

Who maintains this

Julia Technologies is a one-architect consultancy that designs and builds production MCP servers for B2B SaaS products. This connector is the open-source expression of how those servers should be built: narrow tools, safe defaults, disciplined responses. If your product needs to be usable by Claude and other AI agents, that is the work Julia Technologies does.

License

MIT. See LICENSE.

Available Tools

1 tool
connector_statusConnector statusA
Read-only

Report which providers are enabled, whether write tools are registered, and how to enable more.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.7/5.0
Behavior5/5

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

The annotation already indicates readOnlyHint=true, confirming it's a read operation. The description adds valuable context about reporting status and providing guidance on enabling more, which goes beyond the annotation without contradicting it.

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 a single, well-structured sentence that front-loads the key information. Every phrase contributes essential meaning with no wasted words.

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

Completeness5/5

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

With no parameters, no output schema, and no sibling tools, the description fully covers the tool's purpose and output. The agent can confidently decide when and how to use it based on this description alone.

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

Parameters4/5

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

There are zero parameters, so the schema coverage is 100%. The description adds meaning by explaining what the tool reports, fulfilling the baseline expectation for no parameters.

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 uses a specific verb 'Report' and clearly states the resources: enabled providers, registered write tools, and guidance on enabling more. There are no siblings to differentiate, so it stands alone effectively.

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

Usage Guidelines4/5

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

The description provides clear context on what the tool does and what information it returns. It implicitly suggests using this tool to check connector status, but lacks explicit 'when-not-to-use' instructions. However, with no siblings, this is acceptable.

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

TDQS

A4.3/5.0
Disambiguation5/5

Only one tool exists, so there is no possibility of confusion between tools.

Naming Consistency5/5

With a single tool, naming is trivially consistent.

Tool Count2/5

A 'saas-connector' server with only one status tool is too thin; expected multiple tools for CRUD or provider management.

Completeness1/5

Lacks any operational tools to actually interact with SaaS providers; severely incomplete for the stated purpose.

Maintenance

ActivityInactive
ResponsivenessSyncing

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
    A
    quality
    B
    maintenance
    A curated collection of Model Context Protocol (MCP) servers for popular SaaS platforms — Stripe, Sentry, Notion, Linear, Datadog, Vercel, PagerDuty, HubSpot, Intercom, Shopify, Google Workspace
    28
    1
    MIT
  • F
    license
    Not graded
    quality
    D
    maintenance
    Open-source MCP server for Claude AI that connects Stripe and Supabase to enable natural language SaaS analytics, including churn analysis, subscription tracking, and revenue insights.
  • A
    license
    Not graded
    quality
    B
    maintenance
    Open-source MCP hub providing a single endpoint for AI agents to access dozens of business integrations (CRMs, spreadsheets, telephony, ads) with multi-tenancy, OAuth, and context-efficient tool discovery.
    Apache 2.0

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/JuliaTechnologies/mcp-saas-connector'

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