USDA hardiness zone, frost dates and vegetable planting calendar for any U.S. ZIP code.
Scored across 4 tools
The four tools target distinct gardening queries: frost dates, planting calendar, hardiness zone, and current planting windows. There is minor overlap between get_planting_calendar and what_to_plant_now since both deal with crop timing, but their descriptions clarify that one returns a schedule and the other filters by current date.
Three tools follow a clear get_<resource> pattern (get_frost_dates, get_planting_calendar, get_zone_by_zip). what_to_plant_now deviates as a natural-language phrase but remains readable and consistent in snake_case.
Four tools are well-scoped for a focused U.S. grow-zone lookup service. Each tool earns its place by covering a distinct user question without excessive surface area.
The tool set covers the core domain: hardiness zone, frost dates, planting schedule, and current planting recommendations. No obvious lifecycle gaps exist for a read-only reference server of this kind.
Use this when the user asks for the average last spring frost, first fall frost, or growing season length for a U.S. ZIP code (or a city + state). Returns NOAA 1991-2020 frost dates (10/30/50% probability) and a source link to cite.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | No | 5-digit U.S. ZIP code, e.g. 30301 | |
| city | No | City name (optional, instead of zip) | |
| state | No | 2-letter state code, with city |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive). The description adds meaningful behavior beyond them: the NOAA 1991-2020 data source, the 10/30/50% probability levels returned, and that a source link is included for citation.
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, zero waste: the usage trigger comes first, the return content second. Nothing is repeated from the schema or annotations.
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, the description must say what comes back, and it does: frost dates at 10/30/50% probability plus a citation link. For a simple read-only lookup with fully described parameters, nothing an agent needs is missing.
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 earns an extra point by clarifying that a ZIP code OR a city+state combination are alternative input modes, which the individual parameter descriptions do not frame as alternatives.
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+resource (returns average frost dates / growing season length) and scope (U.S. ZIP, NOAA 1991-2020). It is distinguishable from siblings like get_planting_calendar, though it never names or contrasts them explicitly.
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?
"Use this when the user asks for the average last spring frost, first fall frost, or growing season length" gives a clear trigger condition. It does not state when not to use it or name alternatives such as get_planting_calendar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks when to start seeds indoors, transplant, direct sow or plant a fall crop for vegetables at a U.S. ZIP code. Optionally pass one crop; otherwise returns all supported crops. Includes a source link to cite.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | Yes | 5-digit U.S. ZIP code, e.g. 30301 | |
| crop | No | Optional crop slug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world and non-destructive, so safety is covered. The description adds behavior beyond that: the US-only scope, that omitting crop returns all supported crops, and that a source link is included for citation — useful operational context an agent would not otherwise know.
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 tight sentences with no filler. The usage trigger is front-loaded before the optionality and return detail, which is the right order for an agent scanning for relevance.
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 two-parameter read-only tool with full schema coverage and no output schema, this is nearly complete: it conveys scope, trigger, default behavior, and that a citation link comes back. The only minor gap is not hinting at the shape of the timing output (e.g., which stages are returned per crop).
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, but the description adds real meaning: crop is explicitly optional and omitting it changes the result set to all supported crops, which is the key semantic an agent needs. ZIP constraints and the crop enum are already fully documented in 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-and-resource ('planting calendar' returning seed-start/transplant/sow/fall-crop timing) scoped to a U.S. ZIP code, which is much more concrete than the title alone. It does not explicitly distinguish itself from the sibling what_to_plant_now, which sounds adjacent, so it stops short of 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?
Gives a strong trigger condition: 'Use this when the user asks when to start seeds indoors, transplant, direct sow or plant a fall crop.' It also clarifies the optional-crop behavior. It offers no exclusion telling the agent when to prefer get_frost_dates, get_zone_by_zip, or what_to_plant_now instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks what USDA plant hardiness zone (e.g. 7a) a U.S. ZIP code is in, or the average extreme winter low there. Returns the 2023 USDA zone, temperature range and a source link to cite.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | Yes | 5-digit U.S. ZIP code, e.g. 30301 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive and openWorld=false, so the safety profile is covered. The description adds value the annotations cannot: it states the data vintage (2023 USDA zone) and that a citable source link is returned, which matters for an agent that must attribute output.
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: trigger first, return payload second. Zero filler and the most decision-relevant information is front-loaded.
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, read-only lookup with full schema coverage and annotations, nothing an agent needs is missing. Because there is no output schema, the description correctly compensates by enumerating what comes back (zone, temperature range, source link).
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% — the single `zip` parameter is documented with a pattern and an example. The description confirms the U.S. ZIP context but adds no format or edge-case 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?
Names a specific verb+resource (USDA plant hardiness zone for a U.S. ZIP) and even gives the output shape (e.g. 7a). The scope is unmistakably distinct from the frost-date, planting-calendar and what-to-plant siblings without needing to name them.
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?
Opens with an explicit trigger: 'Use this when the user asks what USDA plant hardiness zone ... a U.S. ZIP code is in, or the average extreme winter low there.' It gives clear positive context but names no exclusions or alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks what vegetables they can plant or start now (or on a given date) at a U.S. ZIP code. Returns crops whose planting window is open, plus what opens in the next 30 days, and a source link to cite.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | Yes | 5-digit U.S. ZIP code, e.g. 30301 | |
| date | No | Optional date YYYY-MM-DD (default: today, UTC) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, closed-world safety, so the description only needs to add value — and it does: it discloses the 30-day forward lookahead and that a citable source link is included, which the agent cannot know from any structured field. It doesn't mention data freshness or what happens for unsupported ZIPs, keeping it short of a 5.
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?
Single tight sentence that front-loads the trigger, then the return shape. Every clause carries information: trigger, scope, output, and citation affordance — no 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?
There is no output schema, so the description must convey the return value, and it does: open-window crops, next-30-day openings, and a source link. Missing only edge-case behavior (e.g., invalid or unsupported ZIP, non-U.S. locations) that would fully prepare an agent.
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 both parameters (zip pattern, optional YYYY-MM-DD date defaulting to today) are fully documented there. The description adds only the semantic framing that the date means 'the day you're asking about,' which is marginal beyond the schema — baseline 3.
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 question it answers ('what vegetables they can plant or start now'), the scope (U.S. ZIP code), and the return (open windows plus 30-day lookahead). It doesn't explicitly distinguish itself from sibling get_planting_calendar, so an agent must infer the difference between 'now' and 'full calendar'.
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 a concrete trigger condition ('when the user asks what vegetables they can plant or start now (or on a given date)'), which is strong usage guidance. It names no exclusions or alternatives, so the agent is not told when to prefer get_planting_calendar instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_frost_datesget_planting_calendarget_zone_by_zipwhat_to_plant_nowClimate timing for gardens and small farms: frost, heat, soil and planting dates for your plot.
Search crops, check companion planting, explore seasonal calendars, and find planting plans.
US ZIP code intelligence: demographics, weather, tax, crime, housing, voting, and more.
Your garden notebook: ask about your beds, plantings, harvests and frost dates, and log your work.
Add one secure layer between your agents and this server.
