SiteCheck Trade & Energy

EU Taxonomy lookup from the European Commission's Taxonomy

energy_eu_csrd_taxonomy_aligned

Read-only

EU Taxonomy (Regulation 2020/852, used in CSRD reporting) lookup from the European Commission's Taxonomy Compass API: taxonomy-eligible activities by NACE code or keyword, with sector, NACE codes and environmental objectives; for one activity its substantial-contribution and do-no-significant-harm criteria as text. Activity rules only, not company disclosures. Related tools on this server, for a different need: logistics_eu_taric_consultation when you need EU import measures for a goods code from a given origin; energy_entsoe_transparency_eu when you need European electricity market: day-ahead spot prices. Price: $0.002 in USDC per successful call, paid with x402 (Base, Solana or Arc); failed calls are not charged.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "energy_eu_csrd_taxonomy_aligned"
  }
}

Input Schema

Name	Required	Description
`q`	No	Keyword in the activity name, e.g. solar, cement, hydrogen
`lang`	No	Language code, default en (24 EU languages)
`nace`	No	NACE Rev.2 code or prefix, e.g. D35.11, C23.51, F41
`objective`	No	Filter by objective: mitigation, adaptation, water, circular, pollution, biodiversity
`activityId`	No	Compass activity id (from a list result) to get its screening criteria

Output Schema

Name	Required	Description	Default
`count`	No
`query`	No
`source`	No
`checkedAt`	No
`activities`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds genuinely non-schema context: the upstream source (Compass API), the metered payment model ($0.002 USDC via x402 on Base, Solana or Arc) and the fact that failed calls are not charged. It does not mention pagination, result caps, or latency, which are the remaining operational unknowns for an open-world lookup.

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

Conciseness4/5

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

Front-loaded with the identity and capability, then scope limit, then sibling routing, then pricing — a sensible order. The middle sentence is long and stacks several clauses, but each part carries information an agent needs (source, return fields, scope boundary, cost), so there is little waste.

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?

An output schema exists, so return values need not be spelled out, yet the description still signals the key fields (sector, NACE codes, environmental objectives, criteria text). Combined with the disclosed data source, scope boundary and payment terms, an agent has enough to call it correctly; only edge-case behavior (empty results, combined-filter precedence) is unaddressed.

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 100% and every parameter (q, lang, nace, objective, activityId) is already documented with examples in the schema. The description adds only a light framing of the two modes — list by NACE/keyword versus detail by activityId — without explaining precedence when q, nace and objective are combined, so the baseline 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?

States a specific verb and resource (lookup of EU Taxonomy activities from the Commission's Taxonomy Compass API), names the regulation (2020/852) and the reporting regime (CSRD) it serves, and enumerates the two result shapes: eligible activities by NACE/keyword, or screening criteria for one activity. The closing scope line 'Activity rules only, not company disclosures' cleanly separates it from disclosure-oriented siblings like energy_sec_esg_climate_filings.

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?

Gives clear usage context (CSRD reporting, taxonomy eligibility and DNSH screening) and an explicit exclusion ('not company disclosures'), plus names two siblings with the condition that selects them (tariff measures, day-ahead power prices). It stops short of stating when to prefer the keyword path versus the NACE path, or what to do when no activity matches, so it is strong but not a full when/when-not/alternatives map.

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

All SiteCheck Trade & Energy tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?