Check whether CSRD applies after the 2026 simplification; read official VSME and ESRS disclosures.
Scored across 2 tools
The two tools have clearly distinct purposes: one determines reporting obligations and applicability, while the other retrieves the official text of a specific disclosure. There is no meaningful overlap that would cause misselection.
Both names follow a consistent snake_case verb_noun pattern: check_reporting_obligation and explain_disclosure. The convention is predictable and readable.
Two tools is thin for a rules domain that includes CSRD, VSME, BEGES, CO2-Prestatieladder, and multiple ESRS disclosures. The count is borderline rather than clearly mismatched, but the surface feels under-scoped.
The core workflows of checking obligation and retrieving a known disclosure are covered, but there is no way to list, search, or browse available disclosures, which creates a discovery gap. An agent must already know the exact code for explain_disclosure to be useful.
Checks whether CSRD reporting applies to a company after the 2026 EU simplification (or, for a company in France, under French law in force, with the French greenhouse gas report BEGES), whether the voluntary VSME standard and the value-chain cap are relevant, and whether the Dutch CO2-Prestatieladder matters. Uses headcount and turnover; no account needed.
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | nextCursor from an earlier result of this tool. | |
| listed | No | True when listed on an EU regulated market | |
| country | No | Two-letter country code, for example NL | |
| section | No | One part of a shortened result: a "$section" path from an earlier result of this tool, for example items/0/adoption. The other arguments stay as before, and cursor pages a long part. | |
| asked_by | No | Who is asking for sustainability information | |
| employees | Yes | Average number of employees of the group | |
| eu_parent | No | True when the group is headed in the EU (default true) | |
| turnover_eur | Yes | Annual net turnover of the group in euros | |
| employees_basis | No | How employees was counted (the French BEGES threshold counts full-time equivalents under C. trav. L1111-2) | |
| balance_sheet_eur | No | Balance-sheet total in euros (used by the French size test) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, non-destructive and closed-world, so the bar is lower; the description adds genuinely new facts — that it derives its answer from headcount and turnover and requires no account. It does not disclose what the result contains or how the jurisdiction options change the outcome, which would have pushed this higher.
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 that states the core purpose first before listing jurisdiction variants; every clause carries real information. It is dense and runs long, but there is no filler to cut.
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?
There is no output schema, and the description says nothing about what is returned — the shape is only hinted at by the schema's 'section' example (items/0/adoption) and 'cursor' paging. For a 10-parameter, multi-jurisdiction compliance tool, the agent is left guessing at the response structure.
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?
With 100% schema description coverage, the schema already documents all ten parameters, so the baseline of 3 applies. The description adds only that headcount and turnover drive the check, without explaining the roles of country, listed, asked_by, eu_parent or the cursor/section paging pair beyond what the schema says.
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 names a specific decision it makes (does CSRD reporting apply, post-2026 simplification) and enumerates the regimes it covers (French BEGES, VSME/value-chain cap, Dutch CO2-Prestatieladder). It is clearly about a compliance check, but it never names or distinguishes the sibling explain_disclosure, so the agent must infer the split.
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?
Usage context is implied ('Uses headcount and turnover; no account needed'), which tells the agent what inputs are needed and that no auth is required. But there is no explicit when-to-use/when-not guidance and no statement of how this differs from explain_disclosure, which is the obvious alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the official text of a disclosure in the EU voluntary standard for SMEs (VSME, B1-B11 and C1-C9) or in the ESRS (2026 edition, for example E1-8 or S1-5), with its EUR-Lex link. ESRS text is available in English, Dutch, German, French, Italian, Spanish and Polish.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Disclosure code, for example B3 or E1-8 | |
| cursor | No | nextCursor from an earlier result of this tool. | |
| section | No | One part of a shortened result: a "$section" path from an earlier result of this tool, for example items/0/adoption. The other arguments stay as before, and cursor pages a long part. | |
| language | No | The language the person writes in, for labels and headings, for example nl. Defaults to the AI app's locale, else English. | |
| standard | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive and closed-world, so the safety profile is covered. The description adds real behavioral detail - the return includes an EUR-Lex link and ESRS text exists in seven named languages (implying a language limitation on VSME). It does not disclose that results may be shortened and require the cursor/section continuation mechanism, which the schema hints at but never explains.
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 dense sentences with no filler: the what and the return payload come first, then the language availability constraint. Every clause carries information the agent needs.
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?
With no output schema, the description correctly states what comes back (official text plus EUR-Lex link) and which standards/codes are valid. The only gap is the shortened-result/pagination workflow, which an agent would only discover from the schema's 'section' and 'cursor' fields.
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 80%, so the baseline is 3; the description goes further by tying 'standard' values to concrete code families (VSME B1-B11/C1-C9 vs ESRS E1-8, S1-5) and by clarifying that the language list applies to ESRS text, which the 'language' schema entry does not state. It adds no interpretation of 'section' or 'cursor', which remain purely schema-documented.
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?
States a specific verb ('Returns the official text') and a precise resource (a disclosure in VSME B1-B11/C1-C9 or ESRS, e.g. E1-8), including the EUR-Lex link. The purpose is unambiguous and clearly distinct in kind from the sibling check_reporting_obligation, though the description never names that sibling to route the agent explicitly.
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?
There is no when-to-use/when-not guidance and no mention of the alternative tool. The reader must infer that this is for retrieving source text rather than for determining whether a disclosure is required; nothing states prerequisites or selection criteria.
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.
check_reporting_obligation3 fields changedInput schema / properties / balance_sheet_eurAdded value: +{
+ "description": "Balance-sheet total in euros (used by the French size test)",
+ "maximum": 10000000000000,
+ "minimum": 0,
+ "type": "number"
+}Input schema / properties / employees_basisAdded value: +{
+ "description": "How employees was counted (the French BEGES threshold counts full-time equivalents under C. trav. L1111-2)",
+ "enum": [
+ "headcount",
+ "fte",
+ "average"
+ ],
+ "type": "string"
+}Input schema / properties / listedAdded value: +{
+ "description": "True when listed on an EU regulated market",
+ "type": "boolean"
+}check_reporting_obligation1 field changedInput schema / properties / section / descriptionPrevious value: -"One part of a shortened result: a \"$section\" path from an earlier result of this tool, for example items/0/adoption. Pass the other arguments as before; page a long part with cursor."New value: +"One part of a shortened result: a \"$section\" path from an earlier result of this tool, for example items/0/adoption. The other arguments stay as before, and cursor pages a long part."explain_disclosure1 field changedInput schema / properties / section / descriptionPrevious value: -"One part of a shortened result: a \"$section\" path from an earlier result of this tool, for example items/0/adoption. Pass the other arguments as before; page a long part with cursor."New value: +"One part of a shortened result: a \"$section\" path from an earlier result of this tool, for example items/0/adoption. The other arguments stay as before, and cursor pages a long part."check_reporting_obligation2 fields changedInput schema / properties / cursorAdded value: +{
+ "description": "nextCursor from an earlier result of this tool.",
+ "maxLength": 8192,
+ "type": "string"
+}Input schema / properties / sectionAdded value: +{
+ "description": "One part of a shortened result: a \"$section\" path from an earlier result of this tool, for example items/0/adoption. Pass the other arguments as before; page a long part with cursor.",
+ "maxLength": 512,
+ "type": "string"
+}explain_disclosure2 fields changedInput schema / properties / cursorAdded value: +{
+ "description": "nextCursor from an earlier result of this tool.",
+ "maxLength": 8192,
+ "type": "string"
+}Input schema / properties / sectionAdded value: +{
+ "description": "One part of a shortened result: a \"$section\" path from an earlier result of this tool, for example items/0/adoption. Pass the other arguments as before; page a long part with cursor.",
+ "maxLength": 512,
+ "type": "string"
+}check_reporting_obligationexplain_disclosureYour carbon footprint, VSME and CSRD reports and climate plan, with the source of every figure.
UAE Corporate Tax, CSRD scope, EU AI Act risk class and CBAM cost, each line citing its source law
Deterministic, sourced EU compliance checks: NIS2, DORA, GDPR and the Cyber Resilience Act.
Vietnam GHG inventory obligation checker, 2026 regulations, CBAM and ESG articles (read-only).
Add one secure layer between your agents and this server.
