Read the current Baldur's Gate 3 Script Extender runtime log and filter lines by keyword, error, or mod tag to debug mod behavior during a live game run.
Tail the current game run's Script Extender runtime log, optionally only lines containing filter
(e.g. '[Apotheosis]', 'error', 'FAILED').
| Name | Required | Description | Default |
|---|---|---|---|
| lines | No | ||
| filter | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It adds useful scoping ('current game run's' log) but never confirms this is a non-mutating read, does not mention whether the log is truncated, buffered, or where it lives, and gives no pagination or refresh semantics.
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?
A single tight sentence that front-loads the operation and then the optional refinement. No wasted words, though the parenthetical examples could be folded in more economically.
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?
An output schema exists, so return shape needn't be described. However, with zero annotations and 0% schema coverage on a log-tailing tool, the description omits key operational facts such as the `lines` behavior and whether the read is safe/repeatable.
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 0%, so the description must compensate for both parameters. It explains the `filter` argument well (with concrete examples), but the `lines` parameter is never mentioned at all, leaving half the input surface undocumented.
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 states a specific verb (Tail) and resource (the current game run's Script Extender runtime log), which is precise enough for an agent to understand the operation. It does not, however, distinguish itself from sibling SE tools like bg3_se_status or bg3_se_command.
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?
It gives implied usage through the filter examples ('[Apotheosis]', 'error', 'FAILED'), which suggests debugging/diagnostic intent, but it never states when to prefer this tool over the sibling bg3_se_status or bg3_se_live_entry tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.