Ärikratt

Funding overview

funding_overview

Read-only

European Union funding allocations from active source project-key records by period, fund and period, programme, implementing body and project region, plus the top 20 verified legal-entity beneficiaries. Private, redacted and unmatched recipients appear only in aggregates. Missing regions remain null; project geography is not legal seat. Intermediary status is unknown. Awarded support, project budget, co-financing and paid project costs have separate coverage counts; paid cost is not support paid; no absorption ratio is available. State Shared Service Centre (RTK) attribution accompanies results. Truncated lists retain totals; older snapshots return available=false. Use open_calls for opportunities or get_company for company grants. Do not look up natural persons.

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description
`as_of`	Yes
`funds`	No
`totals`	Yes
`periods`	No
`regions`	No
`sources`	Yes
`coverage`	No
`universe`	No
`available`	Yes
`truncated`	No
`absorption`	No
`disclaimer`	Yes
`programmes`	No
`funds_total`	No
`snapshot_id`	Yes
`beneficiaries`	No
`periods_total`	No
`regions_total`	No
`source_details`	Yes	Full attribution and acquisition evidence: source_metadata(key).
`omitted_sections`	No	Sections removed to fit the response budget, including default sections. Request one named section to retrieve it. Present only when truncated.
`programmes_total`	No
`absorption_reason`	No
`beneficiaries_total`	No
`implementing_bodies`	No
`implementing_bodies_total`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 18, 2026

addedOutput schema / properties / omitted_sections

Added value: +{
+  "description": "Sections removed to fit the response budget, including default sections. Request one named section to retrieve it. Present only when truncated.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / source_details

Added value: +{
+  "description": "Full attribution and acquisition evidence: source_metadata(key).",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / sources / items / properties / as_of
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
addedOutput schema / properties / sources / items / properties / key
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```

changedOutput schema / required

Previous value: -[
-  "snapshot_id",
-  "as_of",
-  "sources",
-  "disclaimer",
-  "available",
-  "totals"
-]New value: +[
+  "snapshot_id",
+  "as_of",
+  "sources",
+  "source_details",
+  "disclaimer",
+  "available",
+  "totals"
+]

AddedOct 5, 2026

TDQS

A4.3/5.0

Behavior5/5

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

With annotations already covering the read-only, non-destructive safety profile, the description adds unusually rich behavioral context: private/redacted recipients appear only in aggregates, missing regions stay null, project geography is not legal seat, paid cost is not support paid, intermediary status is unknown, truncated lists retain totals, and older snapshots return available=false.

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?

Purpose is front-loaded and almost every sentence carries a distinct caveat rather than filler, so the length is largely earned. However, the first sentence is an overloaded run-on and the caveats are delivered as an undifferentiated wall, which slightly hurts parseability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/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-value documentation is unnecessary, and the description still covers scope, aggregation keys, data-quality caveats, truncation behavior, stale-snapshot behavior, and sibling alternatives. Nothing an agent needs to call this correctly is missing.

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

Parameters4/5

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 and the description has no parameter semantics to add. Schema coverage is trivially 100%, and nothing in the description contradicts the empty argument object.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (European Union funding allocations) and the exact dimensions it aggregates by (period, fund, programme, implementing body, project region, top 20 beneficiaries). It is clearly distinguishable from data siblings, though the phrase 'by period, fund and period' is a redundant slip that slightly muddies the aggregation keys.

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?

It explicitly routes two cases: 'Use open_calls for opportunities or get_company for company grants' and adds a hard exclusion, 'Do not look up natural persons.' That is strong positive and negative guidance, but it does not say when this tool beats close statistical siblings like region_stats or sector_stats.

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

All Ärikratt 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?