Get bot info

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

Annotations already declare readOnlyHint=true, and the description adds context about the returned data and bot selection behavior. It doesn't contradict annotations and adds value by specifying the exact status items and the optional bot selection mechanism.

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?

Two sentences with front-loaded purpose, followed by optional usage and alternatives. No wasted words; the structure is clear and efficient.

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?

For a simple status tool with one optional parameter and no output schema, the description covers purpose, usage, alternatives, and behavior completely. No gaps are evident.

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 schema already fully documents the bot parameter (100% coverage), but the description goes beyond by adding contextual guidance: when to pass it (multiple bots) and how to discover valid values via list_servers. This adds meaning beyond the schema.

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: to get identity and status of a connected Discord bot, enumerating specific fields like bot user, application, guild count, gateway intents, and Omnicord version. It also distinguishes from siblings by mentioning run_setup_check for health checks and referencing list_servers for configured bots.

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 explicitly explains when to use the bot parameter (when more than one bot is configured) and points to list_servers for discovering bots. It also directs users to run_setup_check for a full health check, providing clear alternative guidance.

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