Loading ToolBench
Model Context Protocol server for vibeboard conference management system. Provides tools to read and write conference data including events, sessions, speakers, agendas, and call-for-papers forms. Supports two tiers: public (read-only, no auth) and keyed (organizer view with write capabilities).
Strong tool definitions with excellent descriptions (avg 180 chars, well above baseline 72 chars for params). All 9 tools have clear verb-noun naming and comprehensive parameter documentation. Input schemas are complete with proper types, enums, and constraints. Output schemas are not explicitly documented in the source, which is the primary gap. Tool annotations (readOnlyHint, destructiveHint) are present and correct. Two write tools properly gate behind confirm:true. Error handling guidance is implicit but not formalized in response schemas.
The published schedule grouped into days in the event's own timezone, each talk with its time, room and speakers. If the organisers have not published the programme yet this says so rather than guessing. With an organiser API key it also returns the working draft grid before publication, the talks still waiting for a slot, and any room or speaker clashes.
What it takes to submit: whether the call is open, when it closes, and every question on the form.
Everything the public front page of one conference states: name, description, dates, timezone, venue, whether the programme is published, whether the call for papers is open, and the links a human would use (agenda, speakers, calendar feed, submission form). With an organiser API key this also reports the counts an organiser runs the event by — submissions waiting on a decision, decisions not yet emailed, unscheduled accepted talks and scheduling conflicts.
The talks on a conference programme — title, abstract, track, format, room, time and speakers — with optional filtering by track, by format, or by a word in the title or abstract. Publicly this returns only talks that are accepted, approved and published; proposals still under review are never included. With an organiser API key it returns every submission, filterable by status, with decision notes and reviewer score averages.
Output schemas not documented. Tool descriptions state what is returned (e.g., 'Everything the public front page states'), but formal output schema definitions are absent from the source. LLMs cannot plan downstream tool calls or extract specific fields without knowing the response structure.
Error handling not formalized. Descriptions mention what tools will NOT return (e.g., 'proposals still under review are never included'), but no structured error responses or recovery guidance are documented. LLMs cannot distinguish retryable from fatal failures.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | 2026-07-28+ | v2 |
The speaker line-up: name, job title, company, bio and the talks each person is giving. Publicly this is the same directory the website shows and never includes contact details. With an organiser API key it covers everyone on the event's roster, including people whose talk is still undecided, and includes their email address.
Lists the conferences on this vibeboard instance whose programme has been published, with dates, location and how many talks and speakers are on each. Events that have not published a programme yet are not listed, exactly as on the website. Start here when you don't know an event's slug.
Put an accepted talk in a room and time slot, refusing — and naming the clash — if it would double-book a room or a speaker.
Exactly who is queued to hear from you and precisely what they would be told. Sends nothing.
Accept, decline or shortlist a proposal. Stages the decision exactly as the buttons do, and emails nobody.
Parameter 'event' is optional in write tools (place_session, set_submission_decision) with unclear fallback. Description says 'leave it out and the tool answers for the event your API key belongs to', but no guidance on what happens if the key is invalid or the event slug is wrong.
Pagination limit defaults to 50 but no guidance on when to increase or decrease. Tools like get_sessions and get_speakers accept limit (1 - 100) but descriptions do not explain the performance or token cost implications of large result sets.
Confirmation gate (confirm:true) is documented in descriptions but no explicit guidance on what the dry-run response contains. LLMs need to know: does confirm:false return the exact plan, or a summary? Can they trust the preview to match the actual execution?