Skip to main content
Glama
kickbase-mcp

kickbase-mcp

by behretv

Sell Player To Kickbase

sell_player_to_kickbase

Accept Kickbase’s system offer on a listed player to complete an instant sale and remove the player from your squad.

Instructions

Accept Kickbase's system offer on a listed player: instant sale. REAL SALE.

Input Schema

NameRequiredDescriptionDefault
league_idNo
player_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. 'instant sale' and 'REAL SALE' warn that this is a real, immediate mutation, but there is no disclosure of permissions, squad removal, fund crediting, failure cases, or irreversibility beyond emphasis.

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?

The description is short and front-loaded with the core action. The all-caps 'REAL SALE' is informal but functions as an emphasis warning, and there is no verbose filler; it is simply too terse for the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a destructive sale operation with no annotations, no output schema, and 0% parameter description coverage. The description omits key prerequisites, side effects such as player removal or fund credit, and error/return behavior, leaving the agent with insufficient context for safe invocation.

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%, so the description must compensate for two undocumented parameters. It only vaguely implies a player via 'listed player' and never explains player_id, league_id, their formats, or the optional/default nature of league_id.

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 action: accepting Kickbase's system offer for a listed player, resulting in an instant sale. The phrase 'system offer' helps distinguish it from generic offer-acceptance siblings like accept_offer, but it does not explicitly name alternatives or clarify when this is preferred over them.

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?

The conditions 'system offer' and 'listed player' imply when the tool applies, but the description gives no explicit prerequisites, when-not conditions, or alternatives such as accept_offer or list_player_for_sale. Usage is inferable but not guided.

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