Skip to main content
Glama

show_bilibili_status_card

Display Bilibili MCP configuration status in a rich card showing account tier, cookie state, and cache headroom, so you can verify setup at a glance.

Instructions

Show bilibili-mcp configuration status as a rich in-chat card.

[RATIONALE] Status tools MUST ship a Prefab surface - one call shows tier, cookie state and cache headroom at a glance.

Return Format

ToolResult with content (plain text fallback) + structured PrefabApp card.

Examples

show_bilibili_status_card()

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

Discloses return format: ToolResult with plain text fallback plus structured PrefabApp card, and lists the status dimensions shown. With no annotations, this gives the agent concrete behavioral expectations. It stops short of covering edge cases or failure behavior, so not a 5.

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

Conciseness3/5

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

The purpose is front-loaded and the return-format note is useful, but the RATIONALE and Examples sections are essentially padding for a zero-param tool; the example only repeats the call name. It is reasonably short but not every sentence earns its place.

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?

For a zero-param status card it covers the core purpose and return format, which is most of what an agent needs to invoke it. However, it lacks guidance on when to choose this over sibling status/cache/trending cards and doesn't mention behavior when configuration is missing or incomplete.

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 covers this completely, so there are no parameter semantics for the description to add. The 0-param baseline of 4 applies; the description correctly avoids inventing parameter details.

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 'Show bilibili-mcp configuration status as a rich in-chat card' and names the concrete contents: tier, cookie state, and cache headroom. This is a specific verb+resource that distinguishes it from sibling tools like show_bilibili_cache_card or show_bilibili_trending_card.

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

Usage Guidelines2/5

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

There is no when-to-use guidance or comparison with alternatives. The RATIONALE is a design mandate about shipping a Prefab surface, not practical advice for choosing this tool over sibling status/cache/trending cards, so the agent receives no selection criteria.

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