Skip to main content
Glama

Stat Ee

by io.github.pipeworx-io

Stat Ee Find Table

stat_ee_find_table
Read-onlyIdempotent

Search Statistics Estonia (Statistikaamet) for ESTONIA official statistics tables by plain-English keyword — "average monthly wage", "population", "GDP", "unemployment", "consumer price index", "births", "exports". Returns each matching table with its full ready-to-use path, its English label chain (e.g. "Economy > Wages and salaries and labour costs > Wages and salaries"), and whether it is a folder or a table. START HERE for any question about Estonian data. Set fetch_latest:true to also return the most recent figures from the top-matching table in one call — useful for "what is the current X in Estonia" questions. Otherwise hand the returned path to table_meta, then query_table, to get the figures. Searches English labels, so English words find the table even though the path ids themselves are Estonian slugs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNoOptional sub-path to search under, e.g. "majandus" (Economy) or "rahvastik" (Population). Default searches the whole tree.
limitNoMax matches to return (default 25, max 100).
queryYesPlain-English words describing the statistic, e.g. "average monthly wage", "unemployment rate", "population by county". All words must appear somewhere in a match's label chain.
max_depthNoLevels of the subject tree to walk below the starting path (default 5, max 6). Tables sit 4-5 levels below the root.
fetch_latestNoWhen true and the top match is a queryable table (.px), automatically fetches the most recent period's data from that table and includes it as "latest_data" in the response. Use this when you want the actual figure ("what is the average monthly wage in Estonia?") rather than just discovering the table path. Default false.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed2 schema fields changed
    • changedInput schema / examples
      Previous value: -[
-  {
-    "query": "average monthly wage"
-  },
-  {
-    "query": "population"
-  },
-  {
-    "query": "unemployment"
-  },
-  {
-    "limit": 3,
-    "path": "majandus",
-    "query": "wage"
-  }
-]New value: +[
+  {
+    "fetch_latest": true,
+    "query": "average monthly wage"
+  },
+  {
+    "query": "population"
+  },
+  {
+    "fetch_latest": true,
+    "query": "unemployment"
+  },
+  {
+    "limit": 3,
+    "path": "majandus",
+    "query": "wage"
+  }
+]
    • addedInput schema / properties / fetch_latest
      Added value: +{
+  "description": "When true and the top match is a queryable table (.px), automatically fetches the most recent period's data from that table and includes it as \"latest_data\" in the response. Use this when you want the actual figure (\"what is the average monthly wage in Estonia?\") rather than just discovering the table path. Default false.",
+  "type": "boolean"
+}
  2. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
+  {
+    "query": "average monthly wage"
+  },
+  {
+    "query": "population"
+  },
+  {
+    "query": "unemployment"
+  },
+  {
+    "limit": 3,
+    "path": "majandus",
+    "query": "wage"
+  }
+]
  3. Added

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds valuable context: the tool returns label chains, indicates folder vs table, searches English labels while path ids are Estonian slugs, and explains the optional auto-fetch behavior of fetch_latest. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is information-dense but every sentence adds value: purpose, examples, return details, workflow guidance, and language quirk. It is front-loaded with the core purpose and logically structured, with no superfluous text.

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 no output schema, the description thoroughly explains what the tool returns (path, label chain, folder/table indicator) and how to use it in a broader workflow. It also covers edge concerns like language mismatches and optional parameters, making it sufficient for an agent to select and invoke the tool correctly.

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 coverage is 100%, so baseline is 3. The description adds value beyond the schema by providing concrete query examples, clarifying the meaning of 'path' with Estonian slug examples, and explaining the fetch_latest behavior in context ('what is the current X in Estonia'). This enhances parameter understanding beyond bare schema 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 the tool's function: 'Search Statistics Estonia (Statistikaamet) for ESTONIA official statistics tables by plain-English keyword'. It includes specific verbs and resources, and distinguishes itself from siblings by explicitly positioning it as the starting point and directing users to table_meta and query_table for subsequent steps.

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

Usage Guidelines5/5

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

The description provides explicit when-to-use guidance: 'START HERE for any question about Estonian data.' It also explains when to use fetch_latest (for actual figures) versus when to hand the path to table_meta/query_table. This directly addresses alternatives and workflows.

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

All Stat Ee toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation3/5

Most tools have fairly distinct action/resource targets and the descriptions carefully separate entry points like ask_pipeworx, deep_research, and ask_pipeworx_grounded. However, ask_pipeworx_beta is explicitly an identical clone of ask_pipeworx right now, and a few related pairs (ai_visibility_check vs scan_competitor_ai_presence, stat_ee_find_table fetch_latest vs estonia_average_wage) add ambiguity.

Naming Consistency3/5

Names are consistently lowercase snake_case and verb-led names like resolve_entity, query_table, and suggest_questions are clear. But the set mixes conventions: bare nouns (subjects, recall, forget), adjective-noun phrases (recent_alerts, recent_changes), no-verb names (estonia_average_wage, table_meta), and multiple prefixes (pipeworx_*, polymarket_*, stat_ee_*). It is readable but not a single predictable pattern.

Tool Count2/5

36 tools is well above the 15-tool threshold for a well-scoped server, and the set spans many unrelated domains: Estonian statistics, Pipeworx research, Polymarket betting, AI visibility, npm scanning, memory, and subscriptions. There is also clear redundancy (ask_pipeworx_beta duplicates ask_pipeworx, ai_visibility_check could be folded into scan_competitor_ai_presence). This feels scattered for a server named 'Stat Ee'.

Completeness4/5

For the broad data-research/agent-assistant purpose, key workflows are well covered: discovery/query/grounded/deep research, entity resolution/profile/compare/validate/recent changes, complete memory CRUD, subscription CRUD with alert feeds, and a full Polymarket edge/arb/fill-risk suite. The main gap is not missing operations within these workflows but rather the overall scope being too broad and unfocused.

Resources