Skip to main content
Glama
Sign In
传承·交大 MCP

传承·交大 MCP

by Flagwill
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

share_auth_status

Read-onlyIdempotent

Verify authentication token existence and expiration, and optionally fetch account profile details without revealing the token.

Instructions

检查 token 是否存在、过期时间与账号资料；不会输出 token。

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

Input Schema

NameRequiredDescriptionDefault
check_profileNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.3/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, so the bar is lower, yet the description adds a genuinely useful security guarantee not present in the structured data: no token is emitted in the response. It still does not say how an expired or missing token is surfaced (error vs. status field) or whether authentication is required to call it.

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?

A single short sentence that front-loads the three things being checked and closes with the key scoping guarantee. Nothing is wasted.

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?

An output schema exists, so return-shape explanation is not needed, and the annotations cover the safety profile. However, the entirely undocumented check_profile parameter leaves a real gap for a tool whose sole input controls response content.

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?

The single parameter check_profile has 0% schema description coverage and is never mentioned in the description. The phrase '账号资料' faintly hints that profile data can be included or skipped, but it never explains that check_profile toggles this behavior or that it defaults to true.

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 states a specific verb and resource: check token existence, expiry time, and account profile, and adds a scope limit ('does not output the token'). It is clear enough to distinguish from share_logout/login_start, though it does not explicitly distinguish itself from the sibling share_get_profile even though it overlaps on '账号资料'.

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

Usage Guidelines2/5

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

There is no guidance on when to call this versus share_get_profile, share_login_complete, or share_logout. The agent must infer that this is a pre-flight auth check; no preconditions or exclusions are given.

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