Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@carbonstop-mcp Calculate carbon footprint of product 'EcoBottle'"
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.
MCP (Model Context Protocol) server for Carbonstop — 碳阻迹碳足迹核算 MCP 服务。
AI 对话中自动调用碳云 API，完成碳足迹建模、产品查询、核算分析。
npm install -g @carbonstopper/mcpOr run directly:
npx @carbonstopper/mcpRelated MCP server: mcp-climatiq
前往 碳云平台 注册登录，创建 API Key（PAT）
设置环境变量：
export CARBONSTOP_API_KEY="csk_xxx.yyy"
# 自编译需额外设置网关地址：
# export CARBONSTOP_BASE_URL="<gateway-url>"启动 MCP Server：
npx @carbonstopper/mcp{
"mcpServers": {
"carbonstop": {
"command": "npx",
"args": ["@carbonstopper/mcp"],
"env": {
"CARBONSTOP_API_KEY": "csk_xxx.yyy"
}
}
}
}{
"mcpServers": {
"carbonstop": {
"command": "npx",
"args": ["@carbonstopper/mcp"],
"env": {
"CARBONSTOP_API_KEY": "csk_xxx.yyy"
}
}
}
}Tool | Description |
| 网关探活 |
| 查看身份信息 |
| 产品列表（支持分页、名称搜索） |
| 产品详情 |
| 产品核算列表 |
| 核算详情（含生命周期各阶段排放） |
| 一键 AI 碳足迹建模 |
网关地址构建时注入，源码及配置中均不可见
认证通过 API Key（PAT），由 MCP 客户端通过环境变量传入
接口调用需有效凭证，网关层鉴权
carbonstop-cli — 命令行工具
MIT
List carbon footprint accounts (models) for a product.
| Name | Required | Description | Default |
|---|---|---|---|
| productId | Yes | Product ID (required) | |
| pageNum | No | Page number (default 1) | |
| pageSize | No | Page size (default 10) | |
| accountStatus | No | Account status (default 3) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description only says 'List', implying a read operation, but does not disclose pagination behavior, default status, return format, or any side effects. For a tool with no annotations, more behavioral detail is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no waste. However, it could include more useful information without becoming overly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters and no output schema, the description is too minimal. It does not explain return values, pagination details, or the meaning of account status. The tool's complexity is low but the description falls short.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 4 parameters, so the baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions, which are self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and the resource (carbon footprint accounts/models for a product). It is specific and distinguishes from siblings like 'account_view' which likely focuses on a single account.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., 'account_view' for individual account details) or when not to use it. Lacks context on prerequisites or filters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed view of a carbon footprint account with emission breakdown by lifecycle stages.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Account ID (required) | |
| groupType | No | Group type (default 0) | |
| lang | No | Language: zh or en (default zh) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must cover behavioral traits. It only states the tool is a read operation ('Get'), but omits details on permissions, error handling, rate limits, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose without any extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description mentions the response includes emission breakdown by lifecycle stages but lacks further detail on other potential fields or structure. Given no output schema, a bit more completeness would be helpful but it is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are described in the input schema (100% coverage), so the description adds only minimal context (e.g., 'emission breakdown by lifecycle stages' hints at the response shape). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a detailed view of a carbon footprint account with emission breakdown by lifecycle stages. This distinguishes it from sibling tools like 'accounts' which likely provide a list or overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'accounts' or other siblings. It lacks when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-click AI carbon footprint modeling. Submit a product description and get factor-matched emission results with lifecycle stage breakdown.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | 一句话产品描述（必填），例如：一瓶农夫山泉500ml矿泉水 | |
| scope | No | 生命周期范围。0=半生命周期，1=全生命周期。可不传 | |
| scopeValue | No | 半生命周期时传 "0,1,2"，全生命周期可不传 | |
| factorScope | No | 因子偏好。1=Ecoinvent，2=国内因子，3=不限来源。可不传 | |
| userKeys | No | 用户自定义因子 key 列表，可不传 | |
| signKeys | No | 标记的因子 key 列表，可不传 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It mentions 'One-click' and 'get factor-matched emission results with lifecycle stage breakdown' but does not disclose rate limits, error handling, or data privacy implications. Missing behavioral details beyond the high-level output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose. Every word adds value. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters (1 required) and no output schema, the description lacks details about return structure, lifecycle stage breakdown interpretation, and advanced parameter usage. Could be more complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-documented. The description adds context for the 'content' parameter ('product description') but does not add meaning beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'One-click AI carbon footprint modeling' with inputs and outputs: 'Submit a product description and get factor-matched emission results with lifecycle stage breakdown.' This distinguishes it from sibling tools like accounts or product_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (for carbon footprint modeling) but provides no explicit guidance on when not to use or alternatives. No exclusions or comparisons to siblings are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Health check — verify the Carbonstop gateway is reachable and the API key is valid.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 explains what the tool verifies but does not disclose potential response details, rate limits, or side effects. For a simple health check, it is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple health check with no parameters and no output schema, the description is complete enough. It tells the agent everything needed to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the description does not add parameter-level details. However, with 100% schema coverage and zero parameters, baseline is 4, and the description does not detract from that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is a health check to verify gateway reachability and API key validity. It uses specific verbs and nouns, effectively distinguishing it from sibling tools like 'accounts' or 'whoami'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it's the first tool to try for connectivity checks, but it does not explicitly state when to use versus alternatives or provide exclusions. However, the purpose is clear enough for a simple ping tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific product by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Product ID (required) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It only states it 'gets' information, implying a read operation, but does not disclose any potential side effects, idempotency, rate limits, or what 'detailed information' includes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is appropriately sized for a simple tool. It is front-loaded with the key action and resource, but lacks any structure or additional detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and no annotations, the description is insufficient. It does not explain what 'detailed information' means in terms of output fields, format, or error handling, leaving the agent uninformed about the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage for the single parameter 'id' is 100%. The description adds no extra meaning beyond the schema's 'Product ID (required)', so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'detailed information about a specific product by ID'. It is specific enough to distinguish from listing tools like 'products', though it does not explicitly differentiate from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, or on any prerequisites. The description solely states what it does without context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List carbon footprint products with pagination and filtering.
| Name | Required | Description | Default |
|---|---|---|---|
| pageNum | No | Page number (default 1) | |
| pageSize | No | Page size (default 12) | |
| status | No | Status filter (default 2) | |
| search | No | Search by product name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It indicates a list operation with pagination and filtering, implying it is read-only, but does not mention any side effects, authentication needs, rate limits, or other behaviors beyond what the schema conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of 7 words with no unnecessary information. Every word is meaningful, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description should clarify return format or fields, but it does not. It only covers the input features, leaving the output ambiguous. For a list tool with 4 parameters and no annotations, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters have descriptions in the input schema (100% coverage), so the description adds no extra meaning. It summarizes the parameters as 'pagination and filtering' but does not enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'list' and specifies the resource 'carbon footprint products', clearly indicating the tool's function. It also mentions pagination and filtering, distinguishing it from siblings like 'product_info' which likely provides details on a single product.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing products with filters, but does not explicitly state when to use this tool over alternatives such as 'product_info' or 'search_factors'. No guidance on prerequisites or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search CCDB carbon emission factors by keyword. Returns matching factors with metadata (unit, source, country, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | 搜索关键词（必填），例如：电力、天然气 | |
| lang | No | 语言：zh 或 en（默认 zh） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. While it implies a read-only search operation, it does not explicitly state that it is non-destructive or discuss any side effects, authorization needs, or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It efficiently conveys the tool's purpose and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description mentions return values (matching factors with metadata) but lacks details like pagination, examples, or error handling. Given the simple nature of the tool and no output schema, it is minimally adequate but could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters (name and lang) with 100% coverage. The description does not add additional semantic meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool searches CCDB carbon emission factors by keyword and returns matching factors with metadata. It is distinct from sibling tools like accounts, product_info, etc. 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor any conditions or exclusions. The description does not specify when not to use it or mention any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the identity (username, company, userId) associated with the current API key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 merely states 'Show' without disclosing any behavioral traits such as auth requirements beyond the API key, error conditions, or response format. This is insufficient for transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence of 14 words that conveys the entire purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description sufficiently explains the return content (username, company, userId). It lacks details on format or behavior, but is generally complete for this simplicity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema coverage is 100%. The description does not need to add parameter meaning. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool shows identity (username, company, userId) associated with the current API key. It uses a specific verb ('Show') and clearly identifies the resource, distinguishing it from sibling tools like accounts or account_view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing current identity, but does not explicitly state when to use vs alternatives or provide exclusions. Given the self-explanatory name, it is adequate but lacks guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v2.1.0account_viewaccountsai_modelpingproduct_infoproductssearch_factorswhoamiEach tool has a clearly distinct purpose: accounts for listing models, account_view for detailed breakdown, ai_model for AI modeling, ping for health, product_info/product for product details/list, search_factors for factors, whoami for identity. No overlap.
Naming is inconsistent: some are single-word nouns (accounts, products), some use underscores (account_view, ai_model), some are verb-like (ping, whoami). No uniform verb_noun pattern or consistent convention.
8 tools is a reasonable number for a carbon footprint service, covering essential read operations and a health check without being excessive.
The server provides listing and viewing of accounts/products, AI modeling, and factor search, but lacks create/update/delete operations for accounts and products, which are notable gaps for a typical resource management scenario.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI governance MCP server for EU AI Act compliance and jurisdiction verification
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/carbonstop-hub/carbonstop-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
