CampusThreads

Search WORKERS (ambassadors) within the tenant. WHEN: user asks about specific workers by name/status/id, or wants an ambassador count or status breakdown. NOT WHEN: the name they mention matches the tenant (auto-scoped, never a record). NOT WHEN: they ask about admin/portal users → use `colleague_query`. NOT WHEN: they ask about leads/prospects → use `prospect_query`. NOT WHEN: they ask WHEN a worker is free / what they're booked for / how they're notified → use `ambassador_availability`. Defaults: no args → count + byStatus + recent. `id` → that ambassador or null. `query` → substring across firstName/lastName/email. Each record includes profile voice-note presence (`hasProfileVoiceNote`, URL, duration) and `topicTags`, which are the topics the ambassador is qualified/interested to talk about for prospect matching. Use `hasVoiceNote` for 'who has a voice note' and `topic` for 'who is qualified to talk about X'. Status semantics: active = championActive && completedPassword; inactive = !championActive; pending = invited but not yet onboarded. Routing: prefer this optimized tool for the workflow it describes. If its result omits a field visible in the admin portal, or source-level detail is needed, call `ct_read` for supported generic entities or `portal_record_query` for an exact record before saying the MCP cannot access it.

Use this to set championActive=true on an ambassador. Reversal of ambassador_deactivate.

Update an ambassador profile, including public chat visibility and chat availability. Set disableChat=false to include them on the hosted chat page, or true to hide them without deactivating their event account. If the widget hides unavailable profiles, also set alwaysAvailableForChats=true or configure a chat schedule. Use ambassador_query to find the profile; use linked worker profiles for administrators. Cannot change company affiliation or auth fields.

Use this to read the CURRENT VALUES of shift/task/invoice operational rules, social-media attribution channels/hashtags for ambassador post analytics, scheduled-report cadence, or rule/policy-level feature toggles for this tenant. Application Settings → Social Media does not control the prospect widget's Content tab feed; use `widget_content_diagnostics` for that. This returns stored settings, not a feature catalogue — for 'how do I…' / 'where do I configure…' questions about the portal, use `product_help_search` instead. Routing: prefer this optimized tool for the workflow it describes. If its result omits a field visible in the admin portal, or source-level detail is needed, call `ct_read` for supported generic entities or `portal_record_query` for an exact record before saying the MCP cannot access it.

Update this tenant's operational settings (the values application_settings_get reads back): who can join, shift clocking/approval/cancellation rules, the default hourly rate, invoice config, social-media attribution hashtag tracking for ambassador post analytics, scheduled reports, and feature on/off toggles. Pass only the fields you want to change; omitted fields are left untouched. Reversible. These social-media fields do not control the widget Content tab feed. For branding and prospect-nurturing settings use widget_settings_update.

Use this for the full USAGE HISTORY of ONE physical asset — every logged event (Used in Activation, Changed Location, Changed Owner, Altered or Repaired, Shipped / In Transit, Damaged or Expired, Lost or Missing): when it happened, who carried it out, and the posting it was used for. Identify the asset by `id` or `query` (name substring). Returns the event timeline newest-first, counts by event type, and `usageCount`. To rank MANY assets by usage, use `physical_asset_query` and sort on its `usageCount`. For the immutable audit trail of event create/edit/delete actions, use `physical_asset_audit_trail`. Routing: prefer this optimized tool for the workflow it describes. If its result omits a field visible in the admin portal, or source-level detail is needed, call `ct_read` for supported generic entities or `portal_record_query` for an exact record before saying the MCP cannot access it.

Use this to find the BEST TIME to schedule a GROUP of ambassadors — 'when can the most of them meet', 'best 3-hour window next week for a team event'. Give it the ambassador ids to consider, an event duration and a date window; it computes — server-side — every candidate start time and ranks them by how many ambassadors are concurrently free, accounting for each one's weekly availability (in their own timezone), their time-off blocks, and shifts they're already booked for. Returns ranked windows, each with the available + unavailable ambassador names. Pick the in-scope ambassador set yourself first (e.g. by location/program) — this tool does the scheduling math, not the guest-list selection. Do NOT compute overlaps by hand from per-ambassador `ambassador_availability` calls; that is exactly what this replaces. Routing: prefer this optimized tool for the workflow it describes. If its result omits a field visible in the admin portal, or source-level detail is needed, call `ct_read` for supported generic entities or `portal_record_query` for an exact record before saying the MCP cannot access it.

Summarize campus-tour and visit-program operations: upcoming sessions, visitor capacity, waitlists, check-ins, no-shows, attendance, and feedback ratings. Returns aggregate metrics only and never returns visitor names, emails, custom answers, or accommodation notes. Routing: prefer this optimized tool for the workflow it describes. If its result omits a field visible in the admin portal, or source-level detail is needed, call `ct_read` for supported generic entities or `portal_record_query` for an exact record before saying the MCP cannot access it.

Read the tenant's current Chat Guidelines exactly as the admin portal defines them. Use this for 'what are the chat guidelines', 'conversation guidelines', or ambassador/prospect chat moderation guidance. The admin portal stores this as the auto-generated Chat Guidelines resource (`resource.chatGuidelines=true`) and syncs its custom description to the tenant school settings. Returns the custom guidelines plus the always-enforced baseline rules shown in the portal. Routing: prefer this optimized tool for the workflow it describes. If its result omits a field visible in the admin portal, or source-level detail is needed, call `ct_read` for supported generic entities or `portal_record_query` for an exact record before saying the MCP cannot access it.

Update the tenant's custom Chat Guidelines, mirroring the admin portal's edit field on Moderation → Chat Guidelines. This edits the auto-generated Chat Guidelines resource description; the backend then syncs the same text to tenant settings for moderation.

Search COLLEAGUES (fellow admins — people who log into the portal alongside the signed-in user) within the tenant. WHEN: user asks 'who else has access', 'list our admins', 'who's on our team', or wants the admin headcount. NOT WHEN: the name they mention matches the tenant (auto-scoped, never a record). NOT WHEN: they ask about workers → use `ambassador_query`. NOT WHEN: they ask about leads → use `prospect_query`. Defaults: no args → all colleagues + count. `id` → that colleague. `query` → name/email substring. `isYou: true` flags the signed-in admin. Routing: prefer this optimized tool for the workflow it describes. If its result omits a field visible in the admin portal, or source-level detail is needed, call `ct_read` for supported generic entities or `portal_record_query` for an exact record before saying the MCP cannot access it.

Post a new comment on a task or resource. Provide exactly one of `taskId` or `resourceId`, plus `message`. The signed-in admin is recorded as the creator. Parent's tenant ownership is verified server-side.

Permanently delete a comment. Only the comment's creator can delete it. Two-phase: preview, then confirm with token.

Read comments across one or many tasks or resources in a SINGLE call. Provide exactly one of: `taskId` (one task), `taskIds` (batch of tasks), `resourceId` (one resource), `resourceIds` (batch of resources). ALWAYS prefer the batch form when checking comments across multiple parents — one call with `resourceIds: [1,2,3,...]` is dramatically faster than N calls each with one `resourceId`. Each returned comment carries `parent: { kind, id }` so you can group results client-side. Parent's tenant is verified server-side. Routing: prefer this optimized tool for the workflow it describes. If its result omits a field visible in the admin portal, or source-level detail is needed, call `ct_read` for supported generic entities or `portal_record_query` for an exact record before saying the MCP cannot access it.

Edit the message of an existing comment. Only the comment's creator can edit it (enforced server-side). The `edited` flag is set automatically.

The community bot's activity feed — every autonomous action it has taken (answers, engagement prompts, acceptance celebrations, office-hours syncs, escalations, weekly pulses, moderation, …). Filters: `kind` (machine kind, see byKind keys in the result), `channel`, `limit`. Items carry a human `title` — use that wording with the user, never the raw kind. Matches the Community page's 'Bot Activity' feed and its metrics. Routing: prefer this optimized tool for the workflow it describes. If its result omits a field visible in the admin portal, or source-level detail is needed, call `ct_read` for supported generic entities or `portal_record_query` for an exact record before saying the MCP cannot access it.

The Discord community's channels with activity: name, type, topic, message count, and the latest message preview. Filter: `query` (channel name substring). Matches the Community page's channel list. Refer to channels as #name. Routing: prefer this optimized tool for the workflow it describes. If its result omits a field visible in the admin portal, or source-level detail is needed, call `ct_read` for supported generic entities or `portal_record_query` for an exact record before saying the MCP cannot access it.

[Tenant: Lumo (slug=lumo-demo). Every tool is auto-scoped here — never search FOR this name as a record.] Community members ranked by engagement (messages, questions, reactions). Filters: `admittedOnly` (members whose offer of admission has been celebrated), `query` (name substring). Returns display name, engagement score and grade, message/question/reaction counts, last activity, and whether they have been admitted. Bots and ambassadors are excluded, matching the Community page's engagement list. Routing: prefer this optimized tool for the workflow it describes. If its result omits a field visible in the admin portal, or source-level detail is needed, call `ct_read` for supported generic entities or `portal_record_query` for an exact record before saying the MCP cannot access it.

Moderation cases the community bot opened for flagged Discord messages. Filter: `status` (open = still needs administrator review, resolved, any). Returns the member's name, channel, reason, the bot's explanation, the flagged content, and case status. Matches the Community page's 'Moderation Review' feed. Routing: prefer this optimized tool for the workflow it describes. If its result omits a field visible in the admin portal, or source-level detail is needed, call `ct_read` for supported generic entities or `portal_record_query` for an exact record before saying the MCP cannot access it.

Use this for ANY question about the Discord community's overall state — 'how is the community doing', engagement grade, member/message/question counts, the latest weekly pulse (top concern topics with week-over-week trends, most active channels), and the class-composition snapshot (programs, regions, admitted count). Matches the Community page header and its Weekly Pulse / Class Composition cards. For individual questions, members, channels, moderation cases, or the bot activity feed, use the dedicated community_* tools. Routing: prefer this optimized tool for the workflow it describes. If its result omits a field visible in the admin portal, or source-level detail is needed, call `ct_read` for supported generic entities or `portal_record_query` for an exact record before saying the MCP cannot access it.

Prospect questions asked in the Discord community and how each was handled. Filters: `status` (pending = still awaiting a reply, queued = reply in progress, answered = bot answered, escalated = handed to staff), `channel` (name, with or without #), `query` (substring of the question text). Returns the asker's name, channel, question, status, and the bot's response preview. Matches the Community page's 'Messages Needing Responses' feed (status: pending) and its questions list. Routing: prefer this optimized tool for the workflow it describes. If its result omits a field visible in the admin portal, or source-level detail is needed, call `ct_read` for supported generic entities or `portal_record_query` for an exact record before saying the MCP cannot access it.

Discord community verification and role-gating status. Use this for questions about who has verified their Discord account, who is still Unverified, verification-link events, and the current managed role transition from Unverified to Verified Prospect. This reflects the live prospect verification flow used by the Discord community. Broader ambassador/admin Discord OAuth linking and periodic role reconciliation are not live admin-portal features unless matching records are present in source data. Routing: prefer this optimized tool for the workflow it describes. If its result omits a field visible in the admin portal, or source-level detail is needed, call `ct_read` for supported generic entities or `portal_record_query` for an exact record before saying the MCP cannot access it.

Use this for literal raw-message searches across conversations, e.g. 'any messages with Life Sciences or Health Sciences?', 'what did people say about X?', or 'search all chats for this phrase'. Searches both sides of regular conversation messages (prospect-authored, ambassador-authored, and admin-authored) across external prospect threads and internal threads, plus Expert AI bot query/response turns and Ambassador Matchmaker query/response turns. Prefer this over `conversation_topic_summary`, `knowledge_search`, `prospect_thread_query`, and manual `message_query` fan-out when the user asks whether specific words appeared in message bodies. Routing: prefer this optimized tool for the workflow it describes. If its result omits a field visible in the admin portal, or source-level detail is needed, call `ct_read` for supported generic entities or `portal_record_query` for an exact record before saying the MCP cannot access it.

Use this when the user asks which topics are associated with conversations, or which ambassadors have handled conversations about a topic. Mirrors the admin portal Conversations page: real prospect↔ambassador threads are grouped by ambassador, while AI bot and matchmaker conversations are reported separately and must not be attributed to ambassadors. Prefer this over `knowledge_search` for exhaustive conversation-topic counts. Optional `topic` filters by topic substring, e.g. 'varsity sports'. Routing: prefer this optimized tool for the workflow it describes. If its result omits a field visible in the admin portal, or source-level detail is needed, call `ct_read` for supported generic entities or `portal_record_query` for an exact record before saying the MCP cannot access it.

Show current tenant/auth context and coarse tool capability counts.

Generic schema-driven read. Use when you need portal/source fields that a normalized domain tool does not expose. For common workflows, prefer optimized tools first; use ct_read as the complete fallback.

Discover CampusThreads portal entities, fields, types, allowed values, operations, and writable fields before using ct_read/ct_write.

List CampusThreads MCP workflow skills available to guide multi-step work.

Read one CampusThreads MCP workflow skill before executing a multi-step workflow.

Generic schema-driven write with strict validation and dry-run previews. Defaults to dryRun:true. Currently supports company_settings; use existing domain mutations for other entities until their schema write contracts are added.

Use this for ANY broad org-wide question — 'how are we doing', 'what needs my attention', 'give me a summary'. Returns ambassador status, shift status incl. needsAttention count, prospect count, prospect-thread backlog — all in one call. Routing: prefer this optimized tool for the workflow it describes. If its result omits a field visible in the admin portal, or source-level detail is needed, call `ct_read` for supported generic entities or `portal_record_query` for an exact record before saying the MCP cannot access it.

Use this for 'what needs my attention', 'what's outstanding', 'what should I do today', 'anything I'm behind on' — it returns one actionable digest fused across shifts, prospect threads and tasks: shifts proposed by ambassadors / pending approval / awaiting a report / with cancellation requests / unfilled and starting soon, prospect threads needing a response or help, and overdue tasks. For read-only METRICS and leaderboards use dashboard_overview instead. For shift-only action item questions ('when it comes to shifts', 'shift queue', 'what shift work is on me'), set `area: 'shifts'` so the result excludes unrelated thread/task sections and avoids extra queries. Each section returns `items` up to `detailLimit`; if `count` is higher than `items.length`, say more exist and ask before drilling in. Routing: prefer this optimized tool for the workflow it describes. If its result omits a field visible in the admin portal, or source-level detail is needed, call `ct_read` for supported generic entities or `portal_record_query` for an exact record before saying the MCP cannot access it.

Create a new ambassador group with an explicit (manual) member list. Dynamic criteria-based groups (by country, program, ambassador type, tags, etc.) must be created in the portal — this tool creates manual-selection groups only.

Use this for ANY question about ambassador groups (the way the tenant clusters ambassadors). No args → count, totalMemberships, recent. With `id` → single group. Filters: `query` (name substring). Routing: prefer this optimized tool for the workflow it describes. If its result omits a field visible in the admin portal, or source-level detail is needed, call `ct_read` for supported generic entities or `portal_record_query` for an exact record before saying the MCP cannot access it.

Rename a group or replace its member list. The member list is REPLACED wholesale — pass the full intended set of ambassador ids, not a delta. Only manual-selection groups should have their members edited this way.

Start a new INTERNAL thread — a discussion among the named ambassadors (plus you). Pass the ambassador record ids to include as contributors and, optionally, a `title` (up to 50 characters). After creating, post into it with `thread_send_message`.

Use this for internal admin↔ambassador chat threads, including posting conversations that are automatically created for a specific posting so ambassadors/admins can discuss that shift opportunity. Returned `source: 'posting'` means an auto-created posting conversation; `postingId` is for internal tool joins only and must not be shown to the user. Describe these as 'posting conversations' or 'the conversation for <posting title>', never as IDs, variables, or system-generated shells. No args → count, byStatus (active = msg in last 7d / quiet), recent. With `id` → single thread. Filters: `status`, `source`, `postingId`, `ambassadorId`, `query` (thread name). Routing: prefer this optimized tool for the workflow it describes. If its result omits a field visible in the admin portal, or source-level detail is needed, call `ct_read` for supported generic entities or `portal_record_query` for an exact record before saying the MCP cannot access it.

Generate an invoice for an ambassador for a pay period — the equivalent of the ambassador detail → Invoices → Add Invoice action. The total amount, hours and shift count are COMPUTED by the backend from the ambassador's shifts worked between startDate and endDate; you do not supply them. By default the period must contain at least one qualifying shift — pass allowEmpty:true to issue a zero-shift invoice anyway. The invoice is shared to the ambassador's app.

Use this for ANY question about invoices (records of ambassador earnings). No args → count, totalSum (per currency), top-earners-by-amount, recent. Single: `id` (one invoice). Batch: `ids: [...]`. Filters: `ambassadorId` (numeric user id) OR `ambassadorIds: [...]` (many), `generatedAfter`/`generatedBefore` (ISO datetime — 'past year', 'this month'). ALWAYS prefer the batched form over per-ambassador drilldown. Routing: prefer this optimized tool for the workflow it describes. If its result omits a field visible in the admin portal, or source-level detail is needed, call `ct_read` for supported generic entities or `portal_record_query` for an exact record before saying the MCP cannot access it.

Use this for narrative / lookup questions across long-form content (resources, AI-summarized thread learnings, post-shift reports, cached web pages). Semantic-search the company's knowledge base by similarity. Prefer the structured *_query tools for exhaustive aggregates like counts.