Skip to main content
Glama

get_network_stats

Read-only

Get the network-level statistics

How the whole network moves: Movers (AP) and Movers (SMP), Cross-border moves, Bulk moves, Joiners, Leavers and Net growth, the Leaver rate (annualized), Concentration (AP) and Concentration (SMP) (HHI, top 5, top 10), Concentration per country, Foreign-served participants and penetration. Each flow statistic gives its count over the last 7 and 30 days, the 7-day mean and the change against the period before.

Every rate is of the registered-participant count at the START of its period (base, the end of base_day) and is returned beside its absolute count. A day with no completed change scan is a gap: gap_days counts them, and moves found after a gap are counted on the next scan day. A 7-day mean is the mean over the scanned days of its window; a gap day is in neither the sum nor the divisor, and a window of gap days only has no mean (null). The series starts 2026-08-02; a window that would open earlier is clamped to it. as_of is the last complete UTC day and every flow period ends there. Concentration, Foreign-served participants and penetration are snapshots: each is the latest stored value and carries its own day, which can be one day after as_of.

concentration_by_country gives, per country, how the Peppol IDs of that country are shared over the providers that serve it: the HHI, the effective number of providers (10000 / HHI), the largest provider with its share, the top-4 and top-10 shares and the number of providers above 1%. The basis is the provider rosters (certificate seats); Vendors are not counted. Only a country with 8 or more providers is returned.

The headline numbers are free. The organic/bulk split, the cross-border split, the bulk share, penetration and the 30-day trends are returned for a Market key only (see x-required-tier on the fields); the body is private to the caller.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.9/5.0
Behavior5/5

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

readOnlyHint=true already covers the safety profile, and the description adds substantial context beyond it: tier/auth gating ('returned for a Market key only', body private to the caller), gap-day handling for scans, series clamping at 2026-08-02, snapshot-vs-flow semantics, and the 8-provider country cutoff. These are exactly the operational caveats an agent needs before interpreting results.

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?

It is front-loaded (headline purpose first, then flow definitions, then rate/base semantics, then snapshots, then country detail, then tier gating), and every sentence carries data-interpretation content. It is dense and long for a no-parameter tool, but the length is largely justified by the absence of an output schema, so it stops short of 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 no output schema, the description must carry the entire return-value burden, and it does: it names the fields, explains how rates are based, defines gap_days, describes concentration_by_country composition, and flags which fields need a Market key. Nothing an agent needs to call and interpret this zero-arg tool 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 no parameters (0 count, 100% coverage), so there is nothing for the description to disambiguate. Baseline 4 applies; the description appropriately spends its words on return semantics instead.

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 opening sentence states a specific verb+resource ('Get the network-level statistics') and then enumerates the exact metrics returned (movers, cross-border, bulk, joiners/leavers, concentration, penetration). It is unambiguous about what it produces. However, it never distinguishes itself from close siblings like get_network_summary, get_network_history, or get_network_stats_history, so an agent cannot tell from the description alone which of these overlapping network-level tools to pick.

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

Usage Guidelines2/5

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

There is no explicit when-to-use guidance and no mention of alternatives or exclusions relative to the many sibling stats tools. The only routing-adjacent content is the tier note ('returned for a Market key only') and the country-provider threshold, which constrain output rather than tell the agent when this tool is the right choice.

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.

Resources