Skip to main content
Glama

Recent changes

list_recent_changes
Read-onlyIdempotent

Dataset change feed, newest first: data[] {changed_on, fact_id, country, category, change: added | updated | removed, old_value, new_value, source_url}. Use it to refresh caches or alert users when a fact changes, then fetch the current cited value (sources, license, confidence) with the matching tool, e.g. get_country_facts or check_entry_requirements. Entry rows: country is the destination, fact_id is entry:->. Parameters: set since to the last changed_on you processed (inclusive: that day repeats). Filter by category and/or country; exactly limit rows means older ones were cut, so raise limit or narrow. Examples: {"since":"2026-10-01"}, {"since":"2026-10-01","category":"entry","country":"JP"}. Read-only; keyless (free key or x402 lifts limits: https://citedtravel.com/pricing/); errors RFC 9457.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum rows, newest first. Default 100; values are clamped to 1-500 (numeric strings are accepted).
sinceYesReturn changes on or after this date. Calendar date, YYYY-MM-DD.
countryNoOnly changes for this country (for entry facts, the destination) as an ISO 3166-1 alpha-2 or alpha-3 code, case-insensitive (e.g. JP, jp or JPN). Names are not accepted: resolve them with resolve_country first.
categoryNoOnly changes in this category (entry = visa/entry pilot). Omit for all.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / category / description
      Previous value: -"Only changes in this category (entry = visa/entry pilot). Omit for all categories."New value: +"Only changes in this category (entry = visa/entry pilot). Omit for all."
    • changedInput schema / properties / limit / description
      Previous value: -"Maximum rows, newest first. Default 100; values are clamped to 1-500, and 0, an empty or a non-numeric value means 100. Numeric strings such as \"50\" are accepted."New value: +"Maximum rows, newest first. Default 100; values are clamped to 1-500 (numeric strings are accepted)."
    • changedInput schema / properties / since / description
      Previous value: -"Return changes recorded on or after this date (inclusive). Use the last changed_on you processed. Calendar date, YYYY-MM-DD."New value: +"Return changes on or after this date. Calendar date, YYYY-MM-DD."
  2. Changed4 schema fields changed
    • changedInput schema / properties / category / description
      Previous value: -"Only changes in this category (entry = visa/entry pilot). Omit for all."New value: +"Only changes in this category (entry = visa/entry pilot). Omit for all categories."
    • addedInput schema / properties / category / examples
      Added value: +[
      +  "entry"
      +]
    • changedInput schema / properties / limit / description
      Previous value: -"Maximum rows, newest first. Default 100; values are clamped to 1-500 (numeric strings are accepted)."New value: +"Maximum rows, newest first. Default 100; values are clamped to 1-500, and 0, an empty or a non-numeric value means 100. Numeric strings such as \"50\" are accepted."
    • changedInput schema / properties / since / description
      Previous value: -"Return changes on or after this date. Calendar date, YYYY-MM-DD."New value: +"Return changes recorded on or after this date (inclusive). Use the last changed_on you processed. Calendar date, YYYY-MM-DD."
  3. Changed10 schema fields changed
    • addedInput schema / properties / category / description
      Added value: +"Only changes in this category (entry = visa/entry pilot). Omit for all."
    • addedInput schema / properties / category / enum
      Added value: +[
      +  "power",
      +  "currency",
      +  "emergency",
      +  "driving",
      +  "holidays",
      +  "tipping",
      +  "entry"
      +]
    • changedInput schema / properties / country / description
      Previous value: -"Country as ISO 3166-1 alpha-2 or alpha-3 code, e.g. JP or JPN. Use resolve_country for names."New value: +"Only changes for this country (for entry facts, the destination) as an ISO 3166-1 alpha-2 or alpha-3 code, case-insensitive (e.g. JP, jp or JPN). Names are not accepted: resolve them with resolve_country first."
    • addedInput schema / properties / country / examples
      Added value: +[
      +  "JP",
      +  "GB",
      +  "USA"
      +]
    • addedInput schema / properties / country / pattern
      Added value: +"^[A-Za-z]{2,3}$"
    • addedInput schema / properties / limit
      Added value: +{
      +  "default": 100,
      +  "description": "Maximum rows, newest first. Default 100; values are clamped to 1-500 (numeric strings are accepted).",
      +  "examples": [
      +    50
      +  ],
      +  "type": [
      +    "integer",
      +    "string"
      +  ]
      +}
    • changedInput schema / properties / since / description
      Previous value: -"YYYY-MM-DD"New value: +"Return changes on or after this date. Calendar date, YYYY-MM-DD."
    • addedInput schema / properties / since / examples
      Added value: +[
      +  "2026-10-01"
      +]
    • addedInput schema / properties / since / format
      Added value: +"date"
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "anyOf": [
      +    {
      +      "properties": {
      +        "data": {
      +          "description": "Changes, newest first.",
      +          "items": {
      +            "properties": {
      +              "category": {
      +                "type": "string"
      +              },
      +              "change": {
      +                "enum": [
      +                  "added",
      +                  "updated",
      +                  "removed"
      +                ],
      +                "type": "string"
      +              },
      +              "changed_on": {
      +                "description": "YYYY-MM-DD.",
      +                "type": "string"
      +              },
      +              "country": {
      +                "type": "string"
      +              },
      +              "dataset_version": {
      +                "type": "string"
      +              },
      +              "fact_id": {
      +                "type": "string"
      +              },
      +              "new_value": {
      +                "description": "New value (null when removed)."
      +              },
      +              "old_value": {
      +                "description": "Previous value (null when added)."
      +              },
      +              "seq": {
      +                "type": "integer"
      +              },
      +              "source_url": {
      +                "description": "Main source of the fact. Fetch the fact with the matching tool for full citations and confidence.",
      +                "type": [
      +                  "string",
      +                  "null"
      +                ]
      +              }
      +            },
      +            "required": [
      +              "fact_id",
      +              "country",
      +              "category",
      +              "change",
      +              "changed_on"
      +            ],
      +            "type": "object"
      +          },
      +          "type": "array"
      +        },
      +        "dataset_version": {
      +          "description": "Version of the dataset that answered.",
      +          "type": "string"
      +        },
      +        "since": {
      +          "type": "string"
      +        }
      +      },
      +      "required": [
      +        "since",
      +        "data"
      +      ],
      +      "title": "Result",
      +      "type": "object"
      +    },
      +    {
      +      "description": "Only on error results (isError: true): RFC 9457 problem, e.g. unknown country, no data, key required, rate limited, sanctions block.",
      +      "properties": {
      +        "detail": {
      +          "type": "string"
      +        },
      +        "status": {
      +          "type": "integer"
      +        },
      +        "title": {
      +          "type": "string"
      +        },
      +        "type": {
      +          "type": "string"
      +        }
      +      },
      +      "required": [
      +        "type",
      +        "title",
      +        "status"
      +      ],
      +      "title": "Error (problem details)",
      +      "type": "object"
      +    },
      +    {
      +      "description": "Only on error results (isError: true): x402 v2 payment requirements. Pay and retry with _meta[\"x402/payment\"].",
      +      "properties": {
      +        "accepts": {
      +          "type": "array"
      +        },
      +        "error": {
      +          "type": "string"
      +        },
      +        "extensions": {
      +          "type": "object"
      +        },
      +        "resource": {
      +          "type": "object"
      +        },
      +        "x402Version": {
      +          "type": "integer"
      +        }
      +      },
      +      "required": [
      +        "x402Version",
      +        "accepts"
      +      ],
      +      "title": "Error (x402 payment request)",
      +      "type": "object"
      +    }
      +  ],
      +  "type": "object"
      +}
  4. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered; the description adds context those fields cannot carry: keyless access, quota lifting via a free key or x402, and RFC 9457 error responses. It also explains truncation behavior ('exactly limit rows means older ones were cut') rather than leaving it to the schema's clamp note.

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?

Front-loaded with the feed's identity and payload shape, then folds parameters, examples and access notes into compact prose with no filler sentences. The inline `data[]` field list slightly overlaps the output schema, keeping it just short of a 5.

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 an output schema present, annotations covering safety, and full parameter coverage, the description only needed to add workflow, resume semantics and access/error behavior — all of which it does. Nothing an agent needs to call this correctly is left implicit.

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 goes past it: the inclusive boundary semantics of `since` ('that day repeats') and the truncation diagnostic for `limit` are operational meaning the schema's terse wording does not convey. It also clarifies that entry rows key country to the destination.

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?

States a specific verb+resource with ordering and scope: 'Dataset change feed, newest first', and enumerates the row shape an agent will receive. It also names the follow-up siblings (get_country_facts, check_entry_requirements), so the agent can distinguish a change-delta tool from a current-value tool without opening either schema.

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?

Gives an explicit two-step workflow: use this to refresh caches or alert users on change, then fetch the current cited value with the matching tool, naming concrete alternatives. The `since` resume protocol ('set since to the last changed_on you processed') plus the 'raise limit or narrow' instruction supply the when-to-use conditions the tool needs.

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