Skip to main content
Glama
Sign In

TravelCharika

by com.travelcharika
OverviewDiscussionsAdmin

When to go

best_months
Read-onlyIdempotent

When to go to one place: TravelCharika's verdict for each of the twelve months (sweet spot, good, ok or avoid) with its reason, scored from ten years of measured climate and the public holidays that crowd it; the typical daytime high, rainy days (what counts as one is in the answer's rainy_days_are: days with at least 1 mm of rain, as a weather station counts them), humidity and sunshine of each month; the sweet spot; and the verdict in one sentence, as the place's page says it. A busy month is a crowded one, not a bad one; crowds gives the busiest and quietest months as the page's graph of how busy it gets shows them, and how that is measured. Given a month, that month alone, as its own page has it: the verdict and its reason, the high and the low, the afternoon's feels-like high, rainy days, sunshine, daylight, the crowd score, the public holidays that fall in it with their dates, what to pack, and the month's page. Given a departure city, how far the place is from it. A place under travel advice is answered with the advice first, as its page shows it. Not a forecast: every figure is a ten-year average.

Input Schema

NameRequiredDescriptionDefault
monthNoA month: 1 to 12, or its name ("December", "dec"). Optional: that month alone, in more detail.
placeYesA place TravelCharika covers: its id from search_places ("bali") or its name ("Bali", "Da Nang", "Ubud").
from_cityNoOne of TravelCharika's departure cities, by its airport code ("DEL", "LON") or its name ("Delhi", "London", "Bombay"). Optional: the answer then says how far the place is from it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / month
      Added value: +{
+  "description": "A month: 1 to 12, or its name (\"December\", \"dec\"). Optional: that month alone, in more detail.",
+  "type": [
+    "integer",
+    "string"
+  ]
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / from_city / description
      Previous value: -"One of TravelCharika's departure cities, by its airport code (\"DEL\", \"LON\") or its name (\"Delhi\", \"London\", \"Bombay\"). Optional; fares are paused, so it changes nothing for now."New value: +"One of TravelCharika's departure cities, by its airport code (\"DEL\", \"LON\") or its name (\"Delhi\", \"London\", \"Bombay\"). Optional: the answer then says how far the place is from it."
  3. Changed1 schema field changed
    • changedInput schema / properties / from_city / description
      Previous value: -"One of TravelCharika's departure cities, by its airport code (\"DEL\", \"LON\") or its name (\"Delhi\", \"London\", \"Bombay\"). Optional: for that city's fares."New value: +"One of TravelCharika's departure cities, by its airport code (\"DEL\", \"LON\") or its name (\"Delhi\", \"London\", \"Bombay\"). Optional; fares are paused, so it changes nothing for now."
  4. First observed

TDQS

A3.9/5.0
Behavior4/5

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

The annotations already declare read-only, idempotent, closed-world behavior, and the description adds genuinely non-obvious context: every figure is a ten-year average, not a forecast, and a busy month is crowded rather than bad, with crowds measured per the page's graph. It doesn't cover latency, coverage limits, or error behavior for unknown places, which is why it stops short of a 5.

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

Conciseness3/5

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

The core purpose is front-loaded, but the body is a long semicolon-chained run-on that mixes return-value inventory, definitions, and mode switching into single sentences. Every clause carries information, yet the packaging makes it harder to parse than it needs to be.

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 no output schema, the description carries the return-shape burden and does so thoroughly, enumerating what each mode returns and even defining rainy_days_are. It omits failure behavior for unsupported places and the relationship to sibling tools, leaving minor gaps for a three-parameter tool.

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 semantics: month produces a distinct expanded response (high/low, feels-like, daylight, crowd score, holidays with dates, what to pack), and from_city adds a distance dimension. That goes beyond restating the schema's own one-liners.

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?

It states a specific verb and resource – TravelCharika's month-by-month verdict on when to visit one place – and spells out what the verdict contains (sweet spot, good, ok, avoid, reasons, climate figures). It never names a sibling, so an agent can't tell from the text alone whether where_to_go or events is the better fit for a broader or date-specific query.

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?

It explains the modifier-driven modes clearly: 'Given a month, that month alone' and 'Given a departure city, how far the place is from it'. What's missing is any exclusion guidance about when to prefer where_to_go or events instead of this tool, so the routing logic against siblings is left implicit.

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

All TravelCharika 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