How do I use northwood-carbon MCP server?

1. Click on "Install 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., "@northwood-carbon MCP server show me the three portcos with the largest gap to their 2030 targets" 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.

de en es ja ko ru zh

northwood-carbon MCP server

by trippborstel-hub

Overview Schema Related Servers Score Discussions

Python

Remote

northwood-carbon MCP server

An MCP (Model Context Protocol) server that exposes Northwood Capital Partners' portfolio carbon data as tools any MCP-compatible agent (Claude Desktop, Claude Code, etc.) can call.

Turns carbon questions like "Which three portcos are furthest behind their 2030 targets, and what's the cheapest initiative for each?" into tool calls, not data wrangling.

Tools

Tool	Purpose
`list_portcos`	All 10 portcos with sector, status, revenue, facilities, data grade
`get_portco_emissions`	Scope 1 / Scope 2 emissions for a portco, filterable by year + scope
`gap_to_target`	Gap analysis vs SBTi-aligned 42% by 2030 pathway
`list_initiatives`	Decarbonization levers with reduction, capex, status
`simulate_reduction`	What-if: apply initiatives, return projected emissions + capex

Related MCP server: Sablier MCP Server

Install

# Clone
git clone <repo-url> northwood-carbon-mcp
cd northwood-carbon-mcp

# With uv (recommended)
uv sync

# Or with pip
pip install -e .

Run

uv run server.py
# or
python server.py

The server speaks MCP over stdio, so you don't run it directly in most cases — you register it with a client that spawns it.

Connect to Claude Desktop / Claude Code

Add to your MCP config (~/.claude/mcp.json or Claude Desktop settings):

{
  "mcpServers": {
    "northwood-carbon": {
      "command": "uv",
      "args": ["--directory", "/path/to/northwood-carbon-mcp", "run", "server.py"]
    }
  }
}

Restart the client. The five tools appear automatically.

Example session

You: What are Meridian's 2024 Scope 1 emissions?

Claude → get_portco_emissions(portco="meridian", year=2024, scope=1)
       ← {"emissions": {"2024": {"scope1": 750.0}}, "units": "tCO2e", ...}

Claude: Meridian Business Solutions emitted 750 tCO2e in Scope 1 during 2024,
        primarily natural gas for space heating across 16 offices.

You: Which portcos are off-track for 2030 and what's the cheapest initiative for each?

Claude → list_portcos()
       → gap_to_target(portco=<each>)   × 10
       → list_initiatives(portco=<off-track one>, status="planned") × 3
       ← synthesizes ranked answer with capex + reduction per lever

Data

Static snapshot in data.json, sourced from the Northwood engagement's Week 3 carbon inventory and Week 4 decarbonization work. Drop in a live DB connection by replacing the DATA = json.loads(...) line with a query layer — the tool surface stays identical.

Structure

.
├── server.py       — FastMCP server, 5 tools, ~200 LOC
├── data.json       — Static data (PORTCOS, TRAJECTORY, INITIATIVES, RISK_SUMMARY, ESG_SCORES, FACILITIES)
├── pyproject.toml
└── README.md

Available Tools

5 tools

gap_to_targetA

Compute gap between current trajectory and SBTi-aligned reduction target.

Uses latest forecasted annual total and compares against the pro-rated linear pathway from base year to target year.

Args: portco: Portco slug or name. target_year: Year to evaluate against (default 2030).

Returns: Dict with: current_tco2e, target_tco2e, gap_tco2e, gap_pct, on_track (bool), verdict (short string).

ParametersJSON Schema

Name	Required	Description	Default
`portco`	Yes
`target_year`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior4/5

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

No annotations exist, so the description fully carries behavioral transparency. It clearly describes the computation, inputs, and return structure, indicating a read-only behavior. However, it does not mention dependencies like forecast data availability.

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

Conciseness4/5

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

The description is efficient, using three sentences plus an args/returns block. It is front-loaded with the purpose. Could be slightly more structured but remains clear and without redundancy.

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?

Given the tool's simplicity (2 parameters, simple computation), the description covers all necessary aspects: purpose, inputs, and return values. The presence of an output schema complements the description, making it highly complete.

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

Parameters5/5

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

With 0% schema description coverage, the description adds significant meaning: it explains that 'portco' is a slug or name and 'target_year' defaults to 2030, plus lists all return fields. This fully compensates for the schema's lack of descriptions.

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 precisely states the tool computes the gap between the current trajectory and an SBTi-aligned target, specifying the method and inputs. This distinguishes it from siblings like get_portco_emissions or simulate_reduction.

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

Usage Guidelines3/5

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

The description explains how the gap is computed but does not explicitly guide when to use this tool over alternatives. Usage context is implied but no exclusion criteria or prerequisites are mentioned.

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

get_portco_emissionsA

Get Scope 1 and Scope 2 emissions for a specific portfolio company.

Args: portco: Portco slug (e.g. 'meridian') or name substring (e.g. 'Meridian'). year: Optional. Restrict to a single year (e.g. 2024). If omitted, returns totals for every available year. scope: Optional. 1 or 2 to filter to a single scope. If omitted, returns both.

Returns: Dict with portco metadata and an 'emissions' map of {year: {scope1, scope2, total}} in tCO2e. Values are tonnes CO2-equivalent.

ParametersJSON Schema

Name	Required	Description	Default
`portco`	Yes
`year`	No
`scope`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.6/5.0

Behavior5/5

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

Despite no annotations, the description fully discloses input behavior (slugs vs name substrings, optional year/scope filtering) and output shape (dict with emissions map in tCO2e). It implies read-only access, which is appropriate for a 'get' tool.

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

Conciseness4/5

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

The description is well-structured with Args and Returns sections, providing clear information without excessive verbosity. It could be slightly more terse, but the structure aids readability.

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

Completeness4/5

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

For a simple get tool with an output schema, the description covers all parameters and return format. It does not mention error handling or authentication, but these are not critical for completeness given the tool's straightforward nature.

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

Parameters5/5

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

Given 0% schema description coverage, the description adds crucial meaning: portco can be a slug or name substring, year restricts to a single year, and scope filters to 1 or 2. This far exceeds what the schema (just titles and types) provides.

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 gets Scope 1 and 2 emissions for a portfolio company, with a specific verb and resource. It distinguishes itself from sibling tools like list_portcos or simulate_reduction, which serve different purposes.

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 explains the tool's purpose and parameter options, but does not explicitly state when to use it over siblings. However, the narrow scope makes usage clear without needing exclusion clauses.

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

list_initiativesA

List decarbonization initiatives with estimated reduction, capex, and payback.

Args: portco: Optional. Filter to a single portco. If omitted, returns all portfolio initiatives. status: Optional. One of 'planned', 'in_progress', 'complete'.

Returns: List of initiative dicts: {portco, id, name, category, status, est_reduction_tco2e, capex_k, start_date}.

Useful for cost-curve analysis, payback screening, and status roll-ups.

ParametersJSON Schema

Name	Required	Description	Default
`portco`	No
`status`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations, the description carries the full burden of disclosing behavior. It explains the filtering options and return structure, which is sufficient for a read-only list tool. However, it does not mention any potential side effects, authorization requirements, rate limits, or error handling. A higher score would require more detailed behavioral context, such as pagination or data freshness.

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 extremely concise, with the main purpose stated in the first sentence. The Args and Returns sections are clearly formatted and front-loaded. Every line serves a purpose with no redundancy or fluff. It is well-structured and easy to parse quickly.

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

Completeness4/5

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

Given that the tool has an output schema (though not provided in the input), the description adequately documents the return format with field names and descriptions. The two optional parameters are fully explained. For a straightforward list tool, the description covers all essential information (purpose, parameters, returns, use cases). It only lacks advanced context like pagination or sorting, which would be nice but not necessary.

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?

The input schema has zero description coverage, but the description's Args section explicitly explains each parameter's purpose and values. For status, it enumerates the valid options ('planned', 'in_progress', 'complete'), which adds semantic value beyond the schema's bare type definitions. The description also clarifies that omitting portco returns all portfolio initiatives, providing default behavior context.

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 begins with 'List decarbonization initiatives with estimated reduction, capex, and payback,' which is a specific verb-resource combination. It clearly distinguishes this tool from its siblings: list_portcos lists companies, gap_to_target and simulate_reduction are analytical, and get_portco_emissions retrieves emission data. The purpose is unambiguous and well-scoped.

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 states 'Useful for cost-curve analysis, payback screening, and status roll-ups,' which provides clear context on when to use the tool. However, it does not explicitly exclude scenarios where alternatives might be better, nor does it mention prerequisites or when not to use it. The sibling tools are not directly compared, but the use cases are well defined.

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

list_portcosA

List all 10 Northwood portfolio companies with sector, status, and headline metrics.

Returns a list of dicts containing: slug, name, sector, fund, status, revenue ($M), ebitda ($M), facilities count, data_grade, base_year, target_year, target_reduction_pct.

Use this as the starting point for portfolio-level questions.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

No annotations provided, but description covers that it lists all companies and specifies return fields. No hidden behaviors; adequate for a simple read-only list.

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?

Two sentences, front-loaded with purpose and immediate value, 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?

Given 0 parameters and output schema exists, description still enumerates return fields for clarity. Provides complete starting point for portfolio queries.

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?

Input schema is empty (0 parameters). Description adds no parameter info because none needed. Baseline 4 for 0-param tools.

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?

Description explicitly states 'List all 10 Northwood portfolio companies' with specific fields (sector, status, headline metrics), clearly distinguishing from sibling tools like gap_to_target or get_portco_emissions.

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?

Explicitly says 'Use this as the starting point for portfolio-level questions', indicating when to use. No explicit when-not or alternatives, but context is clear enough.

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

simulate_reductionA

What-if analysis: apply a subset of initiatives and return projected post-lever emissions.

Args: portco: Portco slug or name. initiative_ids: List of initiative IDs (from list_initiatives) to 'turn on'.

Returns: Dict with baseline (current trajectory endpoint), applied initiatives, total reduction, total capex, and new endpoint vs target.

ParametersJSON Schema

Name	Required	Description	Default
`portco`	Yes
`initiative_ids`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It describes a simulation ('what-if', 'projected'), implying read-only behavior, but does not explicitly state that it has no side effects or requires specific permissions.

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?

Description is concise and well-structured: one-line summary, then Args, then Returns. Every sentence adds value with no redundancy.

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

Completeness4/5

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

Output schema exists, so description need not detail return values but still lists key return fields (baseline, applied initiatives, reductions, capex). For a simulation tool with two parameters and clear return, this is sufficient.

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?

Schema coverage is 0%, but description adds meaning: clarifies 'portco' as slug or name, and 'initiative_ids' as a list from list_initiatives. This compensates well, though could include more detail on valid values or constraints.

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?

Description clearly states it performs 'What-if analysis' by applying a subset of initiatives and returning projected post-lever emissions. It effectively distinguishes from sibling tools like gap_to_target (gap calculation), get_portco_emissions (baseline), list_initiatives (list initiatives), and list_portcos (list portcos).

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

Usage Guidelines3/5

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

Description implies usage for hypothetical scenarios but lacks explicit guidance on when to use versus alternatives (e.g., when not to use or mention of prerequisites). Context from sibling tools helps but not explicitly stated.

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. Dates show when Glama detected each change.

5 tool updatesv0.1.0May 1, 2026
- First observedgap_to_target
- First observedget_portco_emissions
- First observedlist_initiatives
- First observedlist_portcos
- First observedsimulate_reduction

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: listing portfolio companies, retrieving emissions data, listing initiatives, simulating reductions, and computing gap to target. No overlap or ambiguity.

Naming Consistency4/5

Four tools use a consistent verb_noun pattern (list_portcos, get_portco_emissions, list_initiatives, simulate_reduction). However, 'gap_to_target' starts with a noun rather than a verb, creating a minor inconsistency.

Tool Count5/5

5 tools is an appropriate size for a focused carbon analysis server. Each tool serves a distinct function without unnecessary duplication or gaps.

Completeness4/5

The tool set covers the core analysis workflow: list companies, retrieve emissions, view initiatives, simulate reductions, and check targets. Missing write operations (e.g., create/update initiatives) but reasonable for a read/analysis-oriented server.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Caplia AOAuth
io.github.Caplia-Tech
MCP server for VC pitch-deck scoring, thesis-fit matching, and deal-flow management.
Finance AI & Machine Learning
2
anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
mcp A
com.everstake
MCP server connecting AI agents to non-custodial staking data across 130+ networks.
Blockchain Cryptocurrency
1111
ClawLinkOAuth
dev.claw-link
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
App Automation Workplace & Productivity
24

Related MCP Servers

carbonstop-mcpofficial
Energy Research & Data
carbonstop-hub
A
license
B
quality
D
maintenance
MCP server enabling AI assistants to automatically perform carbon footprint modeling, product queries, and emission analysis via the Carbonstop Cloud API.
Updated 3 months ago (2026-06-03 08:31 UTC)
8
31
MIT
Sablier MCP Serverofficial
Finance AI & Machine Learning Research & Data
sablier-ai
A
license
A
quality
D
maintenance
An MCP server that lets AI assistants analyze portfolios, stress-test scenarios, generate synthetic market paths, and scan SEC filings — in under 2 minutes.
Updated 3 months ago (2026-05-28 05:46 UTC)
83
3
MIT
authn-authz-with-mcps
Security Web3 & Decentralized Tech
rabi-siddique
F
license
Not graded
quality
B
maintenance
This MCP server provides authentication via wallet sign-in (SIWE) and authorization with scoped access to read and trade portfolios, enabling secure portfolio management through natural language.
Updated 2 months ago (2026-07-21 05:42 UTC)
-
mcp-carbon-interface
Energy Open Data
pipeworx-io
A
license
Not graded
quality
C
maintenance
MCP server for the Carbon Interface API (v1), enabling AI agents to estimate carbon emissions through natural language queries via Pipeworx gateway.
Updated 12 days ago (2026-08-26 16:46 UTC)
16
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/trippborstel-hub/northwood-carbon-mcp'

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

northwood-carbon MCP server

Tools

Install

Run

Connect to Claude Desktop / Claude Code

Example session

Data

Structure

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

carbonstop-mcpofficial

Sablier MCP Serverofficial

Latest Blog Posts

MCP directory API