Loading ToolBench
MCP server for Network School Luma events - provides tools to fetch, search, and register for events, plus access to a wiki with information about visas, internet, food, and getting started
The server defines 5 tools with explicit names, descriptions, and input schemas. However, there are significant gaps in parameter descriptions, output schema documentation, and error handling guidance. Tool naming follows verb_noun convention (get_*, search_*, register_*), which is good. Parameter schemas are present but many lack descriptions or constraints. The descriptions are concise but sometimes vague, for example, 'Get all Network School events happening today' doesn't explain what fields are returned or what the agent should do with the result. Output schemas are not documented anywhere in the code. Error handling returns text responses with isError flags but provides no recovery guidance (e.g., 'query parameter is required' doesn't suggest what query format is expected). The server is functional for basic read operations but lacks the polish and detail expected of production-grade tools.
Get all Network School events happening today
Get Network School events happening in the next N days
Register for a Network School event using the event ID from the event listing
Search Network School events by name or description
Search the Network School wiki for information about visas, internet, food, getting started, and more
Output schemas not documented. No field-level descriptions for what each tool returns (event structure, wiki page structure, etc.). LLMs cannot plan downstream tool calls or extract the right data without knowing the response format.
Vague tool descriptions. E.g., 'Get all Network School events happening today' doesn't explain WHEN to use this vs get_upcoming_events, what fields are returned, or how the result should be interpreted. Descriptions should be 50 - 200 chars and answer: What, When, What Returns.
register_for_event has a phone_number parameter with default empty string, which may cause silent failures if the API requires validation. Defaults must not cause data loss or unexpected side effects.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Error messages provide no recovery guidance. E.g., 'query parameter is required and must be a string' tells the LLM to retry but not what a valid query looks like. Pattern: 'Invalid status: got "pending", must be one of: open, in_progress, resolved, closed'.
event_id parameter description says 'The event API ID (e.g., evt-xxx) from the event listing', includes an example value, which LLMs tend to reuse literally. Use enum constraints or regex patterns instead.
timezone parameter in register_for_event lacks validation. Should either: (a) document the valid timezone format/examples, (b) provide an enum of supported timezones, or (c) note that invalid timezones will be rejected with a helpful error listing valid options.
days parameter in get_upcoming_events has type 'number' but validation checks 'typeof days !== "number" || days < 1'. Schema should specify minimum: 1, and ideally maximum (e.g., 365) to prevent absurd values.
No pagination or result limits documented. If get_todays_events or get_upcoming_events return hundreds of events, the response will bloat the context window. Pattern: accept limit and offset/page params, return total count, cap results at 20 - 50.