Skip to main content
Glama
tHeMaskedMan981

Network School Events MCP Server

by tHeMaskedMan981
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

Network School Events MCP Server

A Model Context Protocol (MCP) server that provides access to Network School Luma calendar events through Claude Desktop.

Features

Tools

  • get_todays_events: Fetch all events happening today

  • get_upcoming_events: Get events in the next N days (default: 7)

  • search_events: Search events by name or description

  • register_for_event: Register for events directly with your name and email

Wiki Resources

  • Access Network School wiki pages with information about:

    • Visas (Malaysia, Singapore, travel from different countries)

    • Internet (WiFi passwords, SIM cards)

    • Getting Started guide

    • And more - easily add new wiki pages as markdown files!

Related MCP server: Google Calendar MCP Server

Installation

npm install

Build

npm run build

Development

Watch mode for development:

npm run dev

Testing

Test the API connection and event formatting:

npm test

This will fetch events from the Luma API and display them in the formatted output.

Configuration

Add to your Claude Desktop config file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "network-school-events": {
      "command": "node",
      "args": ["/Users/akashkumar/Code/ns-mcp/build/index.js"]
    }
  }
}

You can also copy the configuration from claude_config_example.json in this project.

Usage in Claude Desktop

After configuration, restart Claude Desktop. The server will automatically connect when Claude starts.

You can then ask Claude questions like:

Viewing Events:

  • "What events are happening today at Network School?"

  • "Show me upcoming events in the next 14 days"

  • "Show me events in the next 30 days"

  • "Search for hackathon events"

  • "Find events about AI or machine learning"

  • "Are there any coding events coming up?"

Registering for Events:

  • "Register me for the Vibecoding event with name John Doe and email john@example.com"

  • "Sign me up for event evt-XXX with my name and email"

  • After viewing events, you can say: "Register me for that AI Music Lab event"

Accessing Wiki Information:

  • "How do I get a visa for Malaysia from India?"

  • "What's the WiFi password?"

  • "How do I get started at Network School?"

  • "What are the visa requirements for Singapore?"

  • Claude will automatically access the relevant wiki pages to answer your questions!

Available Tools

  1. get_todays_events: Returns all events happening today

  2. get_upcoming_events: Returns events in the next N days (default: 7)

    • Parameter: days (optional, number)

  3. search_events: Searches events by name or description

    • Parameter: query (required, string)

  4. register_for_event: Register for an event

    • Parameters:

      • event_id (required, string): Event API ID from the event listing

      • name (required, string): Your full name

      • email (required, string): Your email address

      • phone_number (optional, string): Your phone number

      • timezone (optional, string): Your timezone (default: Asia/Kuala_Lumpur)

API

This server fetches data from the public Network School Luma calendar API. No authentication is required.

Adding Wiki Content

To add or update wiki pages:

  1. Create a new .md file in the wiki/ directory:

    echo "# My New Page" > wiki/my-new-page.md

  2. Add your content in Markdown format

  3. Rebuild the server:

    npm run build

  4. Restart Claude Desktop

The new wiki page will automatically be available as a resource that Claude can access!

Tips:

  • Use descriptive filenames (e.g., transportation.md, food-guide.md)

  • Include headers with # for better organization

  • Link to other resources or external URLs

  • Keep information up-to-date

Tech Stack

  • TypeScript

  • Node.js

  • @modelcontextprotocol/sdk

  • axios for HTTP requests

  • date-fns for date formatting

License

MIT

Available Tools

5 tools
get_todays_eventsB

Get all Network School events happening today

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/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 for behavioral disclosure. It states it 'gets' events, implying a read-only operation, but doesn't specify whether this requires authentication, how results are returned (e.g., format, pagination), or any rate limits. This leaves significant gaps for a tool with zero annotation coverage.

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, efficient sentence that front-loads the core purpose without any wasted words. It's appropriately sized for a simple tool with no parameters, making it easy for an agent to parse quickly.

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 the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'events' entail (e.g., structure, fields), how results are returned, or any behavioral constraints. For a tool that presumably returns data, more context is needed to guide the agent effectively.

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?

The tool has 0 parameters, and schema description coverage is 100%, so there's no need for parameter explanation in the description. The description appropriately doesn't mention parameters, earning a baseline score of 4 for not adding unnecessary information.

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 ('Get') and resource ('Network School events happening today'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'get_upcoming_events' or 'search_events', which prevents a perfect score, but the temporal scope 'today' provides some implicit distinction.

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 guidance on when to use this tool versus alternatives like 'get_upcoming_events' or 'search_events'. It implies usage for today's events only, but doesn't specify exclusions or prerequisites, leaving the agent to infer context without explicit direction.

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

get_upcoming_eventsB

Get Network School events happening in the next N days

ParametersJSON Schema
NameRequiredDescriptionDefault
daysNoNumber of days to look ahead (default: 7)

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions retrieving events but doesn't cover aspects like permissions needed, rate limits, pagination, or response format. This leaves significant gaps for a tool that likely queries data.

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, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, earning a high score for 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?

Given the simple input schema (1 parameter with full coverage) and no output schema or annotations, the description is adequate but incomplete. It covers the basic purpose but lacks details on behavior, usage context, or output, making it minimally viable with clear gaps.

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?

The input schema has 100% description coverage, fully documenting the 'days' parameter with its type, description, and default. The description adds no additional parameter details beyond what the schema provides, so it meets the baseline of 3.

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 ('Get') and resource ('Network School events happening in the next N days'), making the purpose understandable. It doesn't explicitly differentiate from sibling tools like get_todays_events or search_events, which limits it to a 4 rather than a 5.

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 guidance on when to use this tool versus alternatives like get_todays_events or search_events. It implies usage for upcoming events but lacks explicit when/when-not instructions or prerequisites, resulting in a minimal score.

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

register_for_eventC

Register for a Network School event using the event ID from the event listing

ParametersJSON Schema
NameRequiredDescriptionDefault
event_idYesThe event API ID (e.g., evt-xxx) from the event listing
nameYesFull name for registration
emailYesEmail address for registration
phone_numberNoPhone number (optional)
timezoneNoTimezone (default: Asia/Kuala_Lumpur)Asia/Kuala_Lumpur

TDQS

C2.9/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 implies a write operation ('Register') but doesn't disclose behavioral traits such as authentication requirements, rate limits, error conditions, or what happens upon successful registration (e.g., confirmation email). This leaves significant gaps 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?

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, earning its place by conveying the core action and resource.

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 this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns upon success or failure, nor does it cover behavioral aspects like side effects or error handling. The schema covers parameters well, but overall context for safe and effective use is lacking.

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 fully documents all 5 parameters. The description adds no additional meaning beyond implying the event_id comes from a listing, which is already covered in the schema. Baseline 3 is appropriate as the schema handles parameter documentation.

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 ('Register for') and resource ('a Network School event'), specifying it uses an event ID from the event listing. However, it doesn't explicitly differentiate from sibling tools like get_todays_events or search_events, which are read-only queries rather than write operations.

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 minimal guidance by mentioning the event ID comes from the event listing, but it doesn't specify when to use this tool versus alternatives (e.g., when registration is open vs. closed) or any prerequisites beyond having an event ID. No explicit exclusions or sibling comparisons are included.

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

search_eventsC

Search Network School events by name or description

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSearch query string

TDQS

C2.9/5.0
Behavior2/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 only states the search functionality without mentioning whether this is a read-only operation, what permissions are needed, how results are returned (pagination, format), or any rate limits. For a search tool with zero annotation coverage, this leaves significant behavioral gaps.

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, efficient sentence with zero wasted words. It's appropriately sized for a simple search tool and front-loads the essential information (search functionality and target resource).

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?

For a search tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the search returns (event objects, IDs, summaries), how results are structured, or any limitations (e.g., partial matches, case sensitivity). Given the lack of structured data elsewhere, the description should provide more context about the tool's behavior and output.

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 documents the single 'query' parameter. The description adds marginal value by specifying it searches 'by name or description', but doesn't provide additional syntax, format, or search behavior details beyond what the schema indicates. Baseline 3 is appropriate when schema does the heavy lifting.

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 verb ('search') and resource ('Network School events'), and specifies the searchable fields ('by name or description'). However, it doesn't explicitly differentiate from sibling tools like 'search_wiki' which searches a different resource, or 'get_todays_events'/'get_upcoming_events' which retrieve events without search functionality.

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 guidance on when to use this tool versus alternatives like 'get_todays_events' or 'get_upcoming_events'. It doesn't indicate whether this is for broad searches versus filtered retrieval, or mention any prerequisites or exclusions for usage.

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

search_wikiC

Search the Network School wiki for information about visas, internet, food, getting started, and more

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSearch query (e.g., "wifi password", "visa", "breakfast", "sim card")

TDQS

C2.9/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 the full burden of behavioral disclosure. It states the action 'search' but doesn't describe how results are returned (e.g., format, pagination), potential limitations (e.g., rate limits, authentication needs), or what happens on errors. The description adds minimal behavioral context beyond the basic action.

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?

The description is a single, efficient sentence that front-loads the core action and resource. It could be slightly more structured by explicitly listing use cases, but it avoids redundancy and wastes no words, making it appropriately concise for a simple search tool.

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?

Given the tool's low complexity (one parameter, no annotations, no output schema), the description is minimally adequate. It covers the purpose and scope but lacks details on behavioral traits, usage guidelines, and output format. Without annotations or output schema, more context on results and limitations would improve completeness for agent invocation.

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%, with the single parameter 'query' well-documented in the schema (including examples like 'wifi password'). The description adds no additional parameter semantics beyond what the schema provides, such as query syntax or result relevance. Baseline 3 is appropriate given high schema coverage.

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 verb 'search' and the resource 'Network School wiki', specifying the content scope (visas, internet, food, getting started, and more). However, it doesn't explicitly differentiate from sibling tools like search_events, which searches events rather than wiki content, though this distinction is implied by the resource type.

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 guidance on when to use this tool versus alternatives. It mentions the types of information available (visas, internet, etc.) but doesn't specify prerequisites, exclusions, or compare it to sibling tools like search_events for event-related queries. Usage is implied by the content scope but not explicitly stated.

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

B3.4/5.0
Disambiguation4/5

Most tools have distinct purposes: get_todays_events and get_upcoming_events are clearly differentiated by time frame, register_for_event handles registration, and search_events focuses on event discovery. However, search_wiki overlaps slightly with search_events in being a search function, though their domains (events vs. wiki content) differ enough to avoid major confusion.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case, such as get_todays_events, register_for_event, and search_events. This uniformity makes the tool set predictable and easy for an agent to understand and navigate without naming conflicts.

Tool Count5/5

With 5 tools, this server is well-scoped for managing school events and related information. The count is appropriate as it covers core operations like event retrieval, registration, and searching without being overly sparse or bloated, fitting typical server purposes efficiently.

Completeness3/5

The tool set covers key event operations like retrieval, search, and registration, but lacks update or delete capabilities for events, which could be gaps in a full lifecycle. Additionally, while search_wiki adds value, it might not fully integrate with the event domain, leaving minor coverage issues for a comprehensive event management system.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • MCP Kynhood Events Server

    Gowtham-3004
    F
    license
    Not graded
    quality
    D
    maintenance
    Enables Claude Desktop to interact with the Kynhood Events API, allowing users to list events with pagination and retrieve detailed event information through natural language queries.

  • Google Calendar MCP Server

    ampcome-mcps
    F
    license
    B
    quality
    D
    maintenance
    Enables Claude to manage Google Calendar events, schedules, and meetings through natural conversation. It supports viewing calendars, creating Google Meet events, and searching for upcoming activities using Nango for authentication.
    6

  • Apple EventKit MCP Server

    harriscarl
    F
    license
    Not graded
    quality
    F
    maintenance
    Provides Claude Desktop with access to Apple Calendar and Reminders on macOS for managing schedules and tasks through natural language. It supports comprehensive operations like creating, editing, and searching events and reminders, along with a custom hashtag-based tagging system.
    3

  • m2k-calendar MCP server

    weiting-tw
    F
    license
    Not graded
    quality
    B
    maintenance
    Enables Claude to query and manage Mail2000 calendar events, including agenda, search, booking, updating, and deleting events through natural language.

Latest Blog Posts

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/tHeMaskedMan981/ns-mcp'

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