Both tools have well-written descriptions (120-180 chars, within baseline 34-392 range) and clear use cases. However, both have EMPTY input schemas (type:object with no properties), violating the critical rule that tools with no input schema must score 0 on schema. Tool names use verb_noun pattern correctly (get_*). No parameter descriptions exist because there are no parameters. Output schemas are completely undocumented, LLMs cannot plan downstream calls or extract required fields. No error handling guidance. These are read-only discovery tools with minimal complexity, but the lack of output schema documentation and empty input schemas are hard failures for production use.

• Document the output schema for both tools. Specify what fields getSelectedElement returns (e.g., elementType, automationId, text, hasXamlSource) and what getDataSnapshot returns (e.g., logs[], network[], preferences, device, sensors, alerts, followUpTools[]).
• Add error handling guidance: 'If no element is selected, returns error code NO_SELECTION. If snapshot is stale, returns SNAPSHOT_EXPIRED with timestamp. Retry with getDataSnapshot() to refresh.'
• Clarify the 'followUpTools' mechanism in getDataSnapshot description: 'Returns an array of followUpTools with identifiers (e.g., {id: "logs_detail", name: "getLogDetail"}) that can be passed to subsequent queries for deeper detail.'
• Add tool annotations (readOnlyHint: true) to both tools in the languageModelTools contribution to signal they are safe to call without side effects.
• Document pagination or limits if either tool can return large result sets (e.g., 'Returns up to 100 log entries; use followUpTools to paginate').