eda_sys_log_find

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose one behavioral trait (if the log panel is open, the search result appears in the frontend) and states the return type, but it does not indicate whether the operation is read-only, whether it has side effects beyond the display remark, or how the matching algorithm behaves (exact, substring, regex). For a tool with no safety annotations, this is a significant gap.

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: a signature line, a short Chinese label, a remark, and a return statement. The signature is front-loaded, giving immediate orientation. There is minimal redundancy, although the '查找条目' label largely restates the signature. It is concise without sacrificing the most critical type information.

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 absence of annotations and an output schema, the description should be self-sufficient. It provides the signature and one display side-effect, but omits essential information: what a log entry looks like, how message matching works (exact vs. partial, case sensitivity, escaping), the meaning of ESYS_LogType values, and the role of the windowId parameter from the schema. An agent would be unable to construct a well-formed query or predict results confidently.

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 only provides generic 'args' and 'windowId' containers, so the description's signature is the primary source of parameter meaning. It adds the full type structure for the first argument (string or array of strings/objects with text and optional attr) and marks the second argument as optional. This is valuable beyond the schema, though it stops short of explaining the semantics of the filter (e.g., what fields are matched) or the possible values of ESYS_LogType.

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 contains a clear signature 'sys_Log.find(...)' plus the Chinese term '查找条目' (find entries) and a return type of matching log entries. This identifies the resource (system log) and operation (find/search) distinctly from siblings like eda_sys_log_add, _clear, _export, and _sort. It falls short of a 5 because it relies mostly on the signature rather than a plain-language statement of purpose, and does not explicitly contrast with sibling log tools.

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?

There is no guidance on when to use this tool versus the many sibling log tools (add, clear, export, sort) or other search tools. The only contextual clue is the remark about frontend display when the log panel is open, which is a behavior hint, not a usage directive. No conditions, exclusions, or alternatives are described.

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