Skip to main content
Glama

upc_free_classrooms

Read-only

Find free UPC classrooms for a campus, date, and class periods. Query public room records, verify per-room occupancy, and return available or access-restricted rooms for study planning.

Instructions

Query public classroom records with an explicit verification scope.

Anonymous read-only requests to fixed school endpoints. No account, Cookie, URL, header, or arbitrary endpoint is accepted.

search-all supplies only the room directory and building options. Its d.js occupancy is ignored: it neither vetoes a detail-free room nor becomes occupied when detail fails. mode=auto returns a directory-only per-building overview for "全部"; a 1–2 building scope is checked room by room through the official detail endpoint. mode=full also supports "全部", but that is a deliberately heavy explicit request. Overview does not return candidate free-room counts.

available means the per-room detail record has no selected-period lessArr overlap; it is not proof of a live empty seat, reservation, or admission. Name markers are returned separately as access_restriction; available_restricted rooms are not ordinary self-study recommendations and are not returned by only_available. availability_certainty reflects detail coverage only, not access.

If the user already named one or two buildings, query them directly; do not ask again. Only an all-building request should start with the overview and a narrowing question.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "campus": "<campus>",
      "date": "<date>",
      "periods": "<periods>"
    },
    "name": "upc_free_classrooms"
  }
}

Input Schema

NameRequiredDescriptionDefault
dateYes查询日期,显式 YYYY-MM-DD。
modeNoauto:全部范围返回按楼目录概览,1–2 栋走 full;overview:只返回目录楼宇/教室数,不查 detail、不判断占用;full:对所选范围(含“全部”)每间 detail 校验。auto
limitNo本次最多返回 1–500 间,默认 200。
campusYes唐岛湾校区或古镇口校区;也接受唐岛湾/古镇口简称。
offsetNo房间结果偏移,默认 0。
periodsYes节次 1–12,至少一节;重复值会去重并按升序提交。第 13 节未验证,传入会返回 unsupported_period。
buildingNo“全部”或学校返回的 building_options[].id;省略 buildings 时使用。全部
buildingsNo可选;1–2 个 building_options[].id。指定后走 full 逐间校验。
only_availableNotrue 只返回普通自习推荐:detail 记录在所选节次无占用,且名称没有研究生专用/教师专用/专用教室等限制线索。受限但记录空闲的房间在 restricted_rooms 单列;unknown/occupied 不返回。
include_conflictsNo已弃用,仅为兼容旧调用保留且不改变结果。search-all 的占用集合不参与判定,conflict_candidates 恒为空。

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations only declare read-only/no-destructive/open-world, while the description adds substantial behavior: anonymous access with no account, cookie, header or arbitrary endpoint, the fact that search-all occupancy is ignored for verdicts, that availability_certainty reflects detail coverage only, and that "available" is not proof of a live empty seat. That is exactly the extra context annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded and the paragraph breaks are readable, but the text leans on internal jargon ("d.js", "lessArr", "search-all") that an agent cannot map to any parameter or output field, and several sentences restate schema-backed rules. It is longer and more implementation-flavored than the caller needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter tool with no output schema, the description does the heavy lifting: it defines what "available" means, explains restricted rooms, certainty, and the deprecated conflict field, and gives workflow guidance for all-building versus narrow requests. What remains thin is any sense of return shape or pagination limits beyond the schema's limit/offset descriptions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description still adds value by explaining how building and buildings interact with mode (a 1-2 building scope goes room by room through detail, "全部" yields a directory-only overview) and by clarifying that only_available excludes restricted rooms while restricted_rooms lists them separately. Some of this overlaps the schema text, which keeps it below a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource ("Query public classroom records") and frames the scope as a verification-scoped availability lookup, which separates it from siblings like upc_library_rooms or upc_power_buildings. It never names those siblings explicitly, so the differentiation is implicit 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.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives concrete routing rules: if the user already named one or two buildings, query them directly and do not ask again; only an all-building request should start with the overview plus a narrowing question. It also explains the auto/overview/full choice, but offers no explicit exclusion against adjacent tools (library seats/rooms) for ambiguous availability requests.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.