bilibili_get_account

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. The description only states the tool gets info from a 'quality library' and explains the parameter. It does not disclose whether the operation is read-only, if authentication is required, what fields are returned, or any rate limits. The term '优质库' is vague and could mislead about the data source. The description is insufficient for an agent to understand the tool's behavior.

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

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

The description is extremely concise: two short sentences that front-load the purpose and parameter explanation. Every sentence is necessary and informative. No fluff or redundancy. It is optimally sized for a simple tool with one parameter.

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

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

Despite the presence of an output schema (which reduces the need to describe return values), the description lacks crucial context for decision-making. The ambiguous '优质库' is not explained. There is no guidance on when to use this tool over sibling tools like bilibili_search_users or bilibili_get_user_works. For a tool with multiple siblings in the same platform, the description should provide more contextual cues to help the agent select correctly.

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

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

The input schema has one parameter 'mid' with no description in the schema itself (schema description coverage 0%). The description adds 'mid 为 B 站用户唯一 ID', which explains the semantic meaning of the parameter. This is valuable beyond the schema. However, it does not specify format, length, or constraints. Given the low schema coverage, the description compensates well but not exhaustively.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: getting Bilibili UP master info. It specifies the resource ('UP主信息') and the required parameter ('mid'). While it doesn't explicitly distinguish from siblings like bilibili_search_users, the verb 'get' and the mention of 'mid' as a unique ID imply a direct lookup, not a search. The addition of '优质库' (quality library) suggests a specific dataset, adding some context but also potential ambiguity.

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

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

The description provides no guidance on when to use this tool versus alternatives. Sibling tools include bilibili_search_users (which might also return user info) and bilibili_get_user_works (which lists works for a user). No mention of prerequisites, limitations, or scenarios where this tool is preferred. The agent has no explicit criteria to choose this tool over others.

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