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

With no annotations, the description carries the behavioral burden. It clearly communicates the action and adds a helpful behavior detail about crossing midnight, though it does not mention side effects like overwrites, conflicts, or persistence.

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 two concise sentences with no filler. It front-loads the core purpose and follows with a practical format clarification.

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 five parameters, no output schema, and no annotations, the description is fairly complete for a simple add operation. It explains the main behavior and format edge case; while it omits error/conflict behavior, that is not critical for basic invocation.

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 coverage is 100%, but the description adds meaningful parameter-related context by explaining that a window crossing midnight (e.g. 23:00-06:00) is handled automatically, which clarifies the start/end relationship beyond individual field descriptions.

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 a specific action and resource: 'Schedules a charging time window.' It distinguishes this from sibling operations like get_charging_schedule, remove_charging_schedule, and set_charging_allowed.

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?

Usage is implied by the tool name and verb, but the description does not explicitly say when to use this tool versus alternatives, nor does it mention exclusions or relationships with sibling schedule-related tools.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It states the output is ordered most recent first and enumerates the returned attributes, which helps the agent predict the result. It does not mention read-only semantics, pagination, or error cases, but the tool name and passive phrasing suggest a non-mutating lookup.

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 a single sentence, front-loads the most important fact (past sessions ordered newest first), and lists attributes without redundancy. Every phrase adds 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 no output schema, the description does a reasonable job of outlining the returned data and ordering, which is the main thing an agent needs. It is slightly incomplete because it does not clarify how 'started and stopped the charge' is represented, nor does it explain the default limit behavior, but the schema covers parameter constraints.

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?

Both parameters (limit, charger) already have descriptions in the schema, so coverage is 100%. The tool description does not add any additional parameter-level semantics beyond the schema, so the baseline score of 3 applies.

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 identifies the resource ('past charging sessions') and specifies ordering and key fields, making the tool's purpose clear. However, it lacks an explicit verb like 'lists' or 'returns,' and it does not explicitly contrast with get_charging_schedule, so it falls just short of full clarity.

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 word 'past' implies this is for completed sessions, and the listing of start/stop/energy fields gives context. But there is no explicit statement of when to use this versus siblings like get_charging_schedule, nor exclusions for cases where history is unavailable.

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

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

With no annotations, the description must convey side effects and return behavior. It does not state whether the tool is read-only, returns data, or has any side effects. While the tool name suggests a getter, the description itself does not disclose the behavioral contract, leaving uncertainty about what the tool does.

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 a single, concise sentence fragment that directly states the subject. It includes a relevant detail about time format (HH:MM) without extraneous information. It is well-structured and easy to parse, though slightly informal as a fragment.

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 tool is a simple getter, the description is incomplete because it fails to explicitly state the action (retrieval) and the expected result. It provides the subject matter but not the operational context. A user cannot fully understand what the tool does without inferring from the name, making it contextually incomplete.

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?

Both parameters have individual schema descriptions explaining their purpose and optionality ('Charger name. Unnecessary if only one is configured'). The tool description does not add additional meaning beyond the schema, placing this at the baseline. The descriptions are adequate but not enhanced by the main description.

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 'Scheduled charging time windows' is a noun phrase and does not explicitly state that the tool retrieves or returns the schedule. It lacks a clear verb like 'get' or 'retrieve', making the action ambiguous. A user might infer it from the tool name, but the description alone is insufficient.

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 provides no guidance on when to use this tool versus sibling tools such as add_charging_schedule or remove_charging_schedule. It does not mention that it is for viewing or retrieving existing schedules, nor does it contrast with the mutation tools. The absence of any directional context leaves the user without selection criteria.

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

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

With no annotations, the description carries the full burden. It clearly states the tool is read-only and mentions that changes are not possible through this tool, indicating no side effects. It does not discuss error conditions or permission requirements, but the core behavioral trait is disclosed.

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 somewhat verbose and contains clunky phrasing, especially the section about 'under "readOnly" OCPP, Modbus and MQTT'. It could be streamlined to 'Full read-only configuration: device, power limits, SPL mode, solar, LEDs, and read-only OCPP, Modbus, and MQTT settings (changeable only via the web interface).'

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 description lists the main categories of configuration returned (device, power limits, SPL mode, solar, LEDs, and network protocols) and explains the read-only constraint. It does not describe the output structure, but for a configuration fetcher this is acceptable given no output schema is provided.

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 single parameter 'charger' is well-described: it is the charger name and is explicitly noted as unnecessary when only one is configured. This fully clarifies the optional nature and purpose of the parameter.

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 this tool retrieves the full configuration (device, power limits, etc.) and is read-only, distinguishing it from the status and setting tools. However, the phrasing 'and under "readOnly" OCPP, Modbus and MQTT' is slightly awkward and could be interpreted ambiguously.

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 notes the configuration is read-only and that changes can only be made via the web interface, which guides agents not to use this tool for modifications. It does not explicitly state when to use it, but the read-only nature is a clear context clue.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It discloses the default aggregation over all chargers when 'charger' is omitted and defines the output categories returned: house draw, car draw, and active limits. It does not discuss response format or edge cases, but the read-only nature is clear from the get verb and the subject matter.

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?

Two compact sentences, front-loaded with the core result and then providing the aggregation default. There is no filler, repetition of schema property names, or unnecessary detail.

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 two-parameter read tool, the description covers the operation, the default parameter behavior, and the nature of the returned data. It does not explicitly route to sibling tools, but the instantaneous-status framing and sibling names provide enough context; an output schema is absent, but the described readings are sufficient for an agent to invoke and interpret the result.

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 schema already documents both optional parameters, and the description adds meaningful behavior for the charger parameter: omitting it reports all chargers. This clarifies the default beyond the schema's note that the parameter is unnecessary when only one charger is configured. Element semantics are left to the schema, which covers them adequately.

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 that the tool reports 'charging status and instantaneous power' for chargers, enumerating the key readings: house draw, car draw, and active limits. This makes it clearly distinct from sibling history, configuration, and schedule 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?

The 'instantaneous' wording implies current-state usage as opposed to historical data, but the description never explicitly names alternatives or says when not to call this tool. The only usage guidance is about omitting the charger parameter, which concerns invocation rather than tool selection.

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

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

With no annotations present, the description carries the burden and clearly states that the tool removes an existing schedule, implying a destructive change. It does not mention irreversibility or side effects, but the core behavior is transparent.

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 a single, focused sentence with no redundant information, making it easy to parse and act upon.

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 description provides enough context to understand what the tool does and how to obtain the required id. There is no output schema, but the absence of return-value details is not critical for this simple removal action.

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 schema already provides descriptions for all three parameters, and the description adds useful context that the id comes from get_charging_schedule. It does not elaborate further, but coverage is complete.

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 action ('Removes a scheduled time window') and the specific resource, and references get_charging_schedule to distinguish it from adding or retrieving schedules.

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 explicitly instructs that the id should be obtained from get_charging_schedule, providing a clear precondition. It does not explicitly contrast with add_charging_schedule, but the action is unambiguous.

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

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

With no annotations, the description must carry the behavioral disclosure burden. It adds one useful caveat ('allowed maximum is whatever the device declares'), but it does not state whether the limit is applied immediately, persists, requires selecting a charger when multiple are configured, or what happens on invalid/out-of-range values. This is a significant gap for a mutating tool.

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 two short, front-loaded sentences with no fluff or tautology. Every sentence contributes either to the core action or to a useful behavioral boundary.

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 description covers the core intent and a device-specific caveat, which is adequate for a simple setter. However, for a mutation with no annotations and no output schema, it omits practical operational details: how to discover the device-declared maximum, whether the requested value is clamped or rejected, and what response or confirmation to expect.

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%, so the baseline is 3 even without parameter details in the description. The description reinforces that amps is measured in amperes and adds the device-declared cap context, but it does not add meaningful semantics beyond the schema, especially for the optional charger parameter.

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 a specific action ('Sets the maximum current in amperes') and a specific resource ('charger can deliver to the car'). It distinguishes itself from sibling set_* tools like set_charging_allowed or set_home_power_limit by focusing on current limits, even though it does not explicitly name any sibling.

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 explicit guidance about when to use this tool versus alternatives, and no mention of excluded scenarios. The note about the device-declared maximum is a constraint on behavior, not usage context or selection criteria.

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

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

With no annotations provided, the description must fully disclose behavior, and it does. It reveals the non-interrupting behavior, the lack of a local-network method to stop active charging, and the refusal condition when no scheduled windows exist. These are non-obvious behavioral traits that prevent misuse and give the agent an accurate model of the tool's effects.

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 and front-loaded: the primary purpose appears in the first sentence, and the following sentence delivers two important caveats. Every clause earns its place; there is no filler or redundant restatement of the tool name.

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 boolean setter with only one required parameter, the description is complete. It states the core behavior, the important side-effect (no interruption of in-progress sessions), the failure precondition, and the network limitation. No output schema exists, but for a set operation this is not a significant gap; the agent has enough to invoke it correctly.

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%, with the schema already clearly documenting 'allowed' as 'true to permit charging, false to block new sessions' and 'charger' as optional when only one is configured. The description adds no additional parameter semantics beyond what the schema provides, so the baseline score 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 opens with a specific verb and resource: 'Allows or blocks charging outside the scheduled windows.' It further clarifies scope by stating that it 'governs whether a session may begin,' which distinguishes it from other control tools that adjust limits or schedules. Even without naming a sibling, an agent can unambiguously separate this from set_home_power_limit, set_charger_current_limit, and the schedule-related 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?

The description gives explicit when-to-use and when-not-to-use context: it only affects new sessions and 'does NOT interrupt charging already in progress.' It also discloses that the charger refuses the change unless at least one scheduled window exists, which is a critical precondition. This tells the agent exactly when the tool is valid and when another approach would be needed, while also noting that no local-network alternative exists for interrupting in-progress charging.

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

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

With no annotations, the description carries the behavioral burden. It does disclose the core action, the no-parameter default, and the coupling requirement for timezone fields. However, it does not mention side effects, success/failure behavior, or any required authorization, so it is only moderately transparent.

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 three short, purposeful sentences with no filler. The core action is front-loaded, and each sentence adds distinct meaning: the operation, the default behavior, and the parameter coupling rule.

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 setter with no output schema and no annotations, the description is largely sufficient: it covers the operation, the no-parameter behavior, and the critical timezone parameter constraint. It omits explicit success/error behavior and preconditions, so it is not maximally complete.

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 schema already describes all four parameters, so the baseline is 3. The description adds a valuable dependency not captured by the schema: timezone and timezoneCode must be provided together. It also reinforces that omitting parameters sets the current time, which aligns with epochSeconds being optional.

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 ('Synchronizes') and a specific resource ('charger clock'), clearly distinguishing this tool from the get_* and other set_* sibling tools. It also explains the default no-parameter behavior, leaving no ambiguity about what the tool does.

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 usage context is implied: this tool is for setting or synchronizing the charger clock, and the sibling tools are clearly in different domains. However, there is no explicit when-to-use, when-not-to-use, or named alternative tool, and the timezone pairing note is operational guidance rather than tool-selection guidance.

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

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

With no annotations, the description carries the full burden and does well by explaining the propagation behavior in SPL setups and the warning in independent setups. It identifies a meaningful behavioral difference that the schema and annotations would not convey, though it omits details about persistence or side effects.

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?

Two sentences, front-loaded with the core purpose and followed by the key conditional behavior. No filler or redundant restatement of schema fields.

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 tool's moderate complexity and lack of output schema, the description covers the core action, the setup-dependent behavior, and the warning response. It does not explicitly describe the success response format, but for a straightforward setter this is a minor gap.

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 coverage is 100%, so the baseline is 3. The description adds value by clarifying that limitW applies to the household electrical supply rather than a single charger, and the master/slave explanation gives useful context for how the charger parameter behaves.

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?

States a specific action ('Sets') and a specific resource ('maximum power in watts that the household electrical supply can deliver'). It clearly distinguishes itself from the sibling set_charger_current_limit by referring to the household supply rather than an individual charger.

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 gives clear context for when the tool applies, particularly noting the SPL master/slave versus independent setup behavior. It does not explicitly name alternative tools or state when not to use this one, but the household-supply framing makes the intended use reasonably clear.

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

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

As a setter, the action is straightforward and the description adequately conveys the state change. However, it does not mention potential side effects or prerequisites (e.g., whether the charger must be connected). Since no annotations are present, the description carries the full burden but remains sufficiently clear for a simple operation.

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, using two short sentences to convey purpose and parameter details. It contains no redundant information or unnecessary fluff, making it efficient for an agent to parse.

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 description covers the tool's purpose, parameter semantics, and expected behavior for a simple setter. It does not describe return values or error conditions, but given the lack of an output schema and the straightforward nature of the operation, the provided information is sufficient for correct usage.

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 elaborates on the intensity enum values ('0 off, 50 reduced, 100 full') and clarifies that the charger parameter is optional when only one is configured. This adds meaningful context beyond the schema, which already lists the parameters but lacks this explanatory detail.

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 function ('Sets the charger LED intensity') and explains the accepted values, making it unambiguous. It is distinct from sibling tools like set_charging_allowed or set_home_power_limit by specifying the LED intensity setting.

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 states what the tool does but does not explicitly mention when to use it against alternatives. It provides no conditional guidance or contrasting examples with sibling tools, leaving the user to infer its purpose from context.

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

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

With no annotations, the description carries the full burden. It states what the tool does (enable/disable solar charging, set priority) but does not disclose side effects, idempotency, or potential interactions with other settings. This is adequate for a simple setter but lacks depth.

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 a single, concise sentence that covers the core functionality without unnecessary words. It is well-structured and immediately understandable.

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 setter, the description and schema are sufficient to understand how to invoke it. There is no output schema, which is acceptable for a mutating action, but the description does not mention return values or error conditions, leaving minor gaps for edge cases.

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?

All three parameters have descriptions in the schema (charger, enabled, priority), and the tool description reinforces their purpose. However, the descriptions are minimal—priority lacks explanation of its numeric range or default behavior, and charger is only vaguely described as a name.

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 enables or disables solar charging and sets its priority, using specific verbs and a clear resource. It is distinguishable from sibling tools like set_charging_allowed and set_home_power_limit.

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?

No explicit guidance is given on when to use this tool versus alternatives such as set_charging_allowed or set_home_power_limit. The description implies it is for solar-specific settings but does not clarify appropriate contexts or prerequisites.

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