Skip to main content
Glama

alibaba_auth_status

Read-only

Check whether an Alibaba seller is authorized and view when the token expires, so you can confirm access before publishing or updating listings.

Instructions

Show whether a seller is authorized and when the token expires.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
account_keyNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okNo
errorNo
expiredNo
accountsNo
authorizedNo
error_typeNo
expires_atNo
account_keyNo
has_refresh_tokenNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safe, local-read nature is known without the description. The description adds the useful behavioral fact that the payload covers both authorization state and token expiry, but says nothing about what happens with a missing/invalid account_key or token refresh 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?

A single tight sentence that front-loads the core purpose (authorized?) and adds the secondary detail (expiry) without filler. Nothing to trim.

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 values need no explanation, and the read-only annotations cover the safety profile. However, for a tool whose only parameter is undocumented in both schema and description, the definition is not quite complete enough to call confidently without inspecting the schema.

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% for the single account_key parameter, and the description never mentions it — not what it identifies, what format it takes, or what an empty default means. With a non-trivial parameter fully undocumented, the description fails to compensate for the schema gap.

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 check (authorization status) plus a concrete detail (token expiry), which cleanly identifies the tool's job. It doesn't explicitly contrast itself with siblings like alibaba_get_authorize_url or alibaba_complete_authorization, but the resource (auth status) is distinct enough to select it.

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

Usage Guidelines3/5

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

Usage is only implied: an agent infers it should call this to check whether a seller is connected or when the token lapses. There is no explicit statement of when to use this versus alibaba_get_authorize_url (to start auth) or alibaba_complete_authorization (to finish it), nor any prerequisite guidance.

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