Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

kick_gifts

List Kick gifts viewers can send, including prices in Kicks, tiers, types, and level-up message pin limits.

Instructions

List the gifts viewers can send on Kick. Returns the catalog of gifts viewers can send on Kick (kick.com) with Kicks, Kick's virtual currency: gift id, name, price in Kicks, tier (BASIC, MID or HIGHER), type (BASIC or LEVEL_UP), and for level-up gifts the message length they allow and how long they pin the message in chat. This call takes no parameters.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.16

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the burden, and it does signal a read-only catalog listing and explicitly states no parameters are accepted, removing any doubt that it is a side-effecting call. It stops short of describing ordering, pagination, or caching behaviour, which keeps it below the top mark.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the action, followed by a compact field enumeration. There is mild redundancy: the second sentence restates 'the catalog of gifts viewers can send on Kick' almost verbatim from the first, which could have been trimmed.

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 zero-parameter catalog with no output schema, the description does the heavy lifting by enumerating gift id, name, price, tier, type, and level-up message length/pin duration. That is nearly enough for an agent to consume the result; what remains unstated is result ordering or whether the list is paginated.

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, so the baseline is 4. The description reinforces this with an explicit 'This call takes no parameters' statement, which is more than the empty schema alone conveys.

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 opens with a specific verb and resource: 'List the gifts viewers can send on Kick.' The domain (kick.com), currency (Kicks), and returned fields are all named, so the agent knows exactly what this returns. No sibling tool in the kick_* family covers gift catalogs, so the resource is unambiguous even without explicit routing.

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 implied rather than stated: 'gifts viewers can send' tells the agent the catalogue's purpose, and 'This call takes no parameters' sets expectations. But there is no explicit when-to-use or when-not-to-use guidance, and no mention of how this relates to other Kick endpoints an agent might reach for.

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