Skip to main content
Glama
Sign In
UPC-MCP

UPC-MCP

by dlam12138
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

upc_service_search

Read-onlyIdempotent

Search the official e-station service directory by keyword, including login-only school services when an account is saved and coverage warnings for public-only results.

Instructions

Search the official e站通 service directory; read-only.

When a saved account is available, reads the complete directory visible to that account and matches/paginates locally, so login-only items such as 本科生请销假 are searchable. Without a usable account it returns the public directory with public_catalog_only and explicit coverage warnings; that is not the complete personal scope. A search miss is not proof that the school has no such service for another identity.

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": "upc_service_search"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageNo服务目录页码，从 1 开始；已验证 p 参数。
keywordNo官方事项名称关键词；省略则按目录分页。
page_sizeNo每页条数；已验证 50 可用。

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?

Adds substantial behavior beyond the read-only/idempotent annotations: account-dependent scope, local matching and pagination over a fetched catalog, a `public_catalog_only` fallback flag, and explicit coverage warnings. The caveat that a negative result reflects only the current identity's scope is exactly the kind of nuance annotations cannot convey.

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?

Front-loads purpose and read-only status, then layers the account-dependent behavior and the false-negative caveat in a logical order. Four sentences stay on topic, though the final caveat sentence is somewhat verbose and could be tightened.

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?

With no output schema, the description still discloses the fallback response marker and coverage warnings an agent needs to interpret results. For a three-optional-parameter read tool, nothing essential about invocation or result interpretation is missing.

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

Parameters3/5

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

Schema coverage is 100%, so page, keyword and page_size are already documented in the schema; the description adds only the indirect detail that matching and pagination happen locally against the fetched directory. That slightly informs keyword semantics but no format or edge-case detail beyond the 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?

States a specific verb and resource ("Search the official e站通 service directory") plus its safety class, so the agent knows exactly what the tool retrieves. It does not differentiate itself from plausible siblings like upc_service_guide or upc_service_my_todos, leaving the agent to 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.

Usage Guidelines4/5

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

Gives clear situational context: use it against a saved account for full coverage, otherwise expect a public-only result with warnings. It also warns that a miss is not proof of absence. It stops short of naming an alternative sibling or an explicit when-not-to-use condition.

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

Deploy Server

Other Tools