Skip to main content
Glama
Sign In

Nevent MCP

by io.github.nevent-dev
OverviewDiscussionsAdmin

nevent_list_events

Read-only

List the events of the active tenant, one page at a time (nev-api GET /events). Use it to find an event ID before reading its sales with nevent_event_sales_provenance, or to look an event up by name. By default it returns upcoming events ordered by start date; pass future=false for past events, search for text on the name, nature=TICKETED for events with ticket sales, active_only=true to hide inactive ones. Returns { events, page, page_size, totalElements, totalPages }: each event carries id, name, state, active, url, startDate, endDate, ticketsSold, ticketsAvailable, ticketsNumber, location, tenantId and tenantName. Zones, ticket types and experiences are left out to keep the response small. Always paginated (default 25 per page, max 100): request the next page with page+1 while page+1 < totalPages. Scoped to the active tenant by the session JWT; use nevent_switch_tenant to change it.

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": "nevent_list_events"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageNoZero-based page number. Default 0.
sortNoField to sort by. Default venue.startDate. description.name sorts by event name. Any other value is not accepted (nev-api would silently fall back to venue.startDate).
orderNoSort direction. Default asc.
futureNotrue (default) lists upcoming events; false lists past events. Use false to look up the event of a past campaign or sales period.
natureNoFilter by event nature: TICKETED (ticket sales), WAITLIST, REGISTRATION (free sign-up) or UNKNOWN. Sales provenance only makes sense for TICKETED events.
searchNoFree-text search on the event name.
page_sizeNoEvents per page (1-100). Default 25.
active_onlyNotrue returns only active events.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnlyHint/destructiveHint annotations, the description discloses pagination mechanics (default 25, max 100, page+1 while page+1 < totalPages), tenant scoping via session JWT, and what is deliberately omitted (zones, ticket types, experiences). It even lists the returned fields, so the agent knows exactly what comes back.

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

Conciseness4/5

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

Front-loaded with the core action and alternative, then filter guidance, then return shape and pagination. Dense but well-ordered; a couple of clauses (return field list) border on verbosity given there is no output schema, but they earn their place for an agent constructing follow-up calls.

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 an 8-parameter read-only list tool with no output schema, the description supplies pagination rules, filter semantics, tenant scoping, and the exact response shape — everything an agent needs to call it and iterate pages correctly.

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 meaningful usage context beyond the schema — e.g. that future=false targets past campaigns and that sales provenance only matters for TICKETED events. It largely mirrors schema documentation, so it does not rise to a full 5.

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?

States a specific verb and resource (list events of the active tenant) plus the underlying endpoint (GET /events), and explicitly distinguishes itself from nevent_event_sales_provenance by positioning itself as the way to find an event ID first. An agent can tell this apart from the sales tool without opening either 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?

Gives explicit when-to-use guidance ('find an event ID before reading its sales', 'look an event up by name') and names both the alternative (nevent_event_sales_provenance) and the tenant-switching sibling (nevent_switch_tenant). It also maps individual filters to concrete use cases (future=false for past campaigns, nature=TICKETED for sales provenance).

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

All Nevent MCP 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