Skip to main content
Glama

Taiwan Carbon Open Data (Unofficial)

Calculate emissions

calculate_emissions
Read-onlyIdempotent

Calculate emissions for one activity: activity data × an official factor from the database. Checks units, the applicable year and whether the factor may be used for calculation, and returns the formula, kg and tonnes, the factor version and the source URL. Returns a clear error instead of guessing when the unit is incompatible, the year does not match or required data is missing (fuel factors need a user-supplied lower heating value; refrigerants need the basis of the quantity). A refrigerant blend such as R-410A can be calculated by passing refrigerant_blend with the user-supplied composition instead of factor_id. 計算單一活動的排放量:活動數據 × 資料庫中的官方係數。會檢查單位、適用年度與係數是否可用於計算,回傳公式、公斤與公噸、係數版本與來源網址。單位不相容、年度不符或缺少必要資料時(燃料係數需要使用者提供低位熱值,冷媒需要說明數量的依據)回傳明確錯誤,不會猜測。混合冷媒(如 R-410A)可不給 factor_id,改以 refrigerant_blend 提供使用者確認過的成分比例。

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "quantity": "<quantity>",
      "quantity_unit": "<quantity_unit>"
    },
    "name": "calculate_emissions"
  }
}

Input Schema

NameRequiredDescriptionDefault
yearNo活動發生的年度(西元)。有給就必須與係數的適用年度相符,不會自動以其他年度代替。
quantityYes活動數據,不小於零。可用數字或十進位字串(字串可避免精度問題),例如 12000 或 "17.495"。
factor_idNo係數 ID,來自 search_emission_factors 或 get_electricity_factor 的結果。請勿自行猜測。
quantity_unitYes活動數據的單位,例如 kWh、度、L、公秉、kg、t、m3。「度」在電是 kWh、在水是 m³。
factor_versionNo指定係數版本,用來重現過去的計算。不給就用目前版本。
optional_contextNo補充資料。燃料燃燒係數需要 lower_heating_value;冷媒等含氟氣體的逸散需要 refrigerant。
refrigerant_blendNo混合冷媒(例如 R-410A)。成分比例必須來自使用者或設備、冷媒的規格文件;本服務沒有內建任何冷媒的成分,請勿憑記憶填寫,不確定時請向使用者確認。

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Beyond the annotations (which already confirm read-only, idempotent, non-destructive, closed-world), the description discloses validation behavior — unit, applicable year, and factor calculability are all checked — plus the exact response payload (formula, kg, tonnes, factor version, source URL). It also commits to failing loudly rather than guessing on incompatible units, year mismatch, or missing data, which is precisely the behavioral detail an agent needs to plan around failures.

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

Conciseness3/5

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

The English text is dense and front-loaded, with the core formula first and the error/blend cases after. However, the entire description is then repeated verbatim in Chinese, roughly doubling length without adding information for most agents, which is real redundancy rather than concision.

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?

For a 7-parameter tool with nested objects and no output schema, the description supplies the missing return-value information (formula, kg, tonnes, factor version, source URL) and enumerates the failure modes. Nothing an agent needs in order to call it correctly or interpret a failure is absent.

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 100%, so per-field meaning is already documented and the baseline is 3. The description still adds cross-parameter decision information: that refrigerant_blend substitutes for factor_id for blends, and that optional_context is conditional on factor type, which is a relationship the flat schema does not spell out.

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

Purpose4/5

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

The description gives a specific verb and resource plus the exact computation ('activity data × an official factor from the database'), and the phrase 'for one activity' scopes it against batch-style siblings. It stops short of naming any sibling explicitly, so differentiation is inferred rather than stated.

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?

It states concrete preconditions for calling the tool (fuel factors need a user-supplied lower heating value; refrigerants need the basis of the quantity) and offers an explicit alternative path for blends via refrigerant_blend instead of factor_id. It does not say when to prefer this over siblings like calculate_batch or compare_emissions, so it falls short of full when/when-not guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.