Skip to main content
Glama

csrd_scope

Determine whether an undertaking falls within the EU CSRD scope per financial year, returning in-scope status, first reporting year, and cited article rules.

Instructions

Applies the EU-directive scope rules of CSRD sustainability reporting to the facts given and reports, per financial year, whether the rules reach the undertaking: Directive 2013/34/EU (Arts. 1, 2, 3, 19a, 29a, 40a) as amended by Directive (EU) 2026/470 and the application dates of Art. 5(2) Directive (EU) 2022/2464 as amended by Directives (EU) 2025/794 and 2026/470 (consolidated versions of 18 March 2026). Amounts in EUR only (never converted); employees are the average number during the financial year. Returns in_scope (yes/no/depends for the latest financial year assessed), first_reporting_financial_year (with where the report is published), one result per financial year from FY2024, the rules applied with article citations and quoted provisions, questions_for_counsel where national law or legal judgement decides, facts_needed, notified national measures for member_state, and legal_basis_version (CELEX, consolidated version dates, date checked). EU-directive level only, not legal advice; no network access. Later figures repeat the latest year unless assume_latest_figures_continue is false.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNo
currencyYesMust be EUR: convert other currencies yourself and state the EUR figures.
entity_typeNoCredit institutions and insurance undertakings are covered in any legal form; AIFs and UCITS are excluded.
member_stateNoTwo-letter code of the EU Member State (e.g. DE, FR, EL); used for notified national measures and Annex I/II legal forms.
designated_pieNoDesignated a public-interest entity by its Member State (Art. 2(1)(d)).
eu_undertakingYesTrue if governed by the law of an EU Member State; false for a third-country undertaking.
financial_yearsYesOne entry per financial year. Give the year before the first year of interest too: Art. 3(10) compares two years.
parent_undertakingNoParent of a group; give group_* figures.
financial_year_starts_onNoMM-DD, default 01-01.
legal_form_in_annex_i_or_iiNoEU undertakings: true if the legal form is listed in Annex I or II (e.g. AG, GmbH, SA, SARL, BV, NV, S.p.A.); null if unknown (call sources with member_state to see the list).
financial_holding_undertakingNo
listed_on_eu_regulated_marketNoTransferable securities admitted to trading on an EU regulated market.
assume_latest_figures_continueNoDefault true.
member_state_exemption_2025_2026NoThe Member State used the option of Art. 5(2) fifth subparagraph Directive (EU) 2022/2464 for this undertaking (FY2025-FY2026); null if unknown.
only_debt_securities_min_denomination_eur_100000No
covered_by_parent_consolidated_sustainability_reportNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does so well: EUR-only with no conversion, employees as financial-year average, the 'later figures repeat the latest year unless assume_latest_figures_continue is false' rule, questions_for_counsel escalation, and no network access. It stops short of describing error handling or the full response shape, so 4 rather than 5.

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?

It is front-loaded with the purpose, which is good, but the remainder is a single dense paragraph stuffed with statutory citations and parentheticals that are not needed for tool selection. Every element is arguably relevant to a legal-audit tool, but the lack of structure hurts 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 16-parameter legal tool with no output schema, the description compensates by enumerating the return fields (in_scope, first_reporting_financial_year, per-year results, rules applied with citations, questions_for_counsel, facts_needed, legal_basis_version). It is close to complete, missing only a fuller description of edge-case outputs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 75%, so the schema already explains most inputs (entity_type, member_state, financial_years, etc.). The description only restates a couple of those semantics (EUR-only, average employees) and adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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 states a precise verb+resource: it applies CSRD EU-directive scope rules to given facts and reports, per financial year, whether the rules reach the undertaking. It names the governing directives and even points to a sibling (call sources with member_state), so an agent can tell what it does and where to go for the legal-form list.

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?

It conveys scope boundaries (EU-directive level only, not legal advice, no network access) and a default behavior for repeated figures, but gives no explicit when-to-use vs the siblings timeline, thresholds, or sources. Usage is implied rather than directed.

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

Deploy Server

Other Tools