de en es ja ko ru zh

northwood-carbon MCP server

Name: northwood-carbon MCP server
Author: trippborstel-hub

by trippborstel-hub

Overview Schema Source Related Servers Discussions Admin

Python

Remote

northwood-carbon MCP 서버

Northwood Capital Partners의 포트폴리오 탄소 데이터를 MCP 호환 에이전트(Claude Desktop, Claude Code 등)가 호출할 수 있는 도구로 노출하는 MCP(Model Context Protocol) 서버입니다.

*"2030년 목표에서 가장 뒤처진 포트폴리오 기업 3곳은 어디이며, 각 기업에 가장 저렴한 이니셔티브는 무엇인가?"*와 같은 탄소 관련 질문을 데이터 처리가 아닌 도구 호출로 변환합니다.

도구

도구	목적
`list_portcos`	부문, 상태, 매출, 시설, 데이터 등급을 포함한 10개 포트폴리오 기업 전체
`get_portco_emissions`	연도 및 범위별로 필터링 가능한 포트폴리오 기업의 Scope 1 / Scope 2 배출량
`gap_to_target`	SBTi 기준 2030년까지 42% 감축 경로 대비 격차 분석
`list_initiatives`	감축량, 자본 지출(capex), 상태를 포함한 탈탄소화 수단
`simulate_reduction`	가상 시나리오: 이니셔티브 적용 시 예상 배출량 및 자본 지출 반환

Related MCP server: Sablier MCP Server

설치

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

# With uv (recommended)
uv sync

# Or with pip
pip install -e .

실행

uv run server.py
# or
python server.py

이 서버는 stdio를 통해 MCP를 통신하므로, 대부분의 경우 직접 실행하지 않고 서버를 생성하는 클라이언트에 등록하여 사용합니다.

Claude Desktop / Claude Code에 연결

MCP 설정(~/.claude/mcp.json 또는 Claude Desktop 설정)에 추가하세요:

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

클라이언트를 재시작하면 5개의 도구가 자동으로 나타납니다.

예시 세션

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.json에 포함된 정적 스냅샷은 Northwood 참여 프로젝트의 3주 차 탄소 인벤토리와 4주 차 탈탄소화 작업에서 가져온 것입니다. DATA = json.loads(...) 라인을 쿼리 계층으로 교체하면 실시간 DB 연결이 가능하며, 도구 인터페이스는 동일하게 유지됩니다.

구조

.
├── 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.

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

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

A4.3/5.0

Scored 2026-05-01 18:00 across 5 tools

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

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 4 months ago (2026-06-03 08:31 UTC)
8
8 npm
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 4 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 4 days ago (2026-09-17 23:53 UTC)
4 npm
MIT

northwood-carbon MCP 서버

도구

설치

실행

Claude Desktop / Claude Code에 연결

예시 세션

데이터

구조

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

carbonstop-mcpofficial

Sablier MCP Serverofficial