How do I use realevents-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@realevents-mcp List public events happening next week" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

realevents-mcp

by ykastelnik

Overview Schema Related Servers Score Discussions

TypeScript

Remote

RealEvents MCP Server

Create and manage events on RealEvents from any MCP-compatible AI assistant.

CodeQL npm version npm downloads License: MIT

Documentation and install snippets: https://realevents.co/mcp

Install

{
  "mcpServers": {
    "realevents": {
      "command": "npx",
      "args": ["-y", "realevents-mcp"]
    }
  }
}

For Claude Desktop on macOS, the config file is at ~/Library/Application Support/Claude/claude_desktop_config.json. For other clients, see their MCP documentation.

Related MCP server: Google Calendar MCP Server

Tools

Public, no token needed:

Tool	Description
`list_public_events`	Browse upcoming public events. Filter by format, date range or search term.
`get_event`	Get an event's public details by slug. Follows old links after a slug change.
`register_for_event`	RSVP for an attendee: going, maybe or not going, with plus-ones and a note.
`create_event`	Create a new event page. Returns the public link and the manage link.

Organizer tools, all requiring the manage token:

Tool	Description
`get_manage_event`	Full event details plus the guest list.
`list_registrations`	The guest list on its own, optionally filtered to confirmed / maybe / declined.
`get_event_stats`	Page views, head-count, remaining capacity, view-to-attendance rate.
`update_event`	Change any event detail or setting.
`duplicate_event`	Copy the event into a new draft one week later.
`cancel_event`	Mark the event cancelled. The page stays online.
`set_cover`	Set the cover image from a public image URL.
`list_comments`	Read the guest conversation: questions, replies and reactions.
`post_comment`	Post to the thread as the organizer. Visible to every guest who RSVPed.

Comments only work on events where the organizer has switched them on (update_event with allow_comments: true). Until then both comment tools return a message saying exactly that.

Cover images

set_cover takes a public image URL, not a file. MCP tool arguments are JSON text, so an assistant cannot hand a local image to the server; if the picture is on the user's computer, the manage page's upload does the job better anyway (drag and drop, preview, crop). Around 1200px wide or more looks best - set_cover says so when the image is smaller rather than silently accepting a thumbnail.

Timezones

create_event takes a timezone (an IANA name such as Europe/Paris) alongside start_datetime. Set it. The start time is interpreted in that zone, and the zone defaults to UTC, so creating an event for 19:00 without one produces a page that reads 19:00 UTC: the wrong hour for everyone outside it.

Prefer a local time with no trailing Z:

start_datetime: "2026-06-15T19:00:00"
timezone:       "Europe/Paris"

Attendance is counted in people

An event's attendance figure is a head-count: confirmed guests plus everyone they bring. A guest arriving with three others takes four of the available places, so a party can be refused on an event that still shows free rows. When that happens the error states how many places are left, so the call can be retried with a smaller party rather than reported as a failure.

Plus-ones only attach to a confirmed answer, and are capped by the event's own plus_ones_limit (0 disables them). When the organizer collects names rather than a headcount, every declared guest needs one. get_event reports both settings.

Manage token

Events created with create_event return a manage_token. Save it: it is the only way to manage the event later.

To set a default token so you don't have to pass it on every call:

{
  "mcpServers": {
    "realevents": {
      "command": "npx",
      "args": ["-y", "realevents-mcp"],
      "env": {
        "REALEVENTS_MANAGE_TOKEN": "your-token"
      }
    }
  }
}

Security

Signed with npm Provenance, built from this repository via GitHub Actions. Every published version is traceable back to the exact commit and workflow run that built it.

For maintainers: publishing checklist

Before publishing a new version:

Bump version in package.json
Verify mcpName: "io.github.ykastelnik/realevents" is still present
Bump version and packages[0].version in server.json to match
Tag vX.Y.Z and push: the publish.yml workflow handles the npm publish
Locally: ./mcp-publisher publish to sync the MCP Registry listing

License

MIT

Available Tools

6 tools

create_eventA

Creates an event page on RealEvents. The event is created with a start time only. To set an end time, duration, or to update other details (description, location, theme, cover image), use the update_event tool with the manage_token returned by this tool. Returns the public link, manage link, and slug. Save the manage link - it is the only way to edit the event later.

ParametersJSON Schema

Name	Required	Description
`title`	Yes	Event title (e.g. 'Bordeaux Tech Meetup')
`format`	No	Event format. Default: in_person
`location`	No	Physical location (for in_person or hybrid events)
`description`	No	Event description (supports HTML)
`virtual_link`	No	Virtual meeting link (for virtual or hybrid events)
`max_attendees`	No	Maximum number of attendees (no limit if not set)
`start_datetime`	Yes	Start date and time in ISO 8601 format (e.g. '2026-06-15T19:00:00Z')
`organizer_email`	No	Organizer email to receive the manage link by email

TDQS

A4.2/5.0

Behavior4/5

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

Discloses that event is created with start time only, and that manage_token is returned for later updates. With no annotations provided, description carries full burden; it covers key creation behavior but omits error conditions and permissions.

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?

Two sentences, front-loaded with purpose and immediately followed by usage guidance. Every sentence adds value with no unnecessary text.

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 tool with 8 parameters (2 required) and no output schema, the description covers return values (public link, manage link, slug) and important behavior (manage link as only edit access). Could mention error handling or output structure, but sufficient for a create tool.

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%, so baseline is 3. The description adds minimal parameter-specific meaning beyond the schema, only noting that only start_time is set initially.

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 'Creates an event page on RealEvents' and specifies the scope (only start time initially). It distinguishes from sibling tool update_event, which handles additional 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?

Explicitly mentions using update_event for setting end time, duration, etc., and emphasizes saving the manage link for editing. Does not explicitly list when not to use, but context is clear.

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

get_eventA

Get details of a public event by its slug. Returns title, date, location, registration count, and description.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	Event slug (the part after /e/ in the URL, e.g. 'bordeaux-tech-meetup')

TDQS

A4.2/5.0

Behavior4/5

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

No annotations provided, so description fully informs about read-only nature and return fields. Does not cover error handling or authentication, but for a simple GET it is sufficient.

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?

Single sentence, front-loaded with essential purpose and output information. No wasted 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 simple tool with one parameter and no output schema, description covers purpose, identifier, and return values. Missing potential error scenarios but adequate.

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 already provides a detailed description of the 'slug' parameter (100% coverage). Description adds minimal extra meaning ('by its slug') but not essential.

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 verb 'get', resource 'public event', identifier 'slug', and lists specific return fields. Distinguishes from sibling tools like list_public_events and create_event.

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?

Implicitly clear that this tool is for retrieving details of a specific public event given its slug. No explicit alternative guidance, but context of sibling tools makes usage obvious.

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

get_manage_eventA

Get full event details including the registrations list. Requires the manage token (the secret part of the manage URL) or REALEVENTS_MANAGE_TOKEN env var.

ParametersJSON Schema

Name	Required	Description	Default
`manage_token`	No	Manage token from the /manage/{token} URL. Falls back to REALEVENTS_MANAGE_TOKEN env var if omitted.

TDQS

A4/5.0

Behavior3/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It implies a read operation ('Get') and mentions token-based authentication, but does not disclose other traits like idempotency, rate limits, or error handling. The coverage is adequate but not comprehensive.

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, front-loading the purpose ('Get full event details including the registrations list') and then providing essential auth guidance. Every sentence earns its place with no redundant or extraneous content.

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 simple tool with one optional parameter and no output schema, the description covers the main purpose and authentication. However, it does not clarify the tool's niche relative to sibling 'get_event', which might be confusing if both are available. Slightly more context on when this tool is appropriate would improve completeness.

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%, and the tool description does not add any new meaning beyond what is already in the input schema. The schema already explains the manage_token parameter's source and fallback. Thus the description adds no extra semantic value.

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 the verb 'Get' and resource 'full event details including the registrations list'. It distinguishes the tool from siblings like 'get_event' (which likely returns public details without registrations) by specifying the inclusion of registrations and the requirement of a manage token.

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 explicitly states the auth requirement ('Requires the manage token or REALEVENTS_MANAGE_TOKEN env var'), guiding when to use the tool. However, it does not explicitly contrast with alternative tools like 'get_event', leaving the agent to infer when to choose this one over others.

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

list_public_eventsA

Browse upcoming public events on RealEvents. Filter by format, date range, or search term. Returns titles, dates, locations, and public links.

ParametersJSON Schema

Name	Required	Description
`date`	No	Filter by date range
`page`	No	Page number, 1-indexed
`format`	No	Filter by event format
`search`	No	Search events by title (partial match)
`per_page`	No	Items per page, max 50

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description must carry full burden. It discloses that the tool lists public events and returns specific fields, but does not mention pagination behavior, rate limits, or whether it is read-only. The behavioral transparency is limited.

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 sentence that efficiently conveys the tool's purpose, filtering capabilities, and output. No unnecessary words.

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?

No output schema exists, but the description lists returned fields. However, it omits details on default sorting, pagination behavior despite page/per_page parameters, and whether results are ordered. Moderate completeness for a list tool.

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 explains each parameter. The description adds minimal value by enumerating filter types but does not clarify details like date range enum values or search partial match behavior.

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 the tool browses upcoming public events with filtering by format, date range, or search term, and lists returned fields. It distinguishes from sibling tools like create_event or get_event which are CRUD operations.

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 usage for browsing and filtering events but does not explicitly state when to use this tool vs alternatives or any prerequisites. The context is sufficient for a simple list operation.

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

register_for_eventB

ParametersJSON Schema

Name	Required	Description
`slug`	Yes	Event slug (the part after /e/ in the URL)
`email`	Yes	Attendee email address
`last_name`	No	Attendee last name (optional)
`first_name`	No	Attendee first name (optional)

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It discloses that registration is for public events and returns a confirmation, but does not mention side effects (e.g., email sent, payment), auth requirements, or error cases. For a mutation tool, this is insufficient.

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?

Two sentences with no fluff. Every word adds value: verb, resource, input method, output summary. Ideal conciseness.

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 tool with 4 parameters and no output schema or annotations, the description is somewhat complete: it states input (slug, email) and output (confirmation with status and date). However, it omits details about optional parameters (last_name, first_name), possible status values, and error handling.

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 describes all parameters. The description adds only the phrase 'by slug' which aligns with the slug parameter. No additional meaning beyond the schema is provided.

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 the verb 'Register', the resource 'attendee for a public event', and the method 'by slug'. It also mentions the return value, distinguishing it from siblings like create_event (creates an event) and get_event (retrieves event info).

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

Usage Guidelines2/5

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

The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or conditions (e.g., event must be public). The agent is left to infer usage from context.

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

update_eventB

Update an existing event by manage token. Only provide the fields you want to change. Use this to set end_datetime, change status (e.g. 'cancelled'), or update any other detail after creation.

ParametersJSON Schema

Name	Required	Description
`slug`	No	New URL slug
`theme`	No
`title`	No	New event title
`format`	No	New event format
`listed`	No	Whether the event is listed in the public directory
`status`	No	New event status (use 'cancelled' to cancel the event)
`location`	No	New physical location
`description`	No	New description (supports HTML)
`end_datetime`	No	New end date/time (ISO 8601)
`manage_token`	No	Manage token. Falls back to REALEVENTS_MANAGE_TOKEN env var if omitted.
`virtual_link`	No	New virtual meeting link
`max_attendees`	No	New max attendees
`start_datetime`	No	New start date/time (ISO 8601)
`organizer_email`	No
`notify_on_registration`	No

TDQS

B3.4/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. Only mentions the action and mechanism, but fails to disclose behavior like error handling, idempotency, return value, or side effects. Significant gap for a mutation tool.

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?

Two concise sentences, front-loaded with key info. No wasted words.

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

Completeness2/5

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

Given 15 parameters and no output schema, the description is insufficient. Missing details on return value, prerequisites, error scenarios, and behavioral nuances.

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 has high coverage (80%), so baseline is 3. Description adds usage hint ('Only provide the fields you want to change') but no new semantic depth beyond schema descriptions.

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 action ('Update an existing event') and key requirement ('by manage token'). It distinguishes from siblings like create_event and list_public_events, though not explicitly naming them.

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?

Provides clear guidance on when to use: to update an existing event, and which fields to change ('Only provide the fields you want to change'). Includes examples like end_datetime and status. Lacks explicit when-not-to-use or alternative tools.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0

Disambiguation5/5

Each tool has a clear, distinct purpose: create, read public/private, list, register, update. No overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (e.g., create_event, get_event, list_public_events), making them predictable and easy to distinguish.

Tool Count5/5

With 6 tools, the set covers core event management operations without being overwhelming or sparse. Perfectly scoped for the domain.

Completeness4/5

Covers creation, reading (public and private), listing, registration, and updating. The only minor gap is the lack of a dedicated delete tool, but cancellation via update_event mitigates this.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Eventship
com.eventship
Run in-person events from your AI: create events, manage tickets, attendees, broadcasts.
App Automation Customer Support Marketing
2
agent-marketplace
com.bizgigz
BizGigz Agent Marketplace - register AI agents, manage API keys, and discover MCP capabilities
Agent Orchestration Developer Tools Autonomous Agents
2
Aibooma - AI Agent Registry
com.aibooma
AI agent registry — search, discover, register, and connect agents via MCP.
Agent Orchestration Search Developer Tools
2
Asyntai – AI Support Agent for Websites
com.asyntai
Run your website's AI support agent from Claude, Cursor or any MCP client. Manage the knowledge base, edit agent instructions, read conversations and leads, reply live to visitors, and check plan usage. 54 tools, OAuth sign-in, no API key. Free with every Asyntai account: https://asyntai.com/documentation/mcp/
AI & Machine Learning App Automation Customer Support
1

Related MCP Servers

Microsoft Events MCP Server
Search Developer Tools
trsdn
A
license
A
quality
C
maintenance
Enables AI assistants to search, filter, and analyze Microsoft events (conferences, workshops, webinars) using the Microsoft Events API.
Updated 14 days ago (2026-08-20 22:43 UTC)
4
2
MIT
Google Calendar MCP Server
Calendar Management Workplace & Productivity
volodymyrkoval
F
license
Not graded
quality
D
maintenance
Integrates Google Calendar with AI assistants via MCP, enabling calendar listing and event CRUD operations.
Updated 9 months ago (2025-12-07 15:15 UTC)
The Events Calendar MCP Serverofficial
Content Management Systems Calendar Management
the-events-calendar
A
license
A
quality
F
maintenance
Enables AI assistants to manage events, venues, organizers, and tickets on WordPress sites via CRUD operations.
Updated a year ago (2025-08-25 14:09 UTC)
3
38
2
ISC
Cal.com MCP Server
Calendar Management Workplace & Productivity
imubashir9
F
license
Not graded
quality
D
maintenance
Exposes Cal.com scheduling tools to AI agents via MCP, enabling listing event types, checking availability, and managing bookings (create, cancel, reschedule).
Updated 5 months ago (2026-04-02 11:39 UTC)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ykastelnik/realevents-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

RealEvents MCP Server

Install

Tools

Cover images

Timezones

Attendance is counted in people

Manage token

Security

Links

For maintainers: publishing checklist

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

The Events Calendar MCP Serverofficial

Latest Blog Posts

MCP directory API