get_current_appGet the ID of the app currently in the foreground on an LG webOS TV. Identifies which app is active to enable context-aware automation or control.
現在前面に表示されているアプリの ID を返す。
| Name | Required | Description | Default |
|---|---|---|---|
| device | No | 対象デバイス名または IP。省略時は既定デバイス（--device / WEBOS_DEVICE / devices.json の defaultDevice） |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the safety profileessed by the tool. The description clarifies that it returns an app ID, but does not disclose extra behavioral details such as output format or behavior when no foreground app exists.
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 one compact, front-loaded sentence with no filler or redundant phrasing. Every word earns its place.
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?
For a simple read-only tool with one fully documented optional parameter and no output schema, the description is complete: it states what is returned and the annotations convey that it is non-destructive.
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 description adds no parameter-specific information, but the input schema fully documents the single optional 'device' parameter, including its default behavior. With 100% schema coverage, the baseline of 3 is appropriate.
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 uses a specific verb ('返す' / returns) and a precise resource: the ID of the app currently shown in the foreground. This clearly distinguishes it from sibling tools like list_apps, launch_app, and get_current_channel.
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 implies when to use the tool: when the current foreground app's ID is needed. However, it does not explicitly mention alternatives or conditions for choosing this over list_apps or get_current_channel.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.