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

Annotations already declare this a non-read-only, non-destructive, non-idempotent write, so the bar is lower. The description still adds genuinely useful behavior the schema cannot convey: VIRTUAL crops are fed by the simulator, and REAL crops return MQTT credentials exactly once and the server then hides them from the model — a critical, one-shot side effect an agent must anticipate.

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, purpose front-loaded, with no filler. The second sentence is dense but packs two distinct facts (simulator behavior, one-time credential return) without separating them, which slightly hurts scanability but not economy.

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 values need no explanation. However, for an 11-parameter creation tool with 0% schema description coverage, the description should clarify at least the geography parameters (latitude/longitude/place_name pairing) and the virtual_mode vs virtual_interval_seconds interaction; it covers only 'kind', leaving most of the call surface unexplained.

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% across 11 parameters, so the description carries the full burden and largely fails. It explains only 'kind' (REAL vs VIRTUAL) and its consequences; form, setting, exposure, latitude/longitude, place_name, virtual_mode and virtual_interval_seconds are left entirely to bare enum values in the schema, with no explanation of which combinations are valid.

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+resource ('Crea un cultivo'), which inherently separates it from update_crop, delete_crop and list_crops. It also clarifies that the tool has two modes with distinct outcomes. It never names a sibling explicitly, but the create verb makes the routing decision unambiguous.

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 only implied: an agent infers it should call this when a crop must exist. The VIRTUAL/REAL sentence hints at choosing the simulator-backed mode for testing, but there are no explicit conditions, prerequisites, or 'use X instead' statements, and no guidance on prerequisites such as requiring an account or a valid location.

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?

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered; the description earns credit for disclosing WHAT is destroyed (readings, commands, actuators, alerts) and that the operation is irreversible, which annotations do not convey. It stops short of noting authorization requirements or confirmation expectations.

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 short sentences, zero filler, with the action and its cascade scope front-loaded and the irreversibility warning placed last where it reads as a caution. Nothing is redundant with the title.

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 values need not be explained, and the description covers both the blast radius and irreversibility for a destructive operation. Missing only permission/confirmation context, which is a modest gap for a single-parameter delete tool.

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?

Only one parameter (crop_id) at 100% schema description coverage including the 24-hex pattern, so the schema does the heavy lifting. The description only implies the parameter selects which crop to delete, adding no format or validation detail beyond the schema.

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 verb ('Elimina') and resource ('el cultivo') and goes further by enumerating the cascade scope (lecturas, comandos, actuadores, avisos). No sibling tool performs deletion, and the cascade detail separates it unambiguously from update_crop.

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 only implied by the destructive verb — an agent can infer this is the tool for removing a crop, but there is no explicit when-to-use guidance, no note on prerequisites or confirmation, and no mention of alternatives (e.g. deactivating via update_crop instead of permanent deletion).

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?

Annotations already declare this as read-only, idempotent, and closed-world. The description adds that it returns the connected account's name and email, but does not cover authentication behavior, error cases, or rate limits; with output schema present and annotations covering safety, this is adequate.

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 concise sentence with no wasted words, front-loading the returned information and connection scoping.

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 zero-parameter read tool with annotations and an output schema, the description gives sufficient context: it states exactly what data is returned and whose account it is.

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 tool has zero parameters, so there are no parameter semantics to explain. Baseline for zero-parameter tools is 4.

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 identifies the resource as the SmartPot account tied to the current connection and states the returned fields, name and email. It lacks an explicit verb and does not explicitly differentiate from siblings, though no sibling account tool exists.

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 phrase 'esta conexión'—it retrieves the account associated with the current connection. There is no explicit when-to-use guidance, prerequisites, or alternatives, but the zero-parameter read context makes the intent 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?

Annotations already cover readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is handled. The description adds value by telling the agent the response contains automation, health and last-reading sections, which is behavioral context useful for deciding when this call replaces several narrower ones. It omits failure behavior (e.g., unknown crop_id).

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 front-loaded sentence with the verb and resource first and the payload contents after; no filler or redundancy.

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?

With an output schema, full annotation coverage and a fully described parameter, the description is sufficient to call the tool correctly. The only missing piece is guidance on how this differs from specialized siblings like get_crop_insights or get_latest_reading.

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% and the single parameter crop_id is documented with its hex-24 pattern, so the schema does all the work. The description adds no additional meaning about the identifier, which is acceptable at the baseline for fully covered schemas.

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 verb ('Devuelve el detalle') and resource ('un cultivo') and enumerates the detail sections (lugar, automatización, salud, última lectura), which implicitly separates it from get_crop_weather, get_crop_insights and get_latest_reading. It never names those siblings explicitly, so the differentiation is inferred rather than stated.

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 when-to-use instruction and no reference to alternatives, even though the sibling list contains several adjacent reads (get_crop_insights, get_crop_weather, get_latest_reading). The word 'detalle' implies a full-record fetch versus a specialized read, but the agent must infer the choice.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds that results are AI-generated diagnostic content (health index, conclusions, forecast), but says nothing about whether the analysis is cached/stale, how expensive the inference is, or whether it needs fresh readings.

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?

One short sentence, front-loaded with what the tool is and immediately followed by the returned content. Efficient, though it is terse enough that some operational context is missing.

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 values need no explanation, and the single parameter is fully documented. The remaining gap is usage/routing guidance relative to the many sibling read tools, which the description does not address.

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?

There is a single required parameter with 100% schema description coverage (24-char hex identifier), so the schema fully documents it. The description adds no meaning beyond that, which is acceptable at this coverage level.

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 names the resource (SmartPot-AI diagnostic) and enumerates the concrete payload — health index 0-100, conclusions, suggested actions, forecast — so an agent can tell this is an AI-derived analysis rather than raw readings. It is clear but does not explicitly contrast with siblings like get_crop or get_readings_summary.

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 statement of when to call this versus get_crop, get_overview, or get_readings_summary, and no prerequisites (e.g., minimum readings needed for a meaningful diagnosis). Usage must be inferred entirely from the name.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so safety behavior is covered. The description adds only the content scope ('optimal ranges by crop type') and does not describe return format, units, or whether all crop profiles are returned.

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 front-loaded sentence fragment with zero wasted words. It is appropriately sized for a zero-parameter lookup tool.

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 this may be sufficient, but with no output schema the description could do more to explain what the returned profiles contain and how they relate to sibling tools. It does not state whether the profiles are returned for all crop types or only referenced by type.

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 tool has zero parameters, so parameter semantics are minimal. The schema already communicates this via an empty properties object, and the description appropriately does not invent parameter details.

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 the resource content clearly: recommended optimal ranges by crop type, which adds meaning beyond the tool name and title. However, it does not explicitly say that the tool returns these profiles or distinguish it from siblings such as get_crop or get_crop_insights.

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 when-to-use or when-not-to-use guidance, nor any comparison to alternative tools. The agent can infer a simple lookup, but the description provides no routing criteria against siblings like get_crop, list_crops, or get_crop_insights.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds the location prerequisite, but says nothing about where the weather comes from, whether it is cached/live, or how failure is surfaced when no location 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?

One short sentence with the subject front-loaded and the constraint tucked into a parenthetical — nothing wasted. It is borderline terse given the unstated failure semantics, but there is no filler to cut.

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 single-parameter read with full schema coverage and annotations, the essentials are present: what it returns (current weather) and the precondition. The main gap is error behavior when the crop has no location, which is the one thing an agent realistically needs and cannot infer from structured fields.

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?

With a single required parameter and 100% schema description coverage, the schema already carries the semantics (24-char hex crop identifier). The description only implies the crop reference via 'del cultivo' and adds no format or validation detail beyond the schema, so baseline 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?

States a specific resource and scope: current weather at the crop's location, which is clearly distinguishable from sensor-reading siblings like get_latest_reading and get_metric_series. It never names an alternative tool, so differentiation is inferred rather than explicit.

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 parenthetical gives one real precondition (the crop must have a location), which is useful selection criteria. Otherwise there is no guidance on when to prefer this over get_latest_reading or get_crop_insights, and no statement of what happens when the precondition fails.

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?

Annotations already establish that this is a read-only, idempotent, closed-world operation. The description adds only that it covers all crops in the account, but does not explain what the comparison includes, how results are structured, or any behavioral constraints beyond the annotations.

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 short sentence with no wasted language. It is appropriately concise, though its terseness contributes to ambiguity elsewhere.

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?

With no output schema and a vague term like 'comparativa', the description should explain what data the comparison returns. As written, an agent cannot tell whether it returns aggregate metrics, rankings, or something else.

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 tool has zero parameters, so there are no parameter semantics for the description to compensate for. The baseline for a no-parameter tool is 4.

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 says it provides a comparison of all crops in the account, which clarifies the misleading tool name 'get_fleet'. However, 'comparativa' is vague about what is actually compared or returned, so the purpose is only partially clear.

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 does not state when to use this tool instead of siblings such as list_crops, get_crop, get_overview, or get_readings_summary. The account-wide crop comparison scope implies some usage, but no explicit guidance is given.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so safety and repeat-call behavior are covered. The description adds nothing beyond that — not whether a crop with no readings errors or returns empty, nor how fresh the 'latest' reading may be.

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 front-loaded sentence with no filler. It is efficient, though efficiency here partly reflects under-specification rather than disciplined editing.

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 the enumerated metrics in the description are largely redundant with structured data. Combined with complete annotations, the definition is minimally sufficient, but it omits behavioral details (empty-state handling, staleness of 'latest') that an agent would want before calling.

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?

With one parameter and 100% schema description coverage (crop_id documents the 24-char hex format), the schema carries the full burden and baseline 3 applies. The description adds no meaning about crop_id or its scoping effect on the result.

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 restates the title ('Última lectura') and enumerates the sensor metrics returned (temperatura, humedad, luz, pH, TDS, presión, humedad del sustrato). This tells an agent it retrieves the most recent reading and roughly what fields come back, but it never uses a verb and gives no explicit contrast with siblings like get_readings_history or get_readings_summary.

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 statement of when to call this versus get_readings_history, get_readings_summary, or get_metric_series. The word 'última' hints at recency, but no condition, prerequisite, or exclusion is spelled out.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds that the payload includes sample data and model version, which is useful, but says nothing about freshness, caching, or whether it can be slow/expensive.

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 short sentence with no filler, and the key noun (aprendizaje continuo) is front-loaded. It is terse enough that the parenthetical is doing real work, though one more clause about scope would not have been waste.

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 zero-parameter read tool with no output schema, the description gives the essentials: it is a status read and it contains sample and model-version information. A little more on what 'estado' comprises (e.g. counts, last-updated) would make it fully self-sufficient.

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 tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline of 4 applies; the parenthetical does clarify the shape of the return payload rather than any input.

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 names a specific resource ('aprendizaje continuo de la IA') and clarifies what the status covers ('muestras y versión de modelos'), so an agent knows it returns learning-sample and model-version info. It does not need sibling differentiation because no sibling tool overlaps with this domain, but it also doesn't name an alternative.

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 call this versus other status/insight tools such as get_crop_insights or get_overview. The description states what the tool is but not the situation that should trigger it.

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?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description usefully adds that results are aggregated per interval across all crops (no per-crop filtering) via TimescaleDB, but says nothing about result shape, bucket alignment, or empty-window behavior despite an output schema existing.

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 front-loaded sentence with the aggregation scope stated first and the TimescaleDB note parenthetical. No waste, though the parenthetical implementation detail is of limited value to an agent.

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 output schema covers return values and annotations cover safety, so the description's burden is lighter, but for a tool sitting among many overlapping reading/aggregation siblings it should state the select-this-when condition. The metric enum semantics are left entirely unexplained.

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 50%: 'hours' is documented in the schema (1-168), but 'metric' has only an enum with no explanation. The description hints at 'una variable' and 'por intervalo', mapping loosely to the two parameters, but adds no detail about the metric options or the returned averaging window beyond the schema.

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 specifically that it returns per-interval averages of a single variable aggregated across all crops (TimescaleDB aggregates), which is a clear resource+operation. It implicitly contrasts with per-crop reading tools but never names a sibling to confirm the boundary.

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 guidance on when to use this instead of get_readings_history, get_readings_summary, or get_latest_reading, all of which sound closely related. The agent must infer from the word 'promedios' that this is the downsampled/aggregated option.

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?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety is covered. The description adds useful context that this is an aggregated snapshot spanning several domains rather than a single resource, but says nothing about cost, caching/freshness, or permission scope for a broad account-wide read.

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 front-loaded sentence with no filler, listing the domains in a logical order. It is terse to the point of being a fragment (no verb like 'devuelve'), but nothing is wasted.

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 output schema carries the return shape, so the description needn't explain fields. What's missing is routing guidance among many overlapping read tools — the main thing an agent needs to call this correctly — leaving the definition adequate but with a clear 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?

Zero parameters and 100% schema coverage, so there is nothing for the description to disambiguate. Baseline 4 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?

Names the resource (cuenta) and enumerates what the rollup contains (cultivos, salud, dispositivos en línea, comandos, avisos), which makes the composite/dashboard nature clear. It stops short of distinguishing itself from siblings like get_account, get_fleet or get_readings_summary, which an agent could easily confuse with it.

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 statement of when to prefer this over get_account or the per-domain tools (list_crops, list_notifications, get_readings_summary). An agent must infer that this is the one-call snapshot and the others are drill-downs.

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?

Annotations already declare read-only, idempotent, and closed-world behavior, so the description need not repeat safety. It adds useful behavioral context by specifying descending chronological order, but omits pagination/default-limit behavior and what happens when from_time or to_time are omitted.

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?

One compact sentence with no wasted words, front-loading the resource, date-range scope, and ordering. It is appropriately sized for a straightforward read tool.

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 output schema covers return values and annotations cover safety, reducing the description's burden. However, with four parameters and only 25% schema description coverage, the description leaves optional-parameter and pagination behavior underspecified for a history endpoint.

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 low at 25%. The description explains the date-range concept, which maps to from_time/to_time, but does not explain crop_id, the limit default, or the semantics of null date bounds, so it leaves significant parameter meaning to the schema.

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 resource (crop readings) and scope (a date range), and adds the ordering (most recent to oldest). It distinguishes itself implicitly from get_latest_reading, but does not explicitly name sibling tools or contrast with get_readings_summary.

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 historical retrieval over a date range but gives no explicit when-to-use guidance, no alternatives, and no exclusions. It does not tell the agent when to prefer get_latest_reading or get_readings_summary.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered elsewhere. The description adds that output is aggregate statistics over a time window rather than raw samples, which is genuinely useful, but it says nothing about aggregation granularity (per sensor? per variable across sensors?) or behavior when no data exists in the window.

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 short sentence with no filler, and the core payload (min/avg/max per variable) is front-loaded. It is terse to the point of being a fragment, but nothing is wasted.

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 explained, and annotations cover safety. Still, for a tool whose value depends on the aggregation window and scope, the description never mentions the default 24h window, the 168h maximum, or whether results are per-sensor or per-crop, leaving the agent to rely entirely on structured fields.

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%: both crop_id (24-char hex) and hours (1–168, default 24) are documented in the schema. The phrase 'últimas horas' hints that the window is configurable but adds no detail beyond the schema's default and bounds, so baseline 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 fragment identifies the computed statistics (minimum, average, maximum) per variable over a recent time window, which is more informative than the name alone. However, it omits a verb and never distinguishes itself from siblings that also return measurement data, such as get_readings_history or get_metric_series, so an agent must guess which one to call.

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 statement of when to use this tool versus get_latest_reading, get_readings_history, or get_metric_series. The only implicit context is 'últimas horas', which loosely implies a recent-window aggregate, but no exclusions or prerequisites are given (e.g. whether the crop must have readings).

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is fully covered structurally. The description adds nothing beyond that — no statement about what counts as unread, whether the count is scoped to the caller, or whether it is cached/live. For a trivial zero-parameter read, this is adequate but thin.

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 short sentence with no filler, appropriate for a trivial read tool. It is front-loaded with the one fact that matters, though it is terse to the point of omitting the tool's domain context.

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?

There is no output schema, and the description compensates by indicating the return is a quantity ("Cantidad"), which is exactly the one thing an agent needs to know about the response. Given zero parameters and full annotation coverage, only the missing scope/usage context keeps it below a 5.

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 tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate at the input level. No filtering options are implied or needed.

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 concrete resource and metric: the count of unread notifications. That is distinguishable in kind from list_notifications (which returns items) without opening the schema. It stops short of naming that sibling or the notification domain explicitly, but the purpose is unambiguous.

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 call this versus list_notifications or get_overview, both of which likely surface notification information. No prerequisites, no exclusions, no mention of scope (per-user vs global unread). The agent must infer usage entirely.

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?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety is covered. The description adds that the result reports on/off state per device, which is useful, but says nothing about empty results, unconfigured actuators, or behavior for an unknown crop_id.

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?

One short sentence with the resource and return state front-loaded. The parenthetical device enumeration earns its place by defining what counts as an actuator, though it dominates the sentence's length.

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 single-parameter read tool with full schema coverage, complete annotations and an output schema, the description covers the essentials: what is listed and what state is reported. Only edge-case behavior (empty list, invalid crop) is unaddressed, which is minor here.

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% and the single crop_id parameter is fully documented with a regex pattern in the schema. The description only implies scoping to a crop via 'del cultivo' and adds no format or constraint information beyond that, so baseline 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?

States a concrete resource (crop actuators) plus the enumerated device types and the returned state (on/off), so the agent knows exactly what the list contains. It does not, however, explicitly contrast itself with siblings such as get_crop or list_commands.

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 only implied: an agent infers this is the read path for actuator state while send_actuator_command is the write path, but the description never says so or gives any condition or exclusion.

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?

The annotations already declare readOnlyHint, idempotentHint, and closed-world behavior, so the safety profile is covered. The description adds the command status values and origin, which is useful domain context, but says nothing about ordering, pagination, or how recent the results are.

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 front-loaded sentence with no filler, and the status enumeration is compact and useful. It is appropriately sized for a simple list tool, though it omits a few practical details that a slightly longer definition could have included.

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?

Because an output schema exists and the annotations cover read-only/idempotent behavior, the description does not need to explain return values or safety. It is still incomplete for a list tool: it omits the limit behavior, result ordering, and any usage distinction from sibling tools.

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 only 50%: crop_id is documented in the schema, but limit has no description. The description implies crop scoping but does not explain the limit parameter or otherwise compensate for the undocumented 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 identifies the resource ('comandos recientes del cultivo') and adds useful detail about status values and origin. It is distinguishable from send_actuator_command and send_bulk_command because it is about recent command history rather than issuing commands, though it never explicitly says 'list'.

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 on when to use this tool versus alternatives, and no stated exclusions or prerequisites. The intended use (checking recent command history for a crop) is only implied by the phrase 'comandos recientes'.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so safety and idempotency are covered. The description's only additional value is enumerating the summary fields returned, which is largely redundant given an output schema exists; it says nothing about ordering, volume, or pagination.

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 front-loaded sentence with no filler; the scope (account) and returned fields come first. It is arguably too terse rather than too long, leaving no room for the when-to-use guidance it lacks.

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?

With zero parameters, rich annotations and an existing output schema, the definition gives an agent everything needed to invoke it correctly. Only the sibling-routing guidance is missing, which is a minor gap at this complexity level.

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 tool takes zero parameters, so no parameter explanation is required and the schema is trivially complete. Nothing in the description misleads about inputs.

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 verb and resource ('Lista los cultivos de la cuenta') plus the fields each entry carries (tipo, forma, salud, estado del dispositivo, última lectura), so an agent knows this is a summary listing of all crops. It does not explicitly contrast with get_crop or get_fleet, but the plural-scope wording makes the distinction inferable.

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 only implied: the plural 'cultivos de la cuenta' suggests this is the browse-all entry point, but the description never says when to prefer it over get_crop (single crop) or get_fleet. No prerequisites, no exclusions, no named alternatives.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered without the description. The description adds the useful detail that results span multiple notification types, but says nothing about ordering, pagination, or volume — relevant since there is no output schema.

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?

It is a single short fragment with zero waste, but it is under-specified rather than concise: no action verb, no front-loaded purpose statement, and it is written in Spanish while all sibling tool names and most agent-facing context are English.

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 list tool with no output schema, the description should say roughly what comes back (fields, read/unread state, ordering) and how it differs from get_unread_count and mark_notification_read. None of that is present, leaving the agent to call it blind.

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 tool takes zero parameters, so the schema imposes nothing to explain; baseline 4 applies. The description correctly implies no filtering inputs are needed.

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 names the resource (account notifications) and enumerates the notification categories it covers — AI alerts, commands, devices — which helps distinguish it from siblings like list_commands or get_unread_count. However, it is a noun fragment with no verb: it never states that it *lists* or returns them, leaving the action to be inferred from the tool name.

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 call this versus get_unread_count or mark_notification_read, no mention of prerequisites, and no exclusions. The agent must guess from the tool name alone.

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?

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, so the safety profile is covered by structured data. The description adds nothing beyond that — it does not say whether an invalid or already-read notification causes an error, nor what the call returns.

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?

One short sentence with nothing wasted, but it largely restates the tool name, so it barely earns its place. It is appropriately sized for a single-parameter mutation, just not informative.

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 one-parameter mutation with full schema coverage and annotations, the minimum viable information is present. Still missing is any statement about error conditions or the effect on an already-read notification, which an agent would want before invoking.

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%, and the single parameter is fully documented in the schema including its 24-character hex pattern. The description contributes no additional meaning about the identifier, so the baseline 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 states a specific verb and resource ('Marca una notificación como leída'), which maps cleanly to the tool name and tells an agent exactly what state change occurs. It does not, however, distinguish this from siblings like list_notifications or get_unread_count beyond the obvious verb difference.

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 call this versus the other notification tools, no mention of prerequisites, and no note about behavior when the notification is already read. Usage must be inferred entirely from the name.

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?

Annotations already declare readOnlyHint=false and destructiveHint=false, so the write nature is covered. The description adds only the 'at least one variable' validation rule and does not explain duplicate handling, permissions, or other behavioral traits.

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 front-loaded sentence with zero waste. The verb leads and the key constraint follows immediately.

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 an eight-parameter mutation tool with only 13% schema description coverage, one sentence is not enough. Output schema and annotations reduce burden for return values and safety, but parameter meanings and usage context remain largely undocumented.

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 very low (13%), so the description must compensate. It adds the critical rule that at least one measurement variable must be supplied, but it does not explain units or meaning for the eight fields.

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 verb and resource: registers a manually taken measurement. The parenthetical adds a key constraint. It does not differentiate from siblings like get_latest_reading or get_readings_history, but the purpose is clear.

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 no guidance on when to use this tool instead of alternatives, no prerequisites, and no exclusions. Usage is only implied by 'manual measurement'.

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?

Annotations already declare destructiveHint=true and openWorldHint=true, but the description adds a mandatory human-confirmation step and the physical/MQTT nature of the effect that no structured field states. It does not cover what happens on an already-active actuator or whether commands can be reversed.

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 short sentences, front-loaded with the action and immediately followed by the risk warning. Nothing is padded and no sentence is redundant.

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 values needn't be explained, and annotations carry the safety profile, but for a destructive real-hardware mutation with 4 parameters the description is thin. It omits duration semantics (is null an indefinite ON?), failure behavior, and any single-vs-bulk routing.

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?

With only 50% schema description coverage, the description needs to compensate and does not: it never mentions the action enum, the IDs, or the optional duration_seconds window and its default of null. The one genuinely ambiguous parameter (duration) is left entirely to the schema.

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?

Names a specific verb pair (enciende/apaga) and resource (un actuador) plus the transport (MQTT), so the agent knows exactly what the call does. It stops short of distinguishing itself from the sibling send_bulk_command, which is the main neighbouring ambiguity.

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 statement of when to prefer this single-actuator call over send_bulk_command, nor any exclusion or precondition beyond a bare imperative to confirm. The one actionable hint ('confirma antes') is a safety instruction rather than routing 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?

Annotations already declare a destructive, non-idempotent write. The description adds genuine value by disclosing the sent/skipped/failed result breakdown, which hints at partial-failure semantics, but says nothing about permissions, what a 'skipped' crop means, or whether partial application is rolled back.

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 front-loaded sentence with no filler; the effect and the return shape are stated in one pass.

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 destructive bulk mutation affecting up to 50 crops, the description is thin. The output schema covers return values and annotations cover the safety profile, but nothing explains duration_seconds behavior, partial-application consequences, or limits, which an agent needs before firing a bulk actuation.

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, and it does not. It conveys only that one actuator type is applied uniformly, leaving action, crop_ids (max 50, 24-hex format), and especially duration_seconds entirely unexplained in the 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?

States a specific verb and resource: it actuates the same actuator type across multiple crops in one call. The plural scope ('varios cultivos') implicitly distinguishes it from the single-crop send_actuator_command sibling, though it never names that alternative.

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 on when to use this versus send_actuator_command, no prerequisite or permission notes, and no exclusions. Usage is only inferable from the word 'varios'.

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?

Annotations already declare non-read-only, idempotent, non-destructive, closed-world behavior. The description adds useful context that the toggle affects an AI agent driving physical crop actuators, which is important for a mutation tool, but it does not spell out permissions, immediate effects, or failure behavior.

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 front-loaded sentence with no filler. It is appropriately sized for a simple two-parameter toggle.

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 toggle with annotations covering the safety profile, this is largely sufficient. However, because it changes autonomous control of actuators, the description could clarify immediate operational consequences and permission requirements.

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 50%; crop_id is documented in the schema, while enabled lacks a schema description. The description's 'activa o pausa' helps map enabled to the toggle state, but does not add detail about crop scope or side effects.

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 verb pair (activate/pause) and resource (the AI agent that drives crop actuators), so intent is clear. It does not explicitly distinguish this from sibling commands like send_actuator_command, but the automation-level toggle is inferable.

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?

Gives no explicit when-to-use guidance, prerequisites, or alternatives; it only states what the toggle does. An agent must infer that this is for enabling/disabling autonomous actuator control rather than issuing a direct command.

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?

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds a genuinely behavioral rule not in the annotations: "Los campos omitidos conservan su valor actual", disclosing that this is a partial (PATCH-style) update rather than a full replace. It leaves one real ambiguity unaddressed — the schema accepts explicit null for every field, and the description does not say whether null clears a value or counts as omitted.

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 short sentences, zero filler, with the mutation scope stated first and the partial-update rule second. Nothing restates the title or wastes tokens.

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 9-parameter mutation with an output schema already defined, the description is adequate but thin: it explains the default-null = keep-current rule and names four field groups, yet ignores setting/exposure coordinates entirely and says nothing about behavior when crop_id does not resolve. Enough to call the tool, not enough to call it confidently on every parameter.

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 only 11% (only crop_id is documented in the schema), so the description carries most of the burden. It partially compensates by grouping the mutable fields (nombre, tipo, forma, lugar) and by explaining the default=null semantics as "unchanged", but it never mentions setting, exposure, latitude/longitude or place_name by name, leaving half the parameters to be inferred from enum values and min/max alone.

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?

"Cambia nombre, tipo, forma o lugar del cultivo" gives a clear verb (Cambia) plus the resource (cultivo) and enumerates the mutable aspects, so an agent distinguishes it from get_crop/list_crops at a glance. It stops short of naming siblings such as create_crop or delete_crop explicitly, and it silently omits the setting/exposure/latitude/longitude fields, so it is not a full 5.

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 only implied: the imperative "Cambia..." signals the edit operation on an existing crop, and the fact that only crop_id is required makes the intent inferable. There is no explicit when-to-use, no precondition (e.g. crop must already exist), and no pointer to set_crop_automation or delete_crop as alternatives for other modifications.

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