ClimatePoint MCP documentation

Destructive or non-idempotent tools (deletes, component removals, cascades, updates, benchmark selection, EOL commit) are deliberately NOT covered — they always keep the confirmation prompt, even under a grant. action="grant" (default) opens a time-boxed authorization (ttl_seconds, default 1800, max 3600); action="status" reports whether a grant is active and when it expires; action="revoke" ends it immediately. Requires a standard or admin plan. This removes only the human-confirmation prompt; every gated call is still checked so it cannot run twice.

It does not list datasets, process entries, transport legs or end-of-life treatment: read those per node with climatepoint_get_bom_structure, and GWP per variant and life-cycle stage with climatepoint_get_impact_summary. Defaults to markdown rendering for human-readable display; pass response_format="json" for machine consumption.

THREE mutually-exclusive source modes: (1) content_base64 — inline base64 file bytes; the ONLY mode that reaches a CLIENT-local/sandbox file in remote/http mode (requires filename; effective limit ~3 MB over http; full 20 MB only in stdio). (2) source as an https:// URL — the SERVER downloads it (SSRF-guarded; up to 20 MB). (3) source as a file path — resolved on the SERVER (relative to cwd in http mode; absolute only in stdio). A client-side path will NOT be found server-side in remote mode — use content_base64 instead. Stores the document, creates the document record, triggers AI classification. Supports PDF, DOCX, XLSX, CSV, PNG, JPG, WebP. climatepoint_initialize_scope researches the documents already attached when it starts; documents attached later are not part of that run.

This pipeline researches the product documents already uploaded with climatepoint_upload_document. Initializes LCA scope (AI pipeline: goal, AI system-boundary suggestion, benchmarks, KPIs, variants). Takes 45-90 seconds. Requires confirmation. The LCA workflow then continues with the study purpose (climatepoint_compliance_check set_goal), the system boundary (climatepoint_update_product_scope: epd_boundary for an EN 15804 EPD, scope_boundary otherwise), the functional unit (proposed by climatepoint_generate_functional_units, persisted by climatepoint_update_product_scope) and the Bill of Materials (climatepoint_generate_bom). Exception: if the product already had a committed functional unit, this run CLEARS it and returns it as functional_unit_cleared; re-committing that FU with climatepoint_update_product_scope restores it without generating a new one (when that FU has no reference_flow and the product has no BoM yet, generating a new one instead is the user's decision). Likewise, a product that already has a BoM but no committed functional unit needs the FU the BoM was built against — which only the user can say — rather than a newly generated one. Without climatepoint_update_product_scope, climatepoint_generate_bom returns functional_unit_evaluation_required when the product has no functional unit anywhere; when only the product-level FU was cleared, climatepoint_generate_bom still passes and climatepoint_calculate_variant_impact refuses with functional_unit_required. Later boundary or functional-unit edits with climatepoint_update_product_scope expect scope_goal too (unless the product already has a goal): the web app's Define Scope step expects a goal statement and shows it empty otherwise.

Requires a completed climatepoint_initialize_scope; confirmed_insights are that run's product insights as confirmed by the user. The options are stored as candidates (products.functionalUnits) but none is committed: only climatepoint_update_product_scope (with the selected/recommended functional_unit object) commits one, and climatepoint_generate_bom requires a committed one.

Supports both simple text/unit updates and full functional unit objects with reference_flow and assumptions. A scope_boundary or functional-unit change expects scope_goal alongside it (unless the product already has a goal): the web app's Define Scope step expects a goal statement and shows it empty otherwise. Workflow order: climatepoint_initialize_scope, the study purpose (climatepoint_compliance_check set_goal), the boundary, the functional unit, the BoM. For an EN 15804 EPD (purpose epd with EN 15804 modules on) the boundary is epd_boundary (option a–f, B6, module choices), saved through the same write as the web app's Define Scope; a free-text scope_boundary is refused for it (EPD_BOUNDARY_STRUCTURED_REQUIRED). Requires confirmation. scope_description (the scope text) is written in its own call on the state-guarded contract: preview, then confirm with confirm_token and expected_md5; the saved response carries prior_value for undo.

action="get" (default) returns goal (purpose, study_reasons, target_audience); the study's standard, enabled and schema_version; its study_information, methodology and verification sections exactly as stored (inner keys stay camelCase, e.g. methodology.cutoffPercentage, verification.criticalReviewRequired; null when not set); resolved method + region lock state; available regions; and iso_methodology_review, the check climatepoint_generate_lca_report blocks on (study fields vs the built model). action="set_goal" sets study purpose/reasons/audience (confirmation required, as for set_methodology below); workflow order: climatepoint_initialize_scope, then set_goal (the purpose), then the boundary (climatepoint_update_product_scope: epd_boundary for an EN 15804 EPD, scope_boundary otherwise), then the functional unit and the BoM; after purpose epd the saved response carries next_step; action="set_region" switches the method by region (destructive — rebinds LCI nodes; gated by confirm/confirm_text). action="set_methodology" / "set_study_information" correct the ISO study fields that print into the report: pass methodology / study_information with the camelCase keys get returns; an omitted key is kept, null clears one. Only that section changes. Values are validated as the web app does (field_errors on failure, nothing written). set_goal, set_methodology and set_study_information need confirmation: the first call writes nothing and returns the before/after diff, which the user reviews, and a confirmation_token; a second call with the same arguments and confirm_token writes it. product_id is the study (product) id.

Supports pagination via limit (default 50, max 200) and offset (default 0). Returns { skus: [...], pagination: { total, limit, offset, returned, has_more } }; each SKU row includes id, product_id, variant_name, variant_type, sku_code, sku_description, is_active, created_at and variant_order — the metadata variant-scoped tools such as climatepoint_get_variant_structure or climatepoint_compare_variants take. Richer per-variant state (including derived LCA readiness and the zero-contribution audit) is in climatepoint_get_variant_structure.

Supports pagination via limit/offset. Each variant carries lca_readiness (derived compile state) and zero_contribution_audit — a read-only check of whether its material leaves would actually contribute to the total; compiled_but_blocking:true means the stored total is silently understated (every leaf contributes zero) and the audit's warning names the specific remedy.

Writes no BoM and does no research itself: with a functional unit (the variant's own functional_units, else the product's committed one — climatepoint_generate_functional_units proposes one and climatepoint_update_product_scope commits it) it returns agent_research_required guidance aligned to that unit: the teardowns, spec sheets and material data the BoM needs. climatepoint_set_product_structure saves the resulting structure. Without a functional unit the confirmed call returns functional_unit_evaluation_required with candidate functional units (functional_unit_required, without candidates, when generating them fails). Requires confirmation.

Phase is inferred from arguments: file_base64 (+ file_name) or raw_text EXTRACTs the rows plus the interpretation rules for the items[] format; items[] (a per-row interpretation) ASSEMBLEs a validated tree and returns a confirm_token; confirm_token writes the structure (re-uses set_product_structure). document_id of an already-uploaded doc is ingested server-side (for browser/no-subagent runtimes; returns run_id); run_id returns that run's status.

Each node carries model: its matched dataset (activity, reference product, geography, unit, database version, LCI source), its manufacturing-process and capital-goods entries (quantity, unit, binding, selection method, DQR, dataset), its transport legs with a non-zero distance (mode, distance, priced share, origin, destination, dataset) and its end-of-life treatment. Datasets are named, never quantified: no emission factor or other LCI coefficient is returned. Pass include_model_detail=false for ids and structure only. include_dq_detail=true adds each process and capital-goods entry's stored DQ scores and reasoning, assumptions text and calculation state, and an md5 of each node's stored process arrays.

The variant includes lca_readiness and zero_contribution_audit (see climatepoint_list_variants). Three honesty flags: evaluated=false means the check did NOT run — read audit.note (the read failed/rejected/truncated, the check is turned off, or material sourcing is outside the study boundary) — and is NOT a clean bill of health; method_checks_skipped=true means the study method was not established for this caller, so blocking_leaves is a lower bound; zero_contribution_checks_skipped=true means only unmatched leaves were counted, so a matched-but-zero leaf is invisible in that response. The variant includes distances: its own avg_eol_distance_km, a factor-free distribution_lanes summary and any legacy avg_user_distance_km (null inherits the product family's, except on a benchmark); set them with climatepoint_set_variant_distances, which writes distribution as lanes only. The variant includes root: the root node's node_id, units and lifetime_parameters_data as climatepoint_set_lifetime_parameters stored them (null when there is no root; with several top-level nodes root is null and roots lists each). Each node carries the same model as climatepoint_get_bom_structure (its dataset, process entries, transport legs and end-of-life treatment, named only); pass include_model_detail=false to omit it.

Requires confirmation. Every node except the tree root carries location data via sourcing_data (manufacturing_location, vendor_location, assembly_location) — sub-assemblies too, not just leaves. A node may also carry waste fields (waste, waste_mode, waste_kg), material classification, LCI matching fields, and data objects (match_data, transport_data, eol_analysis_data, etc.). Extra fields pass through. Nodes are PHYSICAL bill-of-materials items. Anything a node merely consumes is a field on that node, not a child of it: process energy -> manufacturing_process_data, equipment -> capital_goods_data, freight -> transport_data, in-use energy -> use_phase_energy_data, disposal -> eol_analysis_data. A consumable root's lifetime parameter (initial_mass) is auto-filled from the product functional unit (batch_mass / FU_mass) when one is already committed on the product (climatepoint_generate_functional_units proposes one; climatepoint_update_product_scope commits it). If a root is reusable, or its FU is missing/underivable, the response is a workflow_step_required step naming the root; nodes still persist, and a re-call once the missing piece is set gives a clean save.

Omit parent_id to add a root-level component; provide a parent node id to nest under it. variant_id defaults to the product's primary variant. Existing parent node ids are listed by climatepoint_get_bom_structure. Bulk imports are handled by climatepoint_generate_bom and climatepoint_set_product_structure. Returns the created node id, path, and the created rows. unit_weight_kg is the GROSS input mass per unit, before manufacturing waste; waste is the PERCENTAGE of it scrapped at your site, and the LCA compiler always reads it as a percentage. waste_mode and waste_kg are only the builder's display preference and do not change the result; to enter scrap in kg, convert: waste = waste_kg / unit_weight_kg × 100. Material impact and inbound supply-chain transport use the gross mass; the scrap leaves as a waste row; distribution and end-of-life use the net mass (gross × (1 − waste%)). To model a 0.163 kg as-sold part with 6% scrap, enter unit_weight_kg = 0.163 / 0.94 = 0.1734 and waste = 6. A parent's unit_weight_kg is the gross sum of its children, so a root reads above its as-sold mass when leaves carry waste.

Set foreground_provenance to record how the node's own quantities were obtained; on a scored leaf this recomputes pedigree P and the DQR. Requires confirmation. unit_weight_kg is the GROSS input mass per unit, before manufacturing waste; waste is the PERCENTAGE of it scrapped at your site, and the LCA compiler always reads it as a percentage. waste_mode and waste_kg are only the builder's display preference and do not change the result; to enter scrap in kg, convert: waste = waste_kg / unit_weight_kg × 100. Material impact and inbound supply-chain transport use the gross mass; the scrap leaves as a waste row; distribution and end-of-life use the net mass (gross × (1 − waste%)). To model a 0.163 kg as-sold part with 6% scrap, enter unit_weight_kg = 0.163 / 0.94 = 0.1734 and waste = 6. A parent's unit_weight_kg is the gross sum of its children, so a root reads above its as-sold mass when leaves carry waste.

CONSUMABLE GOODS — initial_mass is ROOT-ONLY and is normally AUTO-FILLED by climatepoint_set_product_structure from the product functional unit (batch_mass / FU_mass). A consumable root needs this tool only when set_product_structure reported initial_mass as blocked (e.g. the FU was not set). It takes a single parameter [{name:"initial_mass", unit:"kg", label:"Initial Mass", value:<batch_mass / FU_mass>}]. NESTED consumable/material parts need NO lifetime parameters — they inherit the root lifetime output; initial_mass on a nested component is ignored. REUSABLE / DURABLE PRODUCTS: the lifetime OUTPUT belongs on the ROOT (parent_id null) node only. On the root, pass 1–3 parameters whose units multiply together to produce the target unit (e.g. "MWh/year" × "year" = "MWh", or "use/year" × "year" = "use"). The units must be dimensionally correct — every unit must cancel cleanly. Bad: g × g/month (= g²/month). Good: use/year × year = use. Per-FU figures are the life-cycle total divided by the product of the ROOT parameter values, so they are per ONE unit of the root output: the units must multiply to the functional unit's unit (e.g. FU "1 trip" → a root output in trips), every value must be a finite number, and their product must be > 0 — a non-numeric value, or values whose product is zero or negative, is refused. NESTED parts NEVER carry lifetime parameters — they inherit the root lifetime output automatically; params sent for a nested component are ignored. The server neither estimates these values nor checks their units: it refuses only non-finite or non-positive values, ignores nested entries and stores the rest as passed, so the values come from product specs, typical usage patterns and the BOM itself.

Checks that every node has: (1) unit_type set to a valid Reference Unit, (2) sourcing_data with type ("manufactured"|"assembled"|"sourced") and the matching location field, (3) unit_weight_kg > 0 on all leaf nodes — except a leaf whose Reference Unit prices a process (kWh, MJ, hour, …), which must declare no mass at all. Returns a validation report with errors and warnings. Validates either a node array before it is saved with climatepoint_set_product_structure, or, with a product_id, an already-saved BOM.

Requires confirmation. auto_apply defaults to true; pass auto_apply=false in both calls to preview without persisting. A best whose dataset unit cannot price a leaf entered by mass (not kg, not per item, no conversion_factor; it would compile to 0) is held as needs_review unit_mismatch, and matches[].unit_compatible_candidate names the highest-ranked candidate whose unit can. Counts: matched is the number of leaves whose match was applied (0 when nothing was written, as in a preview or a timeout); held is the number held for review (matches[].needs_review set, no match bound); failed is the number that errored. Terminal statuses: needs_magnitude_check (matches applied), complete (holds persisted or empty tree), suggestions_only (auto_apply=false, nothing written), no_matches_applied (gate ran, nothing written).

For each manufactured node it suggests processes from the node's children, resolves each to an LCI activity (from the sources your plan is entitled to), and appends to manufacturing_process_data — it does NOT match material leaves or touch their match_data (climatepoint_match_raw_materials does that). Requires confirmation. auto_apply defaults to true; pass auto_apply=false in both calls to preview without persisting. Terminal statuses: complete (process entries persisted, or no manufactured nodes), suggestions_only (auto_apply=false — NOTHING was written), no_matches_applied (the apply gate ran but wrote nothing). These are terminal, not in-progress, statuses: there is nothing to poll, and repeating the call runs the AI matcher again. partial/failed are the error statuses; failed always carries isError and means nothing was persisted. One kind of partial DOES carry isError: a run that aborts before the write phase (for example the 90-second timeout) — nothing was persisted there either, and the confirmation token is spent. processes_added counts entries actually written; processes_suggested counts entries produced. auto_apply=false yields suggestions_only unless every node failed, which is failed. After a write (auto_apply) it also turns the assumption text on the variant's process and capital-goods entries into structured calculations and cites them; the response's calculations says what happened. This tool takes no sources: climatepoint_edit_process_entries and climatepoint_convert_assumptions apply them. Assumption text is turned into a structured calculation automatically, and an input variable is cited when the text names its source next to the value or the source is passed. A client document is citable once uploaded with climatepoint_upload_document, either named next to the value (e.g. "1.5 kW (Source: Supplier_TestReport.pdf, p. 3)") or passed in sources.

Requires confirmation. auto_apply defaults to true: top suggestions are written to component_nodes. A best whose dataset unit cannot price a leaf entered by mass (not kg, not per item, no conversion_factor; it would compile to 0) is held as needs_review unit_mismatch, and matches[].unit_compatible_candidate names the highest-ranked candidate whose unit can. Counts: matched is the number of leaves whose match was applied (0 when nothing was written, as in a preview or a timeout); held is the number held for review (matches[].needs_review set, no match bound); failed is the number that errored. Terminal statuses: needs_magnitude_check (matches applied), complete (holds persisted or empty tree), suggestions_only (auto_apply=false, nothing written), no_matches_applied (gate ran, nothing written).

Each suggestion is annotated with lci_source_id (pass it through to climatepoint_apply_match_by_id / climatepoint_apply_use_phase_match — ids from some sources 404 without it) and applyable_by_id (false = live-query source, persisted only by material matching — climatepoint_match_variant_materials or climatepoint_match_raw_materials — which re-derives its candidates).

Results are scoped to the sources your plan is entitled to (US LCI and openEPD on the free plan; more databases on paid plans) — the lci_source_id on each result names its source. Each result carries applyable_by_id: when it is false (live-query sources such as openEPD), apply_match_by_id refuses that activity; material matching (match_variant_materials or match_raw_materials, auto_apply: true) can persist an openEPD match by re-deriving the candidates — it may pick a different candidate, and that call is variant-wide, not a single-component apply of the searched dataset.

Correct mode: supply activity_id + reference_product_name (both required — reference product disambiguates co-product allocation) + override_reason; resolves the allocated factor, computes DQ, full-replaces the match, sets magnitude_check_status=corrected. Live-query sources (openEPD — search results flag these applyable_by_id:false) CANNOT be applied here; material matching (match_variant_materials or match_raw_materials, auto_apply: true) can persist one by re-deriving the candidates, and match_single_component is preview-only and never persists. Custom process mode: supply custom_process_id (instead of activity_id/reference_product_name/lci_source_id) + override_reason to bind one of the product company's custom processes (e.g. a supplier PCF/EPD factor; its lifecycle_category must be material_sourcing, manufacturing, or unset) to a material leaf; dq_assessment is not accepted in this mode, and the data-quality pedigree reads Pending because a custom process has no similarity score or dataset version (a manual DQ override can score it later). Confirm mode: omit activity_id/reference_product_name and set override_source=magnitude_confirmed to clear the pending flag without changing the match. Requires confirmation token.

Requires confirmation. Batch semantics: operations (1-50) are applied in order to the component as it is read, and written in ONE write behind ONE confirmation; if any operation is refused, nothing is written. Entries no operation names stay exactly as they are. At most one operation per entry. add: name, a source and either quantity or bound_node_id (a capital good always needs quantity); the server generates the entry id. A source is required on add: the tool never writes an unmatched entry. update: entry_id plus set { name, quantity, bound_node_id, conversion_factor, source, selection_method, assumptions, lifecycle_stage } and/or sources and/or ter_assessment; a source in set rebinds the entry to another dataset. remove: entry_id. lifecycle_stage (manufacturing entries only): material_sourcing reports the entry under Material Sourcing (A1-A2, scope 3), for a raw-material process such as smelting or refining; the default, component_manufacturing, reports it under Component Manufacturing. Not accepted for capital goods. Assumption text on an added or updated entry is turned into a structured calculation after the write (the response's calculations says what happened); pass sources (documents, citations or references) on an add or update to get its input values cited. Changing an entry's assumptions text keeps the calculation made for the old text as the superseded one. source is { lci_activity_id, reference_product_name, lci_source_id? } for an LCI dataset (ids from climatepoint_search_lci_datasets), or { custom_process_id } for one of the company's own factors (climatepoint_list_custom_processes, climatepoint_create_custom_process). Capital goods (array: "capital_goods"): quantity is the allocation quantity (stored as allocation_quantity); bound_node_id only chooses where the entry is shown; conversion_factor is not accepted; unbinding a capital good is not offered (use the whole-array writers climatepoint_update_component / climatepoint_update_variant_component). Manufacturing entries: a bound entry (bound_node_id) is sized as the part's kg divided by conversion_factor when the dataset unit is not kg, so binding an entry later via set.bound_node_id to a non-kg dataset needs set.conversion_factor. Technological representativeness (TeR) is scored by the server. ter_assessment is needed only once an earlier response in this session has reported a TeR fallback; until then the server scores TeR itself. A reported fallback is resolved by an update operation per named entry carrying only ter_assessment. ter (1-5), judged ONLY on technology: 1 = same process, same technology route, same product specification 2 = same process and technology route; generic or averaged rather than the specific product, or a different scale or technology generation within that route 3 = same process family, but a materially different formulation or a different technology route within it 4 = a related process standing in as a proxy: different technology, comparable function 5 = a different process used as a placeholder; representativeness not established Boundary: pigment, additive or colour differences within the same binder-and-carrier route stay at 2; a change of binder, carrier or cure mechanism is 3. Dataset age is not TeR; it is scored separately as TiR.

Requires confirmation. activity_name, unit, gwp (kg CO2e per one unit), citation and reference_year are all required: reference_year is the data year of the factor and feeds the temporal data-quality score, so a factor without one is refused. Duplicate rule: activity names are unique per company and geography, case-insensitively. Re-sending a factor with the same activity_name, unit, gwp and reference_year creates nothing and returns the existing row with duplicate: true. Any other existing factor of that name and geography (another letter case, or a different unit, gwp or reference_year) is an error naming the existing ids: bind one of them, or choose a different activity_name. "kWh" and "MJ" are case-sensitive; any other casing is rejected. gwp_fossil, gwp_biogenic and gwp_luluc optionally record the ISO 14067 split of gwp; they are stored as given, are not checked against gwp, and are not part of the duplicate rule (a duplicate returns the stored row, split included). A duplicate whose sent split differs from the stored one also carries split_not_applied.

Each row's id is what source.custom_process_id takes in climatepoint_edit_process_entries and what custom_process_id takes in climatepoint_apply_use_phase_match and climatepoint_apply_match_by_id (apply_match_by_id accepts a lifecycle_category of material_sourcing, manufacturing, or unset). Supports pagination via limit/offset and returns { total, has_more, rows }.

Fetches the product's component nodes, identifies which ones lack locations based on their sourcing_data.type, then suggests locations for them. Only returns suggestions for components that actually need them. Pass auto_apply:true to also write the resolved locations to component_nodes.sourcing_data (chunked, merge-preserved — never clobbers existing locations/location_source/location_confidence). Default auto_apply:false = preview-only (no writes). AI suggestions are non-deterministic: re-running auto_apply:true on a node that still has an absent sub-field can write a different location, so the tool is marked non-idempotent; re-running over fully-populated nodes is a no-op (the filter admits none).

Returns driving_km, maritime_km, air_km (great-circle air distance plus 95 km; port to port on a sea route, null when no sea distance resolved), route_mode, and fallback flags. Writes nothing: these distances are the distance_km values of climatepoint_configure_transport routes (air_km goes on a *_air leg).

Default recomputes ALL eligible nodes (repairs bad/mis-prefixed legs), except groups with hand-set legs (below). AIR FREIGHT: when a component looks like high-value electronics on a sea route, the call writes NOTHING and returns status workflow_step_required / reason transport_mode_decision_required with candidates (maritime_km, air_km, indicative_kg_co2e) and a candidates_digest. Air or sea for each candidate is the user's decision: transport_modes=[{component_id, group, mode}] carries their answers (component_id and group copied from each candidate), or accept_suggested_modes=true plus the echoed candidates_digest records that they accept all. Nothing is stored until every candidate is answered, so each call must resend every earlier transport_modes entry. HAND-SET LEGS: a group (mfg_vendor or vendor_user) holding any leg with a positive distance_km and a distance_source other than ai_generated or default is left exactly as it is (distances, endpoints, LCI match, even when both ends are the same place) and is listed in skipped_groups; only a transport_modes entry naming that group recomputes it, and only a group that travels can be named. Every leg climatepoint_configure_transport writes with a positive distance carries distance_source user_estimate; a leg hand-built with climatepoint_update_component counts as hand-set only when it is written with a positive distance_km and a distance_source other than ai_generated or default. AIR SHARE: a group that is not hand-set and holds an air share ({group}_air_share, the fraction of the shipment flown, set in the app) is recomputed as a split: its surface leg (sea, or road on a drivable route) and its *_air leg both get fresh distances from the same route, and the share is kept unchanged. It is never an air/sea candidate; only a transport_modes entry naming the group settles it to a single mode, which ends the share. Each such group is listed in air_share_groups; applied false means the route returned no air distance and the stored air leg has none, so the shipment is priced at 100% sea or road until the *_air leg is set. For every other group: one whose mode the user chose in transport_modes (mode_source user_override) keeps that mode on every re-run unless a transport_modes entry names that group, but its distance and legs are recomputed. A group with no journey (no vendor location, an invalid location, or both ends the same place) has its main legs reset to zero but KEEPS that mode on the zeroed leg, so a later run in which it travels again writes that chosen mode rather than the route default. Under TRACI 2.2 air is unavailable: no suggestions, and mode "air" is rejected. A group with no distance for its mode (answered or route default) is left unchanged and listed in skipped_groups. On timed_out, only_missing=true continues from where the run stopped. This is the one-call path once locations are resolved (climatepoint_suggest_transport); climatepoint_configure_transport is the manual single-leg override.

The typical end-to-end transport setup is climatepoint_calculate_transport (it resolves locations, calculates distances, and picks the right leg automatically). This tool computes no distances: each route carries distance_km (from climatepoint_calculate_distance for its origin→destination pair, once climatepoint_suggest_transport has resolved the locations) with the explicit leg key, and this tool persists it. To configure transport for a benchmark variant, pass that benchmark's variant_id — otherwise routes target the primary variant. Distribution and end-of-life distances are not set here: compile reads them from the variant's distribution_lanes and avg_eol_distance_km, which climatepoint_set_variant_distances writes. In a study whose system boundary prices supply-chain transport (Cradle-to-Grave or Cradle-to-Gate; an unset boundary counts as Cradle-to-Grave), a route that writes a positive distance_km to the root's vendor_user_road_destination or vendor_user_road_domestic, ending away from the company location, carries a warning: root vendor_user_* legs are inbound (supplier to company) in the builder and the ISO report, so shipping to customers belongs in distribution lanes (climatepoint_set_variant_distances). The warning never blocks the write.

Compile prices end-of-life transport ONLY from avg_eol_distance_km and distribution ONLY from distribution_lanes (or a legacy avg_user_distance_km, which this tool never writes), never from distance_km on a node's eol_transport or distribution_transport leg. Send either key or both; an omitted key is left as stored. For either key, null clears this variant's own value, so it inherits the product family's (benchmarks never inherit). variant_id defaults to the primary variant; pass a benchmark's variant_id to set its distances. END OF LIFE: avg_eol_distance_km is the average km to transport the product to an end-of-life facility; 0 records that there is no haul. The EOL row is priced with the eol_transport.lci_transport_match of the first top-level node that has one, else the lorry default. DISTRIBUTION: distribution_lanes replaces the variant's lanes whole; a stored lane you leave out is deleted. For a single distribution distance, send one lane with share 1. For several markets send one lane each: shares are fractions that sum to 1 (±0.001), at most 6 lanes, one main leg (distribution_maritime, distribution_air or distribution_road_domestic) per lane, plus optional distribution_road_origin and distribution_road_destination legs. lanes: [] records that this variant has no distribution. Distances come from climatepoint_calculate_distance: driving_km.direct on distribution_road_domestic, driving_km.origin_to_port on distribution_road_origin, driving_km.destination_to_port on distribution_road_destination, maritime_km on distribution_maritime, air_km on distribution_air. Send no dataset: this tool attaches each positive leg's default LCI match (a lorry located by the two-letter country code ending the leg's origin_location, or its destination_location on distribution_road_destination; container ship and aircraft at GLO) to a new or changed leg that keeps no stored match, so such a leg needs origin_location and destination_location ("City, CC"), except a re-sent builder manual leg (below). RE-SENDING LANES: a lane's id is at after.distribution_lanes.lanes[].id in this tool's response and at variant.distances.distribution_lanes.lanes[].id in climatepoint_get_variant_structure; a lane sent without id is new. A re-sent lane (same id) keeps a leg's stored match while its key and endpoints are unchanged (origin_location and destination_location; absent equals absent), even when its distance_km changes to another value above 0 (a leg changed to 0 km carries none), and a leg whose distance and endpoints are all unchanged is kept exactly as stored. An unchanged positive leg with no stored match stays without one; compile prices it with its mode's default factor. So does a builder manual leg (stored with no origin_location, no destination_location and no match) re-sent with a new distance_km and still neither endpoint, so it needs no endpoints; any other new or changed positive leg that keeps no stored match still needs both. A kept lane keeps its stored destination and rationale when you omit them; omitting them never clears them. Writing distribution_lanes, or null, also clears this variant's legacy avg_user_distance_km in the same write; the response reports a cleared value as cleared_avg_user_distance_km. Under TRACI 2.2 the call is refused when any written lane has a positive distribution_air leg, a re-sent stored one included, and the error names those lanes; use distribution_maritime or distribution_road_domestic instead. The response gives before, after and effective distances (effective is what compile will use after family inheritance; a leg shows its dataset by name only) and may carry warnings with code root_outbound_legs: in a study whose system boundary prices supply-chain transport (Cradle-to-Grave or Cradle-to-Gate; an unset boundary counts as Cradle-to-Grave), a root's outbound vendor_user legs would also be priced, so distribution would be counted twice.

Merges by exact product_name into the variant's use_phase_energy list; passing null for a carrier clears it (electricity becomes 0, fuel key is removed). Removes are exact-name only. Quantities are totals for one functional unit (see electricity_use_kWh_per_use). The response lists merge and duplicate-name warnings and plausibility warnings (unit-scale slips, implausible annual rates, a match with no quantity). Warnings are returned in this response only and never block the write.

items_md5 is the md5 of the whole stored use_phase_energy array.

Candidates come from climatepoint_match_single_component (lifecycle_context "use_phase"); the chosen candidate's id is activity_id, passed with its lci_source_id (ids from some sources are otherwise looked up in the wrong source). The response may carry unit_warning / cross_kind_warning — non-blocking, but review them. Or bind one of the company's own custom processes by passing custom_process_id instead of activity_id + reference_product_name (exactly one source; climatepoint_list_custom_processes / climatepoint_create_custom_process). A custom process of another company, or a deleted one, is refused. It is written exactly as the web app writes it: selected_<kind>_match, selected_<kind>_match_id, and merged by id into <kind>_matches. Custom-process responses may also carry category_warning; fuel binds may carry fuel_superseded_warning.

climatepoint_configure_use_phase, climatepoint_edit_process_entries and climatepoint_match_manufacturing_processes already do this for what they write; this tool covers the rest: calculations one of their responses reported as pending or failed with a next_step naming it, applying sources after the fact (targets[].sources: stored on the entry, and a current calculation is re-cited), with recite: true to re-cite current calculations whose inputs are still uncited (e.g. after a period when citations were unavailable, warning citations_unavailable), or to backfill a product. Without targets every assumption text of the product (or of variant_id) is in scope; targets (at most 50) narrows it to named entries. At most 25 texts are converted per call; when more remain the response carries next_cursor; each call with cursor set to it, unchanged, continues the run, which is done when no next_cursor is returned. Calculations an analyst made from older text are left alone and counted (stale_skipped); include_stale: true converts them too, replacing the analyst's work — the user's decision, so it always takes a confirmation (see below). Requires confirmation: the first call returns a preview with counts and a confirmation_token; a second call with the same arguments and confirm_token set to it runs the conversion. Under a session grant (climatepoint_authorize_gated_session) it runs without one, except with include_stale: true, which always needs a confirmation. The response is a summary of names, positions, counts and codes, never values. Assumption text is turned into a structured calculation automatically, and an input variable is cited when the text names its source next to the value or the source is passed. A client document is citable once uploaded with climatepoint_upload_document, either named next to the value (e.g. "1.5 kW (Source: Supplier_TestReport.pdf, p. 3)") or passed in sources.

Every target is validated before anything is written, all or nothing: the builder's own formula evaluator recomputes every block and each computed variable's value must equal what its formula gives; the result variable (the last computed variable of the last block) must equal the entry quantity (use phase: the field the item's branch reads, e.g. electricity_use_kWh_per_use; manufacturing: quantity; capital goods: allocation_quantity), or with set_quantity: true it becomes the quantity; every citationId must be in the product's citation library (climatepoint_add_citations). The calculation is stored marked generatedBy "analyst" and current for the entry's assumption text, so the automatic conversion leaves it alone until the text changes. calculation: null moves the stored calculation to superseded (the web app's undo copy). Two calls: without confirm_token it writes nothing and returns before, after, diff, current_md5 and a confirmation_token; confirm with the same arguments plus confirm_token and expected_md5 = current_md5. If an entry changed in between the call returns STATE_CHANGED and writes nothing. A saved response returns the read-back value, new_md5 and prior_value per target; undo by sending each target with restore = its prior_value and expected_md5 = new_md5.

Each row has its APA text and parts, plus cited_by (entries whose current calculation cites it, across every variant's use-phase items, manufacturing processes and capital goods), cited_by_superseded (the same over superseded calculations kept for undo) and custom_processes (custom processes pointing at it).

Idempotent: a citation whose apa_text, or whose url, is already in the library is returned as existing with its id instead of being duplicated, so the returned ids can go straight into calculation variables (climatepoint_set_calculations). Requires confirmation: the first call returns which would be new and a confirmation_token; a second call with the same arguments and confirm_token adds them. When every citation already exists it answers changed: false with their ids and no token. Under a session grant (climatepoint_authorize_gated_session) it runs without the confirmation.

Refuses the whole call (CITATION_IN_USE, with the citing entries counted across every variant) when a current calculation variable cites one or a custom process points at one, and (CITATION_NOT_FOUND) when an id is not in this product's library. Requires confirmation: the first call lists the rows and returns a confirmation_token; a second call with the same arguments and confirm_token removes them. Never covered by a session grant.

PRODUCT-WIDE when variant_id is omitted (affects all variants); VARIANT-SCOPED when variant_id is provided (only that variant's component_nodes are classified and persisted). In auto mode classifies waste, allocates treatments, and atomically persists results. In draft mode stops at draft for review via override tools. Requires confirm_token on first call (AI cost gate).

Computes preliminary_results across selected impact categories and stores them on the product. By default it also generates the product LCA report on first compile (when none exists) and preserves existing report text on recompiles; pass mode to override. Note: report generation is product-level and rebuilds the whole product report. Gated operation. On success, the response includes an lca_report_url (the user-facing report link) when a report exists; otherwise an lca_report_note explains how to create one. The call waits at most ~40 s for the compile (a regenerate_report compile can take ~150 s). A compile still running then returns status "running" (compilation_status "running") with started_at and a poll block; the compile is not cancelled and saves its results server-side. climatepoint_get_report reports its progress in compile_run ("running", or "finished" with result holding the response this call would have returned) and in compiled_at. While a compile for the product is running, a further confirmed call starts no second compile and returns the same running status (already_running: true). Enforces eleven hard pre-flight checks before compiling: (1) the variant must have a BoM; (2) the ROOT component must define lifetime output — initial_mass for a consumable root (auto-filled from the FU) or amortization params for a durable/reusable root; nested parts inherit and need none (climatepoint_set_lifetime_parameters sets the root's); (3) benchmark variants that exist need BoMs, unless acknowledge_benchmarks_skipped=true records that the user declined to build them; a product with NO benchmark variants at all (a non-comparative study) also needs acknowledge_benchmarks_skipped=true, recording that the user confirmed the study is non-comparative; (4) every leaf must carry a usable material LCI coefficient (set by climatepoint_match_variant_materials) OR pass acknowledge_materials_unmatched_skipped=true; (5) every matched leaf must resolve to a NONZERO Material Sourcing contribution — a leaf can pass check (4) and still compile to 0.00 kg CO2e from a missing/zero BOM weight, an explicitly-zero units count, a study/match method disagreement, an unconvertible match unit, or a genuinely-zero coefficient (the reported zero_reason points to climatepoint_update_component, climatepoint_compliance_check, or climatepoint_match_single_component) OR pass acknowledge_zero_contribution_skipped=true; (6) at least one component must have transport_data (written by climatepoint_calculate_transport or climatepoint_configure_transport); (7) every leaf must have eol_analysis_data (written by climatepoint_run_eol_workflow) OR pass acknowledge_eol_skipped=true; (8) every configured use-phase energy input must carry an LCI match OR pass acknowledge_use_phase_unmatched_skipped=true; (9) the product must have a committed functional unit (products.functionalUnit, committed by climatepoint_update_product_scope) — no acknowledgement bypasses this; (10) every root lifetime parameter value must be a finite number and their product > 0 — no acknowledgement bypasses this; (11) the root lifetime output unit must be the functional unit's unit OR pass acknowledge_fu_basis_mismatch=true, recording that the user accepted the basis (per-FU figures are the life-cycle total divided by the root lifetime output). Gates 4-8 apply only when the study system boundary includes the relevant stage. Two non-blocking distance_advisories may appear on the preview and the compile response: eol_distance_missing and distribution_missing (EOL or distribution transport would compile at 0 km); climatepoint_set_variant_distances sets those distances.

Defaults to JSON; pass response_format="markdown" for a human-readable table per variant. precision="full" returns totals unrounded (default rounds the total to 2 dp); include_line_items=true adds each variant's GWP line items as result values only (component_id, description, life_cycle_stage, kg_co2e rounded to 2 dp), never a quantity, unit or dataset, plus line_items_md5 over the unrounded values.

Product-level: rebuilds the WHOLE product report (all variants) and OVERWRITES existing report text and manual edits. Requires compiled LCA results — a product that has never compiled has none until climatepoint_calculate_variant_impact runs (it enforces the full pre-flight checks and auto-generates this report on first compile). Same compile as climatepoint_calculate_variant_impact with mode=regenerate_report. Gated operation (confirmation required). NOT the same as climatepoint_generate_report, which writes the legacy executive narrative. The recompile covers every included variant, so three of calculate_variant_impact's pre-flight checks run here: (9) the product must have a committed functional unit (products.functionalUnit, committed by climatepoint_update_product_scope) — no acknowledgement bypasses this; and on each variant's root, (10) every root lifetime parameter value must be a finite number and their product > 0 — no acknowledgement bypasses this; (11) the root lifetime output unit must be the functional unit's unit OR pass acknowledge_fu_basis_mismatch=true, recording that the user accepted the basis. When the study has ISO compliance enabled, the ISO study fields that print into the report are checked against the model (reason iso_methodology_review_required): methodology complete and study reasons non-empty — no acknowledgement bypasses this; the declared allocation matches the components' applied allocation, the characterisation label matches the compiled method, and the cut-off is within the framework's per-flow maximum — climatepoint_compliance_check action="set_methodology" fixes them, OR acknowledge_iso_methodology=true records that the user accepted the mismatch.

Report state is PRODUCT-level: it reads the ISO LCA report, falling back to the legacy executive report. Defaults to JSON; pass response_format="markdown" for a sectioned human-readable view. Returns a section index only; pass include_content=true for full section text (large). Also reports compile progress: compiled_at (when compiled results were last saved) and compile_run, the latest climatepoint_calculate_variant_impact compile this server started for the product (running, or finished with its result; kept 30 minutes). fields returns named stored values raw (unparsed) with an md5 each, e.g. reports.limitations as its stored text.

Rows are { kind: company_share | share_request, email_domain, permissions, created_at }, plus is_onboarding_grant on a company share and status, expires_at and requester_email_domain on a share request; summary counts each kind and the requests by status. Read-only.

High and Medium items print in the report; Low items are stored but not printed. mode "append" adds to the stored items (either stored shape is read), "replace" stores exactly the items sent (an empty list stores [], which the web app regenerates on its next open). Always stores a JSON array, each new item marked origin "analyst". Two calls: without confirm_token it writes nothing and returns before, after, diff, current_md5 and a confirmation_token; confirm with the same arguments plus confirm_token and expected_md5 = current_md5. If the stored value changed in between the call returns STATE_CHANGED and writes nothing. A saved response returns the read-back value, new_md5, prior_value and prior_md5; undo by calling with raw_value = prior_value and expected_md5 = new_md5. Refuses with NO_REPORT_ROW when the product has no reports row (it never inserts one).

Returns exists, title, body (markdown subset: headings, paragraphs, **bold**, *italic*, lists, pipe tables), include, updated_at, updated_by, content_hash, and prints (true only when an annex exists, include is true and the body is not blank). The body cites sources with [@<citation id>] markers (several as [@id1; @id2]); each id must be a row of the product's bibliography (product_citations). citations lists each cited id with resolved and its apa_text; unresolved_citation_ids are ids the export will refuse. A product with no report returns exists=false with a note to generate the report first. Write the annex with climatepoint_set_report_annex.

The report must already exist (climatepoint_generate_lca_report). Omitted fields keep their current value; a new annex needs body; include defaults to false for a new annex, and NOTHING PRINTS unless include is true (and the body is not blank). clear=true deletes the annex. Body is a markdown subset (headings, paragraphs, **bold**, *italic*, bulleted and numbered lists, pipe tables; no HTML, images or links). Cite sources with [@<citation id>] markers, several as [@id1; @id2]: ids come from the product's bibliography (product_citations); the export prints each as its Appendix C number, and refuses to render while any cited id is not in the bibliography (returned as unresolved_citation_ids). Confirmation required: the first call (no confirm_token) writes nothing and returns the before/after (title, include, body length, and the full new body), which the user reviews, and a confirmation_token; a second call with the same arguments and confirm_token saves it. If the annex changed in between (e.g. edited in the web app), the save is refused with ANNEX_CHANGED and a fresh preview. changed=false (no token) means the annex already holds these values.

Read-only: it stops before the PDF service, so it writes nothing and uses no PDF credit; charts are not drawn. Each call counts against the report service's ISO export rate limit. Sections are keyed by their printed number ("1", "4.1", "7.5.1"), "front" for the cover and contents, "appendices" and an appendix letter ("C"). sections narrows the output and the hits to those sections and their subsections; find counts each string (case-sensitive) and lists the sections it occurs in; offset and limit page the returned text, with next_offset while more remains. Returns template, report_profile, rendered_at, length, text or html, hits and sections_available.

Writes the legacy executive report. This is NOT the ISO LCA report: it never changes the ISO LCA report and does not satisfy the LCA report viewer. The ISO LCA report comes from climatepoint_generate_lca_report (or climatepoint_calculate_variant_impact, whose default mode generates it on first compile). Stored sales projections are required as a workflow-completeness guard because other reports and charts read them. climatepoint_set_projections stores them (climatepoint_upload_projections_file parses an uploaded file). Without stored projections the call fails with PROJECTIONS_REQUIRED unless allow_generic_market=true. The Market Modeling section always uses general industry estimates, not stored figures, so every successful response carries a warning explaining that it does not consume stored projections.

For stored projections that look wrong or are missing: basis carries the user's own reason (e.g. "those volumes are 10x too high, we ship about 5000 units a year") so the regeneration is grounded in their knowledge rather than a fresh estimate. This tool NEVER writes products.projections; climatepoint_set_projections persists a draft the user has verified.

Writes the round as a draft, with report_md: the write step, only once the analyst has seen the preview summary and approved it. Takes the same product_id, round and report_md as that preview, byte for byte, with its preview_token. It never sends the round to the client: the analyst previews and sends it in the app, from reviewUrl. Needs a standard plan. Only the owner of the product's company can call it.