EU compliance facts with sources: TED tender deadline changes, CBAM values, EU deadlines, EUDR scope
Scored across 17 tools
Most tools target clearly distinct resources or actions, such as CBAM defaults, EUDR scope, sanctions search, and trade quotas. The main ambiguity is the singular/plural pair eu_compliance_deadline vs. eu_compliance_deadlines and the related get/list patterns, though descriptions make the intended use understandable.
All names use snake_case and domain prefixes are applied consistently across CBAM, EUDR, EU, and sanctions tools. The only inconsistency is that some tools are noun phrases while others use get_/list_ verbs, but the set remains predictable and readable.
Seventeen tools is slightly heavy but reasonable for a multi-dataset regulatory intelligence API covering several distinct domains. Each tool appears to earn its place by exposing a specific dataset or lookup operation.
Core retrieval patterns are present for many datasets, including search, get-by-id, changes, and cursored polling. However, there are notable gaps such as no tool for current EU funding opportunities beyond changes, and no general TED tender search beyond watched-tender deadline changes.
The current CBAM certificate price used for cost estimates, with its official source. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds two useful facts beyond that: the result includes its official source, and the call is free (no credential or billing). It does not say how current the price is or how often it updates.
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 identifies the resource and the extra payload (source), plus a terse 'Free.' note. Slightly fragmentary at the end but every clause carries information.
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 must convey the return shape, and it does only partially: it names the price and its source, but not the unit, currency, or timestamp (e.g. EUR per tonne CO2e, as-of date), which matter for a price tool feeding cost estimates.
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?
The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No misleading parameter text is present.
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 resource (the current CBAM certificate price) and what it carries (official source). It is clearly distinct from siblings like cbam_default_values and cbam_countries, though it relies on the reader knowing what CBAM is rather than contrasting with those siblings 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?
The phrase 'used for cost estimates' implies the context of use, but there is no explicit when-to-use/when-not-to-use guidance and no named alternative among the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Countries of origin that have their own CBAM default values. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds useful context that the tool is free and that it returns only countries with their own default values, but it does not describe response format or ordering.
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?
The description is extremely concise and front-loaded. Every phrase contributes to defining the resource and its cost behavior.
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?
Given zero parameters, no output schema, and rich annotations, the description is nearly complete. It could explicitly say whether the result is a list of country names or codes, but the core scope is clear.
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?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics beyond confirming that this is a parameterless lookup.
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 clearly identifies the resource as countries of origin that have their own CBAM default values. It does not explicitly differentiate itself from the sibling cbam_default_values tool, but the scope is specific enough for an agent to infer a list of qualifying countries.
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 guidance on when to use this tool versus cbam_default_values or other CBAM siblings. The only hint is 'Free,' which is a cost note rather than usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The EU's official CBAM default embedded-emission values for a CN code, by country of origin and year, with the cost per tonne at the current certificate price and links to the implementing regulation. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| cn | Yes | CN code, 4 to 8 digits, e.g. 7208 or 25232900 | |
| year | No | Year, e.g. 2026 | |
| country | No | ISO country of origin, e.g. IN; omit for the 'other countries' value |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description goes further by disclosing the payload composition (default values plus a derived cost at the current certificate price plus regulation links) and that access is free — genuinely useful context beyond the structured fields. It stops short of noting what happens when no default exists for a code/country.
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 dense sentence that front-loads the resource and then appends output details, plus a one-word 'Free.' fragment. It is slightly run-on, but nothing is padded and the most important clause comes first.
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 must carry the return-value burden, and it does partially by naming values, cost per tonne and regulation links. It omits response format, units/precision, behaviour when defaults are unavailable, and any pagination, which leaves real gaps for a data-retrieval tool.
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 description coverage is 100%, including the non-obvious 'omit country for the other countries value' rule, so the schema does the heavy lifting. The description only restates the keys ('for a CN code, by country of origin and year') without adding format or fallback semantics. Baseline 3 is appropriate.
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 precise resource — CBAM default embedded-emission values for a CN code, keyed by country of origin and year — and adds what else the response carries (cost per tonne, regulation links). That distinguishes it implicitly from cbam_certificate_price (the price itself) and cbam_countries, though no sibling is named explicitly. Clear, but without the explicit differentiation a 5 requires.
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 statement of when to reach for this tool instead of cbam_certificate_price or cbam_countries, and no prerequisites or exclusions. 'Free' signals cost/entitlement, not usage context, so an agent gets no routing help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One deadline from eu_compliance_deadlines by its id, with its source and history. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Deadline id from eu_compliance_deadlines |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds value by disclosing that the response includes the deadline's source and history, plus that the call is free — behavioral facts not present in the structured fields.
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?
One sentence, front-loaded with the operation and resource, with no filler. Every clause (source collection, id lookup, returned contents, cost) earns its place.
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?
For a single-record lookup with no output schema, mentioning that source and history are returned covers the main return-shape gap, and annotations handle safety. It stops short of noting behavior on an unknown id, which is a minor omission for this complexity.
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 description coverage is 100% and the single id parameter is fully documented with its pattern and origin, so the schema does the heavy lifting. The description repeats 'by its id' and 'from eu_compliance_deadlines' without adding format or lookup semantics beyond the schema.
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 (fetch one) and resource (EU compliance deadline) and pins it to the source collection 'eu_compliance_deadlines', which implicitly distinguishes it from the plural list sibling. An agent can tell it is a single-record lookup by id without opening the schema.
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?
The 'by its id' phrasing implies the precondition that you must already have an id, and the reference to eu_compliance_deadlines hints at the list-then-detail flow. However, there is no explicit when-to-use/when-not guidance or named alternative for cases where the id is unknown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dated EU compliance deadlines (CBAM, EUDR and others), each with its legal source and days remaining. Filter by law, status or date range. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Latest date, YYYY-MM-DD | |
| law | No | Filter by law, e.g. CBAM or EUDR | |
| from | No | Earliest date, YYYY-MM-DD | |
| status | No | upcoming or applies |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and openWorld, so the safety profile is covered. The description adds that each entry carries a legal source and days remaining, and 'Free' signals no auth/payment requirement — useful context — but nothing about pagination or result volume.
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?
Three tight sentences: what it returns, how to filter, and cost. Front-loaded with the resource and payload, with no filler.
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?
For a zero-required-param, read-only listing tool with fully documented schema and annotations, the description covers payload shape and filtering adequately. The one omission is disambiguation from the singular sibling tool, which matters for correct tool selection.
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 description coverage is 100%, with formats (YYYY-MM-DD), enum values (upcoming/applies), and examples (CBAM, EUDR) all in the schema. The description restates the same filter set at a coarser level without adding syntax or edge-case semantics, so the baseline 3 applies.
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 resource (dated EU compliance deadlines) plus the returned fields (legal source, days remaining) and supported filters. It does not, however, distinguish itself from the near-identically named sibling 'eu_compliance_deadline' (singular), leaving ambiguity about list vs. single-deadline lookup.
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?
The description lists filter dimensions ('Filter by law, status or date range') but never says when to choose this tool over the singular sibling 'eu_compliance_deadline' or when not to use it. Usage is only implied by the plural 'deadlines' framing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
EU public contracts awarded, from official TED contract award notices: who won, the buyer, value, CPV codes, country, award and contract dates and lots, each with the notice link and a SHA-256 proof of the TED answer. Use since (YYYY-MM-DD) for new awards, and filter by CPV code or prefix, buyer country, or winner (company name prefix or official identifier) to answer "has company X won anything since D". Pass next_cursor back as cursor to page or to poll for awards stored since. Uses the free tier, or the caller's API key.
| Name | Required | Description | Default |
|---|---|---|---|
| cpv | No | CPV code or prefix, 2 to 8 digits, e.g. 72 for IT services; up to 5, comma-separated | |
| limit | No | Awards per page, 1 to 50 (default 20) | |
| since | No | Awards published on or after this date, YYYY-MM-DD (default: 7 days ago; about 45 days are kept) | |
| cursor | No | next_cursor from a previous answer | |
| winner | No | Winning company's name, or its beginning, e.g. Mennica Polska | |
| country | No | Buyer country, 3-letter ISO code as TED uses, e.g. DEU, FRA, POL | |
| winner_id | No | Winning company's official identifier as given in the notice, e.g. a VAT or company number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, open-world, idempotent and non-destructive, so the burden is lighter. The description adds real behavioral context beyond the schema: free tier vs. caller's API key for auth, a SHA-256 proof of the TED answer, and cursor-based polling semantics for newly stored awards.
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 dense paragraph that front-loads what the tool returns before covering filters and paging. Every sentence carries information, though the field enumeration in the opening clause is long and could be tightened.
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 takes on the job of describing return content — and does so (winner, buyer, value, CPV, dates, lots, notice link, proof hash). Combined with 7 fully documented parameters and rich annotations, the only missing piece is explicit differentiation from get_eu_contract_award.
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 100%, so the baseline is 3; the description's mapping of the "has company X won since D" question onto winner + since, and its explanation that winner means name prefix while winner_id means official identifier, add modest interpretive value. It does not add syntax detail beyond the schema, so it does not reach 5.
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 and resource — EU public contracts awarded from official TED contract award notices — and enumerates the fields returned (winner, buyer, value, CPV, country, dates, lots). It is clear what the tool does, but it never names the singular sibling get_eu_contract_award to say how listing differs from fetching one award.
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?
Gives concrete usage patterns: use since for new awards, filter by CPV/buyer country/winner to answer "has company X won anything since D", and pass next_cursor back as cursor to page or poll. This is strong contextual guidance, though there is no explicit when-not or pointer to a sibling alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The full list of products in scope of the EUDR (Annex I), with application dates and sources. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds useful context that the response is drawn from Annex I and includes application dates and sources, plus a cost note ('Free'), but says nothing about caching, freshness, or the shape of the returned list.
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 naming the scope and contents, with no filler. The trailing 'Free.' fragment is terse but carries real cost information for an agent deciding whether to call it.
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?
For a zero-argument, read-only reference lookup with no output schema, the description says enough: what the list is, its legal basis, and that it includes dates and sources. Nothing an agent needs in order to call it correctly is missing.
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?
The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The mention of application dates and sources usefully signals what fields the output carries even without an output schema.
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 resource (the Annex I list of EUDR in-scope products) and what the result contains (application dates and sources). It does not distinguish this from the sibling eudr_scope, so an agent must guess whether that tool is the per-product check versus this bulk list.
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?
No guidance on when to use this versus eudr_scope or eu_compliance_deadline(s), and no stated prerequisites. The agent is left to infer that this is a reference/lookup call rather than a scoped query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Whether a CN or HS code is in scope of the EU Deforestation Regulation (EUDR), which commodity it falls under, and when the rules apply, with sources. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| cn | Yes | CN or HS code, 4 to 8 digits, e.g. 0901 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds two useful behavioral facts — results come 'with sources' and the tool is 'Free' — but says nothing about result shape, latency, or data vintage.
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 dense sentence with no filler, and the core subject (CN/HS code scope) is front-loaded. The noun-clause phrasing ('Whether a CN or HS code is...') is slightly indirect for a tool description but wastes no words.
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?
For a one-parameter lookup with no output schema, the description enumerates what the agent will learn — in-scope status, commodity, applicability dates, sources — which is the right level of return-value signaling. Only the absence of usage/routing context keeps it short of full completeness.
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 description coverage is 100% for the single 'cn' parameter, so the schema already specifies format (4-8 digits, example 0901). The description only echoes that CN or HS codes are accepted, adding no syntax or validation detail beyond the schema; baseline 3 applies.
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 the specific resource (a CN/HS code) and the specific determination (EUDR scope, commodity classification, applicability timing, sources). It is clearly a lookup/check tool rather than a listing tool, though it never explicitly distinguishes itself from the sibling eudr_products.
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 is only implied: an agent can infer you call this when you have a CN/HS code and need its EUDR status. There is no statement of when not to use it, no prerequisites, and no routing guidance relative to eudr_products or the cbam_* siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Changes to open and forthcoming EU funding opportunities on the EU Funding & Tenders Portal (Horizon Europe, Digital Europe, CEF, LIFE, CERV and more): new calls, moved or added deadlines, status changes (forthcoming, open) and calls that closed or were withdrawn, each with the record before and after and a link to the official topic page. Pass next_cursor back as cursor to page or to poll. The portal is authoritative. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| field | No | Only changes to this field | |
| limit | No | Changes per page, 1 to 50 (default 20) | |
| since | No | Changes observed on or after this date, YYYY-MM-DD (default: 7 days ago) | |
| change | No | One kind of change only | |
| cursor | No | next_cursor from a previous answer | |
| identifier | No | Topic or call identifier, or its start, e.g. HORIZON-CL5-2026 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, open-world and non-destructive, so safety is covered. The description adds meaningful context beyond annotations: each change carries the record before and after, a link to the official topic page, and the source authority claim ('The portal is authoritative. Free.'). It does not describe result ordering or rate limits, keeping it below a 5.
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?
Purpose and coverage are front-loaded in the first sentence, followed by two short, useful sentences on polling and authority. The parenthetical programme list is dense but earns its place by defining scope; slightly long single sentence, but no filler.
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 must cover return values, and it does: before/after records, official page link, and next_cursor. For a six-parameter, filter-only read tool this is nearly complete; only ordering, deduplication and empty-result behavior are unstated.
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 100% with enum and range descriptions for field, change, limit, since and identifier, so the schema does the heavy lifting. The description only reinforces the cursor parameter's paging/polling role and adds no new meaning for the other filters; baseline 3 applies.
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+resource ('Changes to open and forthcoming EU funding opportunities') and enumerates the covered programmes and change types (new calls, moved/added deadlines, status changes, closures/withdrawals). This clearly separates it from siblings like get_tender_deadline_changes (tenders) and eu_contract_awards.
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?
It gives concrete usage guidance for paging/polling ('Pass next_cursor back as cursor to page or to poll'), which implies recurring polling is expected. However it never states when to prefer this over sibling deadline/change feeds such as get_tender_deadline_changes or eu_compliance_deadlines, so routing remains inferential.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
EU anti-dumping, countervailing and safeguard regulations as published in the Official Journal (from the Publications Office), each with the CN and TARIC codes found in its text, the countries of origin, the product, the action (provisional or definitive duty, amendment, extension, repeal, termination, registration, initiation) and the EUR-Lex link. Search by CN code (a regulation naming 7208 matches 72085120 and the reverse), date, instrument, action or country. Pass next_cursor back as cursor to page or to poll. Duty rates in force are in TARIC; the Official Journal is authoritative. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| cn | No | CN code, 4 to 10 digits, e.g. 7208 or 72085120 | |
| limit | No | Regulations per page, 1 to 50 (default 20) | |
| since | No | Regulations dated on or after, YYYY-MM-DD | |
| action | No | One kind of action only | |
| cursor | No | next_cursor from a previous answer | |
| country | No | Country of origin, e.g. China | |
| instrument | No | One instrument only (steel: acts under the EU steel regime, Regulation 2026/1384) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds non-obvious behaviour: bidirectional CN prefix matching ('a regulation naming 7208 matches 72085120 and the reverse'), cursor-based paging and polling, and the fact that access is free. Auth and rate-limit behaviour are not addressed, but that is a minor gap.
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 dense paragraph, front-loaded with what the tool returns before covering search axes and paging. Every sentence carries information, though the opening clause is long and packs multiple claims that could be split for faster scanning.
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, so the description usefully enumerates the returned fields (codes, origin countries, product, action, EUR-Lex link) and hints at the next_cursor field via the paging instruction. For a 7-parameter, 0-required filtering tool this is close to sufficient, missing only explicit default/sort behaviour.
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 baseline is 3 and the schema already documents all seven parameters including enum values. The description earns above baseline by explaining matching semantics for 'cn' (partial vs full code) and the pagination contract for 'cursor', neither of which the schema conveys.
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 resource (EU anti-dumping, countervailing and safeguard regulations from the Official Journal) and enumerates exactly what each result carries: CN/TARIC codes, countries of origin, product, action type and EUR-Lex link. An agent can distinguish this from eu_trade_quotas and the sanctions/cbam siblings without opening any schema.
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?
Gives concrete search axes ('Search by CN code, date, instrument, action or country') and operational instructions for pagination ('Pass next_cursor back as cursor to page or to poll'). It also clarifies the TARIC-vs-Official-Journal division of labour, but stops short of stating when this tool should not be used in favour of a sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tariff quotas set by EU trade measures, read from the Official Journal act's own tables: the steel regime's country quotas (Regulation 2026/1384, distributed by 2026/1457) and safeguard quotas such as ferro-alloys. Each row has the quota order number, product category, CN codes, country (or other countries), the volumes in tonnes per period, the out-of-quota duty and the act as proof. By default only the current row per order number; history=true adds rows later acts replaced. Quota balances are in TARIC; the Official Journal is authoritative. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| cn | No | CN code, 4 to 10 digits, e.g. 7208 or 72085120 | |
| celex | No | Only quotas from this act, e.g. 32026R1457 | |
| limit | No | Quotas per page, 1 to 50 (default 20) | |
| cursor | No | next_cursor from a previous answer | |
| country | No | Country, e.g. India or Türkiye | |
| history | No | Also rows replaced by later acts (default false) | |
| order_number | No | Quota order number, e.g. 09.9801 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, open-world. Beyond that, the description discloses the default current-row-per-order-number behavior, what history=true adds, the authority hierarchy versus TARIC, and that access is free — genuine context an agent would otherwise lack. Pagination semantics are left to the schema.
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?
Front-loaded with the resource and source, then returned fields, then default behavior, then sourcing caveat. Information-dense with little waste; the single-word 'Free.' is terse but earns its place as a cost signal.
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 carries the return-value burden and does so by enumerating the row fields (order number, category, CN codes, country, volumes, out-of-quota duty, act). Safety is covered by annotations. Only filter-combination behavior is left unaddressed, which is a minor residual gap.
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 description coverage is 100%, so the baseline is 3. The description adds modest meaning — units (tonnes per period), the 'other countries' residual grouping, and the history default — but no syntax or interaction rules for combining the four optional filters, so it does not exceed the schema meaningfully.
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 resource (EU tariff quotas), its source (the Official Journal act's own tables), and the two regimes covered (steel country quotas, safeguard quotas like ferro-alloys). It enumerates the returned fields, so an agent knows exactly what it gets. It does not explicitly name the nearest sibling, eu_trade_defence_measures, so the boundary with that tool must be inferred.
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?
"Quota balances are in TARIC; the Official Journal is authoritative" effectively excludes balance-lookup use cases, and the default/history behavior is spelled out. But there is no explicit statement of when to call this versus eu_trade_defence_measures or how filters (cn, country, celex) combine. 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.
One TED contract award notice by its publication number, with winners, buyer, value, CPV, dates, lots, the notice link and proof. Uses the free tier, or the caller's API key.
| Name | Required | Description | Default |
|---|---|---|---|
| notice_id | Yes | TED publication number, e.g. 718666-2026 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description still adds real context beyond them: the exact payload fields returned and the authentication/quota note that it 'uses the free tier, or the caller's API key.' It does not say what happens when the notice ID does not exist.
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 sentence with the identity of the resource front-loaded and the returned fields compressed into one list. No filler, no restatement of the title.
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 one fully documented required parameter, no output schema, and annotations carrying the behavioral profile, the description is nearly sufficient; listing the return fields is valuable precisely because no output schema exists. Missing only error/not-found behavior, which is minor for a single-record lookup.
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 100% and the notice_id parameter already carries a format pattern and an example, so the description's phrase 'publication number' adds little beyond it. Baseline 3 applies since the schema does the work.
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 and resource: fetch one TED contract award notice by its publication number, and enumerates what the record contains (winners, buyer, value, CPV, dates, lots, link, proof). The singular 'one ... notice' implicitly contrasts with the plural sibling eu_contract_awards, but the alternative is never named, so an agent must infer the distinction.
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?
'By its publication number' implies the caller must already hold a TED notice ID, which points toward use after a search, but the description never says when to prefer this over eu_contract_awards or what to do if only a keyword is available. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Observed submission-deadline changes, per lot, for a watched TED tender, with the old and new deadline (local and UTC) and links to both official notices. Also returns the current deadlines. Pass next_cursor or checkpoint_cursor back as cursor to page or to poll for new changes. Uses the free tier, or the caller's API key.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Changes per page, 1 to 50 (default 50) | |
| cursor | No | Optional cursor from a previous answer | |
| notice_id | Yes | TED publication number of the watched tender, e.g. 662865-2026 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, open-world and non-destructive behavior, so the bar is lower. The description adds real context beyond them: auth model (free tier or caller's API key), the notion that changes are 'observed' (polling semantics), and the returned cursor tokens used for subsequent calls.
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?
FRONT-loads purpose and payload before the operational cursor sentence; every sentence carries information. The cursor sentence packs two distinct tokens and two modes, which is slightly dense but not wasteful.
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 carries the return-value burden and does so: per-lot granularity, old and new deadlines in local and UTC, notice links, and current deadlines. Combined with annotations, an agent has everything needed to call it correctly.
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 100%, so the baseline is 3. The description goes further by clarifying that the returned next_cursor/checkpoint_cursor values map back onto the input 'cursor' parameter and that limit governs changes per page, adding meaning the schema alone does not convey.
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 and resource (observed submission-deadline changes, per lot, for a watched TED tender) and enumerates the returned payload (old/new deadline in local and UTC plus notice links). This clearly separates it from siblings like list_watched_tenders and eu_compliance_deadlines.
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?
Explains how to use the cursor for paging versus polling for new changes, which tells the agent the two consumption modes. It does not, however, state when to prefer this tool over siblings or what prerequisites (e.g. a watched tender) must hold, so exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The TED tenders Aurelmark watches for submission-deadline changes, with when each was last checked and whether its data is fresh. Free. To have a tender added, email the address in /docs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds genuinely non-structured context: this is a fixed, operator-curated watchlist that cannot be modified through the API, entries are annotated with last-checked and freshness state, and adding a tender requires contacting a human. That is real behavioral disclosure beyond the annotations.
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?
Three short sentences, all front-loaded and load-bearing: what the list is, what each entry contains, and the one thing an agent might otherwise try to attempt through the API. Nothing is wasted.
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 carries the burden of explaining return content, and it does so (tenders plus last-checked and freshness fields). It omits ordering, list size, and whether stale entries are still returned, which would matter for interpreting freshness output.
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?
The tool takes zero parameters, so the baseline is 4. The description adds no parameter meaning, but none is needed, and it correctly implies no filtering or pagination arguments exist.
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 resource — the TED tenders on Aurelmark's watchlist — and states what each entry carries (last-checked time, data freshness). It is clearly a read of a curated watchlist rather than a general tender search. It does not explicitly distinguish itself from the sibling get_tender_deadline_changes, which an agent could easily confuse this with.
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?
The mention that additions happen by emailing the address in /docs usefully tells the agent this list is read-only-with-an-out-of-band-write-path. However, there is no guidance on when to call this versus get_tender_deadline_changes, which is the natural alternative for deadline data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One current listing by list and id (as returned by sanctions_search or sanctions_list_changes), with proof of the file it came from. Uses the free tier, or the caller's API key.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The listing's id on that list, e.g. 36 or RUS0849 | |
| list | Yes | The list |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the bar is lower. The description still adds real value: results carry 'proof of the file it came from' (provenance of the underlying source document) and auth is disclosed ('free tier, or the caller's API key'), which is context annotations cannot express. It omits lookup-failure behavior for an unknown id.
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 sentence, front-loaded with the action and resource, then the parenthetical provenance of the id, then the operational note. Nothing is padded and no clause repeats the tool name or title.
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?
For a two-parameter read tool with full schema coverage and safety annotations, the description covers identity, source-of-id, provenance of output and auth tiers - enough to call it correctly. The one gap is that 'proof of the file' is never concretized (what field or document this yields) and there is no output schema to fall back on.
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 100% - both list (enum of four sources) and id (with pattern and example '36 or RUS0849') are fully documented in the schema. The description adds only the provenance constraint on where ids come from, which is already credited under usage. Baseline 3 is appropriate.
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 retrieval action ('One current listing'), the resource identity ('by list and id'), and adds the scope qualifier 'current'. It also names the producer tools (sanctions_search, sanctions_list_changes), so an agent can distinguish this from the search and change-feed siblings without opening a schema.
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?
By saying the id is 'as returned by sanctions_search or sanctions_list_changes', it implies the correct workflow order: search/list first, then fetch. It stops short of an explicit exclusion (e.g. what to do when you don't have an id, or that sanctions_search should be used for name lookups), so no full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Listings added to, amended on or removed from the US OFAC SDN and Consolidated lists, the UK Sanctions List and the EU Consolidated Financial Sanctions List, found by comparing each official file with the previous copy. Each change has the listing (names, aliases, type, programmes, countries, listing date), the fields that changed, and proof: the official file's URL, its SHA-256 and date. Pass next_cursor back as cursor to page or to poll. The official publication is authoritative. Uses the free tier, or the caller's API key.
| Name | Required | Description | Default |
|---|---|---|---|
| list | No | One list only | |
| limit | No | Changes per page, 1 to 50 (default 20) | |
| since | No | Changes observed on or after this date, YYYY-MM-DD (default: 7 days ago) | |
| change | No | One kind of change only | |
| cursor | No | next_cursor from a previous answer |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the safety annotations, the description discloses provenance and trust details: official files are compared to prior copies, each change includes the official URL, SHA-256, and date, and the publication is authoritative. It also explains pagination/polling and access via free tier or caller API key, adding substantial behavioral context.
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?
The purpose is front-loaded in the first sentence, and subsequent sentences add necessary return-record, pagination, authority, and auth details without repetition. Despite being information-dense, every sentence contributes useful context for invoking or interpreting the tool.
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, but the description adequately explains the returned change record: listing details, changed fields, and proof via official URL, SHA-256, and date. It also covers paging/polling and access modes, leaving little an agent needs to infer before calling the tool.
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 description coverage is 100%, so all five parameters are already documented in the schema. The description adds only that next_cursor can be passed back for paging or polling; it does not add new meaning for list, since, change, or limit beyond what the schema supplies.
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 states a precise resource and verb: listings added, amended, or removed from named sanctions lists, derived by comparing official files. It clearly implies a change-tracking function rather than a search, but it does not explicitly name sibling tools such as sanctions_search or sanctions_entry to sharpen differentiation.
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?
The description gives clear context for use: retrieve observed list changes, optionally paged or polled by passing next_cursor back as cursor. It does not state when to prefer this over sanctions_search or sanctions_entry, so the exclusion guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current listings on the US OFAC, UK and EU sanctions lists whose name or alias contains a word starting with the given text (case, accents and punctuation ignored). A lead for screening, not a match decision: confirm against the official list. Uses the free tier, or the caller's API key.
| Name | Required | Description | Default |
|---|---|---|---|
| list | No | One list only | |
| name | Yes | Name or its beginning, at least 3 letters, e.g. Rosneft | |
| limit | No | Matches, 1 to 50 (default 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real context beyond that: the matching rules (case, accents, punctuation ignored; word-prefix match), the free-tier vs caller-API-key auth behavior, and the caveat that hits are leads rather than confirmed matches.
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 sentences, both dense with information, with the matching rule and list scope front-loaded and the caveat/auth note trailing. No filler.
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?
All three parameters are documented and the tool's limitations are stated, which is enough to call it correctly. With no output schema, the description could have said more about what a returned hit looks like, but for a screening search the essential guidance is present.
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 100%, so the baseline is 3, but the description earns an extra point by explaining the matching semantics of `name` (word-prefix, accent/case/punctuation insensitive) and by scoping results to current listings. It does not clarify that `list` is optional or how omitting it behaves.
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 operation (search) against a specific resource (current US OFAC, UK and EU sanctions listings) with the matching rule spelled out. The word 'current' implicitly separates it from sanctions_list_changes and the search framing separates it from sanctions_entry, but no sibling is named outright.
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?
'A lead for screening, not a match decision: confirm against the official list' gives clear usage context and a hard constraint on how results may be used. It stops short of routing the agent to alternatives such as sanctions_entry for a specific record.
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.
eu_trade_defence_measures3 fields changedInput schema / properties / action / enumPrevious value: -[
- "provisional",
- "definitive",
- "amendment",
- "extension",
- "repeal",
- "termination",
- "registration",
- "initiation",
- "other"
-]New value: +[
+ "provisional",
+ "definitive",
+ "amendment",
+ "extension",
+ "repeal",
+ "termination",
+ "registration",
+ "initiation",
+ "quota",
+ "other"
+]Input schema / properties / instrument / descriptionPrevious value: -"One instrument only"New value: +"One instrument only (steel: acts under the EU steel regime, Regulation 2026/1384)"Input schema / properties / instrument / enumPrevious value: -[
- "anti-dumping",
- "countervailing",
- "safeguard"
-]New value: +[
+ "anti-dumping",
+ "countervailing",
+ "safeguard",
+ "steel"
+]eu_trade_quotaseu_trade_defence_measureseu_funding_changessanctions_entrysanctions_list_changessanctions_searcheu_contract_awardsget_eu_contract_awardcbam_certificate_pricecbam_countriescbam_default_valueseu_compliance_deadlineeu_compliance_deadlineseudr_productseudr_scopeget_tender_deadline_changeslist_watched_tendersEU/UK tenders, EU law, funding, medicines, drug shortages, recalls, sanctions, CVE, CERT, holidays.
UAE Corporate Tax, CSRD scope, EU AI Act risk class and CBAM cost, each line citing its source law
EU CBAM engine (Reg (EU) 2023/956): scope, default emissions, certificates and cost per CN code.
EU regulatory compliance data: 17 regulations, deadlines, enforcement actions. EU-hosted.
Add one secure layer between your agents and this server.