Skip to main content
Glama
Sign In
evite-mcp

evite-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

evite_list_events

Read-only

List and filter Evite events you host or attend, with pagination, status filters, and brief, compact, or full response views.

Instructions

List your Evite events (GET /services/events/v1/). Returns events plus a totals breakdown. filterBy=others returns events where you are a guest. view "brief" answers one line per event (title — start — status), upcoming events only unless status is given, 25 per page unless numResults is given.

Input Schema

NameRequiredDescriptionDefault
viewNoResponse shape. compact strips image/avatar URLs from the response; "full" returns Evite's payload untouched. No field projection: this server has no verified record of which Evite fields matter, and inventing one would risk dropping a field a caller needs. "brief" answers one line per event — title — <ISO start or "no date"> — <status> — inside the untrusted-data envelope as `data`, with "-- none" for no events and "-- more" when the page came back full.
filterNoFree-text search over event titles.
offsetNoPagination offset.
statusNoRepeatable status filter (upcoming, draft, archived, past, canceled). Default: upcoming + past; with view "brief", upcoming only.
filterByNoWhose events to list: all, host (you are hosting), or others (you are a guest).all
numResultsNoPage size.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.4.0
    • removedInput schema / properties / status / default
      Removed value: -[
-  "upcoming",
-  "past"
-]
    • changedInput schema / properties / status / description
      Previous value: -"Repeatable status filter (upcoming, draft, archived, past, canceled)."New value: +"Repeatable status filter (upcoming, draft, archived, past, canceled). Default: upcoming + past; with view \"brief\", upcoming only."
    • changedInput schema / properties / view / description
      Previous value: -"Response shape: \"compact\" (default) drops fields the response already carries elsewhere; \"full\" returns every field this server understands. compact strips image/avatar URLs from the response; \"full\" returns Evite's payload untouched. No field projection: this server has no verified record of which Evite fields matter, and inventing one would risk dropping a field a caller needs."New value: +"Response shape. compact strips image/avatar URLs from the response; \"full\" returns Evite's payload untouched. No field projection: this server has no verified record of which Evite fields matter, and inventing one would risk dropping a field a caller needs. \"brief\" answers one line per event — title — <ISO start or \"no date\"> — <status> — inside the untrusted-data envelope as `data`, with \"-- none\" for no events and \"-- more\" when the page came back full."
    • changedInput schema / properties / view / enum
      Previous value: -[
-  "compact",
-  "full"
-]New value: +[
+  "compact",
+  "full",
+  "brief"
+]
  2. Changed1 schema field changedv1.0.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  3. Changed1 schema field changedv0.8.0
    • addedInput schema / properties / view
      Added value: +{
+  "description": "Response shape: \"compact\" (default) drops fields the response already carries elsewhere; \"full\" returns every field this server understands. compact strips image/avatar URLs from the response; \"full\" returns Evite's payload untouched. No field projection: this server has no verified record of which Evite fields matter, and inventing one would risk dropping a field a caller needs.",
+  "enum": [
+    "compact",
+    "full"
+  ],
+  "type": "string"
+}
  4. First observedv0.5.0

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 and openWorldHint=true, so safety is covered; the description still adds real behavioral detail beyond them — the totals breakdown, the paging default of 25, the upcoming-only default, and the untrusted-data envelope with "-- none"/"-- more" sentinels for empty and full pages. It stops short of describing error behavior or rate limits, which keeps it out of the top band.

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?

Purpose and return shape are front-loaded, then defaults and mode-specific behavior follow in one dense paragraph with no filler sentences. It is slightly run-on with several clauses stacked in a single sentence, which costs a little readability but wastes no words.

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?

For a six-parameter, no-required-argument list tool with no output schema, the description covers what comes back (events, totals, brief lines), the paging default, and the status window — enough to call it correctly. A note on what distinguishes the compact vs full payloads beyond the schema, or on large-result behavior, would make it fully complete.

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 contributes defaults the schema does not state: 25 per page unless numResults is given, and upcoming-only when no status is supplied. The filterBy=others and view "brief" notes largely restate the schema's enum documentation, so the added value is real but modest.

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 ("List your Evite events") plus the underlying endpoint GET /services/events/v1/, and adds the return shape ("events plus a totals breakdown"). This clearly separates it from single-record siblings like evite_get_event and from evite_list_templates without the agent needing to open a schema.

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 gives concrete selection cues: filterBy=others for events where you are a guest, and view "brief" for a one-line-per-event answer. It also states the default window (upcoming events only unless status is given). It never explicitly names a sibling alternative such as evite_get_event for detail or evite_rsvp_summary for RSVP counts, so routing is implied rather than spelled out.

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