Skip to main content
Glama

İstanbul günlük etkinlik planı

istanbul_events_plan
Read-onlyIdempotent

Build deterministic one-day event options, with ICS and calendar links.

Each performance includes about.text when published; explain its topic in
1–2 short sentences, preserving uncertainty when a description is unavailable.
min_events (1–max_events) expresses a REQUIRED minimum; for exactly two stops
set min_events=2,max_events=2. required_categories requires one of each named
type, unlike interests (only allowed types). Complete options satisfy both;
partial_options separately list missing_events/missing_categories and do not
generate calendars. fulfillment.status/reason_codes explain complete, partial,
unverified-budget or unmet requests; never present a partial as a full plan.
party_size/ticket_profile or a mixed party map price the whole group at every
stop. max_price_try is the total observed party basket across ALL stops, not
a per-person cap. budget_includes_fees keeps unknown fee totals unverified.
price_quote ticket quantities, total_price_scope and checkout_total_verified
separate observed subtotals from live checkout/seat guarantees.
date: YYYY-MM-DD or today/tomorrow, default today in Europe/Istanbul.
Use selected event_ids (1–20 from search/detail) or district discovery.
A selected performance_id keeps that exact session; an event_id allows its
series sessions. Missing/ambiguous replacements require a new selection.
Selected IDs still respect date and the 18:00–23:59 default window; provide
the session's date and explicit start_time/end_time for daytime selections.
interests accepts up to five search categories. Window is same-day HH:MM.
interests restricts allowed categories; unrelated fallback is never added.
When the user is explicitly participating as an adult, exclude_child_only=true
removes known upper age limits below 18 before the 20-candidate plan budget;
selected child-only sessions are rejected with child_only_age_range. Default
false preserves family discovery. Unknown/minimum-only age rules remain
unverified for the actual participant; do not infer a numeric age.
child_age (0–17) restricts to family sessions with a published matching age range.
Set require_known_end=true when the user must finish by end_time; unknown
ends are then excluded. Otherwise an unknown end is allowed only last.
max_price_try is a total observed minimum-price budget; unknown prices are
returned separately in unverified_budget. min_gap_minutes: 0–240; max_events:
1–3; limit: 1–5 options, default 3. At most 20 candidates are enumerated.
Unknown end times can appear only last, without a window-end guarantee.
Preserve source-time-conflict warnings and ticket-type eligibility warnings;
observed minimum prices need not be per-person general-admission prices.
Date-only flexible-entry tickets appear in flexible_entries (at most 20),
never timed options or calendars. flexible_entry_requires_visit_time explains
the rejection; verify a visit time and admission conditions on the ticket page.
Catalogue-only Biletinial sessions are rejected with session_detail_required;
call event_detail before treating their listed timestamp as a timed visit.
Explicitly restricted ticket dates are rejected with entry_date_restricted.
Timed options exclude mutually incompatible published age ranges. Inspect
checks.common_published_age_range and age_compatibility: unknown age facts
remain unknown, and a common range does not verify the user's actual age.
Sold-out/cancelled sessions are excluded. No travel-time or live ticket
guarantee: non-overlapping times do not prove venues are reachable.
For every event in the presented plan, show a clickable event/ticket-page
link beside its title from ticket_url or non-null ticket_links[].url.
Use the exact returned URL; calendar links are separate and do not replace
event links. If no event link is available, say so without inventing one.
Options prefer known observed totals and reduce repeated event series.
If total_price_known=false, total_observed_minimum_try is null and
known_minimum_total_try is only a partial subtotal, never the full price.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "istanbul_events_plan"
  }
}

Input Schema

NameRequiredDescriptionDefault
dateNo
limitNo
partyNo
districtNo
end_timeNo23:59
child_ageNo
event_idsNo
interestsNo
max_eventsNo
min_eventsNo
party_sizeNo
start_timeNo18:00
max_price_tryNo
ticket_profileNo
min_gap_minutesNo
require_known_endNo
exclude_child_onlyNo
required_categoriesNo
budget_includes_feesNo

Output Schema

NameRequiredDescriptionDefault
okNo
dataNo
errorNo
limitsNo
geojsonNo
sourcesNo
summaryYes
warningsNo
freshnessYes
paginationNo
result_infoNo
next_queriesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedOutput schema / $defs / ResultInfo / properties / coverage
      Added value: +{
      +  "anyOf": [
      +    {
      +      "additionalProperties": true,
      +      "maxProperties": 20,
      +      "type": "object"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Coverage"
      +}
    • addedOutput schema / $defs / ResultInfo / properties / empty_reasons
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {
      +        "type": "string"
      +      },
      +      "maxItems": 30,
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Empty Reasons"
      +}
  2. Changed6 schema fields changed
    • addedInput schema / properties / budget_includes_fees
      Added value: +{
      +  "default": false,
      +  "title": "Budget Includes Fees",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / min_events
      Added value: +{
      +  "default": 1,
      +  "title": "Min Events",
      +  "type": "integer"
      +}
    • addedInput schema / properties / party
      Added value: +{
      +  "anyOf": [
      +    {
      +      "additionalProperties": {
      +        "type": "integer"
      +      },
      +      "type": "object"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Party"
      +}
    • addedInput schema / properties / party_size
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Party Size"
      +}
    • addedInput schema / properties / required_categories
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Required Categories"
      +}
    • addedInput schema / properties / ticket_profile
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Ticket Profile"
      +}
  3. Changed1 schema field changed
    • addedInput schema / properties / exclude_child_only
      Added value: +{
      +  "default": false,
      +  "title": "Exclude Child Only",
      +  "type": "boolean"
      +}
  4. Changed1 schema field changed
    • addedOutput schema / $defs / ResultInfo / properties / filter_counts
      Added value: +{
      +  "anyOf": [
      +    {
      +      "additionalProperties": {
      +        "type": "integer"
      +      },
      +      "type": "object"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Filter Counts"
      +}
  5. Changed2 schema fields changed
    • addedOutput schema / $defs / Source / properties / refresh_status
      Added value: +{
      +  "anyOf": [
      +    {
      +      "enum": [
      +        "idle",
      +        "refreshing",
      +        "failed",
      +        "unavailable"
      +      ],
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Refresh Status"
      +}
    • addedOutput schema / $defs / Source / properties / serving_stale
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "boolean"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Serving Stale"
      +}
  6. Changed2 schema fields changed
    • addedInput schema / properties / child_age
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Child Age"
      +}
    • addedInput schema / properties / require_known_end
      Added value: +{
      +  "default": false,
      +  "title": "Require Known End",
      +  "type": "boolean"
      +}
  7. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, and the description does not contradict them. It adds real behavioral context the annotations cannot carry: no travel-time or live-ticket guarantee, sold-out/cancelled sessions are excluded, catalogue-only sessions are rejected with session_detail_required, date-only flexible tickets go to flexible_entries, and unknown prices land in unverified_budget. It stops short of describing latency, candidate-enumeration cost beyond 'at most 20', or failure modes for invalid input.

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

Conciseness2/5

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

It is a single monolithic block of roughly 400 words with no grouping, so critical rules (date window, ID selection) sit beside edge cases and are hard to scan. It also repeats itself: unknown-end behavior is stated twice, and max_price_try is defined once as 'total observed party basket' and again as a 'total observed minimum-price budget'.

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?

For a 19-parameter planning tool with a rich output shape, the description covers input semantics, exclusion rules, budget interpretation, output sections (partial_options, fulfillment, flexible_entries), and even presentation obligations such as showing a clickable ticket link beside every title. An output schema exists, yet the description still orients the agent to the fields it must interpret, which is appropriate given the tool's complexity.

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 description coverage is 0% across 19 parameters, so the description must carry the load, and it mostly does: it defines min_events/max_events semantics and ranges, limit 1-5 default 3, min_gap_minutes 0-240, date formats and the Europe/Istanbul default window, interests vs required_categories, budget_includes_fees, require_known_end, and max_price_try as a whole-party total rather than per-person. Gaps remain: the 'party' object shape is only called a 'mixed party map', 'district' has no format hint, and performance_id/price_quote are described in prose but do not exist in the schema, which can confuse the agent about what it can actually pass.

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 opening sentence gives a specific verb and artifact: 'Build deterministic one-day event options, with ICS and calendar links.' It also implicitly separates this tool from istanbul_events_search and istanbul_event_detail by framing event_ids as inputs 'from search/detail', so an agent can place it in the workflow without opening another 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?

It states concrete selection paths (selected event_ids vs district discovery), prescribes min_events=max_events=2 for a two-stop plan, tells the agent to call event_detail before trusting catalogue-only Biletinial timestamps, and instructs never to present a partial option as a full plan. It also explains when to set exclude_child_only, require_known_end and child_age, which is unusually explicit routing guidance.

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.