Skip to main content
Glama
Blackie360

Luma Events MCP Server

by Blackie360
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

List Luma events

list_events
Read-only

Retrieve calendar events filtered by date range, approval status, and pagination to view scheduled or pending entries.

Instructions

List events from the calendar attached to the configured API key.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
afterNoOnly events after this ISO 8601 datetime.
beforeNoOnly events before this ISO 8601 datetime.
statusNoFilter by calendar submission status. Defaults to approved.
pagination_limitNo
pagination_cursorNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.7.5
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / after / pattern
      Added value: +"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z))$"
    • addedInput schema / properties / before / pattern
      Added value: +"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z))$"
  2. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already cover the read-only and open-world nature of the operation, so the description does not need to restate safety. It adds useful authorization/source context ('configured API key'), but it does not disclose behavioral details like the default status filter or pagination behavior.

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 front-loaded sentence with no filler. Every word contributes to identifying the action, resource, and data source.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a five-parameter list operation with no output schema, the description is minimally adequate but leaves return shape, default status, and cursor semantics unstated. It relies heavily on the schema and agent inference rather than being self-sufficient.

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

Parameters2/5

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

The schema documents after, before, and status, but pagination_limit and pagination_cursor have no descriptions. The tool description adds no parameter-level meaning and does not compensate for the undocumented pagination semantics at 60% 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 identifies the action ('List'), the resource ('events'), and the data source ('calendar attached to the configured API key'). It is not a tautology and naturally distinguishes this tool from event mutation siblings like create_event and update_event.

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 implies this tool is for listing events from the configured API key's calendar, but it does not explicitly contrast it with alternatives such as get_event for a single event, list_guests, or registration_summary. There is clear context but no when-not-to-use guidance.

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

Deploy Server

Other Tools