How do I use Northbeam MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Northbeam MCP Server show me last week's revenue by channel" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Northbeam MCP Server

by mattcoatsworth

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

Northbeam MCP Server

This is a Model Context Protocol (MCP) server for accessing Northbeam marketing analytics data. It provides tools and resources for querying metrics, dimensions, channel performance, cohort analysis, and attribution data from Northbeam.

## Setup

1. Install dependencies:
   ```
   npm install
   ```

2. Create a `.env` file with your Northbeam API key and brand name:
   ```
   NORTHBEAM_API_KEY=your_api_key_here
   NORTHBEAM_BRAND=your_brand_name_here
   ```

3. Run the server:
   ```
   npm run dev
   ```

## Testing with MCP Inspector

You can test the server using the MCP Inspector:

```
npm run inspect
```

This will open a web interface where you can test all the available tools and resources.

## Available Tools

- `get_metric`: Get metric data from Northbeam
- `list_metrics`: List all available metrics in Northbeam
- `list_dimensions`: List all available dimensions in Northbeam
- `get_channel_performance`: Get channel performance data from Northbeam
- `get_cohort_analysis`: Get cohort analysis data from Northbeam
- `get_attribution`: Get attribution data from Northbeam

## Available Resources

- `northbeam://metrics/{metric_name}`: Get data for a specific metric

## Usage as a Package

You can also use this as an npm package:

```
npx northbeam-mcp
```

Or with the inspector:

```
npx @modelcontextprotocol/inspector npx northbeam-mcp
```

Available Tools

6 tools

get_attributionD

ParametersJSON Schema

Name	Required	Description
`model`	Yes	Attribution model to use
`metrics`	Yes	Metrics to include in the attribution
`end_date`	Yes	End date in YYYY-MM-DD format
`start_date`	Yes	Start date in YYYY-MM-DD format

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_channel_performanceD

ParametersJSON Schema

Name	Required	Description
`metrics`	Yes	Metrics to include in the report
`end_date`	Yes	End date in YYYY-MM-DD format
`start_date`	Yes	Start date in YYYY-MM-DD format

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_cohort_analysisD

ParametersJSON Schema

Name	Required	Description
`metrics`	Yes	Metrics to include in the analysis
`end_date`	Yes	End date in YYYY-MM-DD format
`start_date`	Yes	Start date in YYYY-MM-DD format
`cohort_type`	Yes	Type of cohort analysis

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_metricD

ParametersJSON Schema

Name	Required	Description
`end_date`	No	End date in YYYY-MM-DD format
`dimensions`	No	Dimensions to group by
`start_date`	No	Start date in YYYY-MM-DD format
`metric_name`	Yes	Name of the metric to retrieve

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

list_dimensionsD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

list_metricsD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesv1.0.0Aug 6, 2026
- First observedget_attribution
- First observedget_channel_performance
- First observedget_cohort_analysis
- First observedget_metric
- First observedlist_dimensions
- First observedlist_metrics

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

C2.1/5.0

Scored 2026-08-06 16:30 across 6 tools

Disambiguation5/5

Each tool targets a distinct action: listing vs getting metrics, listing dimensions, and three analysis types (channel performance, cohort, attribution). The purposes are clearly separated by resource type and analysis focus.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern: list_ for enumeration and get_ for single items or report-style analyses. The naming is predictable and easy to generalize.

Tool Count5/5

Six tools is well-scoped for an analytics server, covering exploration (metrics, dimensions) and core analytical operations without being either sparse or overwhelming.

Completeness4/5

The set covers metric listing/retrieval, dimension listing, and key analytical views. A minor gap is the absence of a way to list specific channels or cohorts directly, but the existing tools likely cover these indirectly via parameters.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

SourceMediumOAuth
com.sourcemedium
Query your SourceMedium commerce warehouse, Shopify stores, and ad accounts.
E-commerce & Retail Marketing Data Platforms
1
Consequential AnalyticsOAuth
io.consequential
Read-only access to your Consequential eCommerce marketing analytics and attribution data.
E-commerce & Retail Marketing
1
Recharge Merchant MCPOAuth
com.rechargeapps
Read-only Recharge store analytics: metrics, dimensions, and governed queries in plain language.
E-commerce & Retail Payments & Billing Search
1
AmplitudeOAuth
com.amplitude
Search, access, and get insights on your Amplitude data
Monitoring Search Data Platforms
2

Related MCP Servers

flin-shopify-analytics-mcp
E-commerce & Retail Customer Data Platforms
flin-agency
A
license
B
quality
C
maintenance
Read-only MCP server for querying Shopify analytics data, including orders, customers, products, sales, retention, and attribution.
Updated 5 months ago (2026-04-11 16:39 UTC)
19
MIT
Triplewhale MCP Server
Marketing Finance E-commerce & Retail
mcpflow
A
license
Not graded
quality
D
maintenance
Enables natural language queries to Triplewhale for analyzing marketing and financial metrics such as revenue, ROAS, and net profit.
Updated 2 years ago (2025-03-05 11:47 UTC)
106 npm
MIT
Marketing Analytics MCP Server
Marketing Search CRM
Dweeb1578
F
license
B
quality
C
maintenance
Enables natural language querying of marketing analytics across Google Search Console, GA4, Google Ads, HubSpot, and Bing. Provides tools for search queries, traffic, campaign performance, and composite cross-platform rollups.
Updated 3 months ago (2026-06-29 01:04 UTC)
79
-
GA4 MCP Server
Marketing AI & Machine Learning
devopsbrandmirchi
F
license
Not graded
quality
C
maintenance
Enables querying Google Analytics 4 data through natural language, including running reports, comparing periods, and exploring realtime metrics across multi-tenant properties with OAuth-based authentication.
Updated a month ago (2026-08-18 07:08 UTC)
-