Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@UBC MCP Search UBC Vancouver CPSC 110 sections for 2026W-2 and check for schedule conflicts"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
UBC course discovery and registration planning, designed for MCPHub deployment. Independent project; not affiliated with UBC or Workday.
The public profile provides seven read-only tools over the official UBC Academic Calendar and UBCGrades. Vancouver and Okanagan catalog reads and a historical grade-distribution request have passed live checks.
The personal profile adds four tools over a user's isolated Workday snapshots. The snapshot connector, encryption, credential separation and revocation have automated integration coverage. A manual course-capture extension is included. It captures visible search results and an open section detail dialog; a separate explicit action captures private registrations from View My Courses. It does not silently fetch the full catalog or refresh source data. An installed-browser registration export passed a real local connector/MCP acceptance run; a hosted personal connector and course-search export acceptance remain outstanding.
Workday UI fields were inspected in an authenticated browser on 2026-10-26. This is evidence of field availability, not evidence of a public Workday API or an unattended production integration. See validation.
Related MCP server: penn-course-mcp
Requires Node.js 24 or newer.
npm ci
npm run build
npm startThe default transport is stdio. stdout is reserved for MCP protocol messages.
node dist/cli.js --list-tools lists the public tools. Public mode reads no
personal environment credentials and cannot expose personal tools.
Configure an MCP client with node as the command and the absolute path to
dist/cli.js as its argument. No public-source API key is required.
Public | Purpose |
| Source capabilities, connection state, captured scopes and ages |
| Official Calendar subjects for one campus |
| Search one subject's catalog entries |
| Full description and prerequisite/corequisite text |
| Available historical sessions for API v2 or v3 |
| Course and section grade distributions |
| Up to five catalog/grade comparisons |
Personal | Purpose |
| Search captured sections in one exact campus and period |
| Source status, counts, seat pools and observation time |
| Captured personal registrations, if supplied |
| Meeting/date overlaps and available component constraints |
Campus defaults to UBCV; pass UBCO explicitly for Okanagan. Course arguments
use a subject such as CPSC and number such as 110. Historical sessions use
2026W; availability queries require an exact academicPeriod.id returned by
get_data_status, for example 2026W-2. Section searches and personal registrations
are stored as separate snapshot kinds; schedule checks can select either kind.
This prevents confusing Winter Term 2
in January 2027 with the 2027 Winter Session.
For local verification, set UBC_PROFILE=personal and UBC_SNAPSHOT_FILE to an
absolute private JSON file path. Never point a shared Hub service at an
individual's file.
For multi-user use, start the connector with npm run connector. It binds
loopback by default. Provision a binding using the local administrative CLI:
node dist/connector/cli.js create-binding student-labelThis displays a random binding ID, read token and upload token once. Treat the output as secret. The read token belongs in that user's Hub Credential slot; the upload token stays with their local companion. Neither authorizes the other operation. There is no public administrative HTTP endpoint.
Set UBC_PROFILE=personal, operator-controlled UBC_CONNECTOR_URL and the
user's UBC_CONNECTOR_TOKEN (READ token) in the personal process. Bindings never
come from tool arguments. Missing/revoked credentials never use a shared token.
The connector stores token hashes and AES-256-GCM-encrypted snapshot bodies in SQLite. Preserve the complete data directory and its encryption key together. The operator who controls the host and key can decrypt data. Restrict host access and keep the directory and backups private. Source snapshots exported to the user's Downloads folder are ordinary plaintext files and need private handling.
node dist/connector/cli.js revoke BINDING_IDRevocation disables both tokens and removes active snapshots. Revoked data may remain in historical backups; manage backup retention separately.
npm run build:extensionFor a private local acceptance run using an exported registration file:
node scripts/private-check.mjs /absolute/path/to/private-registrations.jsonThis starts a temporary loopback connector, checks personal MCP queries and revocation, prints aggregate results, then removes the temporary encrypted store. It does not upload the input file to the public Internet or delete the input file.
Load the extension/ folder as an unpacked Chrome extension. It requests only
active-tab scripting and downloads, not cookies, persistent host access or passwords.
Log into Workday yourself and complete Duo. Navigate to Find Course Sections,
select a specific Winter Term (not the umbrella Winter Session), and search.
Refresh the results before capturing. Open a section detail dialog to include
unreserved/reserved seats, eligibility rules and all date intervals.
Click the extension's Export course snapshot button. It captures only DOM
records currently loaded. Coverage is always marked partial. A collapsed
+N more meeting list is treated as incomplete; missing meeting data is never
classified as asynchronous. The capture timestamp records the DOM observation,
not an upstream database refresh guarantee. Only the section detail currently
open gains complete meeting/seat-pool fields.
With UBC_CONNECTOR_URL and your UBC_UPLOAD_TOKEN configured in the local
environment, synchronize the saved file:
node dist/connector/cli.js push /absolute/path/to/ubc-snapshot.jsonThis explicitly uploads the structured course snapshot to your connector. It does not upload the browser session, password, cookies or student profile. A push replaces that binding's existing snapshot for the same campus and period; capture all desired loaded records together. Older snapshots cannot replace newer ones. On View My Courses, the separate Export my registrations action captures the loaded Registered and Waitlisted rows, grouped into academic periods. It discards student names/IDs and does not collect grades or financial details. Keep that export private. The same push command accepts its snapshot array. Registration snapshots do not replace section-search availability snapshots. Automatic polling is not implemented in this alpha.
Catalog records do not establish current offerings. Full prerequisite text is preserved; there is no invented prerequisite tree or official degree audit.
UBCGrades is historical. OVERALL is separate from sections to prevent double
counting. The selected API version and session are returned with every report.
Unknown counts remain null. Capacity minus enrollment is not substituted for
unreserved availability. Workday detail fields identify the two seat pools.
openOnly requires an observed Open status, a known positive unreserved/available
count and an observation no older than five minutes. It does not prove eligibility.
Source status is preserved separately from normalized status. Unknown states remain unknown. Stale snapshots remain inspectable with their original age.
Schedule checks preserve multiple date intervals, including reading-break gaps. Unknown meeting patterns and component rules require manual verification. Final exams, travel time and personal eligibility are not inferred.
Tool text is fenced as untrusted source data. No registration/write tools exist.
See Hub deployment. Keep the public profile lightweight; run the connector separately if personal use is enabled.
npm test
npm run test:protocol
npm run test:live
npm run build:extensionThe live suite makes bounded public read requests; the default suite is offline. No test loads personal Workday cookies or sends a registration request.
Compare up to five courses using official descriptions and historical grades. Reports individual source failures without inventing data.
| Name | Required | Description | Default |
|---|---|---|---|
| campus | No | UBCV | |
| courses | Yes | ||
| yearSession | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive and open-world status, so the description only needs to add behavior beyond that — and it does: it discloses partial-failure semantics ('reports individual source failures without inventing data'), which tells the agent how mixed results look. It does not say whether failures surface as errors or partially-populated output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero filler, with the capability and the batch limit front-loaded and the failure-handling caveat second.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no output schema and 0% schema description coverage, the description is thin: it never explains campus/session scoping or what a comparison result contains. Annotations and the safe read profile carry part of the burden, but an agent still lacks guidance on the optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning, yet it only restates the maxItems bound ('up to five'). The campus enum (UBCV/UBCO), the yearSession format, and the subject/course code formats are left entirely to the schema patterns with no explanation in prose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource ('Compare ... courses') with a concrete batch bound ('up to five') and named data sources (official descriptions, historical grades). That batch framing implicitly separates it from single-course siblings like get_course and get_course_grades, but no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case (comparing several courses at once) is implied by the verb and the 2-5 course bound, but there is no explicit when-to-use/when-not guidance and no mention of alternatives such as search_courses or get_course_grades for a single lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read full official catalog text for a course. Does not establish current offering or personal eligibility.
| Name | Required | Description | Default |
|---|---|---|---|
| campus | No | UBCV | |
| course | Yes | ||
| subject | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and openWorld. The description adds real context beyond them: the payload is static catalog prose, not live offering data and not eligibility data — an important and non-obvious distinction. It stops short of describing return shape or whether catalog text can be stale.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste, with the positive capability front-loaded and the scope caveat immediately after. Nothing to trim.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The scope caveat covers the biggest failure mode (treating catalog text as a current-offering check), but with no output schema and 0% parameter coverage the description leaves unclear what the returned text contains (prerequisites, credits, description) and how campus affects results. Adequate but with clear gaps for a three-parameter, open-world read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden for the three parameters, yet it says nothing about subject, course, or campus. The regex patterns and campus enum/default are the only guidance available, and the description does not even clarify that campus defaults to UBCV.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb (read) plus a specific resource (full official catalog text for a course), which distinguishes it implicitly from siblings like get_course_grades or compare_courses. It does not name any sibling explicitly, so differentiation is inferred rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Does not establish current offering or personal eligibility" is a genuine when-not constraint that prevents misuse. However, it never says when to use this instead of search_courses (which presumably locates a course) or which sibling answers offering/eligibility questions, so the routing guidance is only half complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Historical UBCGrades reports for a course, separating OVERALL from individual sections. No prediction of grades or current seat counts.
| Name | Required | Description | Default |
|---|---|---|---|
| campus | No | UBCV | |
| course | Yes | ||
| subject | Yes | ||
| yearSession | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, open-world, and non-destructive behavior. The description adds value by specifying that results are historical, separated into OVERALL and individual sections, and exclude predictions or current seat counts. It still omits auth, rate-limit, and pagination details, but it meaningfully exceeds the annotation baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences, front-loaded with the tool's scope and followed by a useful exclusion. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, 0% schema description coverage, and no output schema, the description is materially incomplete. It gives high-level scope but does not explain parameter meaning or enough return structure for an agent to invoke the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only implies that 'course' is involved and does not explain subject, course patterns, campus, or yearSession semantics, leaving most parameter meaning to the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource and scope: historical UBCGrades reports for a course, split into OVERALL and section-level data. It distinguishes the tool from predictive or live-seat tools via the second sentence, though it does not explicitly differentiate from siblings like get_course or compare_courses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'historical UBCGrades reports for a course,' and the description adds a useful exclusion ('No prediction of grades or current seat counts'). However, it never names alternatives or states when another sibling tool should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check available sources, connection state, observed periods, coverage and data age. No refresh is implied.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, openWorld, and non-destructive. Beyond that, the sentence 'No refresh is implied' adds a genuinely useful behavioral fact absent from structured fields: calling this does not fetch or update data, so results may be stale. It stops short of describing what 'data age' looks like or failure modes when no source is connected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero filler. The core purpose is front-loaded, and the caveat about refresh is placed as a single clarifying clause at the end.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of telling the agent what comes back, and it does so by enumerating the five reported dimensions. It's nearly complete; it could note shape or behavior when no sources are connected, but nothing essential to invoking it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, and the schema is fully described, so there is nothing for the description to compensate for. Baseline for a no-parameter tool applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb ('Check') plus an enumerated set of resources it reports on: sources, connection state, observed periods, coverage, and data age. It's clearly a diagnostics/status tool, distinct from the course/grades siblings, though it doesn't explicitly name those siblings to sharpen the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the enumeration of returned facts; there is no explicit 'use this when you need to know X before calling Y' or when-not guidance. The one real constraint, 'No refresh is implied,' hints at a usage boundary (this is a passive read, not a sync trigger) but doesn't tell the agent when to prefer it over a refresh or query tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available historical grade sessions. Use before requesting a session with unknown coverage.
| Name | Required | Description | Default |
|---|---|---|---|
| campus | No | UBCV | |
| version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds only that sessions are historical and available; it does not add return shape, pagination, or other behavioral details beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the primary purpose front-loaded and the usage note immediately following. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and annotations cover safety, but the two parameters are undocumented and there is no output schema. An agent can infer a list of sessions, yet the description leaves parameter meaning and return details incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention campus or version at all. The enum values for campus and version provide some structure, but the description does not explain what these parameters mean or how they affect results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: list historical grade sessions. The purpose is clear, though it does not explicitly differentiate itself from siblings such as get_course_grades or search_courses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear usage context: use before requesting a session with unknown coverage. It does not name an alternative tool or state when not to use it, but the intended timing is explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List official Calendar subject codes for a campus. Courses are catalog records, not current offerings.
| Name | Required | Description | Default |
|---|---|---|---|
| campus | No | UBCV |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful domain context about catalog records versus current offerings, but it does not describe return shape, auth needs, or other behavior beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core action, and the second sentence adds a relevant scope clarification without redundancy. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with one optional enum parameter and no output schema, the description covers purpose and catalog-vs-offering scope adequately. It could be slightly more complete by mentioning the default campus or that the result is a list of subject codes, but the essential context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter, campus, with enum values UBCV/UBCO and a default of UBCV, but schema description coverage is 0%. The description says 'for a campus' without explaining the enum values, default, or effect of choosing a campus, so it does not compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource: 'List official Calendar subject codes for a campus.' It also clarifies scope by stating courses are catalog records rather than current offerings, which helps distinguish it from offering-search tools, though it does not name a specific sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The note that courses are 'catalog records, not current offerings' implies the tool is for catalog subject lookup rather than live section search, but it never explicitly says when to use this tool versus search_courses or another sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search one official Calendar subject by keyword and/or course level. Preserves prerequisite text.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | ||
| limit | No | ||
| query | No | ||
| campus | No | UBCV | |
| subject | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds a useful behavior—'Preserves prerequisite text'—but omits return format, pagination, or handling of missing subjects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the core purpose front-loaded and no redundant phrasing. Every sentence earns its place, though the second sentence could be integrated into the first for even tighter flow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter search tool with no output schema, the description is too thin. It does not explain pagination (limit), campus selection, output shape, or how results are ordered, leaving the agent to infer behavior from the schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'subject', 'keyword' (query), and 'course level' (level), but leaves 'limit' and 'campus' undocumented and gives no syntax, defaults, or enum details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Search') and resource ('courses' via 'Calendar subject') and scopes it by keyword and/or course level. However, it does not explicitly distinguish this from siblings like get_course or list_subjects, so an agent must infer the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance and no mention of alternatives. The phrase 'one official Calendar subject' implies a single-subject constraint, but the agent gets no routing help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0-alpha.1compare_coursesget_courseget_course_gradesget_data_statuslist_grade_sessionslist_subjectssearch_coursesScored across 7 tools
Each tool occupies a clearly distinct slot: browsing subject codes (list_subjects), keyword search (search_courses), single-record detail (get_course), grade history (get_course_grades), multi-course comparison (compare_courses), and metadata/health (list_grade_sessions, get_data_status). The descriptions explicitly draw boundaries between catalog records, historical grades, and data freshness, so an agent can select without guessing.
All seven tools follow a uniform verb_noun snake_case convention (list_*, get_*, search_*, compare_*). The two get_course/get_course_grades names are predictably nested rather than confusing.
Seven tools is a tight, well-scoped set for a course-catalog-plus-grades domain, with no redundant or filler entries. Each tool maps to one user intent (discover, inspect, compare, check freshness).
Discovery, detail, grade history, comparison, and data-health are all covered, and prerequisite text is preserved for planning. The main gap is any current-offering/section/seat lookup, which the descriptions disclaim but which agents will likely want for real course planning.
Unofficial NTNU course data: search, timetables, grades, course info, and exam logistics.
Manage your Canvas coursework with quick access to courses, assignments, and grades. Track upcomin…
Search Australian CRICOS courses, education providers and ANZSCO skilled occupations using One U Education (万友教育)'s public catalogue, including tuition, intakes, English requirements, campuses and study pathways. Provides six read-only tools with source links; no API key is required, and tuition fees are indicative and shown in AUD.
Search university course materials, your flashcards, quizzes, streak and quota. All tools read-only.
