Diagnoses a single planting by retrieving its logged coordinates and recent/forecast weather, then flags frost, heat, water, and wind stress.
Diagnose one planting: pulls its coordinates from the log, fetches recent and forecast weather, and flags frost / heat / water / wind stress.
| Name | Required | Description | Default |
|---|---|---|---|
| past_days | No | ||
| planting_id | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full load; it usefully discloses the internal pipeline (reads coordinates from the log, fetches both recent and forecast weather) and that it is an analysis/flagging operation rather than a mutation. It stops short of stating that it is read-only, that it depends on an external weather service (latency/failure modes), or what happens when a planting lacks coordinates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence that front-loads the scope and then the pipeline steps in execution order, with zero filler.
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?
No output schema and no annotations, so the description should say more about the shape of the diagnosis (per-stressor flags? severity? text summary?) and about the configurable lookback. It adequately conveys the overall mechanism but leaves the return value and one of two parameters 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%, so the description must explain the two parameters and largely does not: `planting_id` is only implied by "one planting", and `past_days` (default 7, range 3-92) is never addressed beyond the vague word "recent". An agent gets no hint that the lookback window is configurable.
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 ("Diagnose one planting") and enumerates the concrete outputs (frost/heat/water/wind stress), so the agent knows exactly what the call produces. The word "one" signals single-planting scope, though no sibling is named to contrast with.
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 "one planting" and by the fact that it depends on a logged planting with coordinates, but there is no explicit when-to-use or when-not guidance and no alternative tool (e.g. get_weather directly) is mentioned for cases where a full diagnosis isn't needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.