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

No annotations are present, so the description carries the full burden. It discloses authentication requirements (user_email + session_token), that it is a paid feature, and that it provides real-time logs. However, it does not explicitly state read-only behavior, data retention, or error response details. The parameter description in the schema mentions '只讀你自己的終端機日誌' (read only your own logs), but that is not reinforced in the main description, which says '取得某使用者' (get a user's) - a slight ambiguity.

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 compact and front-loaded with the primary purpose. It repeats information in Chinese and English, which is somewhat redundant, but each sentence earns its place (purpose, auth/paid, setup command). No excessive fluff, but the English summary could be removed for better conciseness.

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?

Given the tool's simplicity (2 params, no output schema) and well-documented parameters, the description covers the essential context: what it does, auth and paid requirements, and the necessary developer setup command. It lacks a description of the return format or pagination behavior, but for a log retrieval tool with a well-known domain, this is acceptable. The mention of 'stderr/throw/crash' adds useful scope information.

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 coverage is 100% with both parameters having detailed descriptions, so the baseline is 3. The tool description does not add new parameter-level meaning; it repeats the auth requirement and mentions the npx setup command indirectly. It also says 'requires user_email and session_token' while the schema marks session_token as optional (only user_email is required), creating minor ambiguity. Thus no value 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 function: '取得某使用者終端機的即時錯誤日誌' (get a user's terminal real-time error logs), specifying stderr/throw/crash. This distinguishes it from siblings like get_console_logs or get_network_errors, as it is specifically for terminal error logs. The verb and resource are explicit.

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 concrete prerequisites: requires user_email and session_token, is a paid feature, and developers must run 'npx bugezy-watch -- <command>' to set up log capture. It does not explicitly compare to sibling tools, but the specificity of 'terminal error logs' implies when to use it. This is clear practical guidance, but lacks explicit alternative/exclusion statements.

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