← MSCI ConnectorCONTENT HISTORY

Update to MSCI Connector

Snapshot Sep 30, 2026 · 22:51 UTC · version 8.0.0

Collection source: not recorded for this historical snapshot.

WHAT CHANGED · RULE-BASED ANALYSIS

First saved snapshot

No earlier snapshot is available to establish a change.

Compare saved observations

Download comparison JSON
Full technical diff · 0 changed fields
Full snapshot data
{
  "description": "Use this skill for MSCI climate and regulatory sustainability metrics at index/security level, including Weighted Average Carbon Intensity (WACI), Implied Temperature Rise (ITR), carbon footprinting, Climate VaR physical/transition risk, SFDR principal adverse impact indicators, and EU Taxonomy alignment. Also use it to show how a climate or sustainability screen — PAB, CTB, SRI, or a low-carbon or screened variant — reshapes an index against its parent. Always pair metrics with available coverage fields.",
  "included_files": [],
  "name": "climate",
  "skill_md_contents": "---\nname: climate\ndescription: >-\n  Use this skill for MSCI climate and regulatory sustainability metrics at index/security level, including Weighted Average Carbon Intensity (WACI), Implied Temperature Rise (ITR), carbon footprinting, Climate VaR physical/transition risk, SFDR principal adverse impact indicators, and EU Taxonomy alignment. Also use it to show how a climate or sustainability screen — PAB, CTB, SRI, or a low-carbon or screened variant — reshapes an index against its parent. Always pair metrics with available coverage fields.\n---\n\n# Climate and regulatory sustainability metrics\n\nReport climate/sustainability metrics with coverage, units, date, and definition. Coverage is part of the result, not optional metadata.\n\n## Output\n\nFor each metric show: metric name, value, unit, coverage, as-of/fetched date, and index/security identity. Spell out WACI on first use. Describe Climate VaR as modelled scenario impact, not realized loss.\n\n## Workflow\n\n1. Resolve the index with `search_index_indexes`, or the security with `search_index_securities` for security-level questions.\n2. Discover the exact metric with `search_index_datapoints`; do not construct ids from naming patterns.\n3. When discovery returns an equivalent `imx` metric for an **equity index-level** analytic, prefer `calculate_metrics`. Otherwise use the catalog datapoint route.\n4. Discover and fetch the metric's `cov_*` or other documented coverage counterpart whenever available. Do not report a coverage-sensitive climate/SFDR metric without its coverage field if the catalog provides one.\n5. For catalog data: `fetch_index_data` for point-in-time; `fetch_index_timeseries` for supported history.\n6. Read `constraints.notes`, variant/currency requirements, and date availability. Sustainability data can be end-of-month; if a request snaps, report the effective fetched date.\n\n## Interpretation\n\n- State the exact currency/denominator basis for WACI or carbon metrics when returned by the catalog.\n- Use the returned metric definition/formula to distinguish similarly named carbon metrics.\n- EU Taxonomy nuclear and gas components should remain separate unless the returned methodology explicitly defines an aggregate the user requested.\n- Climate VaR is model-based and scenario-dependent.\n- Implied Temperature Rise is a forward-looking modelled alignment estimate in degrees Celsius, not a realised or measured temperature. Report the model basis and date returned by discovery, and never present ITR as a carbon intensity or convert between the two.\n\n## Screened index versus parent\n\nFor \"how does the PAB/CTB/SRI version differ from the parent\", or \"what does this screen change\":\n\n1. Resolve both the screened index and its parent with `search_index_indexes`. Do not infer the parent from the name — confirm it, or ask.\n2. Report the same metric id, currency, and date for both, following the `compare` alignment contract.\n3. Give the metric difference first, then the compositional reason where the data supports it — for example excluded constituents or changed sector weights from `composition`.\n4. For the governing exclusion rule or threshold itself, hand off to `methodology`. Do not infer a screen's rule from the metric gap.\n\n## Guardrails\n\n- Never omit available coverage.\n- Do not imply regulatory disclosure sign-off; the data supports disclosure but does not replace the user's reporting methodology and controls.\n- Missing coverage/data is a limitation, not zero exposure.\n"
}

SHA-256 of public snapshot: d570cedcc04b130066cefa2e022801638ca0fafcf879403342eea02f86e2aa35