UPC-MCP

Overview Schema Source Related Servers Discussions Admin

upc_power_remaining

Read-only

Reads a Tangdaowan room's remaining electricity in kWh when you provide one exact building and room, returning the school page's current remaining power value.

Instructions

Read one explicitly named Tangdaowan room's remaining electricity.

Call only when the current user request itself gives both a building and a room. Never infer, reuse, save or guess either value from the account, earlier chats, defaults, history, widgets or other rooms. One room per call; no enumeration or batch probing. The campus is fixed to Tangdaowan and this tool accepts no campus, URL, header, cookie, account, saved target or arbitrary endpoint.

The returned value is the school page's 当前剩余电量 in kWh (度), not a money balance, not an amount owed, and not an arrears field. A unique exact building + room match is required; fuzzy candidates are returned as ambiguous without a reading. The tool has no cache, default room or persistent state. A missing/blank building or room returns missing_input; an invalid value returns invalid_input.

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": {
      "building": "<building>",
      "room": "<room>"
    },
    "name": "upc_power_remaining"
  }
}

Input Schema

Name	Required	Description	Default
`room`	Yes	本次用户明确给出的房间号，单次只查这一间。不得枚举、批量试号、复用历史房间或从账号推断。
`building`	Yes	本次用户明确给出的唐岛湾楼号，必须是 upc_power_buildings 返回的 id（学校表单 option value）。不得从账号、旧聊天、历史、默认宿舍或其他房间推断。

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 4, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond readOnlyHint/openWorldHint/destructiveHint it discloses concrete behavior: unique exact match required, fuzzy candidates yield an `ambiguous` result with no reading, no cache or persistent state, and named error outcomes (`missing_input`, `invalid_input`). It also states the tool accepts no campus, URL, header, cookie, or arbitrary endpoint, bounding the surface area explicitly.

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

Conciseness4/5

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

Well front-loaded, with the core constraint in the first sentence and error semantics at the end. Some redundancy remains — the 'never infer/reuse' prohibition is restated as 'no cache, default room or persistent state', and the non-money point is tripled ('not a money balance, not an amount owed, not an arrears field').

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

Completeness5/5

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

There is no output schema, and the description compensates by naming the returned field (`当前剩余电量`) and its unit, plus the failure modes an agent must handle. For a two-parameter read tool with full annotation coverage, nothing material is missing.

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% and already documents both fields, but the description adds meaning the schema does not: values must match a unique exact building+room pair, mismatch degrades to `ambiguous` rather than a guess, and only one room may be queried per invocation. It does not restate the building-id requirement from upc_power_buildings, but the schema carries that.

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

Purpose5/5

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

States a specific verb and resource — read one explicitly named room's remaining electricity — and pins the scope to a single building+room on the Tangdaowan campus. It also pre-empts confusion with upc_card_balance by declaring the value is kWh (度), not a money balance or arrears figure.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

Gives explicit preconditions: call only when the current user request itself supplies both a building and a room, and never infer or reuse either from account, history, defaults, or other rooms. It also rules out enumeration/batch probing and states one room per call, which is exactly the when/when-not guidance an agent needs.

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