Skip to main content
Glama

macro_snapshot

Macro economic snapshot API — dated Eurozone economic indicators for trading/research agents: euro-area inflation (HICP / CPI), ECB policy interest rates (deposit, refi), unemployment and EUR FX from the official European Central Bank data portal — each indicator with value, as_of date, next_release cadence and a signed dated snapshot receipt for reproducible backtests. The interest-rate, inflation and currency context an agent needs before trading. Price: $0.005 per call (x402 payment, USDC on Base mainnet).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
areaNoHICP reference area: 'U2' (euro area, default) or a country code e.g. 'FR','DE'
indicatorsNoComma-separated: inflation_hicp, core_inflation, unemployment, deposit_facility_rate, main_refi_rate, marginal_lending_rate, fx_usd, fx_gbp, fx_jpy, fx_chf

TDQS

A4.2/5.0
Behavior4/5

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

No annotations provided, so the description carries full burden. It details what the tool returns (value, as_of date, next_release cadence, receipt) and mentions pricing and payment method. This gives sufficient transparency for a read-only data retrieval tool.

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?

The description is detailed (5 sentences) but efficient, front-loading the core purpose. Every sentence adds value; could be slightly shorter but no unnecessary fluff.

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?

Given only 2 parameters with full schema coverage and no output schema, the description thoroughly explains the output structure (value, as_of, next_release, receipt). No gaps in understanding what the tool returns.

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?

Schema description coverage is 100%, but the description adds context: area default 'U2' and lists exact indicator names (e.g., 'deposit_facility_rate'). This goes beyond the schema's generic descriptions.

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?

The description clearly states it's a 'Macro economic snapshot API' for Eurozone indicators, listing specific data points (HICP, ECB rates, unemployment, EUR FX) and source (ECB). It differentiates from siblings like ecb_exchange_rate by covering a broader set of indicators.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description targets 'trading/research agents' and mentions context needed before trading, but does not explicitly state when to use versus alternatives (e.g., ecb_exchange_rate for just FX). No exclusions or when-not-to-use guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.5/5.0
Disambiguation4/5

Most tools have distinct purposes with detailed descriptions. However, there are clusters of similar tools (e.g., multiple token safety and pre-trade verdict tools for different chains) that could cause confusion, though descriptions help differentiate.

Naming Consistency5/5

All tool names follow a consistent pattern of lowercase snake_case with descriptive prefixes (e.g., agent_, crypto_, x402_). No mixing of conventions or ambiguous names.

Tool Count2/5

52 tools is excessive for a single server, covering a wide range of unrelated domains (crypto, legal, climate, transport, etc.). This overwhelms an agent and suggests a lack of focus.

Completeness2/5

The server lacks a coherent domain; it offers one-off tools across many areas but misses fundamental operations for any specific domain (e.g., no company registry for US, no order placement for crypto). Significant gaps exist.

Resources