Skip to main content
Glama
Sign In
UPC-MCP

UPC-MCP

by dlam12138
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

upc_service_guide

Read-onlyIdempotent

Reads an official e站通 service guide by service ID, using the saved session for login-only guides and falling back to the public guide on auth failures.

Instructions

Read one official e站通 service guide; read-only.

Uses the saved account's session when available so login-only guides can be read; falls back to the public guide only for auth-related failures. It never calls start-info, forms, attachments or submits an application. Entry URLs are data and are never opened automatically.

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": {
      "service_id": "<service_id>"
    },
    "name": "upc_service_guide"
  }
}

Input Schema

NameRequiredDescriptionDefault
service_idYesupc_service_search 返回的官方事项 id。

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already cover the read-only/idempotent/non-destructive profile, yet the description adds genuinely new behavior: use of the saved session, public-guide fallback confined to auth failures, and that entry URLs are returned as data and never auto-opened. These are exactly the side-effect and authentication facts an agent needs and cannot infer from structured fields.

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?

Three short lines, front-loaded with the purpose, then behavior, then exclusions — no sentence is redundant. Every clause carries distinct information an agent would otherwise have to guess.

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 one-parameter read tool with full annotation coverage, the description is near-complete on invocation and safety. The only gap is the return shape of the guide itself, which matters slightly because there is no output schema, though the tool's read-one-guide nature makes it largely predictable.

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 description coverage is 100% and the single service_id parameter is already documented as the id returned by upc_service_search. The description adds no further meaning about the parameter (format, range, or what happens on an invalid id), so the baseline 3 applies.

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 with explicit cardinality ("Read one official e站通 service guide") and immediately delimits scope by listing what it does not touch (start-info, forms, attachments, applications). An agent can distinguish this from upc_service_search and from any submission flow without opening the schema.

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?

The exclusions ("never calls start-info, forms, attachments or submits an application") implicitly tell the agent to look elsewhere for those actions, and the auth-fallback note explains behavior when the login-only path fails. It stops short of explicitly naming when to reach for a sibling or that the id must come from upc_service_search first — that routing only appears in the schema.

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