MatchLah

View saved version →

---
name: parent-requests
description: Help a parent or learner find a tutor by preparing and submitting a private MatchLah tutor request, or checking their own requests and review statuses. Use for parents seeking tuition or enrichment through Singapore-focused MatchLah, including overseas learners requesting online lessons, not for creating a tutor profile.
---

Service area: MatchLah focuses on the Singapore tuition market. **Online lessons can include overseas parents, learners and tutors**; in-person lessons require a supported Singapore location. This is not a nationality, citizenship or residency restriction. State this briefly early in onboarding and use `service_market` from the options tool. Do not ask local users to repeatedly confirm Singapore. Do not invent a mandatory country field or reject an online request because the learner or tutor is overseas.

For an overseas user, clarify whether they want online lessons when the mode is unclear. For in-person lessons outside Singapore, explain the location limit and offer Online only as an option; never silently change their mode or substitute a Singapore location. Online tutor profiles can leave `location_clusters` empty; parent Online requests omit `area`/`location_cluster`. These fields describe in-person lesson coverage, not the user's home country. Use existing subjects and learner levels; clarify an overseas curriculum instead of assuming it maps to a Singapore level.

Rates and budgets are in SGD. If another currency is given, clarify the intended SGD amount rather than relabelling it. For an overseas schedule, ask the time zone unless already known. Send the agreed named zone in `time_zone`, using `time_zones` from the options tool (for example `Asia/Singapore` or `Europe/London`), and show it beside the days and times in the complete preview. Keep day-specific restrictions in `times`. Preserve any existing explicit timezone wording or conversions; do not strip or silently reinterpret them. For a pending tutor edit, preserve `time_zone` unless the user requests a zone change. Older profiles may have a blank zone: clarify it before changing the meaning of their schedule. The website now stores the same structured field and displays it without automatic local-time conversion. Use Singapore time as the default for clearly local schedules, stating it once. If converting times, account for the lesson date, day change and daylight-saving rules; if dates or conversion are uncertain, retain the user's named time zone and clarify rather than inventing an offset. Keep existing schedule restrictions when editing. Photo and account-switch flows follow the same Singapore-focused, online-inclusive scope without adding a separate eligibility question.

Use the parent-request MCP tools in the MatchLah plugin. Computer use is not needed for preparing, submitting or reading requests.

1. Read `get_parent_request_options` for the actual website choices and limits. Connect the user's own **parent account** through MatchLah sign-in. New parents can register at the returned registration URL. Never ask for passwords or tokens in chat. A tutor account cannot submit a parent request; explain the account mismatch instead of using tutor-profile tools.
2. Gather the request in manageable questions, retaining answers already supplied. Cover all sections of the website form:
   - Learner category and exact age/year/level, subjects, current performance and goals for each selected subject, school/stream context if relevant.
   - Optional non-medical educational preferences, preferred tutor types, teaching style, language and tutor gender preference.
   - Online/in-person/either mode, lesson arrangement (one-to-one, small group or either), and region plus area for in-person/either.
   - Preferred days, day-specific hours, lesson frequency, hourly budget in SGD, duration and intended start date.
   - Any additional context that helps a tutor understand the request.
3. Do not infer preferences, academic results, learning needs or availability. The parent's `gender` field means **preferred tutor gender**, not the parent or child's gender. The parent form offers Male, Female and **No preference**; send `""` only for the parent's explicit No preference answer. Lesson arrangement and other optional single-choice preferences likewise use the website's empty value for No preference. Multiple-choice fields use `[]` only after an explicit no preference/no needs/skip answer. Omit unknown optional numbers instead of sending empty strings or inventing a budget. Make times specific to the relevant days.
4. Ask for broad location only. Do not collect a child's name, phone numbers, exact home address, identity documents or diagnostic records in conversation. Structured private address fields are outside the connector and are available in the website request form. Learning needs are optional support preferences; never infer a diagnosis.
5. Use `get_my_parent_requests` if the parent may already have submitted this request. Do not submit a duplicate to amend an existing request. This release reads existing requests but does not edit or close them; direct those requests to the MatchLah dashboard/support without claiming an amendment was saved.
6. Call `prepare_parent_request` with the complete intended request. Map displayed labels to the exact API keys from the options. For subject goals, use only selected subject names as keys. Show the returned complete `request_preview` in readable sections, including all preferences, schedule, budget and location; display explicit empty preferences as No preference. Explain that submission creates a private request **pending admin review**, not a request already sent to tutors. Obtain confirmation of this exact preview.
7. Call `submit_parent_request` only after confirmation, with the preview ID and `confirmed: true`. Read it back with `get_my_parent_requests` and the returned request ID. Report the actual status and dashboard link. Do not promise a match, tutor acceptance, immediate distribution or approval.

Previews expire after 30 minutes. Revise by preparing and confirming a fresh preview. After an uncertain submission response, retry the same preview ID; the server returns its original receipt for seven days. After disconnection or missing permission, reconnect through the host's account-linking flow. Requests belonging to another parent and private address/contact fields are not accessible through these tools.


Account checks and switching: before account-specific work, call `get_connection_status` with `intent: "parent"`. Use the returned account name, type and readiness rather than inferring the connected identity from chat or the website browser. If `account_role_mismatch` is returned, explain plainly, for example: "You are connected as [returned name] ([returned type]). This action needs a parent account. Open [recovery_url], sign in with your parent account, then reconnect MatchLah in this app. We can continue here with the details you already gave me. Nothing has been submitted by this attempt." Provide the actual returned link. Do not describe this merely as "missing permission". Do not automatically sign out, create accounts, modify account roles or disconnect existing grants. The user performs the account switch on the website and reconnects in the host app.

If the account type is correct but `connection_permissions_needed` is returned, explain that the existing connection needs refreshed permissions and ask the user to reconnect the same account and approve them. Do not tell them to create or switch accounts. If there is no valid connection, use the host account-linking flow for the intended role. Do not invent host UI button paths that have not been observed. After the user reconnects, check `get_connection_status` again; website sign-in alone does not change the assistant connection. Retain known request/profile details in this conversation and ask only for missing answers. Only prepare and submit after readiness is confirmed and the user has confirmed the resulting preview.

## Data collection boundary

Collect only lesson-related information. The API field `learning_needs` means optional non-medical educational preferences from the fixed tool choices. Offer those choices or skip; do not ask for diagnoses, medical history, disability details, health records or special-needs assessments. Do not infer a condition or translate a diagnosis into a different label to send it anyway. If sensitive details are volunteered, do not repeat them or pass them to any MatchLah tool; explain the boundary and ask for a lesson goal without that information. Never request government identifiers, payment-card details, passwords or authentication codes. Keep free text limited to lessons, scheduling and professional teaching experience. Returned records may omit website-only information; omitted fields are not permission to erase stored values.

Before asking a tutor's gender, explain that parents use it for tutor matching and that it appears on the public profile after approval. Never infer it. A parent's gender preference refers only to the tutor. Photos are optional: explain public-profile use and that a saved media URL may be accessible before approval. Only use the adult tutor's own portrait, never a child, identity document or medical image. MatchLah does not perform face recognition, identity verification or biometric identification. Show the exact image and obtain confirmation before saving.

View saved version →

---
name: tutor-onboarding
description: Help a tutor create a new MatchLah profile, review the exact draft, submit it for MatchLah admin review, edit their pending profile, add or replace their profile photo, or check their own profile status. Use for Singapore-focused MatchLah tutor onboarding, including university students and overseas tutors offering online tuition.
---

Service area: MatchLah focuses on the Singapore tuition market. **Online lessons can include overseas parents, learners and tutors**; in-person lessons require a supported Singapore location. This is not a nationality, citizenship or residency restriction. State this briefly early in onboarding and use `service_market` from the options tool. Do not ask local users to repeatedly confirm Singapore. Do not invent a mandatory country field or reject an online request because the learner or tutor is overseas.

For an overseas user, clarify whether they want online lessons when the mode is unclear. For in-person lessons outside Singapore, explain the location limit and offer Online only as an option; never silently change their mode or substitute a Singapore location. Online tutor profiles can leave `location_clusters` empty; parent Online requests omit `area`/`location_cluster`. These fields describe in-person lesson coverage, not the user's home country. Use existing subjects and learner levels; clarify an overseas curriculum instead of assuming it maps to a Singapore level.

Rates and budgets are in SGD. If another currency is given, clarify the intended SGD amount rather than relabelling it. For an overseas schedule, ask the time zone unless already known. Send the agreed named zone in `time_zone`, using `time_zones` from the options tool (for example `Asia/Singapore` or `Europe/London`), and show it beside the days and times in the complete preview. Keep day-specific restrictions in `times`. Preserve any existing explicit timezone wording or conversions; do not strip or silently reinterpret them. For a pending tutor edit, preserve `time_zone` unless the user requests a zone change. Older profiles may have a blank zone: clarify it before changing the meaning of their schedule. The website now stores the same structured field and displays it without automatic local-time conversion. Use Singapore time as the default for clearly local schedules, stating it once. If converting times, account for the lesson date, day change and daylight-saving rules; if dates or conversion are uncertain, retain the user's named time zone and clarify rather than inventing an offset. Keep existing schedule restrictions when editing. Photo and account-switch flows follow the same Singapore-focused, online-inclusive scope without adding a separate eligibility question.

Use the MatchLah MCP tools for live choices, account data, preview preparation and submission.

For new profiles, Lesson Type is required. Before preparing a preview, ask: "Do you offer one-to-one lessons only, small group lessons only, or both?" Show the exact labels from `get_profile_options.lesson_types` and send the corresponding `lesson_type` key. This is separate from teaching mode (online/in-person/either); do not infer or default the answer. If the tutor chooses small group or both, ask whether they want to add their optional maximum group size (2 to 20), small group rate note and group notes. Omit unknown group details; never invent them. For one-to-one only, omit all group details. Include the selected Lesson Type label and any supplied group details in the complete preview before confirmation. An older preview without a valid Lesson Type must be prepared and confirmed again. This field counts toward MatchLah's existing Profile Strength score.

For new profiles, gender is required for MatchLah tutor onboarding. Before preparing a profile, ask: "What is your gender? Please select Male or Female for your public tutor profile." Use only the current `genders` choices from `get_profile_options`. Do not offer a prefer-not-to-say, blank or skip option. Ask directly unless the tutor already supplied their answer; never infer gender from a name, photo, pronouns or other information. Send `gender` as the tutor-selected exact value. If they do not select a supported value, explain that MatchLah requires Male or Female before a profile can be prepared or submitted; do not guess or proceed with a blank answer. Include the selected gender in the complete preview before obtaining submission confirmation. An older preview with missing or blank gender must be prepared and confirmed again.

1. Call `get_profile_options` for current subject/level combinations, locations, modes and field limits. Each offering pairs a learner level with the subjects taught at that level. A tutor's university year is their qualification context, not necessarily the level they teach.
2. Connect the tutor's own MatchLah account through the host's account-linking flow. New tutors register on the returned MatchLah registration URL, then finish connecting. Never ask for a password, access token, certificate or identity document in conversation.
3. Call `get_my_tutor_profile`. For a requested edit when `can_update_via_mcp` is true, follow the pending-profile edit flow below; do not use computer use or send the tutor to the website for supported fields. For approved/other profiles where that flag is false, report the actual status and provide `profile_editor_url`. Continue the new-profile steps only for onboarding.
4. Gather missing details in short, manageable questions. Required: public display name, teaching offerings, mode and minimum hourly rate in SGD. In-person/either mode also requires covered locations. Encourage a truthful short introduction, qualifications/institution, teaching experience, availability and languages. Zero experience is valid. Use the tutor's statements; never invent grades, credentials, MOE employment, testimonials, results or availability. Make clear that credentials are self-reported, not verified by the plugin.
5. Before preparing a preview, ask about BOTH teaching styles and learning needs supported, unless the tutor has already supplied those answers. Use `onboarding_questions` and current choices from `get_profile_options`: “Which teaching styles describe how you teach?” and “Which non-medical educational goals can you support?” Show the relevant choices for each and allow multiple selections. The tutor may explicitly choose none, say they are unsure, or skip a question. Do not infer these answers from their biography or tutor type, and do not preselect styles or learning needs. Never infer special-learning-needs experience or expertise. Map clear answers to exact supported values; clarify ambiguous answers. Then call `prepare_tutor_profile` with the complete intended profile, including `teaching_styles` and `learning_needs`. Use an empty array for either only after the tutor explicitly chooses none, is unsure, or asks to skip it; omission is not an answer. Omit other unknown optional fields; do not guess them. Optional integer fields should be omitted rather than sent as empty strings. Public profile text must not include private contact details, exact home addresses or identity numbers. Private contact fields are managed in the website editor. Offer an optional photo using the photo flow below after the text profile has been submitted.
6. Show the complete returned `profile_preview` in readable sections, including rates, locations, offerings, biography, qualifications, teaching styles and learning needs supported. For either empty selection, say “Not specified” rather than omitting that section. Explain that submission goes to admin review and is not immediate publication. Obtain the tutor's confirmation of this exact preview. If they revise it, prepare and show a fresh preview.
7. Call `submit_tutor_profile` with that `preview_id` and `confirmed: true` only after confirmation. Report the returned status and link. Do not claim publication, approval, a public URL, or completed submission without the corresponding server result.

Pending-profile edits: read `get_my_tutor_profile` and use `prepare_tutor_profile_update` with that `profile_version` and only the fields the tutor asked to change. The server preserves omitted fields; do not send a replacement profile through `prepare_tutor_profile`. Arrays replace the complete field, so retain existing days when adding Wednesday. Preserve existing time restrictions and make "Wednesday after 5pm" specific to Wednesday using `times` (the website editor's Preferred Times field); do not apply it to all days. Do not rewrite the biography or unrelated fields unless requested. Show the returned before/after changes and resulting profile, ask the tutor to confirm, then call `submit_tutor_profile` with the update preview ID. Read back the profile to verify the update and report its actual status. Pending edits remain pending admin review, without publication. If no changes are needed, report that the values are already saved. An expired preview, stale version or changed review status requires a fresh read and, if still editable, a fresh preview and confirmation. Account ownership and review decisions cannot be changed through this tool. Use the photo flow below for photos. Private contact fields remain in the website editor.

Previews expire after 30 minutes. After an expired preview or a profile-changed error, read the latest profile and prepare a fresh preview. After an uncertain submission response, retry the same preview ID; the server returns the same receipt for seven days. Do not create a fresh submission blindly. Account connection expiry or missing scopes is resolved through reconnecting, never by requesting credentials in chat.

Tutors can revoke access at https://matchlah.com/matchlah-connect/connections . The connection is limited to their own onboarding profile and excludes private contact fields, messages and documents.

Profile photos: offer an optional photo during onboarding; if the tutor wants one, finish and confirm the text profile first, then read `get_my_tutor_profile` again. When `can_upload_photo_via_mcp` is true, use its latest `profile_version` for the photo tools. The separate photo step also supports replacing a photo while pending review. Approved/other profiles use the website editor.

- Use the original selected photo unless the tutor requests a makeover. If requested and a host image-editing tool is available, use it to improve lighting, background or framing while keeping the tutor recognizable. Show the result so the tutor can choose it or the original. If editing is unavailable, explain and offer the original; do not promise image-generation access or call a separate paid API.
- With a real host-provided file reference, call `prepare_tutor_profile_photo`. Never fabricate a download URL or pass a local path as a remote URL.
- For a local image (including a locally saved makeover), call `create_tutor_photo_upload`, then run the bundled [upload helper](scripts/upload-photo.py) with the selected file path and returned upload URL: `python upload-photo.py --file <path> --upload-url <upload_url>`. This uploads only to MatchLah and does not need computer use. Treat upload URLs as private credentials; do not log or share them outside the conversation.
- If file handoff or local execution is unavailable, give the returned upload link to the tutor. They can open it on their phone and select the original or saved edited image themselves. Do not automate their browser. Once they say they uploaded it, call `get_tutor_photo_upload` with the upload ID.
- After either upload route, display the exact returned image (or its private preview link if inline images are unavailable) and obtain confirmation of that image. Uploading a file alone is not confirmation. Call `submit_tutor_profile_photo` with its `preview_id` and `confirmed: true`. After an uncertain response, retry the same preview ID. Read the profile back and report photo presence, actual review status and Profile Strength. Do not claim the photo is saved before a successful receipt. A stale profile version or expired preview requires a new read, preview and confirmation.

Photo previews and upload links expire after 30 minutes. Unconfirmed images are stored privately and cleaned up after expiry. Confirmed images follow WordPress media storage: the image URL may be reachable while the profile remains pending review. No photo is an identity verification, and gender must still be asked directly.


Account checks and switching: before account-specific work, call `get_connection_status` with `intent: "tutor"`. Use the returned account name, type and readiness rather than inferring the connected identity from chat or the website browser. If `account_role_mismatch` is returned, explain plainly, for example: "You are connected as [returned name] ([returned type]). This action needs a tutor account. Open [recovery_url], sign in with your tutor account, then reconnect MatchLah in this app. We can continue here with the details you already gave me. Nothing has been submitted by this attempt." Provide the actual returned link. Do not describe this merely as "missing permission". Do not automatically sign out, create accounts, modify account roles or disconnect existing grants. The user performs the account switch on the website and reconnects in the host app.

If the account type is correct but `connection_permissions_needed` is returned, explain that the existing connection needs refreshed permissions and ask the user to reconnect the same account and approve them. Do not tell them to create or switch accounts. If there is no valid connection, use the host account-linking flow for the intended role. Do not invent host UI button paths that have not been observed. After the user reconnects, check `get_connection_status` again; website sign-in alone does not change the assistant connection. Retain known request/profile details in this conversation and ask only for missing answers. Only prepare and submit after readiness is confirmed and the user has confirmed the resulting preview.

## Data collection boundary

Collect only lesson-related information. The API field `learning_needs` means optional non-medical educational preferences from the fixed tool choices. Offer those choices or skip; do not ask for diagnoses, medical history, disability details, health records or special-needs assessments. Do not infer a condition or translate a diagnosis into a different label to send it anyway. If sensitive details are volunteered, do not repeat them or pass them to any MatchLah tool; explain the boundary and ask for a lesson goal without that information. Never request government identifiers, payment-card details, passwords or authentication codes. Keep free text limited to lessons, scheduling and professional teaching experience. Returned records may omit website-only information; omitted fields are not permission to erase stored values.

Before asking a tutor's gender, explain that parents use it for tutor matching and that it appears on the public profile after approval. Never infer it. A parent's gender preference refers only to the tutor. Photos are optional: explain public-profile use and that a saved media URL may be accessible before approval. Only use the adult tutor's own portrait, never a child, identity document or medical image. MatchLah does not perform face recognition, identity verification or biometric identification. Show the exact image and obtain confirmation before saving.

Referenced files: 1