Skip to main content
Glama

Expat Living Italy

What is missing, by dataset

get_coverage
Read-onlyIdempotent

For every dataset: how many places it covers, out of how many at its grain, plus the source's own coverage caveat. Pass dataset (a slug from list_datasets) to list the places that dataset lacks, with the gaps by region. Use it before telling anyone data does not exist for a place, and to explain a null. Missing means no figure, never a zero. Keys a source publishes that match no current place (a superseded province code) are reported and never mapped onto a current place. Drafts are listed as not served, without counts.

Input Schema

NameRequiredDescriptionDefault
limitNoMissing places per page when dataset is given, 1–100. Default 50.
offsetNoMissing places to skip, for the next page.
datasetNoA dataset slug from /datasets. Omit it for the summary of every dataset; pass it to list the places that dataset lacks.

Output Schema

NameRequiredDescriptionDefault
datasetsYes
attributionYes
missingPlacesNoPresent only when `dataset` was given and it has missing places.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedOutput schema / properties / attribution / properties / license
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "License of Expat Living Italy's own work only; upstream data keeps its own license, per dataset.",
      +  "properties": {
      +    "name": {
      +      "type": "string"
      +    },
      +    "url": {
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "name",
      +    "url"
      +  ],
      +  "type": "object"
      +}
    • changedOutput schema / properties / attribution / required
      Previous value: -[
      -  "publisher",
      -  "url",
      -  "citeAs",
      -  "request"
      -]New value: +[
      +  "publisher",
      +  "url",
      +  "citeAs",
      +  "request",
      +  "license"
      +]
  2. Added

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, it discloses non-obvious domain semantics: missing means no figure and never a zero, superseded source codes are reported but never mapped onto a current place, and drafts appear as not served without counts. These are exactly the behaviours an agent could otherwise misreport.

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 summary mode is front-loaded, followed by the optional mode and then the rule-based caveats; nearly every sentence carries distinct information. Some sentences are dense and stacked ('Missing means no figure, never a zero. Keys a source publishes that match no current place...'), but nothing is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return shape need not be explained; the description covers mode switching, the missing-vs-zero distinction, unmapped codes, and drafts, which is enough to call it correctly. Only the meaning of 'at its grain' is left as unexplained jargon.

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 schema documents limit/offset ranges and the dataset slug on its own. The description still adds value by framing `dataset` as a mode switch (omit for the all-dataset summary, pass for the gap listing), which is more than a restatement of the property text.

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 states the resource precisely: per-dataset coverage counts (places covered out of places at that grain) plus the source's own caveat, and a second mode that lists missing places when `dataset` is passed. It is clearly separable from list_datasets, which is named as the source of the slug, and from the geographic lookup siblings.

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?

Provides explicit when-to-use guidance: 'Use it before telling anyone data does not exist for a place, and to explain a null.' It also routes the agent to list_datasets for the required slug, so the sequencing with a sibling is spelled out.

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