MiniURL

MiniURL create_guest_token

create_guest_token

Create a short-lived MiniURL guest bearer token. Legacy MCP sessions retain it; stateless clients must pass the returned gt_ token explicitly on later requests. shorten_url can provision one automatically.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	No
`meta`	No
`error`	No
`success`	Yes
`approval`	No
`retryable`	No
`request_id`	Yes
`retry_after`	No
`next_actions`	No
`required_scope`	No
`user_action_required`	No

TDQS

A4.5/5.0

Behavior4/5

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

Beyond the annotations (readOnlyHint=false, etc.), the description discloses the token's short-lived nature and the difference between session-retained and stateless usage. This adds useful behavioral context, though it does not detail lifecycle or invalidation 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?

The description is three sentences long, front-loading the core purpose and adding only essential usage notes. Every sentence provides valuable information without redundancy.

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?

Given the tool has no parameters and an output schema exists, the description sufficiently covers the operation's purpose, the token's characteristics, and how to use it in different client contexts. It also mentions an automatic provisioning alternative, making it self-contained.

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

Parameters4/5

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

The tool has zero parameters and the schema description coverage is 100% (empty schema). With no parameters to explain, the description adds all necessary semantic value by focusing on the token's purpose and usage.

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?

The description clearly states the tool's function: creating a short-lived MiniURL guest bearer token. It specifies the token type ('guest bearer token') and its prefix ('gt_'), distinguishing it from other tools like shorten_url or clear_authentication.

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 description provides usage context by explaining that legacy MCP sessions retain the token while stateless clients must pass it explicitly, and notes that shorten_url can provision one automatically. This gives an alternative but does not explicitly state when not to use this tool or give a direct comparison.

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

All MiniURL tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation5/5

Each tool targets a clearly distinct resource and action: links, domains, tags, auth, and account status are all separate concerns. Even similar tools like shorten_url and bulk_create_links are differentiated by single vs. batch creation, and check_alias is distinct from get_link by checking availability before creation.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., add_domain, delete_link, list_tags, verify_registration_code). Mixed verb styles like tag/untag and shorten_url are still predictable and fit the established convention.

Tool Count3/5

At 23 tools, the set is on the heavy side and falls in the 16-25 borderline range. The number is somewhat justified by the broad scope (links, domains, tags, auth, analytics), but it approaches the upper limit where an agent may have difficulty selecting between many options.

Completeness5/5

The tool surface covers the full lifecycle of short links (create, read, update, delete, list, stats), domain management (add, delete, verify, list), tags (create, list, delete, tag/untag), and account/auth flows (guest tokens, registration, pro upgrade). It is hard to identify any critical missing operation for the stated purpose.

Resources

Need Help?