Skip to main content
Glama
Sign In

Suomiatlas — Finnish area statistics

by com.suomiatlas
OverviewDiscussionsAdmin

Transit stops and services inside a Finnish postal area, or within a few km of it

get_nearby_places
Read-only

What is physically inside one Finnish postal area: public transport stops (bus, tram, metro, train, ferry) from Digitransit; daycare centres from the Suomi.fi service catalogue (PTV), with OpenStreetMap adding only those with no PTV daycare within 250 m; and schools, higher and further education, health clinics, pharmacies, supermarkets and libraries from OpenStreetMap; and swimming pools and beaches from LIPAS, the national register of sports facilities. Answers "what is there in Tikkurila?" or "is there a school in 99980?" with counts and names. With withinKm (up to 5) it also looks beyond the area: places within that straight-line distance of the area's boundary, nearest first per category with their distance — one call for "is there a pool or a beach near 00250?". Postal areas only; a city name returns its areas to choose from. Transit counts are platforms (most stops have one per direction); names groups platforms by stop name. A zero for an OpenStreetMap category means none is mapped there, not that none exists; a null count means that source has not been loaded; a null name is a place its source has no name for. This says nothing about travel times or service frequency. Licensed per source: the OpenStreetMap places and the daycare layer are ODbL 1.0, the pools and beaches CC BY 4.0; credit "© OpenStreetMap contributors", Digitransit, the Suomi.fi service catalogue and "Jyväskylän yliopisto, Lipas Liikuntapaikat.fi" when reproducing it.

Input Schema

NameRequiredDescriptionDefault
placeYesPostal area name or 5-digit code, e.g. "Tikkurila", "00530"
withinKmNoAlso look this many km beyond the area's boundary (straight-line, 0.1 to 5), and answer with the nearest places and their distance.
categoriesNoOnly these categories; defaults to all fourteen.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / place / description
      Previous value: -"Postal area name or 5-digit code, e.g. \"Kallio\", \"00530\""New value: +"Postal area name or 5-digit code, e.g. \"Tikkurila\", \"00530\""
  2. Changed1 schema field changed
    • addedInput schema / properties / withinKm
      Added value: +{
+  "description": "Also look this many km beyond the area's boundary (straight-line, 0.1 to 5), and answer with the nearest places and their distance.",
+  "maximum": 5,
+  "minimum": 0.1,
+  "type": "number"
+}
  3. Changed2 schema fields changed
    • changedInput schema / properties / categories / description
      Previous value: -"Only these categories; defaults to all twelve."New value: +"Only these categories; defaults to all fourteen."
    • changedInput schema / properties / categories / items / enum
      Previous value: -[
-  "bus",
-  "tram",
-  "metro",
-  "train",
-  "ferry",
-  "kindergarten",
-  "school",
-  "higher_education",
-  "health_clinic",
-  "pharmacy",
-  "supermarket",
-  "library"
-]New value: +[
+  "bus",
+  "tram",
+  "metro",
+  "train",
+  "ferry",
+  "kindergarten",
+  "school",
+  "higher_education",
+  "health_clinic",
+  "pharmacy",
+  "supermarket",
+  "library",
+  "swimming_pool",
+  "beach"
+]
  4. Changed2 schema fields changed
    • changedInput schema / properties / categories / description
      Previous value: -"Only these categories; defaults to all ten."New value: +"Only these categories; defaults to all twelve."
    • changedInput schema / properties / categories / items / enum
      Previous value: -[
-  "bus",
-  "tram",
-  "metro",
-  "train",
-  "ferry",
-  "kindergarten",
-  "school",
-  "health_clinic",
-  "pharmacy",
-  "supermarket"
-]New value: +[
+  "bus",
+  "tram",
+  "metro",
+  "train",
+  "ferry",
+  "kindergarten",
+  "school",
+  "higher_education",
+  "health_clinic",
+  "pharmacy",
+  "supermarket",
+  "library"
+]
  5. Added

TDQS

A4.6/5.0
Behavior5/5

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

With readOnlyHint/openWorldHint already covering safety, the description still adds substantial non-obvious behavior: source-by-source provenance, the 250 m OSM/PTV daycare deduplication rule, platform-vs-stop counting with the `names` grouping, and the crucial semantic distinction that a zero means 'not mapped' while null means 'source not loaded'. Licensing/attribution obligations are also disclosed. This is far beyond what annotations provide.

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 core scope statement, sources, and example queries are front-loaded, and each later sentence (null/zero semantics, platform counting, licensing) carries distinct operational or legal information. It is dense and long, but almost nothing is filler; slight deduction for the run-on enumeration of categories and sources in the opening sentence.

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?

No output schema exists, and the description compensates fully: it explains the return shape (counts and names), the ordering under `withinKm` (nearest first per category with distance), and the meaning of null/zero values. An agent has everything needed to call and interpret results 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 the baseline is 3, but the description adds real meaning: `withinKm` yields 'nearest first per category with their distance', `categories` defaults to all fourteen, and `names` groups platforms by stop name. It goes beyond restating the schema fields.

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+resource scope: 'What is physically inside one Finnish postal area', then enumerates the exact category set and the data sources behind each. This is clearly distinguishable from siblings like compare_areas, rank_areas, or get_area_report, which operate on aggregates rather than physical proximity listings.

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 usage scenarios ('what is there in Tikkurila?', 'is there a school in 99980?', 'is there a pool or a beach near 00250?') and states the `withinKm` trigger for beyond-boundary searches. Also sets a hard boundary: 'Postal areas only; a city name returns its areas to choose from' and excludes travel times/frequency. It stops short of naming which sibling to use instead for comparisons or rankings.

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

All Suomiatlas — Finnish area statistics toolsInspect
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