School Timetable Builder

School Timetable Builder creates a complete weekly timetable for a primary or lower-secondary school: one timetable per class and one per teacher, including rooms.

Nothing to install or learn: describe your school in the chat, in your own language. Your AI interviews you one topic at a time and checks the data with the service in seconds, for example whether there are enough qualified teachers and enough time in the week.

MCP connector

Server URL: https://timetable-builder.wilbek.workers.dev/mcp
Login: None
Protocol: MCP 2025-11-25
Instructions: School Timetable Builder creates complete weekly timetables for primary/lower-secondary schools (classes, teachers, subjects, rooms). All rules are firm rules: teacher availability (block any day or lesson, e.g. a teacher not available after lesson 4 on Fridays or at another school on Mondays), blocked lessons for a class or grade, teacher workload, planning time at school placed in the teacher's timetable with no empty gaps by default, fixed teachers, double lessons, min/max lessons per day per subject, shared rooms, and classes taught at the same time. Not supported: soft "if possible" preferences weighed against each other, whole-day events, student-choice course timetables. Workflow:
Call FIRST and follow it: interview the user in their own language, one topic at a time, and build the 8 input files.
Let the user give real teacher names as usual, but before sending anything replace each name with a code (T01, T02, ...). Show the user the code list once and keep it in the conversation - you need it to translate the result back.
Call (free, seconds) and fix every problem with the user before going on.
Call only after a successful validation and the user's go-ahead. It takes about 5-8 minutes (longer if others are queued).
In the SAME reply, keep calling with the job_id until it is done (each call waits up to ~25 seconds). Do not end your reply while it runs and never promise to tell the user later - you cannot send a message on your own, so the user would be left waiting. If the result is IMPOSSIBLE or an error: explain it to the user, suggest changes and let the user choose. Never change the school's rules or data yourself (fixed teachers, double lessons, daily limits, groups, lesson numbers ...) and never start a new before the user has agreed to the change - each job counts against a daily limit.
The service does NOT store anything for the user: input files are deleted right after each job, results within 24 hours, and the full-result link expires after 1 hour. So as soon as the timetable is ready: fetch both views (classes and teachers), replace every teacher code with the real name, and give the user the finished timetable as files in this chat (e.g. a spreadsheet with one sheet per class and one per teacher, or a printable document), plus a 'School data' file with all data used so they can re-run later (see the guide). Those files are the user's only copy. Never say the timetable is saved in the service, can be fetched again later, or can be shared via a link from it.
After handing over the finished timetable, add ONE short line (once per conversation) that the user can tell you if they have feedback for the developer. If the user then gives feedback, pass it on with . The service is free to use, with shared limits.

Tools

Reads data3

Changes data2

Skills

None in the store listings or on the server

MCP connector

Server URL

https://timetable-builder.wilbek.workers.dev/mcp

None

Protocol

MCP 2025-11-25

Instructions

School Timetable Builder creates complete weekly timetables for primary/lower-secondary schools (classes, teachers, subjects, rooms). All rules are firm rules: teacher availability (block any day or lesson, e.g. a teacher not available after lesson 4 on Fridays or at another school on Mondays), blocked lessons for a class or grade, teacher workload, planning time at school placed in the teacher's timetable with no empty gaps by default, fixed teachers, double lessons, min/max lessons per day per subject, shared rooms, and classes taught at the same time. Not supported: soft "if possible" preferences weighed against each other, whole-day events, student-choice course timetables. Workflow:

Call FIRST and follow it: interview the user in their own language, one topic at a time, and build the 8 input files.

Let the user give real teacher names as usual, but before sending anything replace each name with a code (T01, T02, ...). Show the user the code list once and keep it in the conversation - you need it to translate the result back.

Call (free, seconds) and fix every problem with the user before going on.

Call only after a successful validation and the user's go-ahead. It takes about 5-8 minutes (longer if others are queued).

In the SAME reply, keep calling with the job_id until it is done (each call waits up to ~25 seconds). Do not end your reply while it runs and never promise to tell the user later - you cannot send a message on your own, so the user would be left waiting. If the result is IMPOSSIBLE or an error: explain it to the user, suggest changes and let the user choose. Never change the school's rules or data yourself (fixed teachers, double lessons, daily limits, groups, lesson numbers ...) and never start a new before the user has agreed to the change - each job counts against a daily limit.

The service does NOT store anything for the user: input files are deleted right after each job, results within 24 hours, and the full-result link expires after 1 hour. So as soon as the timetable is ready: fetch both views (classes and teachers), replace every teacher code with the real name, and give the user the finished timetable as files in this chat (e.g. a spreadsheet with one sheet per class and one per teacher, or a printable document), plus a 'School data' file with all data used so they can re-run later (see the guide). Those files are the user's only copy. Never say the timetable is saved in the service, can be fetched again later, or can be shared via a link from it.

After handing over the finished timetable, add ONE short line (once per conversation) that the user can tell you if they have feedback for the developer. If the user then gives feedback, pass it on with . The service is free to use, with shared limits.