查看执行日志正文

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

With no annotations, the description carries the full burden of behavioral disclosure. It reveals the tool's incremental pagination behavior and the source ('来自执行器'), and explicitly references return fields toLineNum and isEnd. This provides valuable operational context beyond what a typical 'get content' tool might state, aiding the agent in correctly looping through long logs.

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 exactly two sentences, front-loaded with the main purpose. The first sentence states what the tool does, and the second explains the pagination pattern. Every sentence earns its place, with no redundant filler.

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?

The tool is relatively simple (fetch log content with pagination), and the description explains the pagination loop clearly. However, since there is no output schema, the description does not fully describe the response structure (e.g., the exact field name for the log content itself). It mention toLineNum and isEnd, which is helpful, but the overall return format is not specified. This is a minor gap, so a 4 is appropriate.

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 description coverage is 100%, and each parameter already has a clear description, including the fact that logId/executorAddress/triggerTime are obtained from list_job_logs and that fromLineNum should be set to previous toLineNum+1. The tool description adds little beyond restating these schema details, so it stays at the baseline 3.

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 action: '增量拉取某条执行记录的日志正文（来自执行器）' (incrementally pull the log body of a specific execution record from the executor). It uses a specific verb and resource, and it distinguishes this from sibling list_job_logs by emphasizing it retrieves the log content, not the log metadata.

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 instructs that logId, executorAddress, and triggerTime come from list_job_logs, establishing a clear prerequisite. It also details the incremental reading protocol: use returned toLineNum+1 as the next fromLineNum until isEnd=true. This provides concrete when-to-use and how-to-continue guidance, going beyond just stating the tool's purpose.

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