Ärikratt

Source metadata

source_metadata

Read-only

Licence, attribution and distribution evidence for one source. Authenticated, not metered; shares a 60-call bucket with describe_datasets, refilling at one call per second. Independent of daily call and company limits. Current policy checks differ from acquisition rights: unresolved means no retained grant evidence; retained_copy requires an older licensed copy. Includes exact recorded distribution URLs, acquisition/source clocks and transformation codes. Old snapshots return empty acquisitions. Truncated results include acquisitions_total. Use get_company for legal-entity figures. Do not look up natural persons.

Input Schema

Name	Required	Description	Default
`source_key`	No	Source key, e.g. stat, emta or ariregister	stat

Output Schema

Name	Required	Description
`as_of`	Yes
`sources`	Yes
`truncated`	No
`disclaimer`	Yes
`snapshot_id`	Yes
`acquisitions`	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.
`acquisitions_total`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 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 / key
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```

changedOutput schema / required

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

AddedOct 5, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well beyond the readOnly/non-destructive annotations: discloses authentication requirement, an unmetered but rate-limited profile (shared 60-call bucket, 1 call/sec refill), independence from daily/company limits, policy semantics (unresolved vs. retained_copy), old-snapshot empty-acquisition behavior, and truncation signaling. This is exactly the operational context annotations cannot carry.

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-loads the purpose, then proceeds through rate limits, semantics, caveats, and boundaries in a logical order. Dense, with almost every sentence carrying operational value; slightly burdensome reading but no clear waste.

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?

With an output schema present, the description needn't explain return values, yet it still flags the truncated-results indicator. It covers auth, rate limits, semantic ambiguity, boundary with get_company, and persona exclusion—nothing material is missing for correct invocation.

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?

The single source_key parameter has 100% schema description coverage including examples (stat, emta, ariregister). The description adds no additional parameter meaning, so 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?

Opens with a specific verb-and-resource framing: 'Licence, attribution and distribution evidence for one source.' This is clearly distinguishable from siblings like get_company and describe_datasets, which are named explicitly.

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 concrete routing rules: 'Use get_company for legal-entity figures' and 'Do not look up natural persons.' These establish boundaries and exclusions, though there is no explicit when-not-to-use list for this specific tool beyond those two carve-outs.

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?