Skip to main content
Glama

alibaba_get_authorize_url

Read-only

Generate an OAuth authorization URL for Alibaba sellers to grant app access. After they approve, exchange the returned code via alibaba_complete_authorization.

Instructions

Get the OAuth URL the seller opens to grant this app access.

Send the returned URL to the seller. After they approve, the platform redirects to the app's configured callback with a ?code=...; pass that code to alibaba_complete_authorization.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
stateNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okNo
errorNo
error_typeNo
authorize_urlNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds real behavioral context beyond them: the URL is meant to be handed to a human seller, approval triggers a callback redirect carrying ?code, and that code must be forwarded. It does not mention URL expiry or scope requirements, so it is not fully exhaustive.

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?

Two tight sentences: the purpose first, then the hand-off flow. No filler, and the next-step dependency is front-loaded rather than buried.

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?

An output schema exists, so the returned URL format need not be explained, and the description correctly covers the end-to-end auth hand-off. The one real hole is the unexplained `state` parameter; otherwise nothing needed to call this correctly is missing.

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% and the description never mentions the single `state` parameter, so the agent gets no guidance on what to put there or that it is optional (defaults to empty). With a low-coverage schema the description is expected to compensate, and it does not.

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 ('Get the OAuth URL') plus the actor and scope ('the seller opens to grant this app access'). It also implicitly separates itself from alibaba_complete_authorization by naming that tool as the downstream step.

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?

Explains the operational flow clearly: send the URL to the seller, they approve, the platform redirects with a ?code, and that code goes to alibaba_complete_authorization. It names the alternative sibling and the condition for using it, though it never states when this tool should not be used (e.g. already-authorized cases).

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