Skip to main content
Glama

正在上课 / 待考试

ykt_live

Lists ongoing classes and upcoming exams from Yuketang, returning a read-only overview that excludes check-in and live classroom access.

Instructions

列出当前正在进行的课堂和即将开始的考试。进入课堂实时内容需要先签到换取课堂令牌,本服务不代签到,因此只提供只读概览。

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "ykt_live"
  }
}

Input Schema

NameRequiredDescriptionDefault
regionNostandard

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden, and it does disclose two useful traits: the call is read-only ('只提供只读概览') and it will not perform sign-in, so live content is out of reach. It stops short of covering ordering, whether both classes and exams are always returned, or any permission/region behavior.

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

Conciseness5/5

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

Two sentences, zero filler, with the core capability front-loaded and the caveat second. Every clause carries information an agent needs.

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

Completeness3/5

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

The check-in/token caveat is the right thing to surface for a live-class tool with no annotations and no output schema. However, the only parameter is left unexplained, and there is no hint of what the overview actually contains (class names, times, exam dates), leaving the agent under-informed about both input and result shape.

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

Parameters2/5

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

Schema description coverage is 0% and the sole parameter 'region' has four opaque enum values (standard, hetang, changjiang, huanghe) with a default. The description says nothing about what region means or how it filters results, so the agent must guess from bare enum tokens — a real gap for a low-coverage schema.

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 gives a specific verb (列出/list) and two concrete resources (ongoing classes and upcoming exams), which is more precise than the vague title. It also implicitly separates itself from check-in/live-classroom tools by stating it does not perform sign-in, though it never names the sibling (ykt_classroom, ykt_login) that would.

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 states a clear usage boundary: this tool is a read-only overview, and live classroom content requires a check-in token that this service will not obtain. That tells an agent when the tool is insufficient, but it does not point to the alternative tool to call instead, leaving the routing decision half-finished.

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