Skip to main content
Glama

pifini

by net.pifini
OverviewDiscussionsAdmin

Server Details

Real events, reviewed places, and ticket checkout across the Caribbean and Latin America.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
100.0% over 41 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.4/5.0

Scored across 6 tools

Disambiguation5/5

Each tool maps cleanly to a distinct resource and action: searching vs. retrieving events/places, enumerating categories, and creating ticket checkouts. There is no meaningful overlap that would confuse an agent choosing among these tools.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern: search_*, get_*, list_*, create_*. The naming style is uniform and predictable across the whole server.

Tool Count5/5

With 6 tools, the server is appropriately scoped for its purpose: discovering events and places, retrieving details, resolving category taxonomy, and purchasing tickets. No tool feels redundant or extraneous.

Completeness5/5

The tool surface covers the full user journey: search for events/places, get detailed information, discover valid category values, and create a ticket checkout. There are no obvious missing operations that would create a dead end for an agent.

Available Tools

6 tools
create_ticket_checkoutCreate ticket checkout linkAInspect

Create a secure Stripe-hosted payment link for event tickets. Returns a checkout URL — give it to the human to complete payment themselves; each ticket is then emailed with its QR code and its own link, which opens on any phone and can be saved to WhatsApp. Get ticket_type_id values from get_event. Always confirm the exact tickets and total with the human before calling this.

ParametersJSON Schema
NameRequiredDescriptionDefault
itemsYesTicket selections
buyer_nameNoBuyer's name (optional)
event_slugYesEvent slug
buyer_emailYesEmail to deliver tickets to (required — ask the human)

Output Schema

ParametersJSON Schema
NameRequiredDescription
eventNo
totalNo
currencyNo
order_idNo
checkout_urlNo
instructionsNo

TDQS

A4.2/5.0
Behavior4/5

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

The description adds meaningful behavioral context beyond the annotations: the payment link is Stripe-hosted, the human completes payment themselves, and each ticket is emailed with a QR code and phone-friendly link. This explains side effects and follow-up behavior. The annotations are generic and do not contradict the description.

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

Conciseness5/5

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

Three well-structured sentences: the main action, the return/behavior, and the required human-confirmation step. Every sentence earns its place, and no information is wasted or buried.

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?

The description covers the core workflow: create the link, hand it to the human, and know what happens after payment. It also includes the critical prerequisite and confirmation step. It could have explicitly tied event_slug to get_event as well, but the schema and output schema cover the remaining details sufficiently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all four parameters and their roles. The description repeats the 'ticket_type_id from get_event' guidance already present in the schema and adds no new parameter syntax, format, or source details beyond that. Baseline 3 is appropriate.

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 opens with a specific verb and resource: 'Create a secure Stripe-hosted payment link for event tickets.' It clearly distinguishes the tool from the sibling get/search tools, and the return value (checkout URL) is stated explicitly. An agent can immediately tell what the tool accomplishes.

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?

The description gives clear usage context: get ticket_type_id values from get_event, and always confirm exact tickets and total with the human before calling. It does not explicitly state when not to use this tool or name alternatives, but no close alternative exists among the siblings, so the guidance is sufficient.

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

get_eventGet event detailsA
Read-onlyIdempotent
Inspect

Full details for one event by slug: description, venue, date/time, and available ticket types with prices and remaining stock. Use the slug from search_events.

ParametersJSON Schema
NameRequiredDescriptionDefault
slugYesEvent slug from search_events

Output Schema

ParametersJSON Schema
NameRequiredDescription
urlNo
cityNo
slugNo
priceNo
titleNo
countryNo
ends_atNo
summaryNo
websiteNo
categoryNo
currencyNo
timezoneNoIANA timezone of the venue, e.g. America/Mexico_City. Null when unknown.
starts_atNoExact start instant, ISO-8601 UTC. Do NOT format this for a human — it is the wrong calendar day in most of the region. Use local_date / local_time.
local_dateNoThe date the event actually happens where it happens, YYYY-MM-DD. Quote this one.
local_timeNoLocal start time, HH:MM 24h. Null when start_time_known is false — say nothing about the time in that case.
descriptionNo
entry_modelNo
ticket_typesNo
location_nameNo
organizer_urlNo
attendee_countNo
organizer_nameNo
cover_image_urlNo
start_time_knownNoFalse when only the date is known and the stored hour is a placeholder. Never present a start time when this is false.

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds value by explicitly enumerating the returned fields (venue, date/time, ticket types with prices and remaining stock), giving the agent a preview of the response content beyond what annotations convey.

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

Conciseness5/5

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

The description is two concise sentences, front-loaded with the core purpose and then a practical usage hint. No redundant words or repetition of structured fields, making every sentence earn its place.

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 one simple parameter, high schema coverage, an output schema, and complete annotations, the description adequately covers the tool's behavior and usage. It mentions the key response elements, making it self-sufficient for a straightforward getter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a description 'Event slug from search_events'. The tool description repeats this with 'Use the slug from search_events', reinforcing but not adding new meaning beyond the schema. The baseline is 3 given high schema coverage.

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 clearly states it provides 'Full details for one event by slug' and lists specific response components (description, venue, date/time, ticket types with prices and stock). This distinguishes it from siblings like search_events, which find events, and get_place, which retrieves place details.

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?

The description tells the user to 'Use the slug from search_events', providing a clear prerequisite and source for the input. It implies this tool is for fetching a specific event's full details, but does not explicitly state when not to use it or offer alternative tool comparisons beyond the slug hint.

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

get_placeGet place details + reviewsA
Read-onlyIdempotent
Inspect

Full details for one place by slug, including its most recent published reviews if any exist. listing_type distinguishes a curated entry from an unreviewed directory listing (see search_places) — recent_reviews is often an empty array, which means no reviews yet, not a low-quality place. Use the slug from search_places.

ParametersJSON Schema
NameRequiredDescriptionDefault
slugYesPlace slug from search_places

Output Schema

ParametersJSON Schema
NameRequiredDescription
urlNo
cityNo
nameNo
slugNo
typeNo
addressNo
countryNo
summaryNo
websiteNo
categoryNo
avg_ratingNo
price_tierNo
descriptionNo
is_verifiedNo
is_sponsoredNo
listing_typeNo
review_countNo
recent_reviewsNo

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: it explains that recent_reviews may be an empty array meaning no reviews yet (not a low-quality place), and that listing_type distinguishes curated vs. directory entries. This goes beyond the annotations and helps interpretation.

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

Conciseness5/5

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

The description is two concise sentences with no filler. The core purpose is front-loaded, and the important caveat about empty recent_reviews is included. Every sentence earns its place.

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 simple single-parameter tool with an output schema, the description covers the essential usage: how to get the slug, what the response contains, and how to interpret a key field. No critical information is missing. The output schema handles return structure, so description need not duplicate that.

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 slug parameter is already documented. The description adds a meaningful hint about the parameter's origin ('Use the slug from search_places'), which is not in the schema and helps the agent correctly obtain the input. This is a value-add beyond the schema.

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?

The description clearly states the tool returns full details for one place by slug, including recent reviews. It distinguishes this from search tools by referencing search_places for slug acquisition and explaining listing_type, though it doesn't explicitly name a sibling alternative like get_event. The verb-resource pairing is specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides the source for the required slug ('Use the slug from search_places') and clarifies the meaning of an empty recent_reviews array. However, it does not explicitly state when to use this tool vs. alternatives (e.g., when you have a slug and need details, use this rather than search_places). The guidance is implied but not fully explicit.

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

list_categoriesList place categoriesA
Read-onlyIdempotent
Inspect

Discover valid category values for search_places. Pifini's places directory uses Overture Maps' taxonomy — over 1,000 specific values like caribbean_restaurant, church_cathedral, landmark_and_historical_building — rather than broad buckets, so guessing a category string will usually miss. Call this first with a rough query (e.g. 'coffee' or 'beach') to find the exact value, then pass it to search_places' category parameter.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMax results, 1-100 (default 30)
queryNoRough term to match against category values, e.g. 'coffee', 'beach'
countryNoISO-3166 alpha-2 country code — only return categories present in that country

Output Schema

ParametersJSON Schema
NameRequiredDescription
countYes
categoriesYes

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable behavioral context: it uses Overture Maps taxonomy with over 1,000 specific values, and that guessing will usually miss. This explains why the tool is needed and what it returns, 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.

Conciseness5/5

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

The description is a single paragraph but is front-loaded with the purpose, followed by context and usage instruction. Every sentence adds value; no fluff. It is appropriately sized for the tool's simplicity.

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?

Given an output schema exists (so return values are covered), the description is complete. It explains why the taxonomy is needed, how to use the tool, and how to pass results to search_places. The only minor gap is no explicit mention of 'limit' behavior, but schema covers that. Overall comprehensive.

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 each parameter has a schema description. The description adds meaning by explaining that 'query' is a 'rough query' (partial match) and that 'country' filters by country presence. This aids understanding beyond raw schema, though the description does not detail every parameter.

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?

Description clearly states the tool's purpose: 'Discover valid category values for search_places.' It uses a specific verb (discover) and resource (category values), and distinguishes itself from sibling tools like search_places by acting as a preparatory step. Examples of specific category values further clarify the scope.

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?

Explicitly tells when to use: 'Call this first with a rough query... then pass it to search_places' category parameter.' It contrasts with guessing, providing clear context for usage. No alternative tool is mentioned, but the recommendation is direct and actionable.

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

search_eventsSearch eventsA
Read-onlyIdempotent
Inspect

Search upcoming events (festivals, carnivals, concerts, food + cultural events) across the Caribbean, Latin America, and beyond. Returns event names, dates, locations, category, price (when known), and page URLs. Strongest coverage: Barbados, Trinidad, Jamaica, Bahamas, Mexico.

ParametersJSON Schema
NameRequiredDescriptionDefault
cityNoCity name filter
limitNoMax results, 1-50 (default 10)
queryNoFree-text search over title and description
offsetNoSkip this many matching results (for paging past the limit)
countryNoISO-3166 alpha-2 country code, e.g. BB, TT, JM
categoryNoFilter by event category
near_latNoLatitude to search near (pair with near_lng)
near_lngNoLongitude to search near (pair with near_lat)
radius_kmNoSearch radius in km around near_lat/near_lng (default 25, max 500)
entry_modelNoFilter by how someone gets in: 'free' = confirmed free entry, 'ticketed' = Pifini sells tickets, 'external' = paid but sold elsewhere, 'mixed' = umbrella event with both free and paid components, 'unknown' = not yet confirmed either way.
include_pastNoInclude past events (default false)
starts_afterNoEarliest start. A bare date ('2026-08-01') matches the event's LOCAL calendar date in its own timezone and is inclusive — this is what you want for 'what's on this weekend'. A full ISO timestamp ('2026-08-01T18:00:00Z') is compared as an exact UTC instant instead.
starts_beforeNoLatest start, same rules as starts_after. A bare date is inclusive of that whole local day, so starts_after='2026-08-13' with starts_before='2026-08-13' returns everything happening on the 13th where it happens.

Output Schema

ParametersJSON Schema
NameRequiredDescription
countYesNumber of events in this page of results
totalYesTotal events matching the filters, across all pages. Use this before claiming how many exist.
eventsYes
has_moreYesTrue when more matches exist beyond this page.
next_offsetNoPass as `offset` to fetch the next page. Null when this is the last page.

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by noting coverage limitations ('Strongest coverage: Barbados, Trinidad...') and return field specifics including the 'price (when known)' caveat, which helps set expectations.

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

Conciseness5/5

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

The description is two sentences with no waste. It front-loads the action ('Search upcoming events...') and scope, then concisely lists return fields and coverage strengths.

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?

Given the rich schema (13 params, all documented) and the presence of an output schema, the high-level description is sufficient. It orients the agent to the tool's purpose and geographic focus without needing to restate parameter semantics. Slightly more context about filtering capabilities would push it to 5, but it is complete enough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 13 parameters have detailed descriptions in the schema (100% schema description coverage), including nuanced explanations for starts_after and starts_before date handling. The tool description adds no parameter-level detail beyond what the schema already provides, so the baseline score of 3 is appropriate.

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 clearly states it searches upcoming events (festivals, carnivals, concerts, food + cultural events) across a specific geography. It distinguishes itself from sibling tools like search_places and get_event by focusing on multi-event search for the Caribbean/Latin America region.

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 provides clear context for when to use the tool (event discovery in specific regions) but does not explicitly mention when not to use it or name alternatives. The context is sufficient for an agent to infer it is the right tool for finding events as opposed to places or single-event details.

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

search_placesSearch places and businessesA
Read-onlyIdempotent
Inspect

Search Pifini's places directory across the Caribbean and Latin America — restaurants, bars, beaches, attractions, venues, hotels, tour operators, professionals, and services. Every result carries listing_type: 'curated' is a small, editorially reviewed set of flagship entries; 'directory' is the much larger set sourced from open map data (name, category, location, contact info) that has no reviews yet — say so rather than implying a recommendation the data doesn't back up. Category is a specific Overture taxonomy value (e.g. caribbean_restaurant, church_cathedral), not a broad bucket — call list_categories first if unsure of the exact value. Results marked is_sponsored are paid placements — disclose that when recommending.

ParametersJSON Schema
NameRequiredDescriptionDefault
cityNoCity name filter
limitNoMax results, 1-50 (default 10)
queryNoFree-text search over name and summary
offsetNoSkip this many matching results (for paging past the limit)
countryNoISO-3166 alpha-2 country code
categoryNoFilter by exact category value (e.g. 'caribbean_restaurant'). Use list_categories to discover valid values — there are 1,000+, not a small fixed set.
near_latNoLatitude to search near (pair with near_lng)
near_lngNoLongitude to search near (pair with near_lat)
radius_kmNoSearch radius in km around near_lat/near_lng (default 25, max 500)
entity_typeNoFilter by broad type of place

Output Schema

ParametersJSON Schema
NameRequiredDescription
countYesNumber of places in this page of results
totalYesTotal places matching the filters, across all pages. Use this before claiming how many exist.
placesYes
has_moreYesTrue when more matches exist beyond this page.
next_offsetNoPass as `offset` to fetch the next page. Null when this is the last page.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already mark this as read-only and non-destructive, so the description adds valuable context about result types (curated vs directory), data provenance, and disclosure requirements. No contradiction with annotations.

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

Conciseness5/5

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

The description is composed of three well-organized sentences, each conveying essential information: scope, result interpretation, and category taxonomy. No filler or redundancy.

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?

The description covers critical operational nuances including regional scope, data quality tiers, category specificity, and sponsored content handling. With an output schema present, this is sufficiently complete for accurate use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides descriptions for all 10 parameters (100% coverage). The tool description adds minimal parameter-specific context beyond reiterating the category guidance already present in the schema, so it stays at the baseline 3.

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?

Description clearly states the tool searches Pifini's places directory across a specific region, listing the types of places covered. It distinguishes from siblings like search_events and get_place through resource specificity, making the purpose unambiguous.

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 guidance on when to use the tool and directs users to list_categories first for valid category values. It also gives behavioral instructions for interpreting curated vs directory results and disclosing sponsored content, going beyond basic usage.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • Changedget_place1 field changed
      • addedOutput schema / properties / recent_reviews / items / properties / verification_basis
        Added value: +{
+  "description": "How the reviewer's visit was established. ticket_scan and transaction are strong evidence, rsvp and geo_checkin are weaker, manual is self-declared and none is an unverified opinion. Describe the review accordingly.",
+  "enum": [
+    "ticket_scan",
+    "transaction",
+    "rsvp",
+    "geo_checkin",
+    "manual",
+    "none"
+  ],
+  "type": "string"
+}
  2. 1 tool update
    • Changedsearch_events2 fields changed
      • changedInput schema / properties / starts_after / description
        Previous value: -"Only events starting on/after this date, e.g. '2026-08-01' or a full ISO timestamp"New value: +"Earliest start. A bare date ('2026-08-01') matches the event's LOCAL calendar date in its own timezone and is inclusive — this is what you want for 'what's on this weekend'. A full ISO timestamp ('2026-08-01T18:00:00Z') is compared as an exact UTC instant instead."
      • changedInput schema / properties / starts_before / description
        Previous value: -"Only events starting on/before this date, e.g. '2026-08-31' or a full ISO timestamp"New value: +"Latest start, same rules as starts_after. A bare date is inclusive of that whole local day, so starts_after='2026-08-13' with starts_before='2026-08-13' returns everything happening on the 13th where it happens."
  3. 3 tool updates
    • Changedget_event5 fields changed
      • addedOutput schema / properties / local_date
        Added value: +{
+  "description": "The date the event actually happens where it happens, YYYY-MM-DD. Quote this one.",
+  "type": "string"
+}
      • addedOutput schema / properties / local_time
        Added value: +{
+  "description": "Local start time, HH:MM 24h. Null when start_time_known is false — say nothing about the time in that case.",
+  "type": [
+    "string",
+    "null"
+  ]
+}
      • addedOutput schema / properties / start_time_known
        Added value: +{
+  "description": "False when only the date is known and the stored hour is a placeholder. Never present a start time when this is false.",
+  "type": "boolean"
+}
      • addedOutput schema / properties / starts_at / description
        Added value: +"Exact start instant, ISO-8601 UTC. Do NOT format this for a human — it is the wrong calendar day in most of the region. Use local_date / local_time."
      • addedOutput schema / properties / timezone
        Added value: +{
+  "description": "IANA timezone of the venue, e.g. America/Mexico_City. Null when unknown.",
+  "type": [
+    "string",
+    "null"
+  ]
+}
    • Changedsearch_events9 fields changed
      • addedOutput schema / properties / events / items / properties / local_date
        Added value: +{
+  "description": "The date the event actually happens where it happens, YYYY-MM-DD. Quote this one.",
+  "type": "string"
+}
      • addedOutput schema / properties / events / items / properties / local_time
        Added value: +{
+  "description": "Local start time, HH:MM 24h. Null when start_time_known is false — say nothing about the time in that case.",
+  "type": [
+    "string",
+    "null"
+  ]
+}
      • addedOutput schema / properties / events / items / properties / start_time_known
        Added value: +{
+  "description": "False when only the date is known and the stored hour is a placeholder. Never present a start time when this is false.",
+  "type": "boolean"
+}
      • addedOutput schema / properties / events / items / properties / starts_at / description
        Added value: +"Exact start instant, ISO-8601 UTC. Do NOT format this for a human — it is the wrong calendar day in most of the region. Use local_date / local_time."
      • addedOutput schema / properties / events / items / properties / timezone
        Added value: +{
+  "description": "IANA timezone of the venue, e.g. America/Mexico_City. Null when unknown.",
+  "type": [
+    "string",
+    "null"
+  ]
+}
      • addedOutput schema / properties / has_more
        Added value: +{
+  "description": "True when more matches exist beyond this page.",
+  "type": "boolean"
+}
      • addedOutput schema / properties / next_offset
        Added value: +{
+  "description": "Pass as `offset` to fetch the next page. Null when this is the last page.",
+  "type": [
+    "number",
+    "null"
+  ]
+}
      • addedOutput schema / properties / total
        Added value: +{
+  "description": "Total events matching the filters, across all pages. Use this before claiming how many exist.",
+  "type": "number"
+}
      • changedOutput schema / required
        Previous value: -[
-  "count",
-  "events"
-]New value: +[
+  "count",
+  "total",
+  "has_more",
+  "events"
+]
    • Changedsearch_places5 fields changed
      • addedOutput schema / properties / count / description
        Added value: +"Number of places in this page of results"
      • addedOutput schema / properties / has_more
        Added value: +{
+  "description": "True when more matches exist beyond this page.",
+  "type": "boolean"
+}
      • addedOutput schema / properties / next_offset
        Added value: +{
+  "description": "Pass as `offset` to fetch the next page. Null when this is the last page.",
+  "type": [
+    "number",
+    "null"
+  ]
+}
      • addedOutput schema / properties / total
        Added value: +{
+  "description": "Total places matching the filters, across all pages. Use this before claiming how many exist.",
+  "type": "number"
+}
      • changedOutput schema / required
        Previous value: -[
-  "count",
-  "places"
-]New value: +[
+  "count",
+  "total",
+  "has_more",
+  "places"
+]
  4. 2 tool updates
    • Changedget_event1 field changed
      • addedOutput schema / properties / ticket_types / items
        Added value: +{
+  "properties": {
+    "currency": {
+      "type": "string"
+    },
+    "description": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "name": {
+      "type": "string"
+    },
+    "price": {
+      "type": "number"
+    },
+    "remaining": {
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "sales_end_at": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "ticket_type_id": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "ticket_type_id",
+    "name",
+    "price",
+    "currency"
+  ],
+  "type": "object"
+}
    • Changedget_place1 field changed
      • addedOutput schema / properties / recent_reviews / items
        Added value: +{
+  "properties": {
+    "body": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "date": {
+      "type": "string"
+    },
+    "rating": {
+      "type": "number"
+    },
+    "title": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "verified_attendee": {
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "rating",
+    "verified_attendee",
+    "date"
+  ],
+  "type": "object"
+}
  5. 6 tool updates
    • Changedcreate_ticket_checkout1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "checkout_url": {
+      "type": "string"
+    },
+    "currency": {
+      "type": "string"
+    },
+    "event": {
+      "type": "string"
+    },
+    "instructions": {
+      "type": "string"
+    },
+    "order_id": {
+      "type": "string"
+    },
+    "total": {
+      "type": "number"
+    }
+  },
+  "type": "object"
+}
    • Changedget_event1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "attendee_count": {
+      "type": "number"
+    },
+    "category": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "city": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "country": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "cover_image_url": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "currency": {
+      "type": "string"
+    },
+    "description": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "ends_at": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "entry_model": {
+      "type": "string"
+    },
+    "location_name": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "organizer_name": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "organizer_url": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "price": {
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "slug": {
+      "type": "string"
+    },
+    "starts_at": {
+      "type": "string"
+    },
+    "summary": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "ticket_types": {
+      "type": "array"
+    },
+    "title": {
+      "type": "string"
+    },
+    "url": {
+      "type": "string"
+    },
+    "website": {
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}
    • Changedget_place1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "address": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "avg_rating": {
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "category": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "city": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "country": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "description": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "is_sponsored": {
+      "type": "boolean"
+    },
+    "is_verified": {
+      "type": "boolean"
+    },
+    "listing_type": {
+      "enum": [
+        "curated",
+        "directory"
+      ],
+      "type": "string"
+    },
+    "name": {
+      "type": "string"
+    },
+    "price_tier": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "recent_reviews": {
+      "type": "array"
+    },
+    "review_count": {
+      "type": "number"
+    },
+    "slug": {
+      "type": "string"
+    },
+    "summary": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "type": {
+      "type": "string"
+    },
+    "url": {
+      "type": "string"
+    },
+    "website": {
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}
    • Addedlist_categories
    • Changedsearch_events10 fields changed
      • addedInput schema / properties / category
        Added value: +{
+  "description": "Filter by event category",
+  "enum": [
+    "music",
+    "arts",
+    "culture",
+    "festival",
+    "sports",
+    "food",
+    "business",
+    "nightlife"
+  ],
+  "type": "string"
+}
      • addedInput schema / properties / entry_model
        Added value: +{
+  "description": "Filter by how someone gets in: 'free' = confirmed free entry, 'ticketed' = Pifini sells tickets, 'external' = paid but sold elsewhere, 'mixed' = umbrella event with both free and paid components, 'unknown' = not yet confirmed either way.",
+  "enum": [
+    "free",
+    "ticketed",
+    "external",
+    "mixed",
+    "unknown"
+  ],
+  "type": "string"
+}
      • changedInput schema / properties / limit / description
        Previous value: -"Max results, 1-25 (default 10)"New value: +"Max results, 1-50 (default 10)"
      • addedInput schema / properties / near_lat
        Added value: +{
+  "description": "Latitude to search near (pair with near_lng)",
+  "type": "number"
+}
      • addedInput schema / properties / near_lng
        Added value: +{
+  "description": "Longitude to search near (pair with near_lat)",
+  "type": "number"
+}
      • addedInput schema / properties / offset
        Added value: +{
+  "description": "Skip this many matching results (for paging past the limit)",
+  "type": "number"
+}
      • addedInput schema / properties / radius_km
        Added value: +{
+  "description": "Search radius in km around near_lat/near_lng (default 25, max 500)",
+  "type": "number"
+}
      • addedInput schema / properties / starts_after
        Added value: +{
+  "description": "Only events starting on/after this date, e.g. '2026-08-01' or a full ISO timestamp",
+  "type": "string"
+}
      • addedInput schema / properties / starts_before
        Added value: +{
+  "description": "Only events starting on/before this date, e.g. '2026-08-31' or a full ISO timestamp",
+  "type": "string"
+}
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "count": {
+      "description": "Number of events in this page of results",
+      "type": "number"
+    },
+    "events": {
+      "items": {
+        "properties": {
+          "attendee_count": {
+            "type": "number"
+          },
+          "category": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "city": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "country": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "cover_image_url": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "distance_km": {
+            "description": "Only present when near_lat/near_lng were given",
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "ends_at": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "entry_model": {
+            "type": "string"
+          },
+          "organizer_name": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "price": {
+            "properties": {
+              "currency": {
+                "type": "string"
+              },
+              "max": {
+                "type": [
+                  "number",
+                  "null"
+                ]
+              },
+              "min": {
+                "type": "number"
+              },
+              "note": {
+                "type": [
+                  "string",
+                  "null"
+                ]
+              }
+            },
+            "type": [
+              "object",
+              "null"
+            ]
+          },
+          "slug": {
+            "type": "string"
+          },
+          "starts_at": {
+            "type": "string"
+          },
+          "summary": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "title": {
+            "type": "string"
+          },
+          "url": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "count",
+    "events"
+  ],
+  "type": "object"
+}
    • Changedsearch_places9 fields changed
      • addedInput schema / properties / category
        Added value: +{
+  "description": "Filter by exact category value (e.g. 'caribbean_restaurant'). Use list_categories to discover valid values — there are 1,000+, not a small fixed set.",
+  "type": "string"
+}
      • changedInput schema / properties / entity_type / description
        Previous value: -"Filter by type of place"New value: +"Filter by broad type of place"
      • changedInput schema / properties / limit / description
        Previous value: -"Max results, 1-25 (default 10)"New value: +"Max results, 1-50 (default 10)"
      • removedInput schema / properties / min_rating
        Removed value: -{
-  "description": "Minimum average rating 1-5",
-  "type": "number"
-}
      • addedInput schema / properties / near_lat
        Added value: +{
+  "description": "Latitude to search near (pair with near_lng)",
+  "type": "number"
+}
      • addedInput schema / properties / near_lng
        Added value: +{
+  "description": "Longitude to search near (pair with near_lat)",
+  "type": "number"
+}
      • addedInput schema / properties / offset
        Added value: +{
+  "description": "Skip this many matching results (for paging past the limit)",
+  "type": "number"
+}
      • addedInput schema / properties / radius_km
        Added value: +{
+  "description": "Search radius in km around near_lat/near_lng (default 25, max 500)",
+  "type": "number"
+}
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "count": {
+      "type": "number"
+    },
+    "places": {
+      "items": {
+        "properties": {
+          "avg_rating": {
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "category": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "city": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "country": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "distance_km": {
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "is_sponsored": {
+            "type": "boolean"
+          },
+          "is_verified": {
+            "type": "boolean"
+          },
+          "listing_type": {
+            "enum": [
+              "curated",
+              "directory"
+            ],
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "price_tier": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "review_count": {
+            "type": "number"
+          },
+          "slug": {
+            "type": "string"
+          },
+          "summary": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "type": {
+            "type": "string"
+          },
+          "url": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "count",
+    "places"
+  ],
+  "type": "object"
+}
  6. 5 tool updates
    • First observedcreate_ticket_checkout
    • First observedget_event
    • First observedget_place
    • First observedsearch_events
    • First observedsearch_places

Related MCP Connectors

Related MCP Servers

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