get_log_buffer_info

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

Describes return values (entries/capacity, oldest/newest, cumulative stats, dedup). Does not explicitly state read-only but from description it's clearly a read operation. No annotations provided, so description carries burden.

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?

Highly structured with clear sections (When to call, Port convention, Return value, Loop step). No redundant sentences. Front-loaded with usage context.

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?

Overall very complete given no output schema and one parameter. Explains return fields and typical use case. Only minor gap is port parameter explanation, relying on sibling reference.

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?

Schema has 0% coverage for the single 'port' parameter. Description only references the same convention as get_recent_logs, which is insufficient standalone. Agent must look up sibling tool to understand parameter meaning.

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?

Description clearly states the tool's purpose: to check buffer fullness and see recent/oldest items. It uses a specific verb ('볼 때') and resource ('버퍼'). It distinguishes from siblings by mentioning it's for buffer info, not log retrieval or clearing.

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?

Explicitly says when to call: to quickly see buffer state, especially after clear_log_buffer for polling. Provides context for parameter usage by referencing get_recent_logs convention.

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