Find events in Guatemala, get checkout links and draft new events. Public, no key.
Scored across 4 tools
Each tool has a distinct purpose: drafting an organizer event, getting a buyer checkout link, fetching one published event, and searching published events. The closest pair is get-event vs. get-checkout-link, but one returns event details and the other returns a purchase/registration link, so the boundary is clear.
All names use kebab-case with a verb-first pattern: draft-event, get-checkout-link, get-event, search-events. The compound resource in get-checkout-link is still predictable and consistent with the rest of the set.
Four tools is well-scoped for a narrow event/ticketing workflow, and each tool earns its place by covering drafting, event lookup, public search, or checkout linking. There is no redundant or filler tool.
The core workflows are covered: organizers can draft events, buyers can get checkout links, users can inspect published events, and users can search upcoming events. Minor gaps remain around updating/deleting drafts or managing existing organizer events, but publication is intentionally handled through the claim_url flow.
Prepare a person's own event on Pandy Tickets from what they told you (name, date, place, ticket categories with price and quantity). Nothing is published and no account is created: it returns a one-time claim_url, valid 48 hours. The person opens it, signs in with Google, and lands on a screen where they review the event and publish it with one click. Use it when someone wants to organize an event and sell tickets or take registrations. Leave ticket_types empty for a free event. Also fill in, when the person said them: questions to ask each attendee, early-bird price_phases, and transfer_instructions (bank details) so the person only reviews and publishes. Relay the Spanish instructions and the link.
| Name | Required | Description | Default |
|---|---|---|---|
| theme | No | Look of the event page, checkout, emails and tickets. pandy: El estilo de Pandy Tickets. Sirve para cualquier evento. gala: Para recitales, galas, bodas y cenas benéficas. deportivo: Para carreras, torneos y rodadas. academico: Para congresos, simposios y graduaciones. festival: Para conciertos, fiestas y vida nocturna. comunidad: Para shows infantiles y eventos de colegio o iglesia. minimal: Para talleres y eventos corporativos. Tu foto manda. Pick the one that matches the event. Default: the organizer's last look, else pandy. | |
| title | Yes | Event name, up to 160 characters. | |
| venue | Yes | Place or city, up to 240 characters. | |
| end_at | Yes | End, Guatemala local time, YYYY-MM-DDTHH:MM, after start_at. | |
| capacity | No | Most people the event takes in total, if there is a limit. | |
| start_at | Yes | Start, Guatemala local time, YYYY-MM-DDTHH:MM. Must be in the future. | |
| template | No | Kind of event. Default conference. | |
| questions | No | Questions every attendee answers when registering or buying, up to 15. Works for free and paid events. | |
| theme_tone | No | Light or dark version of a look that has both (gala). auto follows the event image: light image, light page. Default: the organizer's last choice, else auto. | |
| title_font | No | Title font. Omit to use the look's own font. | |
| description | No | What the event is about, up to 5000 characters. | |
| accent_color | No | Brand colour as #RRGGBB, if the person gave one. | |
| price_phases | No | Early-bird style price phases, in order, up to 10. The first phase that has not ended applies. Needs paid ticket_types; a free event has no prices to phase. | |
| ticket_types | No | Paid ticket categories. Empty or omitted for a free event. | |
| transfer_instructions | No | Bank, account number and holder for paying by bank transfer, 10 to 2000 characters. The person sees it prefilled when publishing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context annotations can't convey: no publishing, no account created, and a one-time claim_url valid 48 hours with the exact reviewer flow. It leaves one gap the annotations raise — destructiveHint=true and idempotentHint=false imply repeated calls produce separate drafts, which the description never addresses.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with what it does and what it doesn't do, then fills, then guidance on optional fields. Every sentence carries operational weight, including the final instruction to relay the Spanish text and link.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 15 parameters and no output schema, the description correctly supplies the return value (claim_url) and its 48-hour lifetime, plus the human hand-off. It stops short of describing duplicate-draft behavior or any auth expectation on the calling side, which are the remaining unknowns for a mutating tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3; the description adds real semantic guidance beyond the schema by saying what to populate from the person's own words and to only include questions, price_phases, and transfer_instructions 'when the person said them.' This tells the agent not to invent optional values, which the schema cannot express.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (draft/prepare) and resource (a person's event on Pandy Tickets) plus its exact provenance (from what the person told you). Its scope clause, 'Nothing is published and no account is created,' instantly separates it from the read-oriented siblings get-event/search-events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use it when someone wants to organize an event and sell tickets or take registrations' gives a clear triggering condition, and 'Leave ticket_types empty for a free event' resolves the main branch decision. It doesn't explicitly route against the sibling tools (get-checkout-link, get-event, search-events) or say when not to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The link a person opens to buy tickets or register, with Spanish instructions to relay. For paid events (card or bank transfer), checkout opens with the ticket type and quantity already chosen. For free registration, it is the event page. Nothing is reserved or charged: the person completes it themselves.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The event slug. | |
| quantity | No | For paid events: how many tickets, default 1. | |
| ticket_type_id | No | For paid events: the ticket type id from get-event. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world. The description adds genuinely new behavioral context beyond that: 'Nothing is reserved or charged: the person completes it themselves,' which clarifies the side-effect boundary, plus the need to relay Spanish instructions. It stops short of describing error behavior for an invalid slug.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with what the link is and then branching into the paid and free cases. The 'Spanish instructions to relay' note is an embedded operational instruction rather than prose filler, so it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly carries the return-value burden by describing the link itself and how it differs for paid vs free events. Combined with 100% schema coverage and full annotation coverage, an agent has what it needs to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter is already documented, including that quantity and ticket_type_id are 'For paid events.' The description reinforces this conditional scoping ('checkout opens with the ticket type and quantity already chosen') but adds little syntax or default detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource ('the link a person opens to buy tickets or register') and distinguishes two behavior modes (paid checkout vs free registration page). It doesn't name any sibling tool, so the agent gets no explicit routing vs get-event or draft-event, but the purpose itself is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The paid/free distinction implicitly tells the agent when quantity and ticket_type_id matter, which is useful conditional guidance. However there is no explicit 'use this when' statement, no prerequisites, and no comparison to the sibling tools, so usage must be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One published event: description, ticket types with prices and whether each is sold out, what the registration form asks, and how people get in (entry.url and Spanish entry.instructions to relay).
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The event slug, from search-events or the event URL (/e/{slug}). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, and closed-world behavior, so the bar is lower. The description adds genuinely useful context beyond them: it discloses what the response contains (per-ticket sold-out flags, form questions) and flags that entry instructions are in Spanish and meant to be relayed, which is a behavioral nuance an agent would otherwise miss.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence beginning with the resource and then listing the payload contents; no filler or redundancy. It is dense but every clause maps to something the caller gets back, so nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description correctly carries the burden of describing the return contents, which it does in reasonable detail. The remaining gap is error/not-found or unpublished-event behavior, which is minor for a single-parameter read tool whose safety profile is fully covered by annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single slug parameter is fully documented in the schema, including its source (/e/{slug}), so the baseline of 3 applies. The description adds nothing about the parameter and does not need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb/resource pair ('get one published event') and enumerates the payload: description, ticket types with prices and sold-out status, registration form questions, and entry instructions. The word 'published' implicitly distinguishes it from draft-event, but no sibling is named, so differentiation is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no naming of alternatives such as search-events for discovery or draft-event for unpublished events. The only routing hint ('from search-events') lives in the schema, not the description, so the agent must infer that this is the detail-lookup step after searching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search upcoming published events on Pandy Tickets in Guatemala, soonest first, 20 per page. Each result has its public URL, dates, venue, how people get in (free, transfer or card) and the lowest price.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Text in the title, venue or description, e.g. "congreso", "Antigua", "5K". | |
| to | No | Starts on or before this date, YYYY-MM-DD, Guatemala time. | |
| from | No | Starts on or after this date, YYYY-MM-DD, Guatemala time. | |
| page | No | Page number, starting at 1. | |
| entry | No | Only events that take people this way. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds value beyond that: default ordering (soonest first), fixed page size of 20, and the filter scope (only upcoming, only published). It does not mention pagination termination or whether unpublished/draft events are ever returned, which keeps it out of the 5 band.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both front-loaded and waste-free: scope and ordering first, then result shape. Every clause carries information an agent would otherwise have to guess.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully enumerates what each result contains (public URL, dates, venue, entry method, lowest price), which is exactly the gap it should fill. The only omission is clarifying that all five parameters are optional and what the zero-parameter call returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 q, to, from, page and the entry enum fully — the baseline is 3. The description reinforces the entry semantics ('free, transfer or card') and page size but adds no format or edge-case detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb+resource with real scope: 'Search upcoming published events on Pandy Tickets in Guatemala, soonest first, 20 per page.' An agent immediately knows this is the list/search tool rather than a single-item get. It stops short of naming siblings like get-event to draw the boundary explicitly, so it lands just below the top band.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the word 'Search' plus the filter parameters suggest this is for discovering events, and the sibling name get-event implies the retrieval alternative. There is no explicit when-to-use or when-not statement, and no mention that filters are all optional and omitting them returns the full upcoming list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
draft-event7 fields changedInput schema / properties / accent_colorAdded value: +{
+ "description": "Brand colour as #RRGGBB, if the person gave one.",
+ "type": "string"
+}Input schema / properties / price_phasesAdded value: +{
+ "description": "Early-bird style price phases, in order, up to 10. The first phase that has not ended applies. Needs paid ticket_types; a free event has no prices to phase.",
+ "items": {
+ "properties": {
+ "ends_at": {
+ "description": "When the phase ends, Guatemala local time, YYYY-MM-DDTHH:MM. Omit if it ends only when its quantity sells out.",
+ "type": "string"
+ },
+ "name": {
+ "description": "Phase name, e.g. \"Preventa\", up to 60 characters.",
+ "type": "string"
+ },
+ "prices": {
+ "description": "Object mapping a ticket_types name (any letter case) to the price in quetzales in this phase, e.g. {\"General\": \"100\"}. A category left out keeps its base price.",
+ "type": "object"
+ },
+ "quantity": {
+ "description": "Tickets sold in this phase before the next one starts.",
+ "minimum": 1,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "name",
+ "prices"
+ ],
+ "type": "object"
+ },
+ "maxItems": 10,
+ "type": "array"
+}Input schema / properties / questionsAdded value: +{
+ "description": "Questions every attendee answers when registering or buying, up to 15. Works for free and paid events.",
+ "items": {
+ "properties": {
+ "kind": {
+ "description": "Answer type. choice needs options.",
+ "enum": [
+ "text",
+ "long_text",
+ "number",
+ "phone",
+ "date",
+ "choice",
+ "yes_no"
+ ],
+ "type": "string"
+ },
+ "label": {
+ "description": "The question as the attendee reads it, up to 160 characters.",
+ "type": "string"
+ },
+ "options": {
+ "description": "Only for kind choice: 2 to 20 distinct answers, up to 100 characters each.",
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 20,
+ "minItems": 2,
+ "type": "array"
+ },
+ "required": {
+ "description": "Whether the attendee must answer.",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "label",
+ "kind",
+ "required"
+ ],
+ "type": "object"
+ },
+ "maxItems": 15,
+ "type": "array"
+}Input schema / properties / themeAdded value: +{
+ "description": "Look of the event page, checkout, emails and tickets. pandy: El estilo de Pandy Tickets. Sirve para cualquier evento. gala: Para recitales, galas, bodas y cenas benéficas. deportivo: Para carreras, torneos y rodadas. academico: Para congresos, simposios y graduaciones. festival: Para conciertos, fiestas y vida nocturna. comunidad: Para shows infantiles y eventos de colegio o iglesia. minimal: Para talleres y eventos corporativos. Tu foto manda. Pick the one that matches the event. Default: the organizer's last look, else pandy.",
+ "enum": [
+ "pandy",
+ "gala",
+ "deportivo",
+ "academico",
+ "festival",
+ "comunidad",
+ "minimal"
+ ],
+ "type": "string"
+}Input schema / properties / theme_toneAdded value: +{
+ "description": "Light or dark version of a look that has both (gala). auto follows the event image: light image, light page. Default: the organizer's last choice, else auto.",
+ "enum": [
+ "auto",
+ "light",
+ "dark"
+ ],
+ "type": "string"
+}Input schema / properties / title_fontAdded value: +{
+ "description": "Title font. Omit to use the look's own font.",
+ "enum": [
+ "inter",
+ "cormorant",
+ "playfair",
+ "dm-serif",
+ "archivo-narrow",
+ "bricolage",
+ "fraunces",
+ "nunito"
+ ],
+ "type": "string"
+}Input schema / properties / transfer_instructionsAdded value: +{
+ "description": "Bank, account number and holder for paying by bank transfer, 10 to 2000 characters. The person sees it prefilled when publishing.",
+ "maxLength": 2000,
+ "minLength": 10,
+ "type": "string"
+}draft-eventget-checkout-linkget-eventsearch-eventsReal events, reviewed places, and ticket checkout across the Caribbean and Latin America.
Search upcoming public events in Israel by date, city, region or category. Read-only; no API key.
Event ticketing: create and publish events, read orders, attendees and sales analytics.
Find public events and event links, then continue to browser checkout.
Add one secure layer between your agents and this server.
Last observed